Denial of service attack against ip_conntrack ?
Tue, 18 Apr 2000 09:06:48 +0930
In message <Pine.LNX.firstname.lastname@example.org> you wr
> 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
Huh? If you're not letting any connections in:
iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED \
If you are:
iptables -A FORWARD -i ppp0 -m state --state NEW -p tcp --syn \
> > 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
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