What's actually at stake
A Nagios web interface leaks more than status colors. Host names, IP addresses, service inventory, plugin output containing paths and versions — it's reconnaissance gold. And an account with command authorization can disable checks and notifications, schedule downtime, and submit external commands. Treat access to Nagios like access to a management console, because that's what it is.
Option 1: VPN — the recommended default
The cleanest answer is to not publish Nagios at all: keep it on the internal network and give your devices a secure path in.
- WireGuard — modern, fast, built into the Linux kernel, with a solid iOS app. On-demand activation can bring the tunnel up automatically when needed.
- Tailscale / mesh VPNs — WireGuard underneath with the key management done for you; the easiest route for a small team, and NAT traversal means no firewall holes at all.
- Your existing corporate VPN — if the phone can join it, you're done.
Over a VPN, your phone reaches the server exactly as if it were on the LAN — a mobile client like NagMon connects with the internal hostname, and nothing about your monitoring is internet-facing. Even then, keep HTTPS on: encryption inside the perimeter costs nothing.
Option 2: publish over HTTPS
Sometimes a VPN isn't practical. If you do expose the web interface, do all of the following, not a subset:
TLS with a real certificate
Let's Encrypt makes this a ten-minute job on the Apache server that already fronts Nagios:
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d nagios.example.comCertbot configures the vhost and renews automatically. Then redirect or disable plain HTTP — Basic auth over HTTP sends credentials effectively in the clear on every request.
Restrict what's reachable
- IP allowlisting if your remote locations are predictable (home, office egress): a
Require ipblock in Apache shrinks your exposure dramatically. - fail2ban watching the Apache auth log throttles credential-stuffing against the login.
- Keep Core and plugins patched — the CGIs are C programs parsing untrusted input; running years-old builds internet-facing is asking for trouble.
Strengthening authentication
- One account per human. A shared
nagiosadminmeans no audit trail and no way to revoke one person's access. Create individual users:
(sudo htpasswd -B /usr/local/nagios/etc/htpasswd.users rvetter-Buses bcrypt — the default crypt hashes are weak by modern standards.) - Long, unique passwords from a password manager; this is exactly the credential attackers try first against an exposed monitoring host.
- Basic vs. Digest: over HTTPS, Basic is fine and universally compatible (mobile clients including NagMon support both). Digest without HTTPS is still not acceptable exposure.
Read-only accounts
Authorization lives in cgi.cfg, and it's worth being deliberate: viewing status and submitting commands are separate privileges. For an account you use from a phone on the road — or for a wall dashboard — a read-only user limits the blast radius of a lost credential:
# cgi.cfg
authorized_for_all_hosts=rvetter,dashboard
authorized_for_all_services=rvetter,dashboard
authorized_for_all_host_commands=rvetter
authorized_for_all_service_commands=rvetter
authorized_for_read_only=dashboardHere dashboard can see everything but change nothing, while rvetter keeps full command rights — able to acknowledge and schedule downtime from the app. The JSON API honors the same authorization, so a read-only user's API access is read-only too (details).
What not to do
- Don't port-forward plain HTTP from your router to Nagios "just for a few days." Credentials and your infrastructure map cross the internet unencrypted on every refresh.
- Don't rely on a self-signed certificate for internet exposure. It trains you to ignore certificate warnings, and clients that pin trust can't tell your server from an impostor. Self-signed is defensible only for internal servers — which is why NagMon's Allow Self-Signed Certificate option exists, and why we recommend it only for internal use.
- Don't give every account command rights out of convenience. Most sessions are looking, not acting.
The checklist
- ☐ VPN first; publish only if you must
- ☐ HTTPS with a trusted certificate; HTTP disabled or redirected
- ☐ Per-person accounts, bcrypt-hashed (
htpasswd -B) - ☐ Command authorization only for users who need it; read-only for the rest
- ☐ IP allowlist and fail2ban if internet-facing
- ☐ Nagios Core, plugins, Apache, and OS kept current
- ☐ Test from cellular (not your Wi‑Fi) to confirm it works — and that only what you intended is reachable
Locked down? Now make it usable.
NagMon connects over HTTPS or your VPN, supports Basic and Digest auth, and keeps everything on-device. Free on the App Store.