Frequently asked questions

PHP webshells and loaders, known malware by signature and by hash, and the configuration tricks that keep an attacker on a host: handler remapping in .htaccess, auto_prepend_file set from inside a site, PHP dropped into upload directories, image-header polyglots, symlinks pointing out of a home directory, and world-writable or setuid files. Detection uses ClamAV, YARA 4.5, hash sets with a known-good allowlist and heuristics that require several independent signals.

It prevents execution on the web upload path: the PHP adapter runs before your application, and a malicious verdict returns HTTP 403 and deletes the temporary file. Everywhere else — SFTP, the panel file manager, WebDAV, the shell — detection is asynchronous and fast rather than preventive. Blocking a file open at the kernel level is prototyped for a later 1.x release and is deliberately not promised today.

The scan runs in a worker with cgroup limits for CPU, memory and I/O, and the scheduler runs full scans against an I/O budget with configurable backup windows. The upload gate adds at most upload.timeout_ms to an upload request, 2000 ms by default. On our own reference host with 328 accounts and 1.1 TB, a reconciliation crawl ran at roughly 114 scans per minute with two workers and about 270 with four.

It says so. A dead worker, a missing rule set, an unavailable clamd or a namespace fallback puts health into degraded with a named reason, and affected files carry the degraded verdict. A broken scanner never reports clean, and the upload gate follows the on_error policy you configured — fail-open by default, fail-closed if you chose that for the domain.

No file, no sample and no telemetry. Two outbound connections exist: the licence check, which sends the key prefix, a hash of /etc/machine-id, the hostname, the version and the operating system; and the download of signed signature generations. Both terminate on Panomity infrastructure in Germany. Telemetry code is not loaded at all without an explicit opt-in.

CyberPanel on Ubuntu 20.04, 22.04 and 24.04; AlmaLinux, RockyLinux and RHEL 8, 9 and 10; CloudLinux 8; and CentOS 9, with OpenLiteSpeed or LiteSpeed Enterprise. From Shelltrap 0.3.0 also cPanel/WHM on AlmaLinux 8 and 9 and on Ubuntu 22.04 and 24.04, as a beta. Debian is only third-party supported by CyberPanel itself, so we do not promise it. The installer probes the actual host capabilities rather than trusting a kernel version.

Yes, in beta since Shelltrap 0.3.0, on cPanel/WHM servers running AlmaLinux 8 or 9 or Ubuntu 22.04 or 24.04. The daemon detects the platform by itself and builds its site index from the cPanel userdata: main domain, addon domains, subdomains and parked domains. Real-time watcher, all engines, quarantine, per-domain policies, CLI, local API, mail alerts, signed feeds and one licence per server are the same as on CyberPanel. Beta means it is implemented against the cPanel file format and tested against fixtures, without long-running operation on live cPanel hosts behind it yet. Details are on the cPanel page .

Not yet; it is on the roadmap and we are deliberately not giving it a date. On cPanel you drive Shelltrap from the CLI and the local API — the same interface the CyberPanel plugin talks to, so nothing about findings, quarantine, restore or policies is out of reach. The PHP upload gate for EasyApache 4 PHP-FPM exists but is optional and off by default; the real-time watcher sees the same files either way.

How much real-time coverage the host can actually give. Tier A is fanotify with file handles and full coverage. Tier B is fanotify without file handles, so renames arrive with a delay. Tier C has no CAP_SYS_ADMIN and falls back to budgeted inotify plus a checkpointing crawler, with detection delayed and stated as such. Tier D means no usable backend and no installation.

No. Shelltrap runs on the distribution you already have. Not needing an operating system conversion is one of the reasons it exists.

Yes: 14 days free in report-only mode. Every engine runs, signed feeds are downloaded, findings and notifications work — nothing is put into quarantine and the upload gate only reports. It needs a customer account with a confirmed email address; disposable email domains are turned away. Store a payment method in the client area — credit card or PayPal — and the same trial is extended to 30 days from the day it started, with everything except automatic quarantine switched on. Details and conditions are on the trial page .

The daemon stops scanning and stops updating its feeds, in exactly the way an expired licence does: the watcher keeps counting events, the scheduler plans nothing, the upload gate answers allow with the reason unlicensed, and health says unlicensed with a precise cause. Findings, the audit trail and everything already in quarantine stay on your machine and stay visible in the panel and on the CLI. Ordering a licence picks up where the trial left off, on the same server, without reinstalling anything.

One per server and one per customer. The trial is tied to the server fingerprint — a hash derived from /etc/machine-id, the same identifier a paid licence uses — and renewed online once a day, so it runs its course from the day it started rather than from the day the package was last installed. If you need longer for a real reason, such as a maintenance window you cannot move, write to us.

One licence per server, 14.90 EUR per month or 149.00 EUR per year including German VAT, covering every domain and account on that machine. A trial key is the same mechanism with an end date and without automatic quarantine. Activation binds the licence to a fingerprint derived from /etc/machine-id; deactivate releases the slot so you can move it. The daemon verifies an Ed25519-signed token offline, so the licence service does not have to be reachable for the scanner to work.

Nothing crashes and nothing loops. The watcher keeps counting events, the scheduler plans nothing, the upload gate answers allow with the reason unlicensed, health reports unlicensed with a precise cause, and the feed service returns 401. It fails visibly rather than dangerously.

There are none, by design. Packages are served by the licence service against a valid licence or trial key, and the download page has a form for exactly that. The key goes to the licence service directly; this website never sees or stores it, and the service logs only the key prefix.

It can, which is why the defaults are careful: only signature and hash hits quarantine by default, heuristics only report, and PUA signatures are off. A known-good allowlist built from published distribution checksums answers the most common false positives, and every finding shows the signals that produced it so you can argue with it. If a rule generation causes a quarantine storm across several accounts, it is rolled back automatically. When it does get one wrong, reporting it is an automated procedure with an answer in about an hour — see false positives .

Yes, and the restore is complete: owner, mode, times, ACLs, extended attributes and the SELinux context all come back. Restore never overwrites an existing file at the target path. Resellers and customers can request a restore inside their own scope from the panel.

No. A normal removal keeps configuration, state, logs and quarantine. Even a purge only removes quarantined content behind an explicit environment gate that a human has to type. Quarantine is evidence.

Send the finding ID, the rule name and the SHA-256 — all three are in the finding mail — together with the file itself to falsepositive@shelltrap.com , from the email address registered in your client area . The file is re-scanned against the current generation and analysed automatically on our own hardware in Munich, and the answer usually arrives within an hour from sentinel@shelltrap.com . A confirmed false positive is allowlisted by SHA-256 in the next signed feed generation, which is published immediately and picked up by every server at its next feed refresh. The full procedure, including what happens to the file, is on the false positives page .

sentinel@shelltrap.com . Put it on the allowlist of whatever filters your admin mailbox before you switch alerts on. Replies to that address are read, but it is not a support channel: support runs through the client area or hallo@panomity.de , and a suspected false positive goes to falsepositive@shelltrap.com .

There is a local one: HTTP/1.1 over a Unix socket at /run/shelltrap/api.sock, with peer credential checks, roles, opaque object IDs, paging, rate limits and replay protection. It is not reachable over TCP and it is not a public cloud API. The CLI and the CyberPanel plugin both speak it.

It is not a WAF, not a firewall and not an antivirus for desktops. It does not claim to catch everything — no scanner does. And it cannot help against an attacker who already has root on the machine, because nothing running on that machine can.