Management plane hardening — securing the GUI, SSH, API, and console paths

The management plane is the most valuable target on the firewall. An attacker who compromises the management plane owns the firewall — every rule, every NAT, every alias, every audit log. A firewall with hardened data plane rules and an exposed management plane is a firewall the attacker can reconfigure to allow everything.

This lesson covers the management plane hardening checklist: source-restricted GUI, key-only SSH, MFA, API key rotation, console-only break-glass, audit logging. The threats each control addresses and the evidence each control produces.

The management plane attack surface

The management plane is exposed through five paths:

1. GUI. HTTPS on port 443. The web interface the operator uses to configure and monitor the firewall.
2. SSH. SSH on port 22 (or a non-standard port). The command-line interface for scripting, automation, and recovery.
3. API. REST API on port 443, authenticated with an API key/secret pair over HTTP Basic. The programmatic interface for automation tools and configuration management.
4. Console. Serial, BMC SOL, or KVM-over-IP. The physical-or-virtual console for recovery when network access is broken.
5. Audit log. Local log files, remote syslog. The trail of who did what, when.

Each path has different threats and different controls. The hardening checklist addresses each.

$ sockstat -l -P tcp | grep -E ':22|:443|:80|:53' | head -10

root sshd       1234 4 tcp4  192.0.2.1:22      *:*
root lighttpd   1456 5 tcp4  *:443              *:*
root lighttpd   1456 6 tcp4  *:80               *:*
root unbound    1678 8 tcp4  127.0.0.1:53      *:*

Source-restricted GUI

The GUI is the operator’s primary interface. The hardening control is to restrict the GUI’s reachability to a known set of source IPs: the management VLAN, the operator workstations, the jump hosts.

The control has three parts:

1. Source alias. An alias containing the allowed source IPs (operator workstations, jump hosts, the management VLAN subnet).
2. Firewall rule. A pass rule on the LAN interface (and the management VLAN, if separate) that allows HTTPS from the source alias to the firewall’s LAN IP.
3. Anti-lockout rule. The auto-generated anti-lockout rule remains as a fallback. The source-restricted rule sits above it.

The threats addressed: brute-force attacks against the GUI from the Internet, credential-stuffing attacks with leaked passwords, automated vulnerability scanners looking for known GUI exploits.

The evidence produced: the rule in pfctl -s rules, the alias in the configuration, the audit log entries showing only allowed sources reached the GUI.

Key-only SSH

The SSH service is the operator’s command-line interface. The hardening control is to require SSH key authentication, not password authentication.

The control has three parts:

1. Disable password authentication in the SSH service configuration (System → Settings → Administration → SSH). Set Permit root login to prohibit-password or forced-commands-only; set PasswordAuthentication to no.
2. Install operator SSH keys in ~/.ssh/authorized_keys for each operator account.
3. Test key-based login from each operator workstation before disabling password authentication.

The threats addressed: brute-force password attacks against SSH, credential-stuffing with leaked passwords, password-spraying attacks that try common passwords against the SSH service.

The evidence produced: the SSH service configuration, the authorized_keys file, the audit log entries showing key-based authentication.

MFA on the GUI

The GUI supports multi-factor authentication via TOTP (Time-based One-Time Password). The hardening control is to require MFA for every GUI login.

The control has three parts:

1. Enable TOTP in the GUI user configuration (System → Access → Users → <user> → OTP). Each operator enrolls a TOTP secret in their authenticator app.
2. Test MFA login before considering the control complete.
3. Document the recovery for lost TOTP secrets (a console-only break-glass account, or a documented procedure for re-enrolling TOTP from the console).

The threats addressed: credential theft (an attacker with the operator’s password still needs the TOTP code), session hijacking, brute-force attacks even with a valid password.

The evidence produced: the user configuration showing TOTP enabled, the audit log entries showing MFA challenges, the recovery procedure document.

API key rotation

The API authenticates with a key/secret pair, presented as HTTP Basic credentials. The pair has no scope of its own — it carries whatever privileges the user it belongs to carries — so scoping is a matter of which account the pair is issued against.

The control has three parts:

1. Issue each pair against a purpose-built service account whose group membership grants only what that consumer needs. A monitoring scraper gets read privileges; a rule automation gets rule privileges. Nothing gets a pair on an administrative account.
2. Rotate on a schedule (every 90 days for production, more often for high-privilege consumers). A user can hold several pairs at once, so rotation overlaps cleanly: issue the new pair, redeploy, confirm it is in use, delete the old one.
3. Delete unused pairs immediately, and delete leaked ones before anything else. Disabling the owning user stops every pair it holds at once, which is the faster move when the specific pair is not yet known.

The threats addressed: leaked credentials used to reconfigure the firewall, long-lived credentials that are never rotated, credentials on over-privileged accounts.

The evidence produced: the inventory of pairs per account (which exist, on which account, when they were last rotated), and the audit log entries showing use — which record the user, not the pair, and are therefore only as useful as the discipline of one account per consumer.

Console-only break-glass

The console is the operator’s last resort. The hardening control is to have a console-only break-glass account that can authenticate even when network access to the GUI and SSH is broken.

The control has three parts:

1. Local account with a known password or SSH key. The account is documented in the change ticket that created it, in the operator runbook, and in the disaster recovery plan.
2. Sealed credential stored in a safe (physical or virtual). The credential is opened only when network access is broken.
3. Tested access at every change window. The operator logs into the break-glass account from the console; the login is verified; the seal is resealed.

The threats addressed: network-side lockout where the GUI, SSH, and API are all unreachable; credential compromise where the operator’s daily-use credentials are leaked but the break-glass credential remains sealed.

The evidence produced: the break-glass test log (showing when the break-glass account was last tested), the safe access log (showing when the sealed credential was opened), the audit log entries for the break-glass account’s actions.

Audit logging

The audit log is the evidence the controls are working. The hardening control is to log every management plane action with the operator, the timestamp, the action, and the result.

The control has three parts:

1. Enable the audit log in the GUI configuration (System → Settings → Administration → Log). Set the log destination to both local and remote syslog.
2. Configure remote syslog to send the audit log off the firewall. A firewall whose audit log lives only on the firewall is a firewall whose compromises are not visible from outside.
3. Monitor the audit log with alerts on unusual events: failed logins, configuration changes outside change windows, API key usage from unexpected sources.

The threats addressed: undetected compromise (the attacker reconfigures the firewall without anyone noticing), audit gap (the operator cannot answer “who changed this rule last week?”), lateral movement (the attacker uses the firewall to pivot).

The evidence produced: the audit log entries themselves, the remote syslog archive, the alerts on unusual events.

Summary

• Five paths in the management plane: GUI, SSH, API, console, audit log. Each has distinct threats and distinct controls.
• Source-restricted GUI: alias + rule + anti-lockout fallback. Keeps both the daily-use rule and the safety net.
• Key-only SSH: disable passwords, install keys, test before disabling.
• MFA on the GUI: TOTP for every login, recovery procedure for lost secrets.
• API credential rotation: one service account per consumer, scheduled rotation, immediate deletion on leak.
• Console-only break-glass: local account, sealed credential, tested access at every change window.
• Audit logging: local + remote syslog, alerts on unusual events.