Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Chris Brenton <cbrenton@chrisbrenton.org>
To: Josh.Berry@compucom.com
Cc: netfilter@lists.netfilter.org
Subject: Re: IPTables State Tracking
Date: Fri, 29 Aug 2003 20:33:39 -0400	[thread overview]
Message-ID: <3F4FF0E3.2070709@chrisbrenton.org> (raw)
In-Reply-To: 0C7C6E1720E8D74FB52EBEF93649730A0116BF07@2k099exm01.compucom.local

Greetings Josh,

Josh.Berry@compucom.com 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






  parent reply	other threads:[~2003-08-30  0:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-29 14:38 IPTables State Tracking Josh.Berry
2003-08-30  0:11 ` James Mullens
2003-08-30  0:33 ` Chris Brenton [this message]
2003-08-30  3:41 ` Mark E. Donaldson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F4FF0E3.2070709@chrisbrenton.org \
    --to=cbrenton@chrisbrenton.org \
    --cc=Josh.Berry@compucom.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox