- name
- Firewall
- description
- Configure firewalls on servers and cloud providers with security best practices.
- metadata
- {"clawdbot":{"emoji":"🛡️","os":["linux","darwin","win32"]}}
Firewall Rules
Critical First Steps
- Allow SSH/remote access before enabling any firewall — enabling first locks you out
- Test access in a second session before closing the first — verify the rule actually works
- Know how to access provider console — it's the only way back if locked out
Default Stance
- Default deny all incoming traffic — only open what you explicitly need
- Default allow outgoing traffic — most apps need to reach the internet
- Every open port is attack surface — question each one before adding
Essential Ports
- SSH (22 or custom): Always needed for remote access — consider limiting to your IP only
- HTTP (80): Only if serving web traffic — also needed for Let's Encrypt HTTP challenge
- HTTPS (443): For production web services
- Don't open database ports (3306, 5432, 27017) to the internet — access via SSH tunnel or private network
Provider Firewalls (Hetzner, DigitalOcean, AWS, etc.)
- Provider firewall applies before traffic reaches your server — faster, less server load
- Changes usually apply immediately — no reload command needed
- Stateful by default — allow inbound, responses automatically allowed outbound
- Apply to server groups for consistency — easier than per-server rules
- Provider firewall + OS firewall = defense in depth — use both when possible
IP Restrictions
- Limit SSH to known IPs when possible — dramatically reduces attack surface
- Your home IP may change — use a VPN with static IP or update rules when it changes
- Allow IP ranges with CIDR notation — /32 is single IP, /24 is 256 IPs
- Some providers support dynamic DNS in rules — check before building complex solutions
Common Services to Consider
- VPN (WireGuard: 51820/UDP, OpenVPN: 1194) — allows secure access without exposing other ports
- Mail (25, 465, 587) — only if running mail server
- DNS (53 TCP/UDP) — only if running DNS server
- Monitoring agents may need outbound access to specific IPs
Docker Warning
- Docker bypasses most OS firewalls by default — containers expose ports regardless of UFW/iptables
- Solution: bind containers to localhost only and use reverse proxy for public access
- Or configure Docker to respect firewall rules — requires additional setup
- Provider-level firewalls still work — they block before traffic reaches Docker
IPv6
- Firewalls often have separate IPv4 and IPv6 rules — configure both
- Provider firewalls may handle both together — check their documentation
- Attackers probe IPv6 when IPv4 is locked down — don't neglect it
Debugging
- Test from outside your network — rules may look correct but not work
- Provider dashboards often show blocked traffic logs
- "Connection refused" = port closed properly; "Connection timeout" = firewall dropping silently
- Online port scanners verify what's actually open from the internet
Common Mistakes
- Opening ports "temporarily" and forgetting to close them
- Opening 80/443 when no web server runs — unnecessary exposure
- Forgetting UDP for services that need it — DNS, VPN, game servers
- Assuming firewall is active — verify it's actually running/applied
- Only configuring IPv4 — leaving IPv6 wide open
- Trusting "security through obscurity" — non-standard ports slow attackers, don't stop them