Security and hardening

What the panel enforces

• One Linux user per site. Files, the PHP-FPM pool and any runtime process belong to that user. Operations on site content drop privileges to it; the daemon never runs a shell, only direct commands.
• One root process. aurapaneld is the only component running as root, listening on 8443 behind nginx.
• TLS everywhere. TLS 1.2 minimum, HSTS for a year, a placeholder certificate from the first second and Let's Encrypt as soon as DNS allows. HTTPS certificates.
• Headers on every site: Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy, X-Frame-Options (per site: default, same-origin, deny, or left to the application), and the nginx version hidden.
• Log files are never served. Every server block denies *.log and rotated archives under the document root.
• Secrets at rest are encrypted with a master key at /etc/aurapanel/secret.key (root-only): database passwords, Cloudflare tokens, snapshot credentials. They are never echoed back by the API once saved.
• Panel sessions use random 256-bit tokens in HttpOnly, Secure, SameSite cookies with CSRF double-submit; the interface runs under a Content Security Policy allowing scripts only from itself and forbidding framing; there is no CORS.
• Every change is audited. Audit log.

Accounts

Passkeys as a primary credential, TOTP two-factor authentication, idle session timeout, per-IP sign-in rate limiting, and roles that limit each user to the sites they are granted: Users, roles and access. Register a passkey or enable TOTP on the administrator account during first-run setup; the wizard offers it as its last step.

Cloudflare edge shield

For a site proxied through Cloudflare, Edge Shield in the site's Security tab locks the origin so that only Cloudflare's published IP ranges can reach it; anyone connecting to the server's address directly gets a 403. The visitor's real IP is restored from Cloudflare's headers, the ACME challenge path stays reachable, the server's own addresses are allowed so scheduled tasks and health checks keep working, and the range list refreshes every 12 hours over a built-in baseline so it can never become empty.

Optionally add Authenticated Origin Pulls (mutual TLS): the panel enforces it only after confirming the zone has it enabled, so the toggle cannot take the site down.

Basic authentication

A username and password in front of an entire site, for staging or private tools: site → Security → Basic authentication. Credentials are stored bcrypt-hashed under /etc/aurapanel/htpasswd/.

Signed updates

Releases are signed with an Ed25519 key. The updater downloads the package, SHA256SUMS and its signature, verifies the signature with the key installed at /opt/aurapanel/share/release-ed25519.pub, then the checksum, and refuses to install if a release is unsigned, the signature fails or the checksum differs. After installing, it checks the panel's health for 30 seconds and rolls back to the cached previous package if the new version does not come up.

Updates are checked every 12 hours. Settings → auraPanel Updates installs one on request or, with Automatic updates on, applies each new release when it is found. A watchdog timer restarts the daemon if its health endpoint fails three times in a row, so an upgrade that stops the service cleanly cannot leave it down.

Firewall and fail2ban

The installer, unless told otherwise, enables UFW allowing only 22, 80, 443 and the panel port, and installs fail2ban. After that, the panel does not manage firewall rules; it shows fail2ban as a managed service you can start, stop and restart, and nothing more. Rules for other ports, and fail2ban jails, are yours to set on the host.

sudo ufw status
sudo ufw allow from 203.0.113.0/24 to any port 8443 proto tcp   # example: restrict the panel

What remains yours

• Provider firewall or security groups in front of the server.
• SSH hardening: keys, disabling password login, fail2ban jails.
• Operating system updates. The panel updates itself and the packages it installed from the vendor repositories it added; apt upgrades for the rest are yours.
• Application security: the code you deploy, its updates and its own accounts.
• Off-site copies of backups and provider snapshots.
• Anything you run with root on the host outside the panel.

The security overview summarises the same model for evaluation.