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.
CRA Compliance¶
The Security Advisor has a second tab, CRA Compliance. It maps the live security checks onto the requirements of the Cyber Resilience Act (Regulation (EU) 2024/2847, Annex I) and turns them into a readiness record.
- Requirement catalogue — each CRA requirement (access control, attack surface, DoS resilience, security updates, support period/EOL, exploitation mitigation) is backed by the advisor checks that support it, including the Annex I reference.
- Readiness score — percentage of met requirements out of those that can be assessed.
- EOL check — PHP and Debian versions are checked against their end of support (end-of-life = a gap under the CRA support-period requirement). Every installed PHP version is captured — including any additionally installed old version.
- Component inventory — web (nginx), FTP (ProFTPD), mail (Postfix/Dovecot/rspamd), database (MariaDB) and DNS (PowerDNS) are listed by name and version in the evidence. These services come from the Debian package repos and receive security backports for the whole OS support lifetime — so the version number is not an EOL signal; what matters is OS support (OS EOL) and automatic updates.
- Security ring verified — the update check confirms not only that
unattended-upgradesis running, but that the Debian security suite (<codename>-security) is configured as a source, is in the Allowed-Origins pattern, and the periodic trigger (APT::Periodic::Unattended-Upgrade "1") is on. Only then do security fixes actually flow. - Per-service hardening — dedicated checks beyond the inventory: mail transport TLS (Postfix), MariaDB not publicly reachable, ProFTPD chroot (
DefaultRoot ~), and fail2ban jails for mail and FTP (not just SSH). - Informational checks — nginx (HTTPS coverage: how many vhosts carry a TLS certificate) and PowerDNS (DNSSEC coverage: how many zones are signed). Deliberately informational rather than a red flag, because TLS per vhost and DNSSEC per zone can legitimately be optional.
Honest framing: CRA vs. NIS2
The CRA obliges manufacturers of products with digital elements — a hosting/managed service is not itself a CRA product. CRA relevance is therefore (a) enconf as a product (its manufacturer's duty) and (b) this dashboard as environment evidence for customers who make products themselves. For operating a hosting/DNS service, NIS2 (Art. 21 risk-management measures) is the directly applicable regime. The technical measures checked here (patch management, cryptography, access control, hardening) largely cover both frameworks — the dashboard provides evidence, not legal conformity.
- Evidence export — the Export evidence button produces a timestamped, self-contained document (HTML or JSON) with the panel version, score and, per requirement, its status plus the supporting evidence. Ideal for customer queries, cyber-insurance questionnaires or tenders.
Honest framing
The cockpit supports the technical CRA requirements through continuous monitoring and evidence documentation — it does not constitute legal conformity or certification. Conformity assessment, CE marking and reporting obligations remain the manufacturer's responsibility. This note is included in every exported document too.
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.