[lkml]   [2000]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: (iptables) ip_conntrack bug?

On Wed, 15 Nov 2000 16:19:23 Guus Sliepen wrote:
> On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote:
> > I was DDoS'd today while away and came home to find the firewall unable
> to
> > do anything network related (although my connection to irc was still
> > working oddly). a quick dmesg showed the problem.
> > ip_conntrack: maximum limit of 2048 entries exceeded
> [...]
> I have also seen this happen on a box which ran test9. Apparently because
> of
> it's long uptime, because the logs should no signs of an attack.
> I guess conntrack forgets to flush some entries? Or maybe there is no way
> it can
> recover from a full conntrack table? Is it maybe necessary to make the
> maximum
> size a configurable option? Or a userspace conntrack daemon like the
> arpd?

I think something is wrong if the ip_conntrack module does not
flush it's table after the connections and all that stop. I understand why
it does this during the attack...but it doesn't make sense why these tables
are kept long after. A userspace tool is not something i think is needed,
this piece of code should be in the module, it is either not correctly
coded or missing entirely.

> I also see a lot of messages like this (on all 2.4 test kernels):
> NAT: 0 dropping untracked packet c00643f0 1 ->
> NAT: 0 dropping untracked packet c05468e0 1 ->
> NAT: 0 dropping untracked packet c0064760 1 ->
> Turning of multicast on the respective network interface does not stop
> these
> messages, but anyway they seem rather annoying to me :)

Everyone has seen that :) ... that's not exactly what i was talking about
the main error message i was worried about was the "ip_conntrack: maximum
limit of 2048 entries exceeded" when there was absolutely not traffic
coming in and the attack was long since over. I think this is a fairly
major bug with the module since it made the firewall inoperable until i
reloaded the module.. this DDoS could be repeated on any linux box that is
not babysat 24/7 it seems. My firewall drops everything so all the
attacker needs to do is get a bunch of sources to send packets (specific?
not sure) rapidly enough to fill the ip_conntrack table and your site
becomes offline. any other ideas?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.087 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site