Firewall

Configure firewalls on servers and cloud providers with security best practices.

Security Scan

This is an instruction-only skill that offers firewall best-practice guidance and does not request credentials, install code, or perform any actions—its requirements and instructions are consistent with its stated purpose.

Purpose & Capability

The name and description (configure firewalls / best practices) match the SKILL.md content. The skill requests no binaries, env vars, or installs, which is proportionate for a documentation/guidance skill.

Instruction Scope

SKILL.md contains high-level, actionable guidance (ports to avoid/open, provider vs OS firewalls, Docker caveats, IPv6, debugging tips). It does not instruct the agent to read files, access credentials, call external endpoints, run specific commands, or transmit data—staying within the intended advisory scope.

Install Mechanism

No install spec and no code files: lowest-risk model. Nothing will be written to disk or downloaded by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths. That is appropriate for a purely instructional guide.

Persistence & Privilege

always is false and the skill does not request persistent presence or modify other skills; autonomous invocation is allowed by default but the skill has no actions to perform, so privilege surface is minimal.

Assessment

This skill is a read-only set of best-practice instructions and will not change your systems or ask for credentials. It can be safely used as a checklist or reference. Important practical notes before acting on the guidance: (1) follow the advice about testing in a second session and keeping provider console access to avoid locking yourself out; (2) the skill does not perform automated changes—if you want automation, use a well-reviewed tool/CLI/UIs from your cloud provider and provide credentials only to those tools; (3) verify provider-specific details in official docs (rule semantics, IPv6 behaviour, Docker interactions) before applying changes; (4) consider testing changes in a staging environment or with a recovery plan in place. If you expected the skill to actually apply firewall rules for you, note that it contains only instructions and will not perform any network or system operations.

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