Create and Optimize Firewall Rules

This skill creates, analyzes, and optimizes firewall rules across Linux iptables, UFW, pfSense, and cloud provider firewalls (AWS Security Groups, Azure NSGs, GCP Firewall Rules). Every ruleset follows a default-deny philosophy: block everything by default, place the most restrictive rules first and grow more permissive from there, and document the business justification behind each rule. Rule ordering is tuned for performance and clarity - rules ordered by match frequency with the most common traffic first, DENY rules placed before ALLOW rules for the same service, specific source and destination addresses preferred over broad ranges, and similar patterns consolidated to minimize the total rule count.

Use it when writing or auditing firewall rules for a specific platform - a Linux host, a cloud VPC, or a segmented internal network - that needs default-deny discipline and documented justification for every rule. It is not a substitute for its own maintenance discipline: rules should be tested in staging before production, version-controlled, and regularly audited for unused entries via hit-count monitoring.

Given a target platform and traffic requirements, it produces platform-specific rulesets: Linux iptables (flushing existing rules, default-DROP INPUT/FORWARD with ACCEPT OUTPUT, loopback and established/related connections allowed, rate-limited SSH, HTTP/HTTPS, subnet-scoped database access, and sampled logging of dropped packets), Ubuntu UFW (reset to deny-incoming/allow-outgoing defaults, rate-limited SSH, named or port-based web service rules, subnet- and IP-scoped access, and commented rules for auditability), and cloud infrastructure-as-code (an AWS Security Group scoping HTTP and HTTPS ingress to an ALB security group and SSH ingress to a bastion security group rather than open CIDR ranges, with unrestricted egress). It also produces advanced patterns: network segmentation (DMZ-to-internal traffic restricted to specific ports before a catch-all DROP, and blocked lateral movement between internal subnets), and application-specific rules for Docker container-to-container traffic, Kubernetes pod-to-pod communication, and the NodePort service range.

resource "aws_security_group" "web_server" {
  name_prefix = "web-server-"
  description = "Security group for web servers"
  vpc_id      = var.vpc_id

  # HTTP access from ALB only
  ingress {
    description     = "HTTP from ALB"
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  # HTTPS from ALB only
  ingress {
    description     = "HTTPS from ALB"
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  # SSH from bastion host only
  ingress {
    description     = "SSH from bastion"
    from_port       = 22
    to_port         = 22
    protocol        = "tcp"
    security_groups = [aws_security_group.bastion.id]
  }

  # All outbound traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-server-sg"
  }
}

Security hardening layers on top: rate limiting via hashlimit per source IP for HTTP traffic, SSH brute-force protection using the recent module to drop repeat connection attempts within a rolling window, SYN-flood protection capping new SYN packets per second, geo/IP-reputation blocking of known-malicious ranges (using ipset for large blacklists rather than individual rules), and a dedicated logging chain that tags and drops unmatched traffic while separately logging specific connection types like SSH and HTTP. Troubleshooting relies on standard networking tools - connectivity checks (nc, telnet), path tracing (traceroute, mtr), log monitoring (tail/journalctl), and rule inspection (iptables -L --line-numbers, ufw status numbered) plus rule-processing time checks.

Network and platform engineers who need concrete, copy-pasteable rulesets across on-prem and cloud firewalls, backed by a maintenance discipline: documenting each rule's business purpose and owner, regular audits and cleanup, version-controlled configurations, staging tests before production changes, break-glass emergency access procedures, and hit-count monitoring to catch unused rules before they accumulate.