Another question is, what *exactly* happens when ARP requests are spoofed ? Why are there so many connections showing up in seconds and then sitting there and using up resources ? (I watched about 5.000 new connections in 1 minute (!) in iptraf, when after ~ 17.500 connections that scnning worm decided to use another network address than ours. Still our machine had to be rebooted, rcnetwork restart did not help cleaning it up. I'd like to throw away these "half open" ip connections after seconds or at least be able to control how many of them are allowed in a certain time interval. But how ? When after scanning the other ip ranges the worm comes back to us, it's half an hour (even with my "enlarged" arp tables) and we have to reboot again. There are only several machines infected, so it is enough to have 2 or3 PCs with this nice "blaster" to completely disable a 2 MBit link. Bad thing ! Regards, Philipp Sven 'Darkman' Michels schrieb:
Philipp Rusch wrote:
Today we have the situation as follows: One of the other participants in the intranet got the blaster worm in their net, they are still struggling with this. So we get bombed with tons of connections on port 135 from their destination, when the worm(s) scan our net. This fills our arp table / ip connection table with some 17.000-20.000(!) connections in "half open" state, the kernel then throws thousnads of messages like "Neighbour table overflow" and "neighbour table flood" at high rates. When memory is filled, the network services on this box simply stop working. I would call this a classical DOS attack, but what can I do against it ? I already drop all relevant packets from that source, I would have thought that the iptables / kernel code could manage this traffic (sitting behind a 2 MBit link with a PIII-500 / 256 MB RAM)
Here is what I do against the most common "attacks" [snipped firewalling]
iptables won't help in this case cause your problem is not the 20000 half open connections, it's the 20000 (spoofed) ARP's. Did you try to extend your arp table like i suggested you last time? The only thing which will work is the kernel tuning imho. Another Problem is that you only have 256MB ram. If you said you've 20.000 Arp requests, i would say you've a big network behind it. So if you use connection tracking, you use a lot of memory just for that. So try to resize your arp table to the suggested values and take a look if it helps. Watch the arp table and the count with a script like: while true; do DSTRING=$(date +%s) arp -an > arp-${DSTRING}.log sleep 1 done
so you can check after a half hour or so how many arp entries you really had and set the table values to a better size.
HTH, Sven
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here