 |
Linode Forum Linode Community Forums
|
| Author |
Message |
Infinitus
Joined: 08 Jul 2009
Posts: 2
|
| Posted: Wed Jul 08, 2009 8:48 am Post subject: DDoS Mitigation |
|
|
First thing I'd like to point out is that I'm not that knowledgable about linux, hence why I'm posting here, hopefully you can help me.
Anyway, a website hosted on my linode was under DDoS attack last night by an unknown source, they managed in the course of a few hours to use up 75% of my monthly transfer limit, not ideal given my linode usually touchs the limit each month anyway.
My question is are there any systems I can put in place to prevent this happening again or at least mitigate its effects?
If it helps, my linode is a 540 currently running Debian 5. |
|
| Back to top |
|
hoopycat
Joined: 30 Aug 2008
Posts: 1286
Location: Rochester, New York
|
| Posted: Wed Jul 08, 2009 9:17 am Post subject: |
|
|
You can monitor your bandwidth burn rate using http://www.linode.com/forums/viewtopic.php?t=1558, and then have your monitoring stuff (e.g. munin) yell if you're going through too much stuff so you can take manual action. Or, depending on your web server, you might be able to limit a site's bandwidth usage per month/day/hour, if it was HTTP traffic causing the issue. There are also ways to enforce limits using iptables, but I haven't used those in production.
A lot of it boils down to what, exactly, the DDoS was -- the trick to mitigating one is figuring out how it is impacting you and then figure out what is common to all the bad traffic (and makes it identifiably different from "good" traffic). It's a somewhat complex field, and there's no stick-this-in-your-rc.local instant fix, unfortunately. |
|
| Back to top |
|
Infinitus
Joined: 08 Jul 2009
Posts: 2
|
| Posted: Wed Jul 08, 2009 3:08 pm Post subject: |
|
|
Thanks for the advice, I'll have to a deeper look into the subject I think.
For the record, it was not HTTP traffic, the first thing I did was turn off apache, it seems to have been a UDP flood or some other form of junk packets being sent to the server in high volume.
For the moment though the linode staff have helped control the situation, they've nullrouted the servers IP address until this attack subsides. Hopefully that should keep things in one piece. |
|
| Back to top |
|
hoopycat
Joined: 30 Aug 2008
Posts: 1286
Location: Rochester, New York
|
| Posted: Wed Jul 08, 2009 5:16 pm Post subject: |
|
|
| Cool. Yup, that's the sort that's a wicked pisser to deal with locally and probably just needs to be handled upstream. Hmm, I should whip up a Munin plugin to monitor bandwidth burn rate... |
|
| Back to top |
|
freedom_is_chaos
Joined: 12 Sep 2008
Posts: 166
|
| Posted: Tue Jul 14, 2009 11:50 pm Post subject: |
|
|
| At least you didn't get hit like the .gov websites did. Burning 45.5GB per second of bandwidth for several hours. |
|
| Back to top |
|
Smark
Joined: 11 Apr 2007
Posts: 66
|
| Posted: Wed Jul 15, 2009 1:01 am Post subject: |
|
|
I've had some experience with DDoS attacks. Back about 4 years ago (when I was with an old host) I was the target of a HUGE DDoS attack that brought down part of the RackSpace (at the time) datacenter. Before the Linode owners get nervous, nothing like that will ever happen again.
Anyway, one of the early attacks (and not major) was on an IRCd that I ran. Basically they would have thousands of bots connecting every minute. Luckily I found that none of them replied to CTCP VERSION requests, so I developed a mIRC script that Versioned every connection and glined it if there was no response.
It wasnt a flat out DDoS, but I had this issue where I was almost hitting my bandwidth cap every month, only to check apache logs and find there were all these .br users downloading files from the files directory on my server. I eventually just blocked all .br IPs with IPtables... I removed the entries a few months ago and bandwidth usage hasn't changed so i guess they moved on.
Hoopycat was right, its all about finding what makes them different from the average user. I have heard of various bandwidth-usage limiting techniques, most involve IPTables. |
|
| Back to top |
|
| |
|