Skill: ivangdavila/firewall (version 1.0.0)

--- 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


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)