Denial of service attack against ip_conntrack ?

[Rusty Russell]

In message <Pine.LNX.4.10.10004141142330.32024-100000@blackhole.kfki.hu> you wr
ite:
> 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.

Huh?  If you're not letting any connections in:

	iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED \
		-j ACCEPT

If you are:

	iptables -A FORWARD -i ppp0 -m state --state NEW -p tcp --syn \
		-j ACCEPT

> > 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!

Think carefully: how do you decide which packets *not* to track?  How
is this decision faster than associating a packet with a connection?

The current code can be sped up, no doubt.  But the code is not simple
as it is; now is *not* the time to increase complexity.

> 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 :-(. 

Precisely.  Consider the following rule:

	iptables -A FORWARD -i ppp0 -m state --state RELATED -j ACCEPT

This one rule means that we need to track *all* traffic, to identify
packets which are related to it. 8(

> 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.

Yes.  Window tracking very nice: the recent ipfilter paper on the
subject even makes it pretty easy.  I look forward to someone
implementing it in the 2.4 series.

> > If you have other ideas, please suggest them.
> 
> - Have a "warm-up" timer until ACK/FIN packets may generate new
>   connection entries.

This idea I've always liked: say for 20 minutes after boot
(configurable), the TCP tracking is loose like it is now.  After that,
it becomes strict.

But the more I think about it, the more useless it becomes.  If your
setup is insecure with `loose' TCP tracking, then having it insecure
for only a few minutes is still bad.

> - 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.

Currently I have UNREPLIED connections (these are going to be
candidates for Random Early Drop).  RST dropping immediately for
one-way traffic connections is in my new anti-DoS patch, because it's
a common case (scanning).

But you can't not accept retransmissions: that will break things badly.

> - 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".)

Hmmm... interesting.  That could be done by an iptables module which
kept track of the numbers of connections.  It wouldn't be *trivial*,
but it would certainly be possible.  In my new patch, you drop the
packet which creates a connection, the connection is destroyed.  This
means you still spend cycles, but the desired effect would be
attained.

Rusty.
--
Hacking time.