Messages in this thread |  | | Date | Wed, 15 Nov 2000 16:34:50 -0500 | From | safemode <> | Subject | Re: (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 131.211.122.89 -> 224.0.0.2 > NAT: 0 dropping untracked packet c05468e0 1 131.211.122.89 -> 224.0.0.2 > NAT: 0 dropping untracked packet c0064760 1 131.211.122.31 -> 224.0.0.2 > > 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |