Firewall & Access Control Policies

Building, auditing, and automating network defense policies with AI assistance — from iptables rules to Zero Trust architecture.

Today's Agenda

1. Firewall fundamentals — packet filtering, stateful, application-layer
2. iptables / nftables — rule writing with AI assistance
3. Cloud security groups — AWS SGs, Azure NSGs, GCP firewall rules
4. Web Application Firewalls — ModSecurity, AWS WAF, Cloudflare
5. Zero Trust architecture — principles and implementation
6. AI-assisted policy generation — natural language to rules
7. Network segmentation — AI-optimized zone design
8. Access control models — RBAC, ABAC, MAC
9. Policy auditing — finding overly permissive rules with AI
10. CTF Challenge — defend a network with firewall rules

Firewall Fundamentals

A firewall is a network security device that monitors and filters incoming and outgoing traffic based on a defined set of security rules. It acts as the first line of defense between trusted internal networks and untrusted external networks.

Three Generations of Firewalls

• Packet Filtering (1st gen) — inspects individual packets against rules based on IP, port, protocol. Stateless — no memory of previous packets.
• Stateful Inspection (2nd gen) — tracks active connections in a state table. Understands that a reply packet belongs to an established connection.
• Application-Layer / NGFW (3rd gen) — deep packet inspection (DPI), understands HTTP, DNS, TLS. Can block specific URLs, malware signatures, or application behaviors.

Packet Filtering

The simplest firewall type. Each packet is examined independently against an ordered list of rules. No awareness of connection state or application context.

Stateful Inspection

Stateful firewalls maintain a connection table that tracks the state of every active session (NEW, ESTABLISHED, RELATED, INVALID).

Application-Layer Firewalls & NGFW

Next-Generation Firewalls combine traditional firewall capabilities with deep packet inspection, intrusion prevention, and application awareness.

• Deep Packet Inspection (DPI) — examines packet payloads, not just headers
• Application identification — recognizes apps regardless of port (e.g., Slack on port 443)
• TLS inspection — decrypts, inspects, and re-encrypts HTTPS traffic
• Integrated IPS — blocks known exploits and attack patterns inline
• User identity awareness — applies policies per user/group, not just per IP

iptables: Linux Firewall Foundation

iptables is the traditional Linux packet filtering framework. Rules are organized into tables (filter, nat, mangle) and chains (INPUT, OUTPUT, FORWARD).

Rule Anatomy

# Structure: iptables -t TABLE -A CHAIN [match criteria] -j TARGET

# Allow incoming SSH from specific subnet
iptables -A INPUT -p tcp -s 10.0.1.0/24 --dport 22 -j ACCEPT

# Allow established/related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Drop all other incoming traffic (default deny)
iptables -A INPUT -j DROP

Rules are evaluated top-to-bottom. First match wins. Order matters enormously.

Realistic iptables Ruleset: Web Server

#!/bin/bash
# Flush existing rules
iptables -F
iptables -X

# Default policies: deny all incoming, allow outgoing
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow established and related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from management subnet only
iptables -A INPUT -p tcp -s 10.0.100.0/24 --dport 22 -j ACCEPT

# Allow HTTP and HTTPS from anywhere
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow ICMP (ping) with rate limiting
iptables -A INPUT -p icmp --icmp-type echo-request \
  -m limit --limit 1/s --limit-burst 4 -j ACCEPT

# Log dropped packets (limited to avoid log flooding)
iptables -A INPUT -m limit --limit 5/min -j LOG \
  --log-prefix "IPT-DROP: " --log-level 4

# Final explicit drop
iptables -A INPUT -j DROP

nftables: The Modern Replacement

nftables replaces iptables with a cleaner syntax, better performance, and unified IPv4/IPv6 handling. It is the default on Debian 10+, RHEL 8+, and Ubuntu 20.04+.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    # Allow loopback
    iif "lo" accept

    # Track connections
    ct state established,related accept
    ct state invalid drop

    # SSH from management only
    ip saddr 10.0.100.0/24 tcp dport 22 accept

    # Web traffic
    tcp dport { 80, 443 } accept

    # ICMP rate limited
    icmp type echo-request limit rate 1/second burst 4 packets accept

    # Log and drop everything else
    limit rate 5/minute log prefix "NFT-DROP: "
    drop
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}

AI-Assisted iptables/nftables Rule Writing

Instead of memorizing complex syntax, describe your desired firewall behavior to an AI and have it generate rules.

AI Workflow for Firewall Rules

1. Describe intent in natural language — what services, who accesses them
2. AI generates rules with proper syntax and ordering
3. Review critically — check for missing rules, ordering issues, overly broad matches
4. Test in staging — never deploy AI-generated rules directly to production
5. Ask AI to audit — "Are there any security gaps in these rules?"

AWS Security Groups

AWS Security Groups are stateful virtual firewalls attached to EC2 instances. They allow rules only (no explicit deny) — anything not allowed is implicitly denied.

{
  "GroupName": "web-server-sg",
  "Description": "Security group for production web servers",
  "IpPermissions": [
    {
      "IpProtocol": "tcp",
      "FromPort": 443,
      "ToPort": 443,
      "IpRanges": [
        { "CidrIp": "0.0.0.0/0", "Description": "HTTPS from anywhere" }
      ]
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 80,
      "ToPort": 80,
      "IpRanges": [
        { "CidrIp": "0.0.0.0/0", "Description": "HTTP (redirects to HTTPS)" }
      ]
    },
    {
      "IpProtocol": "tcp",
      "FromPort": 22,
      "ToPort": 22,
      "UserIdGroupPairs": [
        { "GroupId": "sg-0a1b2c3d4e5f", "Description": "SSH from bastion SG" }
      ]
    }
  ]
}

Azure NSGs & GCP Firewall Rules

Cross-Cloud Pattern

All three clouds follow the same principle: least privilege by default. Only open what is explicitly needed, reference other security groups/tags instead of IPs when possible.

Cloud Firewall Comparison

Web Application Firewalls (WAF)

A WAF operates at Layer 7 (application layer), inspecting HTTP/HTTPS requests to block web-specific attacks that network firewalls cannot see.

What WAFs Protect Against

• SQL injection — malicious SQL in form fields and URL parameters
• Cross-Site Scripting (XSS) — injected JavaScript in user input
• Command injection — OS commands in HTTP requests
• Path traversal — ../../etc/passwd in URLs
• DDoS at Layer 7 — HTTP floods, slowloris attacks
• Bot traffic — credential stuffing, scraping, abuse

ModSecurity & OWASP Core Rule Set

ModSecurity is the most widely deployed open-source WAF. It runs as a module inside Apache, Nginx, or IIS and uses the OWASP Core Rule Set (CRS) for baseline protection.

# ModSecurity Configuration
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.log

# Block SQL injection in query string
SecRule ARGS "@detectSQLi" \
  "id:1001,\
   phase:2,\
   deny,\
   status:403,\
   msg:'SQL Injection Detected',\
   severity:'CRITICAL',\
   tag:'attack-sqli',\
   logdata:'Matched Data: %{TX.0}'"

# Block path traversal attempts
SecRule REQUEST_URI "@contains ../" \
  "id:1002,\
   phase:1,\
   deny,\
   status:403,\
   msg:'Path Traversal Attempt',\
   severity:'CRITICAL',\
   tag:'attack-lfi'"

# Rate limit requests per IP (60 req/min)
SecRule IP:REQUESTS "@gt 60" \
  "id:1003,\
   phase:1,\
   deny,\
   status:429,\
   msg:'Rate Limit Exceeded'"

Cloud WAF Services

AWS WAF Rule Example

{
  "Name": "BlockSQLi",
  "Priority": 1,
  "Action": { "Block": {} },
  "Statement": {
    "SqliMatchStatement": {
      "FieldToMatch": { "AllQueryArguments": {} },
      "TextTransformations": [
        { "Priority": 0, "Type": "URL_DECODE" },
        { "Priority": 1, "Type": "HTML_ENTITY_DECODE" }
      ]
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlockSQLi"
  }
}

Zero Trust Architecture

"Never trust, always verify." Zero Trust assumes no implicit trust based on network location. Every request must be authenticated, authorized, and encrypted — regardless of origin.

Core Principles (NIST SP 800-207)

• Verify explicitly — authenticate and authorize every access request using all available data points (identity, location, device health, data classification)
• Least privilege access — limit user access with just-in-time and just-enough-access (JIT/JEA)
• Assume breach — minimize blast radius through microsegmentation, end-to-end encryption, and continuous monitoring

Implementing Zero Trust

Key Components

AI-Assisted Policy Generation

AI transforms how we create and maintain security policies. Instead of hand-crafting complex rule syntax, describe your security intent and let AI generate the implementation.

Example: Natural Language to AWS Security Group

AI generates:

• Three separate security group definitions with cross-references
• Proper ingress and egress rules per tier
• SG-to-SG references instead of IP ranges where possible
• Descriptive comments for each rule

AI-Generated Three-Tier Security Groups

# AI-generated AWS CLI commands for three-tier architecture

# Web Tier SG
aws ec2 create-security-group --group-name web-tier-sg \
  --description "Web tier - accepts HTTPS, talks to app tier"

aws ec2 authorize-security-group-ingress --group-name web-tier-sg \
  --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-name web-tier-sg \
  --protocol tcp --port 22 --cidr 10.0.100.0/24

# App Tier SG
aws ec2 create-security-group --group-name app-tier-sg \
  --description "App tier - accepts from web tier, talks to DB tier"

aws ec2 authorize-security-group-ingress --group-name app-tier-sg \
  --protocol tcp --port 8080 \
  --source-group web-tier-sg
aws ec2 authorize-security-group-ingress --group-name app-tier-sg \
  --protocol tcp --port 22 --cidr 10.0.100.0/24

# DB Tier SG
aws ec2 create-security-group --group-name db-tier-sg \
  --description "DB tier - accepts only from app tier"

aws ec2 authorize-security-group-ingress --group-name db-tier-sg \
  --protocol tcp --port 5432 \
  --source-group app-tier-sg
aws ec2 authorize-security-group-ingress --group-name db-tier-sg \
  --protocol tcp --port 22 --cidr 10.0.100.0/24

Network Segmentation Strategies

Segmentation divides a network into isolated zones to limit lateral movement when a breach occurs. Each zone has its own firewall policies controlling inter-zone traffic.

Common Zone Architecture

AI-Optimized Zone Design

AI can analyze network traffic patterns and recommend optimal segmentation by identifying which services actually communicate with each other.

AI-Assisted Approach

1. Collect flow data — feed NetFlow/sFlow data or VPC Flow Logs to AI
2. AI maps communication patterns — identifies actual service dependencies
3. Propose zone boundaries — group services by communication patterns and trust level
4. Generate inter-zone rules — create policies that allow required flows, block everything else
5. Simulate impact — AI predicts which connections would break before you apply rules

Access Control Models

Access control determines who can access what resources and under what conditions. Three major models dominate enterprise security.

RBAC Implementation Patterns

# RBAC Implementation Example
from functools import wraps

ROLES = {
    "admin":     {"read", "write", "delete", "deploy", "manage_users"},
    "developer": {"read", "write", "deploy_staging"},
    "analyst":   {"read", "run_queries"},
    "viewer":    {"read"},
}

def require_permission(permission):
    """Decorator to enforce RBAC on API endpoints."""
    def decorator(func):
        @wraps(func)
        def wrapper(user, *args, **kwargs):
            user_perms = ROLES.get(user.role, set())
            if permission not in user_perms:
                raise PermissionError(
                    f"Role '{user.role}' lacks '{permission}' permission"
                )
            return func(user, *args, **kwargs)
        return wrapper
    return decorator

@require_permission("deploy")
def deploy_to_production(user, service, version):
    """Only admins can deploy to production."""
    print(f"{user.name} deploying {service} v{version} to production")

@require_permission("deploy_staging")
def deploy_to_staging(user, service, version):
    """Developers and admins can deploy to staging."""
    print(f"{user.name} deploying {service} v{version} to staging")

ABAC with Open Policy Agent (OPA)

OPA uses the Rego policy language to make fine-grained, attribute-based access decisions.

# policy.rego — ABAC policy for API access
package api.authz

default allow = false

# Allow if user is in the same department as the resource owner
allow {
    input.user.department == input.resource.owner_department
    input.action == "read"
}

# Allow write only during business hours from corporate network
allow {
    input.action == "write"
    input.user.clearance >= input.resource.classification
    is_business_hours
    is_corporate_network
}

is_business_hours {
    hour := time.clock(time.now_ns())[0]
    hour >= 8
    hour < 18
}

is_corporate_network {
    net.cidr_contains("10.0.0.0/8", input.user.source_ip)
}

Mandatory Access Control: SELinux

SELinux enforces MAC on Linux by labeling every process and file with a security context. Even root cannot bypass SELinux policies.

# View SELinux context of a file
$ ls -Z /var/www/html/index.html
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

# View SELinux context of a process
$ ps -eZ | grep httpd
system_u:system_r:httpd_t:s0  1234 ?  00:00:05 httpd

# Policy: httpd_t can read httpd_sys_content_t
# If an attacker compromises Apache, they STILL can't read
# files labeled with other types (e.g., user_home_t, etc_t)

# Set SELinux to enforcing mode
$ sudo setenforce 1

# Check for policy violations
$ sudo ausearch -m avc -ts today
type=AVC msg=audit(1234567890.123:456): avc: denied { read } \
  for pid=1234 comm="httpd" name="shadow" \
  scontext=system_u:system_r:httpd_t:s0 \
  tcontext=system_u:object_r:shadow_t:s0 tclass=file

Policy Auditing: Finding Overly Permissive Rules

The most dangerous firewall is one full of rules that were "temporary" three years ago. AI excels at finding security gaps humans overlook.

Common Findings AI Catches

• 0.0.0.0/0 on SSH (port 22) — SSH exposed to the entire internet
• Overly broad port ranges — 0-65535 allowed where only specific ports needed
• Stale rules — rules for decommissioned servers still active
• Redundant rules — later rules shadowed by earlier, broader rules
• Missing egress controls — no outbound filtering, allowing data exfiltration
• Unused security groups — old SGs with wide-open rules still attached

AI-Powered Firewall Audit

# Problematic ruleset for AI to audit
iptables -A INPUT -p tcp --dport 22 -j ACCEPT           # SSH open to world!
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT          # MySQL open to world!
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080:8090 -j ACCEPT     # Broad port range
iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT                # Entire /8 trusted
iptables -A INPUT -j DROP

AI Audit Findings

1. Critical: SSH (22) and MySQL (3306) open to all source IPs
2. High: Entire 10.0.0.0/8 trusted — overly broad, should use specific subnets
3. Medium: Port range 8080–8090 should be limited to specific ports in use
4. Low: No rate limiting, no logging before the DROP rule
5. Missing: No ESTABLISHED,RELATED rule — stateful tracking not leveraged

AI-Remediated Ruleset

After AI audit, the ruleset is tightened with specific source restrictions, rate limiting, logging, and proper connection tracking.

#!/bin/bash
# AI-remediated iptables ruleset
iptables -F && iptables -X
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Loopback
iptables -A INPUT -i lo -j ACCEPT

# Connection tracking (was missing)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# SSH restricted to management subnet with rate limit
iptables -A INPUT -p tcp -s 10.0.100.0/24 --dport 22 \
  -m conntrack --ctstate NEW \
  -m limit --limit 3/min --limit-burst 5 -j ACCEPT

# MySQL restricted to app server subnet only
iptables -A INPUT -p tcp -s 10.0.2.0/24 --dport 3306 -j ACCEPT

# Web traffic from anywhere
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Only specific ports instead of range
iptables -A INPUT -p tcp -s 10.0.2.0/24 --dport 8080 -j ACCEPT
iptables -A INPUT -p tcp -s 10.0.2.0/24 --dport 8081 -j ACCEPT

# Log before drop
iptables -A INPUT -m limit --limit 5/min \
  -j LOG --log-prefix "IPT-DROP: "
iptables -A INPUT -j DROP

Automated Compliance Checking

Use AI to continuously verify firewall rules comply with organizational policies and regulatory frameworks.

"""AI-assisted firewall compliance checker."""
import json

COMPLIANCE_RULES = {
    "PCI-DSS-1.3.1": {
        "desc": "Restrict inbound traffic to only that which is necessary",
        "check": lambda r: r.get("source") != "0.0.0.0/0"
                           or r["port"] in [80, 443],
    },
    "PCI-DSS-1.3.2": {
        "desc": "Limit inbound internet traffic to DMZ IPs",
        "check": lambda r: r.get("zone") == "dmz"
                           if r.get("source") == "0.0.0.0/0" else True,
    },
    "CIS-9.2.1": {
        "desc": "SSH must not be accessible from 0.0.0.0/0",
        "check": lambda r: not (r["port"] == 22
                                and r.get("source") == "0.0.0.0/0"),
    },
}

def audit_rules(security_group_rules):
    """Check rules against compliance framework."""
    violations = []
    for rule in security_group_rules:
        for control_id, control in COMPLIANCE_RULES.items():
            if not control["check"](rule):
                violations.append({
                    "rule": rule,
                    "violation": control_id,
                    "description": control["desc"],
                })
    return violations

Defense in Depth: Layered Firewall Strategy

No single firewall layer is sufficient. A robust architecture layers multiple types of filtering at different points in the network.

Firewall Logging & Monitoring

Firewall rules without logging are security theater. You must know what is being blocked and what is being allowed.

Essential Log Sources

• Denied connections — who is trying to reach what? Recon or misconfiguration?
• Allowed connections — sample logging to verify expected traffic patterns
• State table overflows — signs of DDoS or resource exhaustion
• Rule hit counts — identify unused rules (candidates for removal)
• Configuration changes — audit trail for who changed what and when

Firewall & ACL Best Practices

1. Default deny — start with blocking everything, then allow what is needed
2. Least privilege — open only the ports, protocols, and source IPs required
3. Document every rule — include who requested it, why, and an expiration date
4. Use connection tracking — always leverage ESTABLISHED,RELATED states
5. Log before you drop — but rate-limit logs to avoid disk exhaustion
6. Review regularly — quarterly audits with AI assistance to find stale rules
7. Use security group references — prefer SG-to-SG over IP-based rules in cloud
8. Separate management traffic — SSH/RDP on a dedicated management network
9. Test before deploy — use iptables -C to check, nft --check to validate
10. Version control your rules — firewall-as-code in Git with PR reviews

CTF Challenge: Secure the Network

Network Layout

• Web Server (10.0.1.10) — serves HTTPS on port 443, HTTP on port 80
• App Server (10.0.2.10) — API on port 8080, receives from web server only
• Database (10.0.3.10) — PostgreSQL on 5432, app server only
• Admin Bastion (10.0.100.5) — SSH to all servers on port 22
• DNS Server (10.0.1.53) — serves DNS (53/udp, 53/tcp) to all internal hosts

Your Tasks

1. Write nftables rules for each server enforcing least privilege
2. Create AWS security group JSON for the same architecture
3. Write a ModSecurity rule protecting the web server from SQLi and XSS
4. Use AI to audit your rules — fix any findings
5. Document your network segmentation rationale

CTF Challenge: Hints & Evaluation

Key Questions to Ask Yourself

• Can the database server reach the internet? It should not.
• Can the web server connect to the database directly? It should not.
• Is SSH limited to the bastion host only? It must be.
• Are you logging dropped packets? You should be.
• Are you using connection tracking? You must be.
• Do you have egress rules? Do not forget outbound filtering.

Scoring Criteria

Lesson 05 Recap

• Firewalls evolve — from packet filtering to stateful inspection to application-aware NGFWs
• iptables/nftables — Linux host firewalls with powerful rule syntax; AI makes writing them easier
• Cloud security groups — AWS SGs, Azure NSGs, GCP rules all follow least-privilege principles
• WAFs — Layer 7 protection against SQLi, XSS, and other web attacks (ModSecurity, AWS WAF, Cloudflare)
• Zero Trust — never trust, always verify; microsegmentation replaces perimeter trust
• Access control models — RBAC for simplicity, ABAC for flexibility, MAC for mandatory enforcement
• AI-assisted policy — generate rules from natural language, audit for gaps, automate compliance
• Defense in depth — layer firewalls at edge, network, host, and application levels