Security Advisor¶
The Security Advisor checks the security configuration of every connected server as well as panel-wide settings and summarizes the results as a score. Each check yields a rating (Pass, Warning or Critical) and — where it can be done safely — a one-click fix.
You'll find the page in the admin area under Security Advisor.
Score Overview¶
At the top, a ring gauge shows the ratio of passed to total checks (e.g. 12/15).
| Score | Color | Meaning |
|---|---|---|
| ≥ 80 % passed | Green | Solid baseline hardening |
| 50–79 % passed | Yellow | Improvements recommended |
| < 50 % passed | Red | Immediate action required |
The individual checks appear below as cards, sorted automatically: Critical first, then warnings, then passed checks. In multi-server setups each card carries the name of the affected server.
Live Query
Data is fetched fresh from every active server on each visit (not cached). Use Refresh in the top right to re-run the audit.
Panel Checks¶
These checks concern the panel itself, independent of any server.
| Check | Passes when | Fix |
|---|---|---|
| Password minimum length | Minimum length ≥ 12 characters (warning otherwise) | Sets the minimum length to 12 |
| Brute-force protection | Login protection active (max attempts and lockout set), critical otherwise | Enables protection (5 attempts, 15 min lockout) |
Both fixes change the corresponding panel settings directly. Fine-tune them under Settings > Security.
Server Checks¶
These checks are executed by the agent on every active server.
SSH¶
| Check | Pass | Warning | Critical |
|---|---|---|---|
Root login (PermitRootLogin) |
no |
prohibit-password / forced-commands-only |
yes |
| Password authentication | no (key-only) |
yes |
– |
| SSH port | Non-standard port | Port 22 | – |
Firewall & Brute-force¶
| Check | Pass | Critical / Warning |
|---|---|---|
| nftables firewall | Service active | Critical if inactive |
| fail2ban | Service active | Critical if not running |
fail2ban SSH jail (sshd) |
Jail active | Warning if not active |
System & PHP¶
| Check | Pass | Warning / Critical |
|---|---|---|
| Unattended upgrades | Automatic security updates active | Warning if disabled |
| PHP version | No EOL version installed | Critical if PHP < 8.1 is found |
Automatic Fixes¶
Cards with status Warning or Critical offer a Fix button. The following server-level fixes are wired up:
| Check | What the fix does |
|---|---|
ssh_root_login |
Sets PermitRootLogin no (drop-in /etc/ssh/sshd_config.d/enconf.conf), reloads sshd |
ssh_password_auth |
Sets PasswordAuthentication no, reloads sshd |
firewall_active |
systemctl enable --now nftables |
fail2ban_active |
systemctl enable --now fail2ban |
fail2ban_ssh_jail |
Creates the sshd jail and restarts fail2ban |
unattended_upgrades |
Installs and enables unattended-upgrades |
SSH fixes require confirmation
Every SSH fix prompts for confirmation first. The agent additionally has hard-wired safeguards so you can't lock yourself out:
- Disabling root login is refused as long as no other user has an
authorized_keysentry. - Disabling password auth is refused as long as no user has an SSH key on file.
- The SSH port is never changed automatically — you must do that manually, with the firewall/console adjusted accordingly.
In these cases the check is left untouched and you receive an explanatory message.
AppArmor Status¶
If AppArmor is available on at least one server, a dedicated AppArmor card appears with a summary across all servers:
| Metric | Meaning |
|---|---|
| Servers | Servers with AppArmor available / total |
| Profiles | Number of loaded enconf-<user> profiles |
| Complain | Profiles in complain mode |
| Enforce | Profiles in enforce mode |
Below that, the card lists each server individually (total loaded profiles, of those enforce/complain, of those enconf profiles) with a Complain ↔ Enforce toggle.
Complain mode is the shipped default
enconf generates a dedicated AppArmor profile (enconf-<user>) for every customer PHP-FPM pool and loads it in complain mode. In this mode nothing is blocked — rule violations are merely logged to syslog. This is the active protection and exists to observe real customer behaviour before enforcing.
Enforce mode is a deliberate choice (Phase 2)
The toggle can switch a server's profiles to enforce, at which point violations are actually blocked. Only enable this once you have gathered enough complain-mode log data to rule out false positives. Otherwise legitimate customer PHP calls may break.
If loading in enforce mode fails, the server automatically reverts to complain, and the card shows a corresponding notice.
Context: What's Active vs. Phase 2¶
The Advisor reflects the real hardening state and does not oversell:
- Active and rolled out: dedicated Linux user per website, webroot
0710, PHP-FPM pool per website,open_basedir,disable_functions, per-customer/tmp, per-customer MariaDB grants, root-only panel secrets, ProFTPD chroot, nftables SMTP egress block, fail2ban, per-customer systemd slices, and AppArmor profiles in complain mode. - Phase 2 (not active by default): AppArmor enforce mode per server (opt-in via the toggle), tiered systemd slice limits.
- Not architecturally isolable: shared kernel, single MariaDB instance, shared PHP binary, single Postfix/Dovecot/PowerDNS instance — this applies to every single-kernel panel and can only be mitigated with updates.
See Security for the full breakdown.