One of the first slides I created for the Virtual Firewalls webinar explained various categories of traffic filters, from stateless (and fast) packet filters to application-level firewalls.
The well-known packet filters (or ACLs) are the bluntest of traffic filtering tools: they match (and pass or drop) individual packets based on their source and destination network addresses and transport layer port numbers. They keep no state (making them extremely fast and implementable in simple hardware) and thus cannot check validity of transport layer sessions or fragmented packets.
Some packet filters give you the option of permitting or dropping fragments based on network layer information (source and destination addresses), others either pass or drop all fragments (and sometimes the behavior is not even configurable).
Packet filters are easy to use in server-only environments. Life becomes interesting as soon as servers start establishing client sessions to other servers, and turns into hell in environments where clients establish ad-hoc sessions to random destination addresses.
Packet filters with automatic reverse rules (example: XenServer vSwitch Controller) are a syntactic sugar on top of vanilla packet filters. Whenever you configure a filtering rule (example: permit inbound TCP traffic to port 80), the ACL configuration software adds a reverse rule in the other direction (permit outbound TCP traffic from port 80).
ACLs that allow matches on established TCP sessions (typically matching TCP traffic with ACK or RST bit set) make your life a bit easier. In server-only environment you can use them to match inbound TCP traffic on specific port numbers and outbound traffic of established TCP sessions (to prevent simple attempts to establish outbound sessions from hijacked servers); in client-only environment you can use them to match return traffic.
Reflexive access lists (Cisco IOS terminology) are the simplest stateful tool in the filtering arsenal. Whenever a TCP or UDP session is permitted by an ACL, the filtering device adds a 5-tuple matching the return traffic of that session to the reverse ACL.
Reflexive ACLs generate one filtering entry per transport layer session. Not surprisingly, you won’t find them in platforms that do packet forwarding and filtering in hardware – they would quickly overload the TCAM (or whatever forwarding/filtering hardware the device is using), cause packet punting to the main CPU and reduce the forwarding performance by orders of magnitude.
Even though reflexive ACLs generate per-session entries (and thus block unwanted traffic that might have been permitted by other less-specific ACLs) they still work on individual packets and thus cannot reliably detect and drop malicious fragments or overlapping TCP segments.
Transport layer session inspection combines reflexive ACLs with fragment reassembly and transport-layer validation. It should detect dirty tricks targeting bugs in host TCP/IP stacks like overlapping fragments or TCP segments.
Application level gateways (ALG) add application awareness to reflexive ACLs. They’re usually used to deal with broken applications (FTP, SIP ...) that exchange transport session endpoints (IP addresses and port numbers) in application payload – an ALG would detect the requests to open additional data sessions and create additional transport-level filtering entries.
Web Application Firewalls (WAF) have to go way beyond ALGs. ALGs try to help applications get the desired connectivity and thus don’t focus on malicious obfuscations. WAFs have to stop the obfuscators; they have to parse application-layer requests like a real server would to detect injection attacks. Needless to say, you won’t find full-blown WAF functionality in reasonably-priced high-bandwidth firewalls.
Which tool should I use?
As always, the universal answer is It Depends; for more details, read the I Don’t Need no Stinking Firewall, To WAF or not to WAF? and WAF Musings blog posts (they are almost three years old, but still pretty relevant).