Packet filtering with iptable

Netfilter implementation

Just as a reminder: netfilter provides a way for kernel modules to register callbacks/hooks (there are 5 of them) with the network stacks (IPv4,6 and DecNET.) iptable implements in the kernel a named array of rules. For the purpose of implementing a firewall, tracking connections or doing NAT, packets arriving at the netfilter hooks are sent traversing iptables and might or might not get out of it alive.

About the use of the limit module (found in the Packet Filtering HOWTO, from netfilter.org:)

• By combining the number of packet to accept per unit of time (like a second) and the number of burst packet, one can implement syn-flood protection. For instance: -p tcp --syn -m limit --limit 1/s will make you accept five SYN request in burst, after allowing only one per second and reconstituing the burst buffer by one shot every second.

• With -p tcp --tcp-flags SYN,ACK,FIN,RST RST... and limits, one disable a furtive port scanner.

• With -p icmp -icmp-type echo-request and limits, one deals with the ping of death.

Note that the rules can be injected into the packet filtering infrastructure using the iptables commands, but the libipq API is provided as a way to interact from user space with iptables. For instance, there's a version of snort that receives packets from iptables instead of getting them from libpcap and will inform iptables whether the packet should be dropped, rejected or modified.

Firewalling with netfilter

Existing chains:

• PREROUTING: before the route decision is taken (does mangling and nat)
  
• FORWARD, when the firewall is routing input traffic, goes to post-routing (does mangling and filtering)
  
• INPUT: on the incoming traffic (does mangling and filtering)
  
• OUTPUT: the outgoing traffic, goes to post-routing (does mangling, nat and filtering)
  
• POSTROUTING (mangling and nat)

Each tables (filter, mangle and nat) in a chain can be filtered. Each chain implements rule based filtering on its table, and after consultation, the fate of the packet will be decided upon: ACCEPT or DROP. If no rule matches the packing under scrutiny, then the default chain policy is applied -- usually, you want to DROP the packed if you failed to successfully determine its fate after filtering.

Connection tracking:

Tracking connections at the firewall level is important -- for instance, you want to allow new and established connection to leave your network, and established connection to enter your network. Note that after a connection has been established and a few packets have been sent, the connection is declared assured.

Tracking TCP connections closure is done by recognizing the FIN/ACK or RST sequence, and letting the connection enter a time wait status to give a chance to all packets to traverse the firewall ruleset (thing about out-of-order packets reaching the firewall after the connection reset packet has been received.)

Note that UDP and ICMP traffic is tracked as connection in the sense of monitoring what is being sent to who and back, although the UDP and ICMP protocols aren't establishing connections by themselves. Since ICMP packets can be sent back to connection orignators to indicate of a problem, they should be considered as related to other connection traffic.

Some complex protocols (such as FTP) that are sending related connections requests in the a control connection require the firewall to examine the traffic to mark requested new connection as related.

Further readings that I should indulge in:

• PF stateful packet filter porting
• Design and performance of OpenBSD's pf