Denial of service attack against ip_conntrack ?
Fri, 14 Apr 2000 13:19:22 +0200 (CEST)
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
> > 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
> > > 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
- 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
Just some idea,
E-mail : firstname.lastname@example.org, email@example.com
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary