Hello, I wanted to let you know that you are not alone. We manage networks in apartment complexes. Hundreds of students use their computers simultaneously and we have always been able to deal with DoS attacks. The attack you described is identical to the one we have suffered since sometime in September. In short: it cannot be stopped. But there are many things you can do. As you may have found in personal research, the worm has the following characteristics: 1 - It is a Zombie. Computers do NOT automatically start attacking web sites. They wait for an instruction from outside. 2 - The connection to the outside "master server" is done via IRC. 3 - The infected computer attacks 1 to a few web servers at a time. (we have never seen more than 3). 4 - Completely random spoofed src addresses. 5 - The MAC address is (Thank You GOD) not being spoofed. 6 - The intensity of the attack deems the offending computer almost useless during the attack. It seemed from your description that your network was fairly small. In order to save bandwidth, we implement a transparent caching strategy. So we redirect port 80 to the cache. Guess what!!! Our caching server ends up the target of the attack!!! I can tell you that I tried every pertinent module in the patch-o-matic volume. It was a 3 month ordeal with very frequent lockups. "connlimit" does not work because once you enable SYN cookies, there are no connections to limit. "limit" draws too much CPU power, eventually helping lock up the box. Blocking the foreign IP sources at the FORWARD level (or INPUT in my case) stopped the packets, but still kept my server with a very high system use. I have hundreds of rules in the MANGLE and NAT tables, so the bad packets were still traveling and being matched against all those rules. I placed the drops for the foreign IPs in the MANGLE table. If you look at the docs, it is the first table the packet hits. BTW, to stop foreign IP packets, I created one ACCEP rule for every known IP class inside my network. The last line simply DROPs everything coming from the internal network. My networks are basically functional now. But the HIGH CPU use persists. It is likely caused by the interrupt handling or the packet counters/rules checking. I recently ran accross this page on lowering the interrupt handling: ftp://robur.slu.se/pub/Linux/net-development/NAPI/NAPI_HOWTO.txt Feel free to correspond with me. We can trade ideas on the topic. Peter Frischknecht Empowering Solutions, Inc.
