Well well...

For the second time in 2 weeks, we've had DDOS flood attacks on a particular server within our services. Last time, the packets were modified to reflect department of defense computers, and arin's own allocations.. This time, it wasnt that good of a spoof (if any) and was a DDOS from attbi.com and roadrunner.com (cable modems). Todays attacks were a little easier to deal with, because of that.

Both attacks failed to do anything but kill apapche - it just didn't know how to handle itself.

The good part is, I guess, that they're concentrating on 1 server only.

But I wonder why they've chosen that particular IP address to attack - we host no controversial sites, no IRC stuff, no adult stuff... Grr. I could understand if we did any of the above a little bit, but nooooo.

I'm very glad for the understanding customers that we have for these two instances, as well as the dedicatednow staff for being available and helpful both last time around midnight as well as today mid-day. We submitted an emergency ticket, and called and they were right on the issue - didn't even have to identify ourselves. Thanks Jason and crew.

As for the rest, I'm considering sending some letters to congress, petitioning for sterilization of people who are caught DDOSing - they shouldn't be able to breed.

Anyone else wanna join a letter writing campaign? ;)

-David

I dunno.. both my name servers were attacked as well

NS2 i lost apache and ns1 the server barfed and wouldn't reboot because of BIGMEM kernel problems.

fun day myself.

Originally posted by turboweb
I dunno.. both my name servers were attacked as well

NS2 i lost apache and ns1 the server barfed and wouldn't reboot because of BIGMEM kernel problems.

fun day myself.

Actually, sounds much worse than mine...

Here's hoping that the script kiddies move on, or at least grow up...

-David

This is a very extreme way of handling those syn attacks but it worked for me:

Enable syn_cookies
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Then I run this script:

#!/bin/sh

for i in ` netstat -pan | sort +4 | grep SYN_REC | awk '{print $5}' | sed -e s/':.*'/''/g | sort -u `; do iptables -A INPUT -s $i -j DROP; iptables -A INPUT -d $i -j DROP; done


iptables -L -n | awk '{print $4}' | grep -v 0.0.0.0/0 | egrep [0-9] | sort -u > /root/syn_ips.txt

iptables -F

for i in ` cat /root/syn_ips.txt | sort -u `
do
iptables -A INPUT -d $i -j DROP
iptables -A INPUT -s $i -j DROP
done

Be aware this is pretty extreme and will likely end up in ips blocked that aren't dosing you but if that's what it takes then that's what it takes.

Also be sure to add a " | grep -v <YOUR IP> " and any other IPs you REALLY REALLY don't want to get blocked into the netstat line, else YOU could end up blocked too.

Thanks gary - saved that one, hopefully next time will be a long ways away. I do have to recompile the kernels with syn_cookies though, as I don't have tcp_syncookies in the /proc filesystem... I'll have to do that late tomorrow night or sometime, the customers have had enough downtime today, and we have to announce it...

Thank god for webhostingtalk :)

-David

If you're running stock redhat it should go fine without a recompile.

Originally posted by Dixiesys
If you're running stock redhat it should go fine without a recompile.

Tell me, what is this 'stock' thing that you mention?? :eek:

Yeah, we've recompiled the kernel to fix the ptrace thing right when it came out... So..

-David

stock means a redhat-provided kernel from an rpm or an srpm. since you patched a vanilla kernel, it is not 'stock'.

a certain box of ours is being ddos'ed for two days now and counting, but filtering it is a piece of cake and even with no filtering, our dual xeon box is taking the load like a champl and continues functioning with no interruption. eventually the kiddies will run out of ips and move on.

it warms my heart to imagine how pissed off those miscreants must be by now =]

paul