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
next prev 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