Nginx Proxy Manager, a popular web-based and user-friendly reverse proxy management interface for Nginx, has just released version 2.13.6. Although this is only a patch release to a minor version, it actually delivers some fairly significant improvements.
The most notable change is the addition of TOTP-based two-factor authentication, allowing administrators to protect access to the web interface with time-based one-time passwords, bringing a long-requested security feature to Nginx Proxy Manager.
Certificate management has also been expanded. When creating new certificates, users can now explicitly choose between RSA and ECDSA key types, offering greater flexibility depending on compatibility or performance requirements.
Well this is great. NPM is often the most exposed element of a homelab (even if the management portal itself typically isn’t), it’s a critical security element that an attacker would be able to do all sorts of bad things with access to it.
The maintenance and commits on this project have certainly seemed to step up recently. It was pretty much moribund for years, though I kept using it.
I’m willing to be the dumbest member of this community. But on the off chance anyone else doesn’t understand what problem Nginx Proxy Manager solves:
Many ISPs only allow traffic on ports 80 and 443. But distinct from a website where all pages are part of a single process, separate web apps (photos, blogs, calendar, etc) are all made by different people and need their own port.
Nginx Proxy Manager can therefore be the only thing listening at ports 80/443 and then can seamlessly forward the user to the correct port using HTTPS.
Smart people: constructive critiques are welcomed.
That’s one problem it solves, but NPM is really just a frontend for Nginx Reverse Proxy.
And a reverse proxy is one of the basic security steps you need to take when exposing something to the open Internet. You want everything forwarded through it and spend most of your time hardening it and the server it’s running on (and it should be the only thing running on that server, all other services should be running elsewhere, ideally)
Crap, I’m in the process of setting up a headless Ubuntu server on my desktop to eek the maximum amount of CPU/GPU/RAM out of it for AI stuff and was planning on controlling it via my laptop.
I don’t particularly care about privacy on that desktop, but would my ignorance of security hardening open me up to rogue hackers using my machine for their own purposes if I were to set it up so I could control it remotely (not just hardwired)?
For just one person limited use like that, i’d just use a VPN for whenever you’re away from home.
But you could learn a bit about hardening and expose it anyways if you want, I personally just want to be able to access my stuff from anywhere so I spend a decent amount of time hardening.
It’s not too hard, you really just need a certain baseline to defend against script kiddies and bot mass scanners. Unless you’re a business or a high value target or something that’ll attract the skills of “real” hackers
There’s a pile of reverse proxies out there, NPM is one that’s built on nginx’s reverse proxy mechanism that’s a little opaque to configure if you aren’t much for text configuration files. I do like it for quick and easy LetsEncrypt SSL cert management, and it’s integration with Certbot, especially when you have LE moving to very short SSL lifetimes. This can all be done manually with cronjobs etc, but NPM is pretty low effort and works well.
Other reverse proxies that use their own engines are Traefik, Caddy and HAProxy. They each have their use cases, such as docker integration or high availability. None are as easy to use as NPM in my opinion.
Caddy has been pretty straightforward for me tbh, Let’s Encrypt built in, cloudlfare integration with a mature plugin, everything else is configured with a Caddyfile that has sane defaults. Normally, exposing a service is just a few lines to add to that file. I find the lack of a web ui a positive rather than a missing feature.
