Install swell on a Linux Appliance

Network and security appliances run Linux, they are a favorite target, and most of them will not accept an endpoint agent at all. swell closes that gap: a single self-contained binary and a scheduled job give you a recurring sweep of the device's filesystem, with every new file sent to Stairwell for analysis. This page covers installing it that way.

Attackers know which devices have no agent on them. A VPN concentrator, a load balancer, a management appliance, and a firewall are all business-critical, all reachable from outside, and all places where a webshell can sit for months because nothing on the device is looking. Stairwell worked this exact case with a customer during the Citrix CVE-2023-3519 activity, where the artifacts on the appliance were the only evidence available: Stairwell identifies unseen attack methods in Citrix CVE-2023-3519.

Why run swell on a schedule instead of installing an agent?

Because on these devices an agent is usually not an option, and a scheduled binary is.

• Nothing to install. swell carries its own dependencies. There is no package to add to a vendor-supported image and no kernel module in play.
• You control the cost. The sweep runs when you say, at the concurrency you say, skipping files above the size you say. On an appliance with a tight CPU budget, that is the difference between viable and not.
• It comes off as fast as it went on. Removing the scheduled job takes one command, which also makes this reasonable to run as a one-off during an incident and then stop.
• Analysis happens out of band. swell sends files to Stairwell and Stairwell analyzes them there. Nothing on the appliance is quarantined, blocked, or deleted, so a false positive cannot interrupt the traffic the device is carrying.

The honest limit: this is a periodic sweep, not continuous monitoring. You learn that a file appeared by the next run, not the moment it lands. For an appliance that previously had no file visibility at all, a nightly answer is a large improvement over none, and picking the cadence is the whole design decision.

What do I need before I start?

• Shell access to the appliance, and somewhere writable to put a binary.
• The ability to run a scheduled job on it, usually cron.
• Outbound HTTPS on port 443 from the appliance to Stairwell. Appliances often sit in a segment with tighter egress rules than a workstation, so check this before anything else.
• An auth token and the ID of the environment the appliance belongs in.

How do I install it?

Get the Linux binary from swell Downloads. Downloads are date-pinned, so the URL carries the release date:

https://downloads.stairwell.com/swell/<YYYYMMDD>/swell-linux-amd64

Put it somewhere that survives a reboot and, if the vendor's firmware update process replaces the filesystem, somewhere you will remember to reinstate afterward.

$ chmod +x swell-linux-amd64
$ sudo mv swell-linux-amd64 /usr/local/bin/swell

Then check the network from the appliance itself, because this is the host where egress rules are most likely to differ from the rest of your fleet:

$ swell verify connectivity

Four passes and you can continue. Anything else, Pre-Deployment Check covers each failure.

How do I authenticate and register the appliance?

Log in once, interactively. swell stores the token so the scheduled job does not need it on the command line:

$ swell auth login

Then create an asset for the appliance so its files are attributed to it rather than to a shared default. Give it a name you will recognize in an alert at two in the morning, and record the ID it prints:

$ swell onboard vpn-appliance-01 --environment_id=YOUR_ENVIRONMENT_ID
Created asset: "vpn-appliance-01"
Asset ID: "ASSET_ID"

Getting this right matters more here than on a laptop. An asset per appliance is what makes "which device was this on" answerable later, and a single shared asset for twelve appliances makes it unanswerable.

How do I schedule the sweep?

Test the command by hand first, so the scheduled version is a command you have already watched succeed:

$ swell objects upload --asset=ASSET_ID /

swell walks the path, hashes what it finds, and sends it in. Files Stairwell already holds are recognized and not sent again, so the first run is the expensive one and later runs cost a fraction of it.

Then add it to cron:

$ crontab -e

Five fields set the schedule, followed by the command. To run at 22:20 local time every night:

20 22 * * * /usr/local/bin/swell objects upload --asset=ASSET_ID / >> /var/log/swell.log 2>&1

The fields are minute, hour, day of month, month, and day of week, and * means every value. Redirecting output to a file is not optional in practice: a scheduled job with nowhere to write its errors fails silently, and the first you hear of it is when someone asks why the appliance stopped reporting.

On most systems, whether an account may use cron is controlled by /etc/cron.allow and /etc/cron.deny. If cron.allow exists, the account has to be listed in it; if cron.deny exists, the account must not be listed there.

How do I keep the sweep from loading the appliance?

Three flags, and the cadence.

A narrower path than / is often the better answer. Sweeping the directories where a webshell or a dropped binary would actually land, rather than the whole filesystem, cuts the run time sharply and loses very little. Start broad once to see what is there, then narrow.

Pick the cadence to match the device. Nightly during a maintenance window suits most appliances. Something busy and underpowered may want weekly. During an incident you run it by hand and do not wait for the schedule at all.

How do I confirm it is working?

The morning after the first scheduled run:

1. The appliance appears under Assets with the name you gave it. See Assets.
2. Objects attributed to that asset are arriving.
3. /var/log/swell.log, or wherever you sent the output, ends with no failed paths. swell objects upload exits non-zero and names every path it could not send, so this is a real check rather than a glance.

Once files are flowing, the appliance is a first-class part of your environment: YARA rules apply to what it holds, and searches across your fleet include it.

How do I remove it?

Delete the cron entry and delete the binary. That is the whole reversal, and it is why this is reasonable to run as a temporary measure during an incident.

$ crontab -e
$ sudo rm /usr/local/bin/swell
$ swell auth logout

Run the logout before removing the binary if you want the stored credentials gone from the appliance, which on a device in a hostile segment you generally do.

What should I read next?

• swell Command Reference, for every flag on objects upload.
• swell Configuration, for storing the environment and asset settings instead of typing them.
• Pre-Deployment Check, for what to do when the connectivity check fails.