Security, from the first line of code

Control panels are a favourite target because one bug can hand over every site on a server. RespireCloud is built so that the part facing the internet has as little power as possible, and everything it does is on the record.

  1. Browser, CLI or API token

    Signs in with a passkey or a scoped token. Every method and path is denied unless an action allows it.

  2. respirecloudd unprivileged user

    Checks permission, plan limits and risk; validates parameters against the action's schema; writes the audit row.

  3. Bus TLS 1.3, per-server keys

    Each server can only receive its own operations. A compromised server cannot see another's.

  4. respirecloud-agent root, minimal

    Runs typed operations from module manifests only. Commands are argument lists, never shell strings.

Lessons we built in

Authentication that only checked some requests
In 2024 an open-source panel was taken over on thousands of servers because its authentication checked only some HTTP methods. RespireCloud denies every method and path unless an action allows it.
User input reaching a shell
The agent runs programs as argument lists from typed operations. There is no shell string for a parameter to escape from.
A stolen session doing damage
High-risk and critical actions need a fresh passkey or code, and you can end any signed-in device from your Security page. A browser kept signed in with a PIN needs two halves that are useless apart, so a stolen cookie gets nothing.
A bad firewall rule locking you out
Every firewall change arms a rollback timer. If you do not confirm it, the previous rules come back.

Layer by layer

The panel

  • Unprivileged web tier; root work only through typed agent operations
  • Deny by default on every method and path
  • Passkeys, Argon2id passwords, authenticator and recovery codes
  • Two-step sign-in required for administrators and resellers
  • Single sign-on with OIDC and SAML; administrators keep a local way in
  • Step-up for high-risk actions, session rotation
  • Device list with instant sign-out; scoped, revocable API tokens
  • A PIN on a trusted browser: a stolen cookie alone gets nothing, because the browser must also sign with a key that cannot leave it. A PIN never replaces a passkey or code for risky actions
  • A deny on one site, domain, mailbox, database or folder wins everywhere, for administrators too
  • Hash-chained audit log with verification
  • Sign-in alerts for a new country or impossible travel, with a "this was not me" answer
  • Every audit checkpoint can be copied off the server by syslog or signed webhook, so a rewritten log is caught against the copy
  • SAML encrypted assertions, signed requests and single logout (not built, or limited)
  • SELinux enforcing for the per-site firewall is not proven (not built, or limited)

Servers

  • Per-server keys on a TLS 1.3 bus; each server sees only its own operations
  • nftables firewall with presets and an anti-lockout rollback timer
  • CrowdSec intrusion prevention, local by default
  • File-integrity baselines and hardening checks
  • Unattended security upgrades with a service health watch
  • SSH hardening validated with sshd -t
  • Signed updates: the key is built into the program, the root agent checks a release again before it runs, and a release that does not start is replaced by the previous one and a copy of the database
  • Licence-bound downloads: releases and Store add-ons are served only to an installation with its own key and a licence in good standing
  • Rootkit scans (not built, or limited)
  • Real-time file scanning (not built, or limited)

Sites

  • Per-account Linux users, slices and PHP-FPM pools
  • open_basedir to the home; no symlinks to other owners' files
  • Snippet allow-lists checked on the panel and again on the server
  • Malware scanning (ClamAV and YARA) with quarantine
  • A web application firewall per site (Coraza and the OWASP rules): off, detect or block, with exceptions and a kill switch. It adds about 12 ms at the 95th percentile
  • Per-site rate-limit presets, security headers, a proof-of-work bot challenge and hotlink protection
  • Proven on AlmaLinux 10 and Ubuntu 26.04; a restart of the firewall service leaves sites uninspected for about 11 seconds (not built, or limited)

Mail

  • DKIM keys made on the server, ARC sealing
  • SPF, DMARC, MTA-STS and TLS-RPT published automatically
  • Login must match the sender; open relay refused
  • Outbound SMTP blocked for hosting accounts at the firewall
  • A flooding mailbox is held, never bounced; blocklist and reverse-name checks run with a score per domain
  • ClamAV for mail, chosen in the installer; it needs 4 GB and was run on two of the nine systems
  • App passwords for phones, refused by the webmail sign-in; a failed sign-in is logged with the real client address so it can be banned
  • DANE (not built, or limited)
  • The stock fail2ban Dovecot filter does not match Dovecot 2.4; a custom filter was used in the lab (not built, or limited)

DNS and certificates

  • One-click DNSSEC
  • Certificate keys generated on the node
  • ARI-scheduled renewals that never drop a working certificate
  • Secondary name servers: a zone transfer needs the transfer key and a listed address, and a secondary can be promoted
  • CT log monitoring (not built, or limited)
  • No screen yet for promoting a secondary or holding a zone for an outside primary; the actions exist (not built, or limited)

Data

  • Encrypted restic repositories, one per account and target
  • Immutable backups with S3 object lock
  • Secrets in a vault, redacted from logs and the audit trail
  • Whole-server recovery, run for real: a blank node was rebuilt from the backup and bundle in 312 seconds with every item verified
  • Point-in-time database recovery (not built, or limited)
  • Mail in transit, sessions and the licence activation do not come back (not built, or limited)

Built and lab-tested Not built, or built with a stated limit

The Confirm it is you dialog asking for a passkey before deleting a hosting account.

Found a vulnerability?

Email us with the subject "RespireCloud security report". Please do not test against servers you do not own. The technical detail is in the security model.