From: Thomas Ribbrock (emgaron at domain gmx.net)
Date: Wed 26 Jul 2000 - 00:42:56 IST
On Tue, Jul 25, 2000 at 07:41:13PM +0100, Paul Jakma wrote:
> On Tue, 25 Jul 2000, Thomas Ribbrock wrote:
> > Correct me, if I'm wrong, but isn't ipchains stateless? (I've only used
> > ifwadm under Linux so far)
> it doesn't do the tcp connection tracking that other firewalls do, but it
> can do state keeping for specific protocols using kernel modules. (eg to
> make ftp work).
ipfilter tracks more than TCP - keeping state means keeping state on all
Quote form the ipfilter HOTWO:
We want convenience and security in one. Lots of peo-
ple do, that's why Ciscos have an "established" clause that
lets established tcp sessions go through. Ipfw has estab-
lished. Ipfwadm has setup/established. They all have this
feature, but the name is very misleading. When we first saw
it, we thought it meant our packet filter was keeping track
of what was going on, that it knew if a connection was
really established or not. The fact is, they're all taking
the packet's word for it from a part of the packet anybody
can lie about. They read the TCP packet's flags section and
there's the reason UDP/ICMP don't work with it, they have no
such thing. Anybody who can create a packet with bogus
flags can get by a firewall with this setup.
> i don't understand why stateful inspection/connection tracking is such a
> huge win. Love to hear a good explanation.
See above for part of the explanation. Again: It's not only about TCP.
> eg, so ipfilter can do tcp connection tracking, ipchains can't. However,
> ipfilter still can't make ftp work - ipchains can, (aswell as icq, quake,
> ra, etc..).
What makes you think that? Another quote form the HOWTO:
4.6. Magic Hidden Within NAT; Application Proxies
Since ipnat provides a method to rewrite packets as
they traverse the firewall, it becomes a convenient place to
build in some application level proxies to make up for well
known deficiencies of that application and typical fire-
walls. For example; FTP. We can make our firewall pay
attention to the packets going across it and when it notices
that it's dealing with an Active FTP session, it can write
itself some temporary rules, much like what happens with
keep state, so that the FTP data connection works. To do
this, we use a rule like so:
map tun0 192.168.1.0/24 -> 184.108.40.206/32 proxy port ftp ftp/tcp
You must always remember to place this proxy rule before any
portmap rules, otherwise when portmap comes along and messes
around with the packet, the ftp proxy won't notice the ftp
connection, and you'll get errors.
There also exist proxies for "rcmd" (which we suspect
is berkeley r-* commands which should be forbidden anyway,
thus we haven't looked at what this proxy does) and "raudio"
for Real Audio PNM streams. Likewise, both of these rules
should be put before any portmap rules, if you're doing NAT.
You probably should have a glance at that HOWTO:
It's very well written and well worth a read. ipfilter sure seems to be
Whether it really is, I'll be able to tell you some time in August, as I'm
currently moving my Firewall/Dial-Up/Masquerading machine from Linux/ipfwadm
to OpenBSD/ipfilter. I'll be happy to provide first-hand experiences.
-- ----------------------------------------------------------------------------- Thomas Ribbrock http://www.bigfoot.com/~kaytan ICQ#: 15839919 "You have to live on the edge of reality - to make your dreams come true!"
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:06:59 GMT