Re: IPTables State Tracking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Greetings Josh,

Josh.Berry@xxxxxxxxxxxx wrote:

Does IPTables track virtual state of ICMP and UDP packets?

That it does.


I know that
UDP and ICMP are not stateful connections, but does IPTables perform
pseudo-stateful tracking of these connections such as some other
firewalls that basically timeout UDP/ICMP connections after a specific
time?

ICMP gets a bit more complex than that. You can do this for things like Echo-requests, time request, subnet mask requests, etc. as the source and destination remains constant. You can also predict the transport and type/codes used in the response. This is referred to as traffic that is part of a previously "established" session.


When you get into ICMP type 3's and 11's however (host unreachables, TTL exceeded, etc.) you get a bit of a problem as the system transmitting these packets is usually _not_ the host you sent the original packet to. Usually its some router or firewall along the path of the connection. Also, the packet type to some extent is unexpected (you transmitted TCP or UDP and now you are getting back an ICMP packet from some unidentified host).

Both of these packet types store 28 bytes in the payload which identifies the original packet that generated the error (like the TCP or UDP example above). A good firewall (like iptables) can use this payload information to determine if the packet should be allowed through or not.

So these ICMP error packets are not part of the original session, but they were generated because of it. For this reason it is referred to as "related" traffic.

So the good news is yes, iptables will easily handle established and related traffic. The better news is that you have the flexibility to handle them independently and do what ever you want with either.

Note that when you are comparing firewalls you really have to look at the vendor implementation. For example there are a number of firewalls on the market that claim to be based on stateful inspection, and for some protocols they actually are, but for type 3's and 11's they fall back on rudimentary packet filtering (let them all in including the bogus ones, or none at all).

HTH,
C






[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux