Done a search high & low for this, had the same thing happen way back in April but it stopped as soon as it started. Anyway we've had no appache now for nearly 7 hours, our DC support said there's nothing they can do but null route the servers IP...which was a no go as about 250 sites use it. They said they'll pass the ticket onto Network guys to see if they can filter traffic but still waiting...

Had one lad [R1CH] come back with this solution...

======================================
In case you didn't know, the protocol you are being hit with is Direct Connect. DC is a file sharing system that uses a central hub, if a hub is full or if an admin wishes, he can redirect users to a iport of his choosing. Perhaps for some reason your web server has been on the receiving side of such a redirect. Naturally the clients auto-reconnect if they are unable to connect the first time...

To filter this is tricky, it likely can't be done in Apache since it isn't a valid HTTP request so the modules like mod_security never get called. My (horrible) suggestion would be to use the netfilter "string" module and firewall any packets to port 80 with a size less than x bytes (x being the biggest packet you've seen which contains the DC login string) that contain "$MyNick". Use a -j REJECT --reject-with tcp-reset to reset the connection so it isn't hogging resources.

Tried also cranking up the MaxClients figure in apache conf but all that did was knock the load up to the 400+ mark (aaahhhh) so have put that back to normal settings as it didn't really help. The servers got dos deflate & mod_evasive plus I added in a secfilter rule in mod_security for $MyNick but as R1CH mentioned it would work anyway.

Can anyone shed some light on how to stop this attack & get apache back up again, hopefully I'll get a solution here before my DC techos get back to me.

There's probably very little you can do. If the DC doesn't have the hardware to filter out this type of attack then you're going to have to either switch your IP's as they null route your existing ones, or if it's an attack against a particular domain, switch it to some other IP in DNS and have that null routed and hope the attack against it goes away.

That's exactly what we ended up doing, problem was initially we only knew what IP was being hammered, this was a resellers shared IP. Luckily they only had about a dozen sites, switched them all onto dedicated IP's then we could pin-point which site was being attacked, then null routed the IP.

Ended up we didn't have the ip module built into our kernel, DC were going to recompile kernel with it but said it wouldn't be supported & it'd cost us to get it all done. So went the easy way & null routed