Security on your box

Most hosting guides hand you a checklist of twenty hardening steps. On BOA the honest version is shorter: the server hardens itself, and your job is a handful of habits that no software can do for you. This page is that split — what's already handled, what's yours, and where to go when you outgrow the basics.

What BOA already does — without being asked

Everything below is on by default on every install, self-maintained across upgrades, and needs no configuration from you:

• A firewall that learns. CSF + LFD watch every port and login attempt, block brute-force sources, and carry port-scan and SYN-flood protection. Your own IP is protected from self-lockout in ways most hand-rolled firewalls never get right — the box allow-lists the addresses you actually connect from.
• A web-traffic guard. Bad bots, scrapers, request floods and vulnerability probes are detected and shed at the Nginx edge before they reach your sites — including a default-deny policy for AI training scrapers. Most attacks end as one line in a log you never need to read.
• Security patches within the hour. SKYNET, BOA's tag-driven auto-update, exists because of a 2014 Drupal exploit that compromised unpatched sites within hours — with it on (the default), a critical fix reaches your box within about an hour of release, while you sleep.
• Encrypted everything. Free Let's Encrypt certificates with automatic renewal, modern TLS with forward secrecy, HTTP/2 and HTTP/3.
• Contained tenants. Site-owner shell accounts live in a restricted jail, PHP runs with dangerous functions disabled, codebases are read-only to the web server, and processes are hidden between users.
• A quiet kernel surface. Hardened sysctl settings, IPv6 off by default (half-configured IPv6 is a classic source of mystery slowness), restricted system binaries, and password-expiry policy on system accounts.

The full, precisely-sourced list — every mechanism above with its internals — is the security model reference.

The short list that is genuinely yours

1. Use SSH keys, not passwords. You did this at install. Keep the private key safe, and if you ever rebuild the box, carry the host keys over so your tenants' clients still recognise it — the preservation procedure.
2. Keep the box current. Nearly every real-world compromise of a hosted Drupal box is an old, unpatched something. Your two upgrade commands per release cycle are the single highest-value security habit — Keeping current.
3. Treat the control panel login like the root password. The one-time login links BOA emails are the intended way in; the admin (uid-1) account is deliberately restricted, and /admin* paths are IP-guarded by default.
4. Don't loosen what you don't have to. Some conveniences (Midnight Commander or Node in the tenant shell, local sendmail) are off because they can pierce the tenant jail. Each has a documented opt-in with its trade-off spelled out — read the caveat before you touch one.
5. Read the notices. BOA emails the admin address about upgrades and incidents. A box whose operator reads those two-line mails is a box where nothing rots silently.

When something looks wrong

A box acting strangely is almost always load, a block, or a broken upgrade — walk When the box breaks first. If you genuinely suspect a compromise (files you didn't change, processes you can't explain), don't clean up first: preserve evidence, take the site offline via the panel, and get help with the box's logs intact — the help-request guide covers where and how.

Going further

• Advanced (root required): the security model — all fourteen built-in protections with sources, and where every hardening knob lives.
• Advanced (root required): the abuse guard — the traffic-scoring and banning machinery in full.
• Advanced (root required): security audit hardening — the audit history, edgetest, and why the auto-patching exists.