Re: Security flaw in Stateful filtering ??????

Re: Security flaw in Stateful filtering ??????

[Rusty Russell]

In message <20020606220914.A14542@groar.org> you write:
> > iptables -A FORWARD -p tcp -m state --state ESTABLISHED -j ACCEPT
> > iptables -A FORWARD -p tcp -m state --state NEW -j ACCEPT
> > iptables -A FORWARD -p tcp -j DROP
> 
> The meaning of --state NEW is the number one misunderstanding of netfilter's
> dynamic filtering (*).

Hi all,

	I disagree.  Consider the original complaint: that --state NEW
allowed TCP ACK packets through, which allowed an ack scan.  This
surprised the observers, who then blocked acks.

	Of course, you can still use SYNs to scan the network, so they
haven't actually won anything here, except that if their firewall
reboots, established connections will die.

	The confusion here comes from the "TCP connection" vs
"connection tracking connection" distinction, which is subtle and
usually harmless.

Hope that helps,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: Security flaw in Stateful filtering ??????

[Joerg Mayer]

On Fri, Jun 07, 2002 at 09:31:12AM +1000, Rusty Russell wrote:
> 	Of course, you can still use SYNs to scan the network, so they
> haven't actually won anything here, except that if their firewall
> reboots, established connections will die.

If their firewall reboots and is running iptables and thus Linux: How
long will it be down? Which application will actually survive the down-
time? Does this application really matter?

  Ciao
       Jörg

--
Joerg Mayer                                          <jmayer@loplof.de>
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.

Re: Security flaw in Stateful filtering ??????

[Rusty Russell]

In message <20020607015247.L11214@thot.informatik.uni-kl.de> you write:
> On Fri, Jun 07, 2002 at 09:31:12AM +1000, Rusty Russell wrote:
> > 	Of course, you can still use SYNs to scan the network, so they
> > haven't actually won anything here, except that if their firewall
> > reboots, established connections will die.
> 
> If their firewall reboots and is running iptables and thus Linux: How
> long will it be down?

120 seconds to reboot with a fixed kernel...

> Which application will actually survive the down-time?

Everything: it's just like a router going down.

> Does this application really matter?

Um, does connectivity matter 8)

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: Security flaw in Stateful filtering ??????

[Joerg Mayer]

On Fri, Jun 07, 2002 at 12:10:09PM +1000, Rusty Russell wrote:
> > If their firewall reboots and is running iptables and thus Linux: How
> > long will it be down?
> 
> 120 seconds to reboot with a fixed kernel...

Umm, OK, I shouldn't have compared the reboot time of my desktop pc
with a tuned firewall/router pc.

> > Which application will actually survive the down-time?
> 
> Everything: it's just like a router going down.

Yes, sure, but now let's look at where most (linux) firewalls are
deployed: As (or at) the gateway to the internet. Your typical traffic
there will consist of mail, web, p2p, ftp, online gaming, nntp and the
occasional telnet/ssh/...
Mail, p2p and nntp don't really care. If the connections breaks, so
what? Let's try again (application). Web: If the connection breaks, the
user will hit reload way before the firewall is back online; in addition
large transfers can be resumed in many cases. ftp: you are right,
although with current clients, reget and automatic retries are not
uncommon. Online gaming, telnet/ssh/... depend on whether you are
actively doing something when the connection goes down. If you do,
even two minutes is too long ususally. Either your app has thrown
you out with a ping timeout etc, or the user will become impatient
and kill the connection anyway.

> > Does this application really matter?
> 
> Um, does connectivity matter 8)

Sure, what I'm trying to say is, that in many (most) current uses,
connectivity matters. It matters so much though, that it doesn't
matter, whether packets belonging to active connections are dropped
or not after a two minute downtime. They are de facto dead too.

   ciao

PS: I'm the first who will admit, that there are other places/usages,
  where this will make a difference thouth, e.g. connecting Database
  Servers and clients through a firewall. If many client apps are
  idling, they will (hopefully) survive the downtime.
--
Joerg Mayer                                          <jmayer@loplof.de>
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.

Re: Security flaw in Stateful filtering ??????

[Marcus Sundberg]

Joerg Mayer <jmayer@loplof.de> writes:

> On Fri, Jun 07, 2002 at 12:10:09PM +1000, Rusty Russell wrote:
> > > If their firewall reboots and is running iptables and thus Linux: How
> > > long will it be down?
> > 
> > 120 seconds to reboot with a fixed kernel...
> 
> Umm, OK, I shouldn't have compared the reboot time of my desktop pc
> with a tuned firewall/router pc.

You call 120 seconds tuned?
My Linux firewall at home is up with forwarding and SSH-server running
20 seconds after hitting the reset button...

> telnet/ssh/... depend on whether you are
> actively doing something when the connection goes down. If you do,
> even two minutes is too long ususally. Either your app has thrown
> you out with a ping timeout etc, or the user will become impatient
> and kill the connection anyway.

Wrong. I always have several ssh-sessions, often with tunnels,
which I really prefer not to restart even if the network goes down
for several minutes.

//Marcus
-- 
---------------------------------------+--------------------------
  Marcus Sundberg <marcus@ingate.com>  | Firewalls with SIP & NAT
 Firewall Developer, Ingate Systems AB |  http://www.ingate.com/

Re: Security flaw in Stateful filtering ??????

[Henrik Nordstrom]

Rusty Russell wrote:

> > If their firewall reboots and is running iptables and thus Linux: How
> > long will it be down?
>
> 120 seconds to reboot with a fixed kernel...

More like 20 seconds with a standard modular kernel for firewall boxes with a 
slimmed OS running on commodity hardware..

With a truly boot speed optimized system you can get down to about 10 seconds 
for a iptables based firewall from power on to running..

Regards
Henrik

Re: Security flaw in Stateful filtering ??????

[Ben Reser]

On Fri, Jun 07, 2002 at 01:52:47AM +0200, Joerg Mayer wrote:
> If their firewall reboots and is running iptables and thus Linux: How
> long will it be down? Which application will actually survive the down-
> time? Does this application really matter?

Even with about 3 or 4 minutes to reboot I rarely lose connections when
I reboot my firewall.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org

We tend to see all wars through the lens of the current conflict, and we
mine history for lessons convenient to the present purpose.
- Brian Hayes

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Hi,

Rusty Russell wrote:
> 
> 	I disagree.  Consider the original complaint: that --state NEW
> allowed TCP ACK packets through, which allowed an ack scan.  This
> surprised the observers, who then blocked acks.

Precisely.

Actually, my exact complain is now that the documentation is not
making you awared of what you are exactly doing...

Somehow, this is dangerous and can lead you to have a flaw in your
firewall without being awared of it.

Moreover, most of the papers, articles, and web pages about Netfilter
are wrong about this.

Just as an example, the following (very nice) documentation about
Netfilter (http://www.knowplace.org/netfilter/index.html), state
that:

"Note: An ACK packet is a TCP packet with the ACK flag set only. The 
important thing to note here is that after the three-way handshake is 
completed, and the connection is complete, every packet that is part of 
this TCP connection will always have the ACK bit set.

This is also the reason why connection tracking is so important. Without 
connection tracking, there is no way for your firewall to know whether 
an arriving ACK packet is really a part of an established connection. 
When simple packet filters (and Ipchains) receives a packet with the ACK 
flag set, it simply allows the packet through (does this sound like a 
good idea?). When a stateful firewall received an ACK packet, it'll 
consult a connection table to see if the packet belongs to an 
established connection. If it does not, the packet is dropped."

See: http://www.knowplace.org/netfilter/ip_overview.html

Which is obviously wrong in respect of what we were discussing...

I think that this is due (as Rusty said) to a confusion between the
TCP protocol's states and the connection tracking module's states
which are different.

This should definitely be emphased in the documentation (IMHO).


The other points are more about the policy you want to apply for
the development of Netfilter. I mean, should it be left up to
the user to patch this in the ruleset or fixed in the code...

This could be discussed forever without any result.
Therefore, it makes no point to just keep going on this way.


It appears, also, to me that you are focusing more on an
"advanced NAT", than on real "stateful inspection". You agreed
on loosing some stateful key features to increase the connectivity
because as you are using stateful inspection to do NAT, the features
that you loose does not affect so much the security of your network.
But loosing this feature prevent you to use Netfilter as a real
stateful inspection firewall (I'll explain this point later in this
post).

Actually, this discussion start to make aware of the difference
between "connection tracking" and "stateful inspection". :-)


> 	Of course, you can still use SYNs to scan the network, so they
> haven't actually won anything here, except that if their firewall
> reboots, established connections will die.

Well, if you consider a full implementation of a stateful inspection
firewall, you should be able to "hide" a network from outside without
using NAT.

For example, you can make up the following ruleset:

o DENY SYN from outside -> inside
o Allow NEW, ESTABLISHED, RELATED

                       +-----------+
+--------+    +--+    | Hidden Net|
|Internet|----|FW|----| w/o NAT   |
+--------+    +--+    +-----------+

On this configuration, you allow all the computers of your hidden net
to have their own IP address and you disallow any sort of scan from
outside. You can even imagine to have a web server somewhere in your
hidden network (you just have to add as first rule that you allow
all the traffic on the port 80 to this precise IP address).

This configuration can't be done with Netfilter because you are doing
what we could call "connection tracking" and not "stateful inspection".


> 	The confusion here comes from the "TCP connection" vs
> "connection tracking connection" distinction, which is subtle and
> usually harmless.

Harmless if you are running NAT. But, if you are trying to use Netfilter
as a complete stateful inspection firewall, then you are in trouble
(IMHO).

> Hope that helps,

Yes. Thanks. :-)

Regards
-- 
Emmanuel

Security is a process, not a product.
   -- Bruce Schneier (Crypto-gram, February 15, 2002)

Re: Security flaw in Stateful filtering ??????

[Oskar Andreasson]

Hi all,

Hope I am not bursting in to this thread at a too late point.. but here goes.

The --state NEW ! --syn -j DROP rule applied in the iptables tutorial (now at 1.1.11, available at http://iptables-tutorial.haringstad.com). What does it do? Simple enough, it blocks all packets considered as NEW and which does not have the SYN flag set (out of SYN,ACK,FIN). It should solve your (Emmanuel Fleury) problem as it looks today. The NEW state can be used for, as has already been discussed, connection pick-up (i.e., when the firewall reboots). Another, related, usage is if we have a redundant firewall (I haven't seen this discussed so far so.... Consider this:

1 main firewall
1 router 
and a secondary firewall. 

The three are set up in a routing zone. If the main firewall goes down, the router will notice, and route packets through the redundant firewall. If the NEW target was to allow only SYN packets, this would be impossible as you can understand from this.

I have already suggested this, but noone picked up on it. 1. Patch netfilter so you can write and read connection tracking entries via a netlink socket. On top of this, make a daemon that will share states between the firewalls. This will make a much better solution, though a bit more "needy" in resources etcetera. 

Put this idea together with our old behaviour (currently used), and we could perhaps make the default behaviour of netfilter to only pick up SYN packets as NEW, then make it possible to pick up connections by also allowing ACK and other packets, and finally the third solution above. All of them together would cover all big areas AFAIK (e.g. small home networks, medium networks (pickup) and the big and expensive solution (routing zones with several firewalls being able to pick up connections from eachother). 

Finally, I agree with Emmanuel that the current documentation is _not_ clear enough on this matter. As he says, this is a huge backdoor that most people miss when they make a ruleset.

I'm sorry for this rather long mail, but I am just getting some thoughts off of my head. Have a nice day,

Oskar Andreasson
http://www.boingworld.com
http://people.unix-fu.org/andreasson/
mailto: blueflux@koffein.net



----- Original Message ----- 
From: "Emmanuel Fleury" <fleury@cs.auc.dk>
To: <netfilter-devel@lists.samba.org>
Sent: Friday, June 07, 2002 10:15 AM
Subject: Re: Security flaw in Stateful filtering ??????


> Hi,
> 
> Rusty Russell wrote:
> > 
> > I disagree.  Consider the original complaint: that --state NEW
> > allowed TCP ACK packets through, which allowed an ack scan.  This
> > surprised the observers, who then blocked acks.
> 
> Precisely.
> 
> Actually, my exact complain is now that the documentation is not
> making you awared of what you are exactly doing...
> 
> Somehow, this is dangerous and can lead you to have a flaw in your
> firewall without being awared of it.
> 
> Moreover, most of the papers, articles, and web pages about Netfilter
> are wrong about this.
> 
> Just as an example, the following (very nice) documentation about
> Netfilter (http://www.knowplace.org/netfilter/index.html), state
> that:
> 
> "Note: An ACK packet is a TCP packet with the ACK flag set only. The 
> important thing to note here is that after the three-way handshake is 
> completed, and the connection is complete, every packet that is part of 
> this TCP connection will always have the ACK bit set.
> 
> This is also the reason why connection tracking is so important. Without 
> connection tracking, there is no way for your firewall to know whether 
> an arriving ACK packet is really a part of an established connection. 
> When simple packet filters (and Ipchains) receives a packet with the ACK 
> flag set, it simply allows the packet through (does this sound like a 
> good idea?). When a stateful firewall received an ACK packet, it'll 
> consult a connection table to see if the packet belongs to an 
> established connection. If it does not, the packet is dropped."
> 
> See: http://www.knowplace.org/netfilter/ip_overview.html
> 
> Which is obviously wrong in respect of what we were discussing...
> 
> I think that this is due (as Rusty said) to a confusion between the
> TCP protocol's states and the connection tracking module's states
> which are different.
> 
> This should definitely be emphased in the documentation (IMHO).
> 
> 
> The other points are more about the policy you want to apply for
> the development of Netfilter. I mean, should it be left up to
> the user to patch this in the ruleset or fixed in the code...
> 
> This could be discussed forever without any result.
> Therefore, it makes no point to just keep going on this way.
> 
> 
> It appears, also, to me that you are focusing more on an
> "advanced NAT", than on real "stateful inspection". You agreed
> on loosing some stateful key features to increase the connectivity
> because as you are using stateful inspection to do NAT, the features
> that you loose does not affect so much the security of your network.
> But loosing this feature prevent you to use Netfilter as a real
> stateful inspection firewall (I'll explain this point later in this
> post).
> 
> Actually, this discussion start to make aware of the difference
> between "connection tracking" and "stateful inspection". :-)
> 
> 
> > Of course, you can still use SYNs to scan the network, so they
> > haven't actually won anything here, except that if their firewall
> > reboots, established connections will die.
> 
> Well, if you consider a full implementation of a stateful inspection
> firewall, you should be able to "hide" a network from outside without
> using NAT.
> 
> For example, you can make up the following ruleset:
> 
> o DENY SYN from outside -> inside
> o Allow NEW, ESTABLISHED, RELATED
> 
>                        +-----------+
> +--------+    +--+    | Hidden Net|
> |Internet|----|FW|----| w/o NAT   |
> +--------+    +--+    +-----------+
> 
> On this configuration, you allow all the computers of your hidden net
> to have their own IP address and you disallow any sort of scan from
> outside. You can even imagine to have a web server somewhere in your
> hidden network (you just have to add as first rule that you allow
> all the traffic on the port 80 to this precise IP address).
> 
> This configuration can't be done with Netfilter because you are doing
> what we could call "connection tracking" and not "stateful inspection".
> 
> 
> > The confusion here comes from the "TCP connection" vs
> > "connection tracking connection" distinction, which is subtle and
> > usually harmless.
> 
> Harmless if you are running NAT. But, if you are trying to use Netfilter
> as a complete stateful inspection firewall, then you are in trouble
> (IMHO).
> 
> > Hope that helps,
> 
> Yes. Thanks. :-)
> 
> Regards
> -- 
> Emmanuel
> 
> Security is a process, not a product.
>    -- Bruce Schneier (Crypto-gram, February 15, 2002)
> 
> 
> 

Re: Security flaw in Stateful filtering ??????

[Jozsef Kadlecsik]

On Fri, 7 Jun 2002, Oskar Andreasson wrote:

> Another, related, usage is
> if we have a redundant firewall (I haven't seen this discussed so far
> so.... Consider this:
>
> 1 main firewall
> 1 router
> and a secondary firewall.
>
> The three are set up in a routing zone. If the main firewall goes
> down, the router will notice, and route packets through the redundant
> firewall. If the NEW target was to allow only SYN packets, this would
> be impossible as you can understand from this.

We have been using such a redundant setup for more than a year.
It's *not* theoretical.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Security flaw in Stateful filtering ??????

[Oskar Andreasson]

Hi Jozsef,

Sorry for the late reply. I never suggested that this usage (see below) is only theoretical and I'm very sorry if it was misinterpreted as that. 

My proposal was to create a way of doing more secure, and stateful, redundancy mechanism. For example, 2 or more firewalls which shares their conntrack tables via some userspace daemons. This would require the daemon to have read/write access to the conntrack tables via netlink however, and I am not fully aware of the possibilities of this. 

Once again, I am extremely sorry if you misinterpreted the whole mail as a suggestion that this is only theoretical. I know that you among others have told me and others that you've already implemented this in practice. 

Oskar Andreasson
http://www.boingworld.com
http://people.unix-fu.org/andreasson/
mailto: blueflux@koffein.net

----- Original Message ----- 
From: "Jozsef Kadlecsik" <kadlec@blackhole.kfki.hu>
To: "Oskar Andreasson" <blueflux@koffein.net>
Cc: <netfilter-devel@lists.samba.org>
Sent: Friday, June 07, 2002 2:27 PM
Subject: Re: Security flaw in Stateful filtering ??????


> On Fri, 7 Jun 2002, Oskar Andreasson wrote:
> 
> > Another, related, usage is
> > if we have a redundant firewall (I haven't seen this discussed so far
> > so.... Consider this:
> >
> > 1 main firewall
> > 1 router
> > and a secondary firewall.
> >
> > The three are set up in a routing zone. If the main firewall goes
> > down, the router will notice, and route packets through the redundant
> > firewall. If the NEW target was to allow only SYN packets, this would
> > be impossible as you can understand from this.
> 
> We have been using such a redundant setup for more than a year.
> It's *not* theoretical.
> 
> Regards,
> Jozsef
> -
> E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> WWW-Home: http://www.kfki.hu/~kadlec
> Address : KFKI Research Institute for Particle and Nuclear Physics
>           H-1525 Budapest 114, POB. 49, Hungary
> 
> 

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Hi Oskar,

Oskar Andreasson wrote:
> 
> My proposal was to create a way of doing more secure, and
 > stateful, redundancy mechanism. For example, 2 or more firewalls
 > which shares their conntrack tables via some userspace daemons.
 > This would require the daemon to have read/write access to the
 > conntrack tables via netlink however, and I am not fully aware
 > of the possibilities of this.

Well I don't know if it will be more secure, but this idea is
interesting for me.

I already was thinking about something similar.

Indeed, if you consider a network which has several access points
to the Internet (let say FW1 and FW2). It is very 'dangerous' to
run stateful on these access point because a packet which is part
of a connection can go either through FW1 either trough FW2 (no static
routing is assumed).

As only one of your firewall had registered the connection (in the best
case), the other one will drop all the packets... (except if you
consider the "ACK is NEW" behaviour).

The 'solution' would be to consider what can be called a 'distributed
stateful firewall' which maintain a centralized connection table for
all your firewalls...

But, it raises a lot of problems like cache consistency over a network,
what to do if the three way handshake is distributed on the your
firewalls, and so on....

The most surprising is that this 'ACK is NEW' thing is solving
this problem also (even if I think that this is a dirty hack ;-)).

-- 
Emmanuel

You have to understand what the primary objective of an OS is:
To create a virtual environment that is simple and sane to program
against....

Have you learned nothing at all from DOS and Windows?
   -- Linus Torvalds

Re: Security flaw in Stateful filtering ??????

[Jozsef Kadlecsik]

Hi,

On Mon, 10 Jun 2002, Oskar Andreasson wrote:

> Sorry for the late reply. I never suggested that this usage (see
> below) is only theoretical and I'm very sorry if it was misinterpreted
> as that.

Oh, no! I wanted to *second* you in this argument.

Regards,
Jozsef

> ----- Original Message -----
>
> > On Fri, 7 Jun 2002, Oskar Andreasson wrote:
> >
> > > Another, related, usage is
> > > if we have a redundant firewall (I haven't seen this discussed so far
> > > so.... Consider this:
> > >
> > > 1 main firewall
> > > 1 router
> > > and a secondary firewall.
> > >
> > > The three are set up in a routing zone. If the main firewall goes
> > > down, the router will notice, and route packets through the redundant
> > > firewall. If the NEW target was to allow only SYN packets, this would
> > > be impossible as you can understand from this.
> >
> > We have been using such a redundant setup for more than a year.
> > It's *not* theoretical.
> >
> > Regards,
> > Jozsef
> > -
> > E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> > WWW-Home: http://www.kfki.hu/~kadlec
> > Address : KFKI Research Institute for Particle and Nuclear Physics
> >           H-1525 Budapest 114, POB. 49, Hungary
> >
> >
>

-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Security flaw in Stateful filtering ??????

[Henrik Nordstrom]

Emmanuel Fleury wrote:
> For example, you can make up the following ruleset:
>
> o DENY SYN from outside -> inside
> o Allow NEW, ESTABLISHED, RELATED
>
>
>                        +-----------+
> +--------+    +--+    | Hidden Net|
>
> |Internet|----|FW|----| w/o NAT   |
>
> +--------+    +--+    +-----------+
>
>
> On this configuration, you allow all the computers of your hidden net
> to have their own IP address and you disallow any sort of scan from
> outside. You can even imagine to have a web server somewhere in your
> hidden network (you just have to add as first rule that you allow
> all the traffic on the port 80 to this precise IP address).
>
>
> This configuration can't be done with Netfilter because you are doing
> what we could call "connection tracking" and not "stateful inspection".

This configuration can be done just fine with iptables as demonstrated in my 
earlier message, but here we go again (but slightly different):

# Allow existing connections
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow hidden net to initiate new connections (including connection pickup)
iptables -A FORWARD -i eth0 -j ACCEPT
# Drop anything else
iptables -A FORWARD -j DROP

And is considerably more secure design than your proposed use of NEW above if 
you include other protocols than TCP into the mix, plus has the added bonus 
that connection pickup will allow some connections from the hidden network to 
be picked up after a reboot.

Note: The external network is NOT allowed to cause connection pickup, only 
packets send by your hidden network will.

Regards
Henrik

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Henrik Nordstrom wrote:
> 
> This configuration can be done just fine with iptables as demonstrated in my 
> earlier message, but here we go again (but slightly different):
> 
> # Allow existing connections
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> # Allow hidden net to initiate new connections (including connection pickup)
> iptables -A FORWARD -i eth0 -j ACCEPT
> # Drop anything else
> iptables -A FORWARD -j DROP

Sorry, I don't understand something ! :-/

Does that mean that you DROP all the ACKs, even those which are valid ?

Regards
-- 
Emmanuel

I am not a vegetarian because I love animals;
I am a vegetarian because I hate plants.
   -- A. Whitney Brown

Re: Security flaw in Stateful filtering ??????

[Oskar Andreasson]

No,

Look below

----- Original Message ----- 
From: "Emmanuel Fleury" <fleury@cs.auc.dk>
To: <netfilter-devel@lists.samba.org>
Sent: Friday, June 07, 2002 11:31 AM
Subject: Re: Security flaw in Stateful filtering ??????


> Henrik Nordstrom wrote:
> > 
> > This configuration can be done just fine with iptables as demonstrated in my 
> > earlier message, but here we go again (but slightly different):
> > 
> > # Allow existing connections
> > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

This line allows all connections that has a connection tracking entry which shows that the connection that the packet is part of is ESTABLISHED. RELATED means that if the packet is RELATED to a connection tracking entry, it will slipp through as well (i.e. FTP-Data is related to FTP-Control, and ICMP's may be related to TCP connections, etc.).

In other words, the above line allows all packets that are not initiating a new connection to pass through the firewall.

> > # Allow hidden net to initiate new connections (including connection pickup)
> > iptables -A FORWARD -i eth0 -j ACCEPT

_this_ line allows all packets from eth0 (probably your LAN) to pass through the firewall, including the packets opening a new connection. 

> > # Drop anything else
> > iptables -A FORWARD -j DROP

finally, we have a rule that DROP's all other packets, including packets from the internet trying to initiate a NEW connection. 

Does this make sense?=) Of course, note that this will _not_ block traffic directed to the actual firewall itself, but hosts behind the firewall.

Oskar Andreasson
http://www.boingworld.com
http://people.unix-fu.org/andreasson/
mailto: blueflux@koffein.net


> 
> Sorry, I don't understand something ! :-/
> 
> Does that mean that you DROP all the ACKs, even those which are valid ?
> 
> Regards
> -- 
> Emmanuel
> 
> I am not a vegetarian because I love animals;
> I am a vegetarian because I hate plants.
>    -- A. Whitney Brown
> 
> 
> 

Re: Security flaw in Stateful filtering ??????

[Guillaume Morin]

Dans un message du 07 jun à 11:31, Emmanuel Fleury écrivait :
> >iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> >iptables -A FORWARD -i eth0 -j ACCEPT
> >iptables -A FORWARD -j DROP
> 
> Does that mean that you DROP all the ACKs, even those which are valid
> ?

Of course not, the ACKs packets are matched by --state ESTABLISHED since
they do correspond to an established connection. When ACK packets are
matched as NEW, that means that they do NOT correpond to an established
connection in the conntrack.

-- 
Guillaume Morin <guillaume@morinfr.org>

                  Batailler corps et âmes pour un maudit refus
                              (No one is innocent)

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Guillaume Morin wrote:
> Dans un message du 07 jun à 11:31, Emmanuel Fleury écrivait :
> 
>>>iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>>>iptables -A FORWARD -i eth0 -j ACCEPT
>>>iptables -A FORWARD -j DROP
>>
>>Does that mean that you DROP all the ACKs, even those which are valid
> 
> Of course not, the ACKs packets are matched by --state ESTABLISHED since
> they do correspond to an established connection. When ACK packets are
> matched as NEW, that means that they do NOT correpond to an established
> connection in the conntrack.

Ok !!! I see the light now. :-)

Does this means that you are mapping the packets to a state (NEW,
ESTABLISHED, RELATED, INVALID) only based on information on their
header and a query to the connection table ? And that you do not
care about the previous state of the connection ?

At least, it doesn't seems to be necessary to take care of the previous
state of the connection in this case.

Moreover, is it possible to create an entry in the connection table
just by sending an ACK ??? (somebody wrote this at some point).


Finally, I tried to think about this 'connection pick-up' thing and
I really don't understand how do you can restore a connection after
the reboot. What is the algorithm which is used for this ?
(My problem is that in the case of a NAT, you can receive an ACK packet
on your FORWARD chain coming from outside and you have to translate
it to your inner network. But you lost all the informations about it).

-- 
Emmanuel

And I'm right. I'm always right, but in this case
I'm just a bit more right than I usually am.
   -- Linus Torvalds

Re: Security flaw in Stateful filtering ??????

[Guillaume Morin]

Dans un message du 07 jun à 11:57, Emmanuel Fleury écrivait :
> Does this means that you are mapping the packets to a state (NEW,
> ESTABLISHED, RELATED, INVALID) only based on information on their
> header and a query to the connection table ? And that you do not
> care about the previous state of the connection ?

I really do not understand what you mean. The conntrack stores the
previous state of TCP connection. So indeed when a packet arrives, it
checks the information of the TCP and IP headers and tries to see if
there is something stored about this TCP connection.

e.g

for a syn/ack packet

the conntrack says "I've seen a syn from this guy" -> the packet is
matched as ESTABLISHED.  

the conntrack says "I've never seen anything" -> the packet is matched
as INVALID

for your beloved ack packets

the conntrack knows a connection is established -> ACK is matched as
ESTABLISHED

the conntrack has seen no connection -> ACK is matched as NEW

> Moreover, is it possible to create an entry in the connection table
> just by sending an ACK ??? (somebody wrote this at some point).

Of course ! This is what is done when an ACK packet is received and if
the conntrack can't find a related established connection.

> Finally, I tried to think about this 'connection pick-up' thing and
> I really don't understand how do you can restore a connection after
> the reboot. What is the algorithm which is used for this ?

This is a firewall. Basically you let packets pass or you do not. In a
case of connection pick-up, the firewall sees the ACK and thinks "oh, it
looks like there is a established connection but I wasn't there during
establishment. I'll let this connection go on. The following ACKs
packets will be matched as ESTABLISHED"

> (My problem is that in the case of a NAT, you can receive an ACK packet
> on your FORWARD chain coming from outside and you have to translate
> it to your inner network. But you lost all the informations about it).

Of course, it does not work for a NATed connection if the ACK packet
comes from outside.

-- 
Guillaume Morin <guillaume@morinfr.org>

       Unwisely, Santa offered a teddy bear to James, unaware that he had
             been mauled by a grizzly earlier that year (T. Burton)

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Guillaume Morin wrote:
 >
 > I really do not understand what you mean. The conntrack stores the
 > previous state of TCP connection. So indeed when a packet arrives, it
 > checks the information of the TCP and IP headers and tries to see if
 > there is something stored about this TCP connection.
 >
 > e.g
 >
 > for a syn/ack packet
 >
 > the conntrack says "I've seen a syn from this guy" -> the packet is
 > matched as ESTABLISHED.

Ok, in other words:

"The connection old state was NEW" + "I receive a SYN/ACK"
    -> Connection is tagged as ESTABLISHED

So, this example answer to my question.


 > for your beloved ack packets

:-)

 > the conntrack knows a connection is established -> ACK is matched as
 > ESTABLISHED
 >
 > the conntrack has seen no connection -> ACK is matched as NEW

Actually, this is EXACTLY this behaviour which is surprising to me.
Don't miss my point, I don't want this to be changed, but just
writen in the definition of the states (eg in the packet-filtering
HOWTO):


NEW

      A packet which creates a new connection _or_a_ACK_packet_which_is
      _not_belonging_to_an_existing_connection(1).


Footnote (1): This feature has been implemented in order to keep the
connections alive after a reboot of the firewall (see: ...).


 >>Moreover, is it possible to create an entry in the connection table
 >>just by sending an ACK ??? (somebody wrote this at some point).
 >
 > Of course ! This is what is done when an ACK packet is received and if
 > the conntrack can't find a related established connection.

Are you sure ?

My students just told that they was no new connections after the ACK
scanning...

What part of the code have we to look to see this ???


 >>Finally, I tried to think about this 'connection pick-up' thing and
 >>I really don't understand how do you can restore a connection after
 >>the reboot. What is the algorithm which is used for this ?
 >
 >
 > This is a firewall. Basically you let packets pass or you do not. In a
 > case of connection pick-up, the firewall sees the ACK and thinks "oh, it
 > looks like there is a established connection but I wasn't there during
 > establishment. I'll let this connection go on. The following ACKs
 > packets will be matched as ESTABLISHED"

But, it looks like the ACK packets do not create new entry in the table
(well, according to the proc/ thing at least).

 >>(My problem is that in the case of a NAT, you can receive an ACK packet
 >>on your FORWARD chain coming from outside and you have to translate
 >>it to your inner network. But you lost all the informations about it).
 >
 > Of course, it does not work for a NATed connection if the ACK packet
 > comes from outside.

Ok.

Regards
-- 
Emmanuel

I am not young enough to know everything.
    -- Oscar Wilde

Re: Security flaw in Stateful filtering ??????

[Guillaume Morin]

Hi Emmanuel,

Dans un message du 07 jun à 13:30, Emmanuel Fleury écrivait :
> > the conntrack knows a connection is established -> ACK is matched as
> > ESTABLISHED
> >
> > the conntrack has seen no connection -> ACK is matched as NEW
> 
> Actually, this is EXACTLY this behaviour which is surprising to me.
> Don't miss my point, I don't want this to be changed, but just
> writen in the definition of the states (eg in the packet-filtering
> HOWTO):
> 
> NEW
> 
>      A packet which creates a new connection _or_a_ACK_packet_which_is
>      _not_belonging_to_an_existing_connection(1).
> 

Well, I understand your point. I know this is surprising. I really
thought it was in the FAQ or something. 

I looked at the code and I was kind of wrong. Every untracked packets
are considered as NEW. That means that a syn/ack packet, a rst packet
will be matched as NEW. The documentation is correct because it means
the connection in the conntrack sense NOT in the TCP sense.

This is not a security flaw itself since when you allow NEW you always
allow the peer to scan you (syn, syn/ack, ack, whatever)

> > Of course ! This is what is done when an ACK packet is received and if
> > the conntrack can't find a related established connection.
> 
> Are you sure ?

Yes.

> My students just told that they was no new connections after the ACK
> scanning...

That is logical. The scanner sends the ACK packet to the target machine.
The firewall let the packet pass. The target receives the bogus ACK
packet and sends back a RST packet. The firewall sees that and swith the
CONNECTION_CLOSE state which will be ripped off the connection table 10
seconds after that.

> What part of the code have we to look to see this ???@

see net/ipv4/netfilter/ip_conntrack_proto_tcp.c

> But, it looks like the ACK packets do not create new entry in the table
> (well, according to the proc/ thing at least).

It does create an entry.

HTH.

-- 
Guillaume Morin <guillaume@morinfr.org>

                       Sauvez un arbre, mangez un castor

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Hi,

Guillaume Morin wrote:
> 
> I looked at the code and I was kind of wrong. Every untracked packets
> are considered as NEW. That means that a syn/ack packet, a rst packet
> will be matched as NEW.

Yes, I just checked it in the piece of code you pointed out (see below).

> The documentation is correct because it means
> the connection in the conntrack sense NOT in the TCP sense.

I disagree on this point. The documentation is not correct.

Or, at least, the documentation is not precise enough to figure out
this particular point (and this can lead the users to have some flaws
in their firewall).

> This is not a security flaw itself since when you allow NEW you always
> allow the peer to scan you (syn, syn/ack, ack, whatever).

I agree with this. But, the misunderstanding of this feature can lead
to a flaw (it's an indirect flaw somehow).


> That is logical. The scanner sends the ACK packet to the target machine.
> The firewall let the packet pass. The target receives the bogus ACK
> packet and sends back a RST packet. The firewall sees that and swith the
> CONNECTION_CLOSE state which will be ripped off the connection table 10
> seconds after that.

That's partly true, I can see it on the state table (see below).

>>What part of the code have we to look to see this ???@
> 
> see net/ipv4/netfilter/ip_conntrack_proto_tcp.c

I just want to be sure that I well understood this piece of code...



So, here we are, a new TCP packet is coming from some interface and
is not matching with any existing connection.

Then, we call the function 'tcp_new(&conntrack, &iph, length)':

=====
/* Called when a new connection for this protocol found. */
static int tcp_new(struct ip_conntrack *conntrack,
                    struct iphdr *iph, size_t len)
{
         enum tcp_conntrack newconntrack;
         struct tcphdr *tcph = (struct tcphdr *)((u_int32_t *)iph + 
iph->ihl);

         /* Don't need lock here: this conntrack not in circulation yet */
         newconntrack
                 = tcp_conntracks[0][get_conntrack_index(tcph)]
                 [TCP_CONNTRACK_NONE];

         /* Invalid: delete conntrack */
         if (newconntrack == TCP_CONNTRACK_MAX) {
                 DEBUGP("ip_conntrack_tcp: invalid new deleting.\n");
                 return 0;
         }

         conntrack->proto.tcp.state = newconntrack;
         return 1;
}
====

So, basically, we assign to 'newconntrack' the new state of the TCP
connection, which is:

tcp_conntracks[0][get_conntrack_index(tcph)][TCP_CONNTRACK_NONE]


Mmmh, what is get_conntrack_index(tcph) ?

Well, back to the code, we can see that:

=====
static unsigned int get_conntrack_index(const struct tcphdr *tcph)
{
	if (tcph->rst) return 3;
	else if (tcph->syn) return 0;
	else if (tcph->fin) return 1;
	else if (tcph->ack) return 2;
	else return 4;
}
=====

So, an RST packet return 3, a SYN (or SYN/ACK) return 0, a FIN return 1,
a ACK return 2, and finally anything else return 4.

Notice that an X-MAS tree scan will match the RST and return 3.


Ok, let say that our mysterious packet is a pure ACK packet.

So we have: newconntrack = tcp_conntracks[0][2][TCP_CONNTRACK_NONE]

Now, we have to know more about this 'tcp_conntracks' thing...

=====
#define sNO TCP_CONNTRACK_NONE
#define sES TCP_CONNTRACK_ESTABLISHED
#define sSS TCP_CONNTRACK_SYN_SENT
#define sSR TCP_CONNTRACK_SYN_RECV
#define sFW TCP_CONNTRACK_FIN_WAIT
#define sTW TCP_CONNTRACK_TIME_WAIT
#define sCL TCP_CONNTRACK_CLOSE
#define sCW TCP_CONNTRACK_CLOSE_WAIT
#define sLA TCP_CONNTRACK_LAST_ACK
#define sLI TCP_CONNTRACK_LISTEN
#define sIV TCP_CONNTRACK_MAX

static enum tcp_conntrack tcp_conntracks[2][5][TCP_CONNTRACK_MAX] = {
         {
/*      ORIGINAL */
/*        sNO, sES, sSS, sSR, sFW, sTW, sCL, sCW, sLA, sLI      */
/*syn*/ {sSS, sES, sSS, sSR, sSS, sSS, sSS, sSS, sSS, sLI },
/*fin*/ {sTW, sFW, sSS, sTW, sFW, sTW, sCL, sTW, sLA, sLI },
/*ack*/ {sES, sES, sSS, sES, sFW, sTW, sCL, sCW, sLA, sES },
/*rst*/ {sCL, sCL, sSS, sCL, sCL, sTW, sCL, sCL, sCL, sCL },
/*none*/{sIV, sIV, sIV, sIV, sIV, sIV, sIV, sIV, sIV, sIV }
         },
         {
/*      REPLY */
/*        sNO, sES, sSS, sSR, sFW, sTW, sCL, sCW, sLA, sLI      */
/*syn*/ {sSR, sES, sSR, sSR, sSR, sSR, sSR, sSR, sSR, sSR },
/*fin*/ {sCL, sCW, sSS, sTW, sTW, sTW, sCL, sCW, sLA, sLI },
/*ack*/ {sCL, sES, sSS, sSR, sFW, sTW, sCL, sCW, sCL, sLI },
/*rst*/ {sCL, sCL, sCL, sCL, sCL, sCL, sCL, sCL, sLA, sLI },
/*none*/{sIV, sIV, sIV, sIV, sIV, sIV, sIV, sIV, sIV, sIV }
         }
};
=====

Ok, so actually we are looking a the first table 'ORIGINAL':

  tcp_conntracks[0][2][TCP_CONNTRACK_NONE] = sES

Which means that we enter in the state ESTABLISHED.

So you were right... (of course, I would say :-)).

But, let's keep going, the ACK get a RST in reply. So, if we take
a look a the second table on the RST line, you enter in the state
TCP_CONNTRACK_CLOSE.

And the time-out for this state is stored here:

=====
static unsigned long tcp_timeouts[]
= { 30 MINS, 	/*	TCP_CONNTRACK_NONE,	*/
     5 DAYS,	/*	TCP_CONNTRACK_ESTABLISHED,	*/
     2 MINS,	/*	TCP_CONNTRACK_SYN_SENT,	*/
     60 SECS,	/*	TCP_CONNTRACK_SYN_RECV,	*/
     2 MINS,	/*	TCP_CONNTRACK_FIN_WAIT,	*/
     2 MINS,	/*	TCP_CONNTRACK_TIME_WAIT,	*/
     10 SECS,	/*	TCP_CONNTRACK_CLOSE,	*/
     60 SECS,	/*	TCP_CONNTRACK_CLOSE_WAIT,	*/
     30 SECS,	/*	TCP_CONNTRACK_LAST_ACK,	*/
     2 MINS,	/*	TCP_CONNTRACK_LISTEN,	*/
};
=====

So, 10 seconds.

The strange thing is that it seems to my students that the connection
is closed almost immediatly (in less than 10 seconds). Is it true ????



Anyway, as you told at the beginning, it seems that all the ACK, SYN,
SYN/ACK, RST and FIN are hitting the NO state.

Somehow, there is a confusion between the 'NEW' state and the 'INVALID'
state in the way it is coded. Both, NEW and INVALID are 'fake' state
because they never appear in the real state table.

But, this is out of my scope for now.



Another point, I think I get the way the connection pickup work !

So, we just have rebooted the firewall. Let say that the cleaning-lady
was needing some power for her vacumm-cleaner and decided that this
noisy big box on the shelves was not so important.

Hum, so, as a lot of packets have been lost, one of the machine at one
end will probably time-out and retransmit an ACK at some point.

And magically, the connection will be ESTABLISHED again... easy. :-)



The funny thing is that if you have a bad ruleset, you can easily be
DOSed by some external people which are just sending random ACK packets.

Those ACKs will create entries in your connection table as ESTABLISHED
connections with a time-out of.... 5 days !!!!! 8-)

Regards
-- 
Emmanuel

I am not young enough to know everything.
   -- Oscar Wilde

Re: Security flaw in Stateful filtering ??????

[Guillaume Morin]

Hi Emmanuel,

Dans un message du 07 Jun à 17:13, Emmanuel Fleury écrivait :
> >The documentation is correct because it means
> >the connection in the conntrack sense NOT in the TCP sense.
> 
> I disagree on this point. The documentation is not correct.
> 
> Or, at least, the documentation is not precise enough to figure out
> this particular point (and this can lead the users to have some flaws
> in their firewall).

The documentation is correct because it assumes you understand
"connection" as a conntrack entry. I do agree that it should be 
more explicit.

> The funny thing is that if you have a bad ruleset, you can easily be
> DOSed by some external people which are just sending random ACK packets.
> 
> Those ACKs will create entries in your connection table as ESTABLISHED
> connections with a time-out of.... 5 days !!!!! 8-)

Well no, since the concerned box will reply with a RST.

-- 
Guillaume Morin <guillaume@morinfr.org>

              Why critize what you don't understand ? (Sepultura)

Re: Security flaw in Stateful filtering ??????

[Patrick Schaaf]

> > The funny thing is that if you have a bad ruleset, you can easily be
> > DOSed by some external people which are just sending random ACK packets.
> > 
> > Those ACKs will create entries in your connection table as ESTABLISHED
> > connections with a time-out of.... 5 days !!!!! 8-)
> 
> Well no, since the concerned box will reply with a RST.

Alternatively, if no answer comes back at all, the conntrack is in the
(extra) state UNREPLIED. When the connection table becomes full, UNREPLIED
connections are recycled preferentially.

The worst kinds of handleable DoS situations in this area, have been dealt
with 1-2 years ago.

best regards
  Patrick

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Patrick Schaaf wrote:
>>>The funny thing is that if you have a bad ruleset, you can easily be
>>>DOSed by some external people which are just sending random ACK packets.
>>>
>>>Those ACKs will create entries in your connection table as ESTABLISHED
>>>connections with a time-out of.... 5 days !!!!! 8-)
>>
>>Well no, since the concerned box will reply with a RST.
> 
> Alternatively, if no answer comes back at all, the conntrack is in the
> (extra) state UNREPLIED. When the connection table becomes full, UNREPLIED
> connections are recycled preferentially.

Hey, this is not fair !!!!!

This behaviour is not described in ip_conntrack_proto_tcp.c.

Where is it coded ????





Anyway, I would suggest that this 'ACK is NEW' thing is not really
needed forever in your firewall. If this behaviour is active for a
certain amount of time after every reboot, it would be probably enough
to catch up all this pending connections and allow you to classify ACK
as INVALID most of the time....

This is just a suggestion...

Regards
-- 
Emmanuel

A dreamer is one who can only find his way by moonlight, and his
punishment is that he sees the dawn before the rest of the world.
   -- Oscar Wilde

Re: Security flaw in Stateful filtering ??????

[Patrick Schaaf]

> > Alternatively, if no answer comes back at all, the conntrack is in the
> > (extra) state UNREPLIED. When the connection table becomes full, UNREPLIED
> > connections are recycled preferentially.
> 
> Hey, this is not fair !!!!!

The behaviour is as fair as it can be, IMO.

> This behaviour is not described in ip_conntrack_proto_tcp.c.
> Where is it coded ????

Mostly in ip_conntrack_core.c. The early_drop() and unreplied() functions
implement the checking, based on the IPS_ASSURED bit in conntrack->status.
Use "grep" to see where that bit is set.

best regards
  Patrick

Re: Security flaw in Stateful filtering ??????

[Henrik Nordstrom]

On Saturday 08 June 2002 10:21, Patrick Schaaf wrote:

> Mostly in ip_conntrack_core.c. The early_drop() and unreplied()
> functions implement the checking, based on the IPS_ASSURED bit in
> conntrack->status. Use "grep" to see where that bit is set.

ip_conntrack_core is also where the NEW/ESTABLISHED/RELATED states is 
defined. As said numerous times on this thread the conntrack states 
NEW/ESTABLISHED/RELATED has nothing to do with TCP as such.

The states you have been looking into in ip_conntrack_proto_tcp.c is 
the TCP tracking state, which is almost fully independent of the 
conntrack state.

The conntrack packet state is based on how THIS packet relates to the 
connection. The same set of rules applies to all protocols.. First 
packet (and initial retransmissions) is NEW, reply packet to a 
previously seen packet is ESTABLISHED, initiations of related 
connections identified as belonging to an existing connection is 
RELATED to differentiate these from NEW.

The conntrack packet state is what is being matched by -m state.

The TCP tracking state is based on what kind of TCP packets have been 
seen on the connection. The TCP state is what is being printed in 
/proc/net/ip_conntrack but is not really used in any iptables 
rulesets. Mainly determines the current timeout of the conntrack 
entry.

The conntrack packet states are:

INVALID
This packet cannot be tracked for some reason

NEW/ESTABLISHED/RELATED
How this packet relates to the connection. These are not really states 
but derived from the current state and the packet being processed. 
See below.

ORIGINAL/REPLY:  (flag, in addition to NEW/ESTABLISHED/RELATED)
Direction of this packet in relation to the packet that caused this 
conntrack to be created (NEW).

The above states are "ctinfo" and is derived from the conntrack state 
flags and the packet currently being processed. The actual conntrack 
state flags are:

ASSURED
The protocol (TCP/UDP/IMCP...) has seen the initiation and 
establishment of this connection. For TCP this requires seeing the 
whole SYN -> SYN+ACK -> ACK transition, for UDP and ICMP it simply is 
seeing traffic in both directions..

SEEN_REPLY
There has been traffic seen in both directions on this connection. 
This is what makes conntrack packet state ESTABLISHED.

EXPECTED
This connection is identified as belonging to another connection. This 
is what makes conntrack packet state RELATED.

If netiher of SEEN_REPLY or EXPECTED is true for the connection then 
the packet state is NEW.

Of these, only ASSURED is directly dependent on the TCP connection 
tracking state, the others are only dependent on the ability of 
identifying which connection the packet may belong to.

Regards
Henrik

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Hi,

Excellent.

Thanks a lot for pointing ip_conntrack_core.c and explain all this !


Henrik Nordstrom wrote:
> 

....

> The above states are "ctinfo" and is derived from the conntrack state 
> flags and the packet currently being processed. The actual conntrack 
> state flags are:
> 
> ASSURED
> The protocol (TCP/UDP/IMCP...) has seen the initiation and 
> establishment of this connection. For TCP this requires seeing the 
> whole SYN -> SYN+ACK -> ACK transition, for UDP and ICMP it simply is 
> seeing traffic in both directions..
> 
> SEEN_REPLY
> There has been traffic seen in both directions on this connection. 
> This is what makes conntrack packet state ESTABLISHED.
> 
> EXPECTED
> This connection is identified as belonging to another connection. This 
> is what makes conntrack packet state RELATED.
> 
> If neither of SEEN_REPLY or EXPECTED is true for the connection then 
> the packet state is NEW.

Ok.

I think I can see now why you didn't went to much in depth in the
packet-filtering HOWTO. The stateful module could require a full HOWTO
for itself if you want to fully understand it... :-/

The problem is that the definition of the HOWTO states that NEW match:

     A packet which creates a new connection.

That's not true if you consider this from the protocol point of view
(and the confusion is happening very often). I could suggest something
like:

     A packet which creates a new entry in the connection table
     (Warning: NEW is matching all the packets which are creating a
      connection in the considered protocol plus some others. For
      example, considering the TCP protocol, an ACK packet which is not
      part of an existing connection will also match the state NEW).

If you are agree on this modification, I'll do the patch against the
CVS archive.

(By the way, I can add also my proposition in the FAQ if everybody is
  agree).


All suggestions or modifications are welcome.

> Of these, only ASSURED is directly dependent on the TCP connection 
> tracking state, the others are only dependent on the ability of 
> identifying which connection the packet may belong to.

Actually, ASSURED seems to be related to all the protocols which
expect a confirmation from the receiver before establishing the
connection (but in your case only TCP need a confirmation. UDP and
ICMP does not need this). Right ?

Regards
-- 
Emmanuel

Go not to Usenet for counsel, for it will say both
no, and yes, and no, and yes, and no, ....
   -- Unknown

Re: Security flaw in Stateful filtering ??????

[Patrick Schaaf]

> Thanks a lot for pointing ip_conntrack_core.c and explain all this !

Agreed. Thanks, Henrik.

> The problem is that the definition of the HOWTO states that NEW match:
> 
>      A packet which creates a new connection.
> 
> That's not true if you consider this from the protocol point of view

I think you are correct here; there's an ambiguity here, and I'd wish
connection tracking would be called flow tracking or something. However,
it's too late for that, now.

Realistically, I think that the docs would be best augmented by an extra
chapter on "why does the man-in-the-middle say connection to different
things than the protocols". Bad title, I know, but instead of explaining
the difference partially and clumsily everywhere it matters, a lucid extra
part of the docs would be preferrable (and then reference that where it
matters).

> > Of these, only ASSURED is directly dependent on the TCP connection 
> > tracking state, the others are only dependent on the ability of 
> > identifying which connection the packet may belong to.
> 
> Actually, ASSURED seems to be related to all the protocols which
> expect a confirmation from the receiver before establishing the
> connection (but in your case only TCP need a confirmation. UDP and
> ICMP does not need this). Right ?

Right, I think. If another protocol parallel to TCP comes along which has
such a setup phase (SCTP comes to mind), it could be handled likewise.
Also, I could imagine special TCP conntrack helpers to go even further,
and defer the ASSURED marking to a point where more of the connection
is known, e.g. real data has been seen in one direction, and correctly
acked.

best regards
  Patrick

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Hi Guillaume,

Guillaume Morin wrote:
> 
> The documentation is correct because it assumes you understand
> "connection" as a conntrack entry. 

Hum.

> I do agree that it should be  more explicit.

We met an agreement so.

>>The funny thing is that if you have a bad ruleset, you can easily be
>>DOSed by some external people which are just sending random ACK packets.
>>
>>Those ACKs will create entries in your connection table as ESTABLISHED
>>connections with a time-out of.... 5 days !!!!! 8-)
> 
> 
> Well no, since the concerned box will reply with a RST.

Try to imagine what if I try to address ACK to computer which are not
existing in your network.... see the picture now ???? :-)

Regards
-- 
Emmanuel

A dreamer is one who can only find his way by moonlight, and his
punishment is that he sees the dawn before the rest of the world.
   -- Oscar Wilde

Re: Security flaw in Stateful filtering ??????

[Henrik Nordstrom]

Emmanuel Fleury wrote:

> Does this means that you are mapping the packets to a state (NEW,
> ESTABLISHED, RELATED, INVALID) only based on information on their
> header and a query to the connection table ? And that you do not
> care about the previous state of the connection ?

No, NO/ESTABLISHED/RELATED/INVALID is about packet flows, not header 
information.

The first packet (and any retransmissions of the first packet) will be NEW

The reply will be ESTABLISHED

Related packets such as related connection (i.e. FTP data connections) or ICMP 
related to the TCP connection will be RELATED.

> Moreover, is it possible to create an entry in the connection table
> just by sending an ACK ??? (somebody wrote this at some point).

Yes. Exacly the same as a SYN.

> Finally, I tried to think about this 'connection pick-up' thing and
> I really don't understand how do you can restore a connection after
> the reboot. What is the algorithm which is used for this ?
> (My problem is that in the case of a NAT, you can receive an ACK packet
> on your FORWARD chain coming from outside and you have to translate
> it to your inner network. But you lost all the informations about it).

pickup is not always possible in NAT, but in the wast majority of NAT sessions 
the translation applied to the picked up connection will be identical to the 
translations applied to the original connection.

If the NAT translation gets different the connection will be reset by the 
server and the connection pickup fails.

Regards
Henrik

Re: Security flaw in Stateful filtering ??????

[Henrik Nordstrom]

Emmanuel Fleury wrote:
> Henrik Nordstrom wrote:
> > This configuration can be done just fine with iptables as demonstrated in
> > my earlier message, but here we go again (but slightly different):
> >
> > # Allow existing connections
> > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> > # Allow hidden net to initiate new connections (including connection
> > pickup) iptables -A FORWARD -i eth0 -j ACCEPT
> > # Drop anything else
> > iptables -A FORWARD -j DROP
>
> Sorry, I don't understand something ! :-/
>
> Does that mean that you DROP all the ACKs, even those which are valid ?

Valid ACKs (including SYN,ACK, ICMP errors etc) are matched by the first rule 
as these will be ESTABLISHED.

Hidden network sends SYN, this gets state NEW in the firewall and do not match 
the first rule. The second rule then picks up the packet and allows it to be 
sent out as it is sent from the trusted network (eth0), thereby allowing the 
conntrack entry to be created.

SYN+ACK received from the called server, matching the conntrack entry created 
by the SYN and gets matched as ESTABLISHED in the first rule.

Future ACK's matching this conntrack gets matched by the first rule as 
ESTABLISHED.


Now, lets assume the firewall reboots or other action causing the conntrack 
entry to disappear from the netfilter connection tracking table.


Server (external / eth1) sends ACK. As there is no conntrack entry this gets 
state NEW and is NOT matched by the first rule, and as it is not initiated 
from your hidden network (eth0) it is NOT allowed by the second rule and gets 
denied by the third rule. As the packet is not allowed no conntrack entry 
gets ceated here.

Client (internal / eth0) sends ACK. As there is no conntrack entry this is a 
NEW packet and is not accepted by the first rule. But as the second rule 
allows anything from the inside the packet is accepted, allowing the 
conntrack entry to be created.

Server sends ACK after receiving the client ACK. This matches the conntrack 
entry created above and will be matched as ESTABLISHED by the first rule and 
the connection tracking state has been fully restored.

Regards
Henrik

Re: Security flaw in Stateful filtering ??????

[Ben Reser]

On Fri, Jun 07, 2002 at 10:15:26AM +0200, Emmanuel Fleury wrote:
> Precisely.
> 
> Actually, my exact complain is now that the documentation is not
> making you awared of what you are exactly doing...
> 
> Somehow, this is dangerous and can lead you to have a flaw in your
> firewall without being awared of it.
> 
> Moreover, most of the papers, articles, and web pages about Netfilter
> are wrong about this.

So submit a patch to the documentation.  One of the very first emails to
answer your original post said that a patch to the documentation would
be accepted and probably applied promptly.

The issue is understood.  No point in going on and on and on about how
the documentation is wrong in your opinion.  Spend your time fixing it
instead of bitching about it.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org

We tend to see all wars through the lens of the current conflict, and we
mine history for lessons convenient to the present purpose.
- Brian Hayes

Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Ben Reser wrote:
> 
> So submit a patch to the documentation.  One of the very first emails to
> answer your original post said that a patch to the documentation would
> be accepted and probably applied promptly.
> 
> The issue is understood.  No point in going on and on and on about how
> the documentation is wrong in your opinion.  Spend your time fixing it
> instead of bitching about it.

If I have to fix the documentation, I would like to understand the
exact behaviour of the connection tracking module.

My point is not to go "on and on and on", but "deeper and deeper
and deeper". Once I reach to right amount of knowledge about it,
I will fix it (or I will make it so clear that anybody which
has followed the thread will be abble to fix it).

Is it ok ?

-- 
Emmanuel

Help me out, and I won't ever call "netfilter" a heap of stinking dung
again. Do we have a deal?
   -- Linus Torvalds

Re: Security flaw in Stateful filtering ??????

[Patrick Schaaf]

> My point is not to go "on and on and on", but "deeper and deeper
> and deeper". Once I reach to right amount of knowledge about it,
> I will fix it (or I will make it so clear that anybody which
> has followed the thread will be abble to fix it).

The latter approach won't be effective. You want a change, you work with
the core team by submitting patches against the CVS archive. I doubt that
anybody in this thread but you cares enough to do more than help you
along with understanding.

best regards
  Patrick

Re: Security flaw in Stateful filtering ??????

[Ben Reser]

On Sat, Jun 08, 2002 at 04:13:58AM +0200, Emmanuel Fleury wrote:
> If I have to fix the documentation, I would like to understand the
> exact behaviour of the connection tracking module.
> 
> My point is not to go "on and on and on", but "deeper and deeper
> and deeper". Once I reach to right amount of knowledge about it,
> I will fix it (or I will make it so clear that anybody which
> has followed the thread will be abble to fix it).
> 
> Is it ok ?

Sorry I was a bit cranky yesterday.  Things wore thin on me...
But I still think this has ben discussed to death and not just this time
either.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org

We tend to see all wars through the lens of the current conflict, and we
mine history for lessons convenient to the present purpose.
- Brian Hayes

ACK is NEW: Conclusion ? (was:Re: Security flaw in Stateful filtering ??????)

[Emmanuel Fleury]

Hi all,

Ok, let's conclude this thread.

What was the initial problem ?:
-------------------------------

FAQ: Some invalid ACK packets are going through my firewall !!!

   By reading the current documentation, most of the people are assuming
that there is a perfect match between the states of the TCP protocol
and the states of the connection tracking module (NEW, ESTABLISHED,
RELATED and INVALID).

   This is wrong !

   For example, the state NEW of the connection tracking module is
matching much more than the three way handshake initiating a TCP
connection. Actually, all the ACK packets which are not part of a
registered connection are matched as NEW and will create a new
entry in the table. In the same way, the FIN and RST packets which are
not part of any existing connection will create a new entry.

   This behaviour is _not_ a bug of Netfilter, it is intended in order
to avoid to shut down the pending connections after a reboot of the
firewall.

   The solution to fix this behaviour in the ruleset is to write:

# Disallow INVALID packets (must be in first position)
iptables -A FORWARD -m state --state INVALID -j DROP
# Allow existing connections
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
...

   For more details, the precise behaviour of the state machine of the
connection tracking module can be found in: ip_conntrack_proto_tcp.c.



Some pending questions:
-----------------------

1) How to Define NEW and INVALID ?

   Well, actually, the NEW and INVALID states does not exist, except
in a user point of view (where is the definition of those states in the
code ?). They are both matching the NO state which can probably be
defined as:

            All the packets which are not part of a connection.


   Therefore, it is difficult for me to define NEW and INVALID precisely.
If somebody can make this point clear, I would be pleased.


2) What documentation to fix ?

   I would say that this feature require at least an entry in the FAQ
(the first part of this post can probably be used for this, I already
agree on every necessary modification of this text).

   If a clear definition of what NEW and INVALID states are matching can
be done, the packet-filtering-HOWTO should be modified in consequence.

   Moreover, this behaviour should be recalled as often as possible
in order to avoid the confusion between the states of the connection
tracking module and the states of the TCP protocol.


Hope this help.
-- 
Emmanuel

The real fun of living wisely is that you get to be smug about it.
   -- Calvin & Hobbes (Bill Waterson)