Firewalls & ACLs

Evolution of Firewalls

Firewalls have evolved dramatically over the past three decades. Each generation addressed a limitation of the previous one — and understanding that progression reveals why modern next-generation firewalls look and behave the way they do.

Generation	Layer	Key Capability	Key Limitation
Packet Filter	L3/L4	Inspect src/dst IP, port, protocol	Stateless — no session context
Stateful Firewall	L4	Track connection state	Cannot inspect application payload
Proxy / ALG	L7	Full application proxy	Performance bottleneck, limited app support
NGFW	L7	App-ID, User-ID, SSL inspection, IPS	Requires proper sizing and tuning

Packet Filter Firewalls

The earliest firewalls operated at layers 3 and 4, examining each packet in complete isolation. Rules matched on source IP, destination IP, source port, destination port, and protocol (TCP, UDP, ICMP). They were fast and simple, but fatally flawed — they had no memory of previous packets.

Limitations of Stateless Inspection

Cannot distinguish a legitimate TCP response from an unsolicited inbound packet with ACK flag set
Cannot detect IP fragmentation attacks that split malicious payloads across multiple packets
No awareness of application content — port 80 is assumed to be HTTP regardless of what is actually running on it
Vulnerable to IP spoofing — source address is not validated

Stateful Firewalls

Stateful firewalls introduced the concept of connection tracking. When a client initiates a TCP connection, the firewall records the session in a state table. Return traffic is automatically permitted because the firewall recognizes it belongs to an established session — no explicit rule needed for the return direction.

State Table and TCP Tracking

The state table stores tuples of: source IP, destination IP, source port, destination port, and protocol. The firewall follows the TCP handshake (SYN → SYN-ACK → ACK) and tracks state transitions:

SYN_SENT — client sent SYN, waiting for server SYN-ACK
SYN_RECEIVED — server sent SYN-ACK, waiting for client ACK
ESTABLISHED — full three-way handshake complete, data can flow
FIN_WAIT / CLOSE_WAIT — connection teardown in progress
TIME_WAIT — connection closed, waiting for stale packets to expire

SYN Flood Attack

Attackers exploit the half-open connection state by sending massive numbers of SYN packets without completing the handshake, exhausting the firewall state table. SYN cookies and connection rate limiting are the standard mitigations.

Next-Generation Firewalls (NGFW)

NGFWs add application-layer intelligence to stateful inspection. Rather than relying on port numbers, they identify applications by their actual behavior and signatures — a process called App-ID on Palo Alto Networks platforms, or deep packet inspection on other vendors.

Core NGFW Capabilities

Application identification regardless of port, protocol, or encryption
User identification — tie policy to users/groups via Active Directory integration
SSL/TLS decryption — inspect encrypted traffic before applying policy
Integrated IPS — detect and block exploits, malware, and command-and-control
URL filtering — categorize and control web access by destination
WildFire / sandbox — submit unknown files for behavioral analysis

Access Control Lists (ACLs)

ACLs are ordered lists of rules applied to router or switch interfaces. Each rule — called an Access Control Entry (ACE) — specifies match criteria and an action (permit or deny). ACLs are typically less sophisticated than firewall policies but are still widely used for coarse-grained traffic control on routers.

First-Match Rule Ordering

ACLs process rules sequentially from top to bottom. As soon as a packet matches a rule, the action is taken and evaluation stops. Rules below a match are never checked for that packet.

Implicit Deny

Every ACL ends with an invisible implicit deny-all rule. If no ACE matches the packet, it is dropped. This is intentional — anything not explicitly permitted is forbidden by default.

Standard vs Extended ACLs (Cisco IOS)

Type	Match Criteria	Numbering	Placement
Standard	Source IP only	1–99, 1300–1999	Close to destination
Extended	Src IP, Dst IP, Protocol, Port	100–199, 2000–2699	Close to source
Named	Either type, identified by name	N/A	Flexible

ACL Configuration Examples

cisco-ios

! Extended ACL — permit web traffic from sales subnet
ip access-list extended SALES-OUTBOUND
 permit tcp 192.168.10.0 0.0.0.255 any eq 80
 permit tcp 192.168.10.0 0.0.0.255 any eq 443
 deny   ip any any log

! Apply to interface
interface GigabitEthernet0/1
 ip access-group SALES-OUTBOUND in

iptables

# Allow established and related traffic (return traffic)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

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

# Allow HTTP and HTTPS outbound
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

# Drop everything else and log it
iptables -A INPUT -j LOG --log-prefix "DROPPED: "
iptables -A INPUT -j DROP

Security Zones

Security zones are logical groupings of interfaces that share the same trust level. Traffic between different zones is inspected and subject to policy. Traffic within the same zone is typically allowed by default.

Classic Three-Zone Model

Zone	Trust Level	Typical Contents
Inside / Trust	High	Internal corporate workstations and servers
Outside / Untrust	Low	The internet / any external network
DMZ	Medium	Publicly accessible servers: web, mail, DNS

DMZ Architecture

The demilitarized zone (DMZ) is a semi-trusted network that sits between the internal network and the internet. Servers in the DMZ are accessible from both directions but are isolated from the internal network by the firewall — so a compromised DMZ server cannot directly attack internal systems.

→

Internet → DMZ: Only specific inbound ports open (e.g., TCP 443 to web server, TCP 25 to mail server).

→

DMZ → Internet: Limited outbound (e.g., DNS queries, software updates).

→

DMZ → Inside: Blocked by default. Only specific backend calls allowed (e.g., DMZ web server querying internal database on TCP 3306 — and even then, only to that specific DB host).

→

Inside → DMZ: Typically permitted for management and monitoring.

Firewall Rule Best Practices

Least privilege — permit only what is explicitly required, deny everything else
Specific rules before general rules — more specific matches should appear higher in the rulebase
Cleanup rule — end every rulebase with an explicit deny-all that logs dropped traffic
Enable logging on all rules — both permitted traffic (for auditing) and denied traffic (for security)
Use named objects and groups — reference address objects and service objects instead of raw IPs and ports
Document every rule — include ticket number, business reason, owner, and expiry date
Review rules regularly — remove or disable stale rules and recertify active rules quarterly
Avoid any-any-any rules — a rule that permits all source, all destination, all application is a policy failure
Never open administrative ports (SSH, RDP, HTTPS mgmt) to the internet directly

Previous Module Next Module