Dashboard: Security tab

ProxMenux Monitor · Dashboard~18 min

Every security control in the dashboard, grouped into two clearly-labelled blocks: configuration of the Monitor itself (auth, SSL, tokens, Secure Gateway) and configuration of the Proxmox host it watches (firewall, Fail2Ban, Lynis).

Two scopes, one tab

The Security tab is divided into two clearly separated sections: ProxMenux Monitor (settings for the dashboard itself) and Proxmox VE (settings for the host underneath). Cards render conditionally — Fail2Ban and Lynis only appear once installed.

ProxMenux Monitor

Four cards control how the dashboard itself is reached and authenticated.

Authentication

The card lets you manage the dashboard's own login. The full first-launch flow, password policy, TOTP enrolment screens and lost-authenticator recovery are documented in Access & Authentication — this card is the day-to-day surface for those settings:

Authentication Status — badge showing Enabled / Disabled / Declined.
Change Password — current password + new password + confirmation.
Enable / Disable Two-Factor Authentication — opens the QR enrolment dialog when enabling, asks for the current password when disabling.
Disable Authentication — destructive action that re-shows the first-launch Protect your dashboard? dialog on next visit.

SSL / HTTPS

Serves the dashboard over HTTPS without any reverse proxy in front. The card auto-detects the certificate that Proxmox itself uses (under /etc/pve/local/) and shows the subject, issuer and expiry so you can verify it before activating. Two paths to enable HTTPS:

Use Proxmox Certificate — one click. The Monitor reuses the certificate installed on the host. Good fit for users who already have their PVE running on the same DNS name as the dashboard.
Use Custom Certificate — paste absolute paths to your own .pem certificate and .key private key. The paths are validated before the service restarts; if loading fails, the dashboard falls back to HTTP automatically (no broken state).

SSL/HTTPS card with HTTPS Enabled status, Active Certificate showing pve-ssl.pem and pve-ssl.key paths, and a Disable HTTPS button — HTTPS active — the card surfaces the certificate currently in use, the file paths and a *Disable HTTPS* action that drops back to HTTP on the same port.

ACME / Let's Encrypt via Proxmox

If your Proxmox node already has Let's Encrypt configured at Datacenter → Certificates → ACME, that's the certificate the host serves to browsers — and that's what the dashboard reuses when you click Use Proxmox Certificate. You don't need separate ACME plumbing for the Monitor.

For a step-by-step walkthrough — including how the Monitor auto-detects the ACME-uploaded certificate, what gets written to disk, and how to fall back to a custom .pem / .key pair — see HTTPS for ProxMenux Monitor.

API Access Tokens

Long-lived tokens (1 year) for unattended integrations — Homepage widgets, Home Assistant REST sensors, Grafana scrapers, n8n flows, custom scripts. The card walks you through three states: empty → form → generated.

Generate a token. Click Generate New API Token. The form asks for a descriptive Token Name (helps you identify it in the active list later) and your password as second-factor confirmation. If 2FA is enabled, the form additionally asks for the current TOTP code.

API Access Tokens generate form with Token Name input, Password input, Generate Token and Cancel buttons — The Generate API Token form — fill in a name and confirm with your password (and TOTP if 2FA is on).

Save the token immediately. The full token string is shown only once after generation. The card highlights this with an amber notice and a copy button. There's no way to retrieve it later — you'll only see the prefix in the Active Tokens list.

API token generated successfully with masked token, copy button, instructions for Authorization Bearer header and Active Tokens list with prefix — Token generated — the value is shown once with a copy button and the exact `Authorization: Bearer` snippet. Below, the Active Tokens list keeps name + prefix + creation date so you can revoke individual tokens later.

The card shows every active token with a Revoke button per row. Revoking invalidates the token immediately; any integration using it stops working from that moment. Cookbooks for Homepage, Home Assistant, n8n and Prometheus are in Integrations.

Secure Gateway

Reach the dashboard, the Proxmox web UI and any guest from anywhere on your Tailscale tailnet, without exposing any port to the public internet. The Monitor deploys an Alpine LXC container on the host running tailscaled as a subnet router; once approved in the Tailscale admin console, your remote devices reach the host's LAN IP from anywhere.

Step-by-step wizard

Before clicking Deploy Secure Gateway, generate an auth key in your Tailscale admin console — the wizard will ask for it in step 2.

0. Generate the Tailscale auth key

Sign in to login.tailscale.com/admin/settings/keys and click Generate auth key…. Choose a pre-authenticated key (so the gateway doesn't need an interactive Tailscale login), and copy the value — it's shown only once.

Tailscale admin console Settings Keys page with Generate auth key button highlighted — Tailscale admin console — *Settings → Keys → Generate auth key…*. Use a free Tailscale account if you don't have one yet (link inside the wizard).

1. Open the wizard

Back on the Security tab, click Deploy Secure Gateway. The first step is an intro with what you'll get and what you need.

Secure Gateway Setup wizard intro step explaining what the gateway provides: VPN access, no port forwarding, end-to-end encryption — Step 1 — overview of what the Secure Gateway provides and a reminder that you'll need a free Tailscale account.

2. Tailscale Authentication

Paste the auth key from step 0 and pick a hostname (this is what the gateway will appear as in the Tailscale admin console — typically proxmox-gateway or your node name).

Secure Gateway wizard step asking for Tailscale Auth Key and Device Hostname with link to generate the key — Step 2 — paste the pre-auth key and choose the device hostname. The link below the field opens the Tailscale page from step 0 if you skipped ahead.

3. Access Scope

Choose what your tailnet can reach through the gateway:

Proxmox Only — only the Proxmox UI and the Monitor. Smallest attack surface.
Full Local Network — the entire LAN subnet (auto-detected from the host's primary interface). Lets you reach NAS, printers, VMs and any other LAN device.
Custom Subnets — list specific CIDRs. For multi-VLAN setups where you want to expose some segments but not others.

Secure Gateway wizard Access Scope step with three options: Proxmox Only, Full Local Network, Custom Subnets — Step 3 — pick the access scope. *Full Local Network* auto-fills with the detected LAN subnet.

4. Advanced Options (optional)

Two optional toggles. Both are off by default:

Exit Node — when enabled and selected from a remote device, all that device's internet traffic exits through the Proxmox host's WAN. Useful for travel scenarios where you want your phone's traffic to look like home.
Accept Routes — let this gateway reach networks advertised by other tailnet subnet routers (for multi-site setups).

Secure Gateway wizard Advanced Options step with Exit Node and Accept Routes checkboxes — Step 4 — Exit Node and Accept Routes. Skip both if all you want is dashboard access from your phone or laptop.

5. Review & Deploy

Final summary before the deploy starts. The wizard reminds you that one manual step in Tailscale admin is still pending after deploy: approving the subnet route.

Secure Gateway wizard Review and Deploy step with Configuration Summary showing hostname, access mode, networks, exit node, accept routes and a Deploy Gateway button — Step 5 — review the configuration and deploy. The blue notice at the bottom flags the pending route approval.

One last manual step in Tailscale admin

After deploy, go back to login.tailscale.com/admin/machines and approve the subnet route the gateway is advertising. Until you do, remote devices on your tailnet won't actually be able to reach LAN IPs through the gateway. Tailscale marks pending routes with a yellow warning on the device row — click Edit route settings and tick the route box.

Proxmox VE

The host's own protections — firewall, intrusion prevention and security audit. Last two only render when their respective tools are installed.

Proxmox Firewall

The card surfaces the Proxmox VE built-in firewall (which is independent from any host-level iptables / nftables you may run alongside). Three blocks:

Cluster Firewall + Host Firewall — global toggles. The cluster firewall must be active for any host-level rule to take effect; the card flags this dependency inline.
Quick Access Rules — pre-defined rows for ports that matter to ProxMenux itself: 8008/TCP (Monitor), 8006/TCP (Proxmox Web UI). Each row shows the current allow / deny / unprotected state. The Proxmox Web UI is allowed via the built-in Proxmox firewall macro and can't be removed accidentally.
Rules Overview — counters for total rules, accept rules, drop / reject rules and distinct ports protected. Numbers are read from /etc/pve/firewall/cluster.fw and /etc/pve/nodes/<node>/host.fw.
Firewall Rules — full list with action / protocol / port / source / level. + Add Rule opens an inline editor; the trash icon on each row removes the rule. Edits write to the same files Proxmox uses, so changes also appear in the Proxmox UI (Datacenter / Node → Firewall).

Fail2Ban (conditional)

What it is. Fail2Ban is an open-source intrusion-prevention daemon that watches log files for repeated failed login attempts and bans the offending IP at the firewall level. It's the de-facto answer to brute-force scanners that hit SSH and web login forms 24/7. ProxMenux wires it to three jails by default: SSH, the Proxmox web UI login (port 8006), and the ProxMenux Monitor login (port 8008).

Fail2Ban is not bundled. The card detects whether it's installed and adapts: when missing it offers a one-click install; once installed it shows live jail status, banned IPs and lets you tune retries / ban time per jail.

Fail2Ban card showing Not Installed state with explanation of what it would configure: SSH, Proxmox web UI and ProxMenux Monitor protection with nftables backend, plus an Install and Configure Fail2Ban button — Fail2Ban card before install — the blue box previews what the install would configure.

Click Install and Configure Fail2Ban and you get a confirmation modal listing every change the script will make on the host:

Install Fail2Ban confirmation modal listing SSH protection aggressive mode, Proxmox web interface protection port 8006, ProxMenux Monitor protection port 8008, auto-detected nftables backend, journald log level adjustment and SSH MaxAuthTries hardening — Install confirmation — explicit list of jails, tweaks to journald log level (so the auth jail can read SSH events) and an SSH-hardening side effect (`MaxAuthTries=3`).

Confirmation triggers a streaming install panel (apt + jail config + tests). Same plumbing as the ProxMenux CLI installer.

Fail2Ban Installation panel showing live install log: package install, journald MaxLevelStore tuned for auth logging, jails configured, nftables backend detected, MaxAuthTries hardening, fail2ban-client communication test, completion message — Install in progress — every step is logged in the panel. Connection-closed at the bottom marks the end of the streaming session.

After install the card flips to the live status view: jails configured, banned IPs counter, recent ban events. The big tabs split Jails & Banned IPs from Recent Activity (the last N entries from the Fail2Ban log).

Fail2Ban card after install with Active status, three jails configured (proxmenux, proxmox, sshd), Banned IPs counter, Total Bans, Failed Attempts, and per-jail rows with retries, ban time, window and gear icon — Fail2Ban active — the three default jails (`proxmenux`, `proxmox`, `sshd`) with their retries / ban time / window settings.

Tune jail rules. Click the gear icon on any jail row to adjust Max Retries, Ban Time (use a permanent ban if you want offenders blocked until you manually unban) and Find Time (the rolling window for counting retries). Common values are documented inside the form.

Configure sshd jail form with Max Retries, Ban Time in seconds with Permanent Ban option, Find Time, common values reminder, and Save Configuration button — Editing the sshd jail — pick a stricter *Max Retries* for SSH if you only ever log in from your own subnet, or extend *Ban Time* for the public-facing dashboard.

The full What it installs / how it's configured / how to uninstall walkthrough — including the manual install path, the SSH MaxAuthTries side effect, and the relationship with the proxmenux-auth.log journal — is in ProxMenux → Security → Fail2Ban.

Without Fail2Ban, brute-force protection is best-effort

ProxMenux Monitor has its own application-level ban hook in the Flask request pipeline — but it only takes effect if Fail2Ban is installed and writes to the bans table. Without Fail2Ban, the Monitor logs failed logins to proxmenux-auth.log for future inspection but doesn't actively block IPs.

Lynis Security Audit (conditional)

What it is. Lynis is an open-source security auditing tool that runs ~280 tests across the host (file permissions, kernel hardening, SSH config, package vulnerabilities, crypto policy, scheduled tasks, banner grabbing, etc.) and produces a hardening score 0–100, a list of warnings and a list of suggestions. It's the de-facto baseline for "is this server in good shape" on Debian-based servers.

Why it's useful. Knowing the security posture of your server is hard to do by reading config files one by one. Lynis catches the things that are routinely overlooked: kernel hardening flags missing, weak SSH ciphers enabled, journal not persistent, sudoers NOPASSWD on default accounts, and many more. Re-running it after applying ProxMenux post-install tweaks gives you an objective number for the improvement.

Lynis Security Audit card with Not Installed state and Install Lynis button, listing features: hardening scoring, vulnerability detection, compliance checking and GitHub source — Lynis card before install — the blue box summarises what the tool does.

Lynis is also not bundled. ProxMenux installs the latest release directly from the official GitHub source (not the Debian package, which lags several minor versions).

Install Lynis confirmation modal listing what Lynis does: hardening scoring, vulnerability detection, configuration analysis, compliance checking, source from official GitHub repository — Install confirmation — explicit about the GitHub source.

Lynis Installation streaming panel: installing latest scan tool, version 3.1.6 confirmed, installation completed message — Install in progress — same streaming panel pattern as Fail2Ban.

After install the card shows the version and an empty audit history. Click Run Security Audit to start the first scan.

Lynis Security Audit card after install with version 3.1.6 Installed badge, Last Scan timestamp, Hardening Index 0, Warnings 0, Suggestions 0, an empty audit report row and a Run Security Audit button — Lynis installed, no audit yet. The card prefills the metric tiles with zeros.

Lynis Security Audit card while audit is running showing Security audit in progress message, estimated 2-5 minutes duration, and a disabled Running Audit button — Audit in progress — the action button shows a spinner and the card explicitly warns that the scan can take 2–5 minutes.

When it finishes, the card flips to the results view: hardening index, warnings, suggestions and an Audit Reports list with each historical scan.

Lynis Security Audit card with results: Hardening Index 71 with Lynis 66 PVE 71 breakdown, 3 warnings, 40 suggestions, Security Hardening Score progress bar Proxmox Adjusted 71 of 100 in the Good range, audit reports list with PDF download and Run Security Audit button — Audit results — Hardening Index **71/100 (Good)** on a sample run. The card also shows the "Lynis raw score" (66) versus the Proxmox-adjusted score (71) which adds back 11 points for findings the Lynis test corpus flags but are expected behaviour on Proxmox VE.

Lynis raw score vs Proxmox-adjusted score

Lynis ships rules tuned for general-purpose Debian. Proxmox legitimately diverges from some of them (services running as root for cluster reasons, custom journald tuning, etc.). The card shows both numbers so you can:

Track your Lynis raw score the same way external auditors would.
Track the Proxmox-adjusted score — a fairer baseline if you're comparing nodes inside the same cluster.

The full report. Each audit row in the list has a PDF button that downloads a multi-page report with the executive summary, system info, security posture, every warning with explanation, every suggestion ranked by impact, and the package inventory. It's the artifact you would attach to a security review.

Sample first page of the Lynis Security Audit Report PDF showing executive summary with hardening 71 of 100, warnings and suggestions counts, system information block with hostname, kernel, Lynis version, report date, security posture overview — First page of a downloaded report — executive summary, system information and security posture overview. The full report continues with detailed warnings, suggestions and the installed-packages list. A sample PDF is attached for reference.

Run the audit periodically (after major Proxmox upgrades, after applying post-install tweaks, before opening a remote-access path) and keep the reports — the trend matters more than any single number.

The full What it installs / how it's configured / how to uninstall walkthrough and a written sample report breakdown are in ProxMenux → Security → Lynis.

How the data is collected

Card	Endpoint	Source
Authentication, 2FA, password change	/api/auth/*	Local SQLite + JWT issued by the Monitor.
SSL / HTTPS	/api/auth/ssl/*	`openssl x509` on `/etc/pve/local/pve-ssl.pem` + `/etc/proxmenux/ssl_config.json`.
API tokens list / mint / revoke	/api/auth/api-tokens	Token rows kept locally; nothing leaves the host.
Secure Gateway (deploy + status)	/api/oci/*	Provisions Alpine LXC + `tailscaled` via `pct create` / `pct exec`.
Firewall status & rules	/api/security/firewall/*	`pve-firewall` + `/etc/pve/firewall/<cluster\|host>.fw`.
Fail2Ban (only when installed)	/api/security/fail2ban/*	`fail2ban-client status`, `/var/log/fail2ban.log`, `/etc/fail2ban/jail.local`.
Lynis audit (only when installed)	/api/security/lynis/*	Runs `lynis audit system` in the background; report parsed from `/var/log/lynis-report.dat`.

# Confirm the auth log on the host (used by Fail2Ban + audit)
journalctl -t proxmenux-auth --since '7 days ago' | tail

# Cross-check the firewall rules the dashboard sees
pve-firewall status
cat /etc/pve/firewall/host.fw

# Verify Fail2Ban (only if installed)
fail2ban-client status
fail2ban-client status sshd

# Verify Lynis (only if installed)
lynis show version
ls -lh /var/log/lynis-report.dat

Where to next

Access & Authentication — full first-launch flow, 2FA app picker, lost-authenticator recovery, reverse-proxy snippets.
Integrations — cookbooks for using API tokens with Homepage, Home Assistant, Prometheus, n8n and the Secure Gateway end-to-end.
API Reference — every /api/auth, /api/security and /api/oci endpoint with method, body and curl examples.
ProxMenux → Security → Fail2Ban — install walkthrough, jails configured, manual install path.
ProxMenux → Security → Lynis — sample report, score interpretation, when to re-run.

ProxMenux Monitor: Previous

Terminal tab

ProxMenux Monitor: Next

Settings tab