A firewall that does not lock you out
Every server needs one and it takes ten minutes. The only real risk is locking yourself out while writing it.
Deny by default
Allow what you actually serve — SSH, your web ports, whatever your application needs — and drop the rest. An allow-list is short, readable and hard to get subtly wrong.
Never on the public internet
- Database ports: MySQL 3306, PostgreSQL 5432, MongoDB 27017
- Caches: Redis 6379, Memcached 11211
- Management: Docker API 2375, Kubernetes, panels on odd ports
- Anything with a default password you have not changed
These are what get servers compromised, and a compromised server on our network becomes an abuse case even when you are the victim. Bind them to localhost, or firewall them to the addresses that need them.
Do not forget IPv6
IPv4 and IPv6 rules are separate. A machine that is closed on IPv4 can be wide open
on IPv6, and attackers scan both. Check with ss -ltnp what is actually
listening on which family.
Test without stranding yourself
Apply the rules, then open a second session before you close the
first. On systems with iptables-apply or a timed rollback, use it. And
remember the console is always there when it goes wrong
— a firewall cannot block a keyboard.
Rate limits are not a DDoS defence
They help against brute force and scrapers. Volumetric attacks are handled upstream before they reach you: see how DDoS filtering works.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base