Your host firewall is probably not the one deciding
Auditing a server firewall and finding it correct proves nothing if the provider is filtering in front of it.
Two firewalls, one of them invisible
Most cloud hosts put a network firewall in front of the instance, configured in their control panel rather than on the machine. It is entirely separate from whatever the operating system is running.
That leads to two opposite mistakes:
- False confidence. The host firewall allows a port, so you assume the service is reachable. It is not, because the provider is dropping it upstream.
- False security. The host firewall blocks a port, so you assume it is closed. If the provider layer allows it and the service binds to all interfaces, the block may not be doing what you think.
Test from outside, always
The only reliable check is a connection attempt from another network. Checking listening sockets on the machine tells you what the machine believes. It tells you nothing about what the internet can reach.
Do this after any firewall change, in both directions: confirm what should be open is open, and confirm what should be closed is closed.
Bind to loopback rather than filtering
For anything that only needs to be reachable locally, or through a reverse proxy, bind it to the loopback interface instead of relying on a firewall rule. Then no firewall, at any layer, can accidentally expose it.
This matters particularly with containers, where publishing a port often bypasses host firewall rules entirely by inserting its own. A container published to all interfaces can be reachable despite a host rule that appears to forbid it.
Document why each port is open
Every open port should have a reason attached to it somewhere you will find later. Non obvious ones are the dangerous ones: a management port that a fleet of devices genuinely needs will look like an oversight to whoever audits it next, and closing it breaks something six months later with no obvious cause.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.