Hardening an exposed server: the minimal list that changes everything

Start by closing, not by watching

The first measure is not a detection tool: it is the inventory of what listens on the network. A database, an administration interface or a monitoring dashboard reachable publicly are open doors, whatever the rules behind them.

1. List the ports actually open from outside, not the ones in the configuration.
2. Put everything that can be behind a reverse proxy or a tunnel.
3. Restrict administration access to a VPN or to known addresses.
4. Leave public only the services that must be: web, and nothing else by default.

Access: keys, separate accounts, revocation

Password authentication on remote access must be disabled. Each person has their own key and their own account: that is what allows revoking access without general coordination, and knowing who did what.

Plan the exit as much as the entry. The question “what happens if this key leaks tonight?” must have an answer in one command, not in a meeting.

Limit what gets through anyway

No line is enough on its own. Their value is cumulative: they reduce the noise until the attempts that deserve human attention become visible.

Make the logs usable before you need them

Logs kept only on the machine concerned disappear with it. A copy off the server, with sufficient retention, is what will separate an investigation from a guess.

Check as well that the visitor’s real address reaches the application: behind a badly configured proxy, every access appears to come from the same internal address, and any analysis becomes impossible.

Check from the outside, regularly

Hardening is verified from the internet, not from the configuration. A monthly scan of open ports and a certificate check are enough to detect drift: a service exposed temporarily for a test, and never closed again.

The best protection remains the surface you do not expose. Everything else consists of watching what you could not close.