Denial of service attack against ip_conntrack ?

[Jozsef Kadlecsik]

On Fri, 14 Apr 2000, Rusty Russell wrote:

> In message <20000409125451.B18510@aldem.net> you write:
> >   The problem is different - my testing show that connection record
> >   is created even if I send packet with only FIN or ACK packet set.
> 
> I stole the connection tracking code from masquerading.  What do you
> think is the correct behaviour if the machine reboots?  It doesn't
> matter in this case, because you can always do the same thing with
> real SYN packets.

It is not only the DoS attack. The other side of the problem is that ACK
scannings cannot be prevented with the current TCP conntrack model as
well.

> >   In addition - I really do not think that we need unconditional
> >   tracking of _all_ connections - in some cases it is not necessary
> >   (just imagine two busy gateways/firewall - one is central and one
> >   is behind it - but both are responsible for firewalling).
> 
> We don't need all of them, but it's much nicer to control.  I am
> aiming for completeness and simplicity of administration with the
> netfilter stuff, not speed or efficiency (we have FAST NAT, and
> hardware routers for that).

The possible audience for netfilter is wide: on one side small
groups with thin 64k connections to the Internet. But on the
other side are universities, research insitutes, labs etc. with fat
Internet connections. They do need speed and efficiency - and for
firewalling!

> > > I'm testing a patch now which introduces a more sophisticated form of
> > > DoS avoidance, which should prevent it from hitting the wall quite as
> > > suddenly (by definition, you will eventually lose).
> > 
> >   No way - it cannot be done... Until we have table of connections, and
> >   until there is no filtering on the other level (IPsec?) it is not
> >   possible by definition - because it is too easy to send a lot of
> >   SYN packets...
> >   
> >   Timeouts can help, but only in case of slow links, not on high-speed
> >   links...
> 
> Here's my proposed approach:
> 
> Firstly, don't track connections where the packets which create them
> get dropped.  Secondly, do Random Early Drop when a watermark is
> reached.  Thirdly, try to reduce the conntrack size so it will fit
> into a 256-byte (rather than 512-byte) slab allocator.  Fourth, TCP
> SYN-SENT connections which get a RST reply can be forgotten instantly.

If there were no NAT, then it would be easy to delay the creation of 
a new connection after the packet filtering. However with NAT and the
current infrastructure (conntrack - NAT - packet filtering), I don't
really see how could it be done simply :-(. 

I think the conntrack size cannot really be shrinked: sooner or later
(better sooner) sequence number checking with window sizes/scale
factors should be introduced for an improved TCP connection tracking.

> If you have other ideas, please suggest them.

- Have a "warm-up" timer until ACK/FIN packets may generate new
  connection entries.

- Create the new connection entries but with a flag like
  POSSIBLE_ESTABLISHED (with faster timeout?). Until a positive reply
  packet is not detected, don't accept other incoming packets. If the
  reply packet is RST, drop the connection entry immediately.

- What about fine grained watermarks? Netfilter's infrastructure suggests
  it: conntrack table, with which one can control the number of 
  connections per source/destination (/protocol?). (Some kind of wildcard
  notation would be quite exciting: "any C network may have only x
  parallel connections/sec".)

Just some idea,
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