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)

Security flaw in Stateful filtering ??????

[Mikkel Christiansen]

Hi 

I'm still not sure I quite understand what actions an 
ACK packet from an unregistered connection causes when 
running in connection-pickup mode. Mainly, I'm interested
in knowing whether it causes a new connection to be 
registered in the connnection table or not?
 
Thanks for all the feedback - atleast to us - this is 
a quite interesting discussion.

-Mikkel

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

[Harald Welte]

On Fri, Jun 07, 2002 at 11:42:08AM +0200, Mikkel Christiansen wrote:
> Hi 
> 
> I'm still not sure I quite understand what actions an 
> ACK packet from an unregistered connection causes when 
> running in connection-pickup mode. Mainly, I'm interested
> in knowing whether it causes a new connection to be 
> registered in the connnection table or not?

yes, of course, it causes a new conntrack table entry to be created.
the entry will be UNREPLIED.  So in case the other end behind the
firewall will reply with an ACK packet, we call the connection
ESTABLISHED.

In case we run out of conntrack entries, the UNREPLIED entries are
deleted, because they _could_ be from an ACK scan.

> Thanks for all the feedback - atleast to us - this is 
> a quite interesting discussion.

... a discussion which has happened multiple times before.

look in the mailinglist archives and search for conntrack entries with
high timeount and UNREPLIED state.

> -Mikkel

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

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

[Andy Whitcroft]

If I understand correctly what is being said is that if
an ACK only packet passes the firewall for a connection
which is otherwise unknown a lost connection is assumed
and the connection will be reaquired, ie become valid
and allow reply packets to be treated as ESTABLISHED from
a contrack point of view.

Whilst this sounds dangerous, the key statement here is
that the ACK only packet is treated as NEW.  If you are
accepting state NEW you are allowing new connections
to pass the firewall in that direction anyhow, so the
firewall is 'open' in that direction.  So almost any
kind of port scan is likely to work in that direction.

Taking your example, this will occur because the packet
matches the NEW state match and is acceptable, note it
is not matching the ESTABLISHED state.

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

A more typical example would be something like below.
Here we only accept NEW packets from the LAN interface
(a safe and secure internal network).  In the case of
a loss of the connection (from a firewall reboot) we
will be getting ACK packets from both ends of the
connection.  However, the packets from the dangerous
end of the connection will not be compared to the
NEW state and so be dropped as expected.  The first
ACK from the secure internal network will reopen
the connection in the firewall and then the external
ACK's will start to be accepted as ESTABLISHED.

iptables -A FORWARD -i $WAN -o $LAN -p tcp \
      -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $LAN -o $WAN -p tcp \
      -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p tcp -j DROP

Assuming I understand this correctly this seems safe
as connection reaquire can only occur in the directions
through the firewall that we have already said
attempting to open connections is valid.

Cheers.

-apw

RE: Security flaw in Stateful filtering ??????

[Sneppe Filip]

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

Yes, it's that time of the month again :-) 

Emmanuel Fleury [mailto:fleury@cs.auc.dk] wrote:
>
>Patrick Schaaf wrote:
>
>> The behaviour is intentional. The reason is "connection pickup". Imagine
>> a situation where the firewall reboots. All active conntracking information
>> will be lost. With the observed behaviour, connections are "relearned"
>> on the fly as they create new traffic.
>
>I simply disagree with you on this point (sorry :-/).
>
>I wouldn't accept to have such a flaw in my firewall just because of
>an hypothetic reboot of one of my gateway !!!!
>
>Of course, I could be wrong, but in this case this 'feature' should be
>highly documented and be disabled as default. IMHO.

Hi Emmanuel,

Please note that connection tracking doesn't just pick up connections
based on ACK packets willy-nilly after hypothetical reboots. So there
really is no security problem whatsoever.

It's all a matter of the policy set by the admin. If you have rules
that say to accept ESTABLISHED packets, and to accept tcp connections
to port 25 of your mailserver's IP address, and if your firewall reboots,
it's not like all of a sudden other ports to the mailserver will open 
automagically!

If the mailserver sends a packet with sourceip=it's IP, source port=25,
destip=remote IP, destport= > 1023, it will get dropped, and if 
the other end sends a non-SYN packet to port 25, it goes through and the 
connection picks up, just like you specified in the rules. 

It's a feature I want, and I assume a lot of people want it, since
Checkpoint has been behaving exactly like this for many years.

If you're worried about weird scans, just specify tighter rules
and combine the ESTABLISHED and NEW states with additional checking
of TCP flags.

iptables offers flexibility, not a policy, and one should tailor 
netfilter/iptables to one's needs/policy.

Regards,
Filip





[-- Attachment #2: Type: text/html, Size: 2627 bytes --]

Security flaw in Stateful filtering ??????

[Emmanuel Fleury]

Hi,

I am co-supervising students in Aalborg university on a project
about firewalls (and more precisely about stateful firewalling)
in collaboration with Mikkel Christiansen.

Recently, they were testing some of their ideas to improve the
connection tracking module of Netfilter in the university lab
and they discovered some weird things in the behaviour of
Netfilter.

I am just quoting their mail here:

=====
....

The Setup:
----------
A classical client-filter-server setup (two different networks on each
end with a filter/gateway in between). The filter/gateway is configured
to route between the two nets and has the following rules in IP Tables
as suggested by the documentation (see:
http://netfilter.samba.org/documentation/HOWTO/packet-filtering-HOWTO-5.html):

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

These rules should indicate that we allow packets that create new
connections and packets that are a part of an established connection.
We then drop everything else. These are not good rules for a filter but
they illustrate the point.


The Problem:
------------
When sending an ACK packet, the packet is allowed through the filter.
Due to the second rule. This means that ACK packets are accepted as
being in the state NEW and does not create an entry in the state table.
So if any rule state that we allow NEW connections, this rule can be
used for port scanning.

The ACK packet and the corresponding RST packet were observed on every
machine, i.e. client, server and filter. And, actually, we were able to 
perform a complete ACK scan of the whole network through the filter by
using "nmap -sA".


A Solution:
-----------
As a temporary hack the following rule can be added as the second rule:

iptables -A FORWARD -p tcp --tcp-flags ACK ACK -j DROP

However, this is not a solid solution and the code should be modified,
as we see it, not to recognize ACK packets as being in the state NEW.

We were wondering if this is intentional due to some reason that we
cannot see or if it is a flaw as suggested ?

We have found something about it in the Iptables tutorial (1.1.8),
page 54 (Appendix B, "State NEW packets but no SYN bit set").
But, this is not really convincing.

Any idea ????

Regards,
Mikkel Refsgaard Bech
Torben Vinther Schmidt
Carsten Stiborg
=====

For short:
- ACK packets are classified as NEW (without opening a connection),
- Therefore, allowing NEW packets allow all the ACK packets to go
   through,
- And consequently, in this setting, you can perform ACK scanning
   if you just trust the documentation...

Actually, I don't know what to answer to them. Has somebody any clue to
explain this ?

Regards
-- 
Emmanuel

Maybe somebody should tell gcc maintainers about programmers
that know more than the compiler again.
   -- Linus Torvalds

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

[Martin Josefsson]

On Thu, 2002-06-06 at 19:21, Emmanuel Fleury wrote:

[snip]
> I am just quoting their mail here:
 
[snip again]

> For short:
> - ACK packets are classified as NEW (without opening a connection),
> - Therefore, allowing NEW packets allow all the ACK packets to go
>    through,
> - And consequently, in this setting, you can perform ACK scanning
>    if you just trust the documentation...
> 
> Actually, I don't know what to answer to them. Has somebody any clue to
> explain this ?

Tell them (well  they are probably the ones cc'd :) to read through the
netfilter and netfilter-devel mailinglist archives as there's been
discussions about this.

And tell them that they should look at the conntrack-tcp-nopickup patch
in patch-o-matic. This patch disables the exact thing described here.

I recently mailed a patch against patch-o-matic that improves the
conntrack-tcp-nopickup patch so you can change the behaviour at runtime.

The newest tcp-window-tracking patch also has support for disabling this
type of connection pickup.

If you apply the conntrack-tcp-nopickup patch these ACK's will be marked
as INVALID instead of NEW.

-- 
/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

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

[Maciej Soltysiak]

Hi,

> A Solution:
> -----------
> As a temporary hack the following rule can be added as the second rule:
> 
> iptables -A FORWARD -p tcp --tcp-flags ACK ACK -j DROP
Well, i think everybody who gets to that point uses:
iptables -A FORWARD -p tcp -m state --state NEW --syn -j ACCEPT

type of rules. new + syn.

> However, this is not a solid solution and the code should be modified,
> as we see it, not to recognize ACK packets as being in the state NEW.
I belive that state NEW says: a packet never seen before. A tuple that
does not exist in currect tracked connections table.
I am no netfilter super guru/hacker, but i think connection tracking only
does its job on the information based on what is in the IP header.
So it works for all IP protocols.
But TCP, being so different, should be handled with the --syn flag option
to handle new connections.

I think that -m state NEW does its job logically, altough it would be very
useful if it did some TCP flags inspection on TCP packets.


> We were wondering if this is intentional due to some reason that we
> cannot see or if it is a flaw as suggested ?
I belive the explanation above explains it.
 

Comments, anyone?
Regards,
Maciej Soltysiak

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

[Emmanuel Fleury]

Maciej Soltysiak wrote:
> Hi,
> 
> 
>>A Solution:
>>-----------
>>As a temporary hack the following rule can be added as the second rule:
>>
>>iptables -A FORWARD -p tcp --tcp-flags ACK ACK -j DROP
> 
> Well, i think everybody who gets to that point uses:
> iptables -A FORWARD -p tcp -m state --state NEW --syn -j ACCEPT
> 
> type of rules. new + syn.
> 
> 
>>However, this is not a solid solution and the code should be modified,
>>as we see it, not to recognize ACK packets as being in the state NEW.
> 
> I belive that state NEW says: a packet never seen before. A tuple that
> does not exist in currect tracked connections table.

So, what are the INVALID packets ?????


According to my poor knowledge of TCP, I was classifying the NEW packets
as the packets which were part of the first three way handshake:

SERVER (LISTENING)                       CLIENT (CONNECTING)
                            SYN
                    <-------------------


                         SYN + ACK
                    ------------------->


                            ACK
                    <-------------------

                     3-Way TCP handshake


After this, I was assuming that we were in the ESTABLISHED state.

Regards
-- 
Emmanuel

Premature optimization is the root of all evil.
   -- Donald Knuth

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

[Maciej Soltysiak]

> > I belive that state NEW says: a packet never seen before. A tuple that
> > does not exist in currect tracked connections table.
> 
> So, what are the INVALID packets ?????
quote:
"A packet which could not be identified for some
 reason: this includes running out of memory and ICMP errors which
 don't correspond to any known connection."

> After this, I was assuming that we were in the ESTABLISHED state.
Hmm, i think we are in established just after the first SYN.
so the SYN/ACK and ACK are ESTABLISHED, as having the same parameters as
the first SYN. Same tuple.

So i think conntrack works irregardles of the protocol seen.

If this is true (i am going to research that), that would mean my
assumption regarding how conntrack wroks is true.


Regards,
Maciej

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

[Guillaume Morin]

Dans un message du 06 jun à 20:52, Emmanuel Fleury écrivait :
> So, what are the INVALID packets ?????

The INVALID state concerns the connection state. INVALID packets carry
connection flags that are not expected by the conntrack.

e.g syn/ack with a previous syn

> After this, I was assuming that we were in the ESTABLISHED state.

They are.

The ACK packets match as NEW are a special case. It happens when
netfilter can't find a related connection. It has been discussed here
plenty of times. It allows to change NAT easily and to interrupt traffic
if for some reason, your firewall crashes or something.

I agree that it should be documented. I really thought it was in the FAQ
or something. Anyway, it has been discussed here several times. Feel
free to submit some documentation updates.

-- 
Guillaume Morin <guillaume@morinfr.org>

    Last night I saw the face of God, but waking I'd forgotten who she was.
                                    (Addict)

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

[Patrick Schaaf]

> I agree that it should be documented. I really thought it was in the FAQ
> or something.

Seeing that five people independantly answered roughly the same,
within 20-30 minutes of the original question, I think we have
here a very genuine FAQ.

:)
  Patrick

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

[Henrik Nordstrom]

Emmanuel Fleury wrote:

> So, what are the INVALID packets ?????

Packets where it is impossible to identify a session key to use when matching 
reply packets as belonging to the same session. This is mostly malformed 
packets.

I think RST of a non-existing session also classifies as INVALID, but I am not 
sure.. and in reality does not matter much..

Regards
Henrik

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

[Patrick Schaaf]

Hello,

> iptables -A FORWARD -p tcp -m state --state NEW -j ACCEPT
>
> The Problem:
> ------------
> When sending an ACK packet, the packet is allowed through the filter.
> Due to the second rule. This means that ACK packets are accepted as
> being in the state NEW and does not create an entry in the state table.
> So if any rule state that we allow NEW connections, this rule can be
> used for port scanning.

The "problem" has been reported here several times, already.

> We were wondering if this is intentional due to some reason that we
> cannot see or if it is a flaw as suggested ?

The behaviour is intentional. The reason is "connection pickup". Imagine
a situation where the firewall reboots. All active conntracking information
will be lost. With the observed behaviour, connections are "relearned"
on the fly as they create new traffic.

> A Solution:
> -----------
> As a temporary hack the following rule can be added as the second rule:
> 
> iptables -A FORWARD -p tcp --tcp-flags ACK ACK -j DROP

This is indeed only an ugly hack. Make your students think about what
exactly they want. Somehow, new connections need to be accepted, or
you wouldn't have anything to match the ESTABLISHED rule. The thing
you want to at least accept, are packets with SYN set, and the SYN/ACK
in the opposite direction. A real forwarding table will additionally
match on certain ports, to make sure even the SYN is only accepted
for permitted protocols.

Thus, you want a ruleset like this to properly do "no connection pickup".
I assume we are talking about tcp, only:

1) permit ESTABLISHED
2) deny INVALID
(now only state NEW should be left, right?)
3) deny packets which are neither SYN nor SYN/ACK
4-N) specifically permit the desired protocols, using port based matches.

> We have found something about it in the Iptables tutorial (1.1.8),
> page 54 (Appendix B, "State NEW packets but no SYN bit set").
> But, this is not really convincing.

I hope I could explain the rationale, and how to cope if your policy
demands it, a bit better.

best regards
  Patrick

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

[Emmanuel Fleury]

Hi,

Patrick Schaaf wrote:
> 
> The "problem" has been reported here several times, already.

Sorry, I should have browse the archive more carefully.

> The behaviour is intentional. The reason is "connection pickup". Imagine
> a situation where the firewall reboots. All active conntracking information
> will be lost. With the observed behaviour, connections are "relearned"
> on the fly as they create new traffic.

I simply disagree with you on this point (sorry :-/).

I wouldn't accept to have such a flaw in my firewall just because of
an hypothetic reboot of one of my gateway !!!!

Of course, I could be wrong, but in this case this 'feature' should be
highly documented and be disabled as default. IMHO.

One of the major argument in favor of the stateful inspection is that
it prevents from a lot of weird scans (NULL scan, X-MAS scan, ACK scan,
...). If you just drop this feature, I really don't see the point to
activate this 'connection tracking thingy' and make your gateway
sensitiv to DOS attack, just for fun...

Ok, I am pretty newbie in this topic, so I don't have any idea of:
'How often a gateway has to reboot'. But, somehow, I heard that
Linux boxes had pretty good uptimes (well, at least, mine have).

And, even in case of reboot, what sort of connection is more important
than preventing such scan of your network ????

Anyway, I should browse the archive of the mailing-list and try to
convinced myself how foolish I am. :-)

> This is indeed only an ugly hack. Make your students think about what
> exactly they want. Somehow, new connections need to be accepted, or
> you wouldn't have anything to match the ESTABLISHED rule. The thing
> you want to at least accept, are packets with SYN set, and the SYN/ACK
> in the opposite direction. A real forwarding table will additionally
> match on certain ports, to make sure even the SYN is only accepted
> for permitted protocols.
 >
> Thus, you want a ruleset like this to properly do "no connection pickup".
> I assume we are talking about tcp, only:
> 
> 1) permit ESTABLISHED
> 2) deny INVALID
> (now only state NEW should be left, right?)
> 3) deny packets which are neither SYN nor SYN/ACK
> 4-N) specifically permit the desired protocols, using port based matches.
> 
> 
>>We have found something about it in the Iptables tutorial (1.1.8),
>>page 54 (Appendix B, "State NEW packets but no SYN bit set").
>>But, this is not really convincing.
> 
> 
> I hope I could explain the rationale, and how to cope if your policy
> demands it, a bit better.

Actually, they are measuring the Round Trip Time (RTT) of SYN and ACK
packets in order to minimize the time-out of a connection in the
connection table.

One of their experiment was trying to figure out what is the impact of
removing a connection too early from the connection table.

The plan was to see what was happen when the last ACK (answering to
the FIN packet) was retransmitted because of the loss of the FIN packet.

Of course, it was expected that the firewall, as the connection has been
pruned from the connection list, would have dropped the retransmitted
ACK.... of course the behaviour that they get was somehow different of
what they were expected.


Regards
-- 
Emmanuel

What happens if a big asteroid hits the Earth?
Judging from realistic simulations involving a sledge hammer and
a common laboratory frog, we can assume it will be pretty bad.
   -- Dave Barry

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

[Patrick Schaaf]

> > The behaviour is intentional. The reason is "connection pickup". Imagine
> > a situation where the firewall reboots. All active conntracking information
> > will be lost. With the observed behaviour, connections are "relearned"
> > on the fly as they create new traffic.
> 
> I simply disagree with you on this point (sorry :-/).

Umm. No need to be sorry. Disagreement are what spans up a problem domain.

> I wouldn't accept to have such a flaw in my firewall just because of
> an hypothetic reboot of one of my gateway !!!!

That's your policy choice. I may have others, in other situations.

> Of course, I could be wrong,

In your policy choice? Unlikely.

> but in this case this 'feature' should be
> highly documented and be disabled as default. IMHO.

Any sensible patch to the current documentation has a good chance of being
applied immediately.

Disabling the current behaviour is out of the question. iptables is used
as-is in the field.

> One of the major argument in favor of the stateful inspection is that
> it prevents from a lot of weird scans (NULL scan, X-MAS scan, ACK scan,
> ...).

My personal "must have" reason is proper per-tcp-connection NAT, i.e. the
ability to change rules without breaking already-active connections.

That's not dependant on reboot/pickup, so I probably personally wouldn't
care in most setups where I used iptables' conntracking in the past.

But if I learned that such a radical change were imminent, I'd be very
alert to recall where it may bite me in my "installed base", and I'd
probably miss one or two.

> Anyway, I should browse the archive of the mailing-list and try to
> convinced myself how foolish I am. :-)

Just remember that you are arguing out of your current view of where to
utilize iptables, and that you can easily implement the no-pickup policy
using a suitable rule "idiom", or using one of the explicit patches.

all the best, and low jitter to your students' measurements
  Patrick

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

[Emmanuel Fleury]

Patrick Schaaf wrote:
> 
> That's your policy choice. I may have others, in other situations.

Well, you're right this is a choice. I was just a little bit surprised
that:

1) This choice has not been so well documented,
2) No alternative, except the PATCH-O-MATIC, was proposed to the user.

But, once again, this is my policy choice.


> Any sensible patch to the current documentation has a good chance of being
> applied immediately.

I think, it could help to just add in the Packet-filtering HOWTO,
section 7.3 (Filtering Specifications)  :

NEW

     A packet which creates a new connection _and_all_ACK_packets_.


It sounds to be fair enough. At least the user know what he's doing.


> Disabling the current behaviour is out of the question. iptables is used
> as-is in the field.

Well, at least the PATCH-O-MATIC can help to disable if you choose it.
:-/

> My personal "must have" reason is proper per-tcp-connection NAT, i.e. the
> ability to change rules without breaking already-active connections.
> 
> That's not dependant on reboot/pickup, so I probably personally wouldn't
> care in most setups where I used iptables' conntracking in the past.
> 
> But if I learned that such a radical change were imminent, I'd be very
> alert to recall where it may bite me in my "installed base", and I'd
> probably miss one or two.

Well, I won't fight for it. :-)

> all the best, and low jitter to your students' measurements

Thanks for them. :-)

Regards
-- 
Emmanuel

De gustibus non disputandum.
   -- Linus Torvalds

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

[Henrik Nordstrom]

Emmanuel Fleury wrote:

> I wouldn't accept to have such a flaw in my firewall just because of
> an hypothetic reboot of one of my gateway !!!!

And exactly what is the flaw here? What is it that your firewall ruleset is 
trying to achieve?

Sure NEW matches more than SYN, but as demonstrated you can easily refine what 
you accept as session initiations and this is what iptables firewalling is 
about. Making a ruleset that allows exactly what you intend.

To me the connection pickup feature is highly valuable, and I never seen it as 
a problem.

> Of course, I could be wrong, but in this case this 'feature' should be
> highly documented and be disabled as default. IMHO.

For most people the feature is no or minimal security risk as they always 
combine NEW with other criteria.

Only for people reading NEW as a synonym for SYN and therefore does not use 
--syn in their rules for maching TCP session initiations is at risk.

> One of the major argument in favor of the stateful inspection is that
> it prevents from a lot of weird scans (NULL scan, X-MAS scan, ACK scan,
> ...). If you just drop this feature, I really don't see the point to
> activate this 'connection tracking thingy' and make your gateway
> sensitive to DOS attack, just for fun...

And netfilter conntrack allows you detect such scans just fine. You just need 
to refine a little bit what you accept as NEW.

These scans will all show up as NEW in the filter.

> And, even in case of reboot, what sort of connection is more important
> than preventing such scan of your network ????

One does not rule out the other.

> Actually, they are measuring the Round Trip Time (RTT) of SYN and ACK
> packets in order to minimize the time-out of a connection in the
> connection table.

Why?

conntrack already deals with DOS situations due to too many unassured 
connections quite nicely..

(unassured == have seen traffic in one direction only)

and TCP is fairly strict on the minimum CLOSE_WAIT window to avoid false RST 
(or connection hangs in precense of stateful firewalls) due to lost FIN+ACK. 

> One of their experiment was trying to figure out what is the impact of
> removing a connection too early from the connection table.

Not good, but sometimes there is no choice due to memory constraints..

> The plan was to see what was happen when the last ACK (answering to
> the FIN packet) was retransmitted because of the loss of the FIN packet.

If you drop these too often you may DOS servers/clients..

> Of course, it was expected that the firewall, as the connection has been
> pruned from the connection list, would have dropped the retransmitted
> ACK.... of course the behaviour that they get was somehow different of
> what they were expected.

Only because they assumed NEW is a synonym for SYN.

Regards
Henrik

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

[Emmanuel Fleury]

Henrik Nordstrom wrote:
> 
> And exactly what is the flaw here? What is it that your firewall ruleset is 
> trying to achieve?

Ok, a 'flaw' is not exactly matching with this. Now that I am more
awared of the problem, I can describe this as: "an under-specified
feature which can lead the user to have a flaw in his firewall without
be awared of it".

Let me express my understanding of the problem:

The core of the problem seems to be a conflict between two features:

1) The existing connections shouldn't be stopped when you change the
    rules of your firewall at run time (something which occur much more
    often than the reboot of one firewall).

2) The connection tracking / Stateful inspection


Somehow the stateful inspection is probably flushing the connection
table when the rules are updated (is it right ?).

And therefore, all the connections are cuted when you change your
ruleset...

The solution which have been implemented is to consider the ACK packets
as beeing part of the NEW state (in place of the ESTABLISHED state as
one would expect, well, at least me).

But, I still don't understand how the data packets can go through your
firewall if they are not matching NEW (except if you have an assymetric
configuration as NAT)...

Moreover, the fact that you match ACK packets with NEW, break part of
the stateful inspection and force the user to make some additional rules
in order to avoid ACK scanning of your network.


Is it right ?????

This is no critics ! My point is just to try to understand the thing !


> Sure NEW matches more than SYN, but as demonstrated you can easily refine what 
> you accept as session initiations and this is what iptables firewalling is 
> about. Making a ruleset that allows exactly what you intend.

Yes, but the point is that you leave up to the user to fix something
which is obviously wrong in Netfilter. Somehow this should be
definitely be considered as a bad thing. IMHO.

> To me the connection pickup feature is highly valuable, and I never seen it as 
> a problem.

I can perfectly understand this if in place of speaking about reboot,
you speak about ruleset update. This feature make perfect sense for me.


> For most people the feature is no or minimal security risk as they always 
> combine NEW with other criteria.
> 
> Only for people reading NEW as a synonym for SYN and therefore does not use 
> --syn in their rules for maching TCP session initiations is at risk.

Well, somehow, you are speaking about the people who are just trusting
the documentation (eg packet-filtering-HOWTO).


>>Actually, they are measuring the Round Trip Time (RTT) of SYN and ACK
>>packets in order to minimize the time-out of a connection in the
>>connection table.
> 
> Why?
> 
> conntrack already deals with DOS situations due to too many unassured 
> connections quite nicely..
> 
> (unassured == have seen traffic in one direction only)

Ok, but this is preventing SYN-flooding only.

What about attacks (or just normal use after all) which are establishing
normal connection: three way handshake + exchange of data + closing the
connection.

After the last packet, and according to the few I know from Netfilter,
you will have to wait 2 minutes before removing the connection from
the connection table (these 2 minutes are specified in the RFC).

Therefore, if you can fill up your table in less than 2 minutes all the
new connections will be stopped.

Well, at least, this is what I understood of my students explanations...

> and TCP is fairly strict on the minimum CLOSE_WAIT window to avoid false RST 
> (or connection hangs in precense of stateful firewalls) due to lost FIN+ACK. 

Yes. The problem is as being the "man in the middle", you cannot be
awared if the final FIN has been received or not, so you have to wait
for the time-out.... in theory.

Because in practice, if you can guess the Round Trip Time, you can just
adapt your time out for this connection...

Well, at least, that's what the students claim and they are doing a lot
of experiments in the lab about it... ;-)

>>The plan was to see what was happen when the last ACK (answering to
>>the FIN packet) was retransmitted because of the loss of the FIN packet.
> 
> If you drop these too often you may DOS servers/clients...

Well, will see on the experiments. There is one experiment planed on
very fluctuating Round Trip Time (they are using the delay box from
the FreeBSD firewall in order to simulate random Round Trip Time).

Regards
-- 
Emmanuel

A child of five could understand this. Fetch me a child of five.
   -- Groucho Marx

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

[Henrik Nordstrom]

Emmanuel Fleury wrote:

> The core of the problem seems to be a conflict between two features:
>
> 1) The existing connections shouldn't be stopped when you change the
>     rules of your firewall at run time (something which occur much more
>     often than the reboot of one firewall).
>
> 2) The connection tracking / Stateful inspection

Nope. The connection pickup feature is purely about reboots and failover. 
Change of rules do not affect connection tracking in any manner. Only packets 
and actions taken by your ruleset does (DROP/REJECT kills the conntrack 
entry)

> But, I still don't understand how the data packets can go through your
> firewall if they are not matching NEW (except if you have an assymetric
> configuration as NAT)...

???

> Moreover, the fact that you match ACK packets with NEW, break part of
> the stateful inspection and force the user to make some additional rules
> in order to avoid ACK scanning of your network.

Not really, it only makes state NEW not very useful as a match as it is 
extremely broad.

A somewhat sane typical iptables rulesets looks like

-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD [definition of allowed connection] -j ACCEPT
-A FORWARD [definition of allowed connection] -j ACCEPT
-A FORWARD [definition of allowed connection] -j ACCEPT
...
-A FORWARD -j DROP

If we take the quoted example of a SMTP server, and adds a HTTP server in the 
mix this becomes

-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -d ip.of.smtp.server -p tcp --syn --dport 25 -j ACCEPT
-A FORWARD -d ip.of.smtp.server -p tcp --syn --dport 80 -j ACCEPT
-A FORWARD -j DROP

And will properly block all those scans you are so worried about.

Another exampe config, where connection pickup is wanted..

eth0: connected to internal trusted network
eth1: connected to external untrusted network

-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow for outgoing SSH sessions with connection pickup after reboot
-A FORWARD -i eth0 -p tcp --dport 22 -j ACCEPT
[more rules allowing what should be allowed...]
-A FORWARD -i eth0 -j REJECT
-A FORWARD -j DROP

which also blocks such scans if received from the outside (eth1), but allows 
some of them if received from the inside (eth0) and targeting allowed 
services.


I do have a few real life cases where -m state --state NEW is a valuable 
match, but these are too obscure for this thread.

Regards
Henrik