Hey, a friend of mine asked me how to stop a ddos attack against his apache server and i wasn't quite sure how to answer since he runs a windows server.
Now i'm not completely clueless about this, but what are some ways to stop a ddos attack against both a windows box and a linux box?
*looks at bad_brain* >_>
Stopping a DDos attack
Stopping a DDos attack
¯\_(ツ)_/¯ It works on my machine...
-
bad_brain
- Site Owner
- Posts: 11636
- Joined: 06 Apr 2005, 16:00
- 19
- Location: In your eye floaters.
- Contact:
*looks back* <_<
sorry, but in context with Windows servers I can't really help. but well, Apache is Apache I guess, at least the logs should be the same then....but to use the techniques I do you will need a Linux box.
- stop Apache
- grab the access_log
- move it to a Linux box and process it with the command chain here:
http://code.suck-o.com/36287
you will get an output like:
first number is the amount of requests, second is the IP that made the requests...unusual amounts of requests are are safe sign for a bot.
ban the IPs and start again:
- clean the access_log on the server
- start Apache
- wait to gather request
- stop Apache
- and so on...
if the requests cause database queries you can take the pressure off the system by placing a blank index.html file (if the bots load http://domain.com/), this can make work easier if the system is slow because of the db load.
a halfway automatized way to ban bots that worked really well for me in the past (especially on SYN-floods) is this little script I wrote:
http://code.suck-o.com/36286
it grabs the connections in SYN state from netstat, adds/replaces "route add -host " at the start of every line plus "reject" at the end of every line, so you will get a file like:
then it runs the output file and removes all created files afterwards...so you run the script, wait a little, run it again, etc. (of course you will have to replace 123.123.123.123 in the script with the real server IP).
of course a little collateral damage can happen (but on low/mid-traffic sites it's rare that you will hit a regular request in SYN state, while during a DDoS many of the bot requests hang in SYN state simply because the server is not able to reply fast enough due to the loads of requests).
with a little luck you can maybe convert the script to MS syntax, but I don't know if it's possible.
P.S. I prefer to use "route" instead of firewall rules, at least on Linux it is the far better way because when you have loads of firewall rules every request has to process it will cause a high i/o-wait rate which can affect the whole system and even freeze it completely because the CPU is 100% busy with waiting. but if the botnet is just a few hundred firewall rules also work well.
P.P.S. if things get really tough your friend could point his domain to one of my spare servers and I'll grab the bot IPs for him (for a small fee). let me know in case it is needed...
P.P.P.S (
) once you have some bot IPs feel free to post them and I will check if they maybe appear in the botnet lists I have from former attacks against suck-o.
sorry, but in context with Windows servers I can't really help. but well, Apache is Apache I guess, at least the logs should be the same then....but to use the techniques I do you will need a Linux box.
- stop Apache
- grab the access_log
- move it to a Linux box and process it with the command chain here:
http://code.suck-o.com/36287
you will get an output like:
Code: Select all
6363 123.123.123.123
4350 124.124.124.124
1999 125.125.125.125
...
...
...
ban the IPs and start again:
- clean the access_log on the server
- start Apache
- wait to gather request
- stop Apache
- and so on...
if the requests cause database queries you can take the pressure off the system by placing a blank index.html file (if the bots load http://domain.com/), this can make work easier if the system is slow because of the db load.
a halfway automatized way to ban bots that worked really well for me in the past (especially on SYN-floods) is this little script I wrote:
http://code.suck-o.com/36286
it grabs the connections in SYN state from netstat, adds/replaces "route add -host " at the start of every line plus "reject" at the end of every line, so you will get a file like:
Code: Select all
route add -host 123.123.123.123 reject
route add -host 124.124.124.124 reject
route add -host 125.125.125.125 reject
...
...
of course a little collateral damage can happen (but on low/mid-traffic sites it's rare that you will hit a regular request in SYN state, while during a DDoS many of the bot requests hang in SYN state simply because the server is not able to reply fast enough due to the loads of requests).
with a little luck you can maybe convert the script to MS syntax, but I don't know if it's possible.
P.S. I prefer to use "route" instead of firewall rules, at least on Linux it is the far better way because when you have loads of firewall rules every request has to process it will cause a high i/o-wait rate which can affect the whole system and even freeze it completely because the CPU is 100% busy with waiting. but if the botnet is just a few hundred firewall rules also work well.
P.P.S. if things get really tough your friend could point his domain to one of my spare servers and I'll grab the bot IPs for him (for a small fee). let me know in case it is needed...
P.P.P.S (
) once you have some bot IPs feel free to post them and I will check if they maybe appear in the botnet lists I have from former attacks against suck-o.
-
bad_brain
- Site Owner
- Posts: 11636
- Joined: 06 Apr 2005, 16:00
- 19
- Location: In your eye floaters.
- Contact:
right IceDane, but using the kernel routing table isn't causing problems like firewall rules, simply because the processing of the incoming requests is dropped at a very early stage already. of course using the routing table is not perfect, but the only drawback is a general routing slowdown which might be a little annoying on gameservers but for a regular productive server with websites, etc., it isn't noticeable for visitors.
of course this all applies only to small/medium sized botnet attacks, if a server is hit by 100,000 bots it will affect the whole network infrastructure, such an attack can not be controlled anymore on software/host level, the only option is a hardware filtering in cooperation with the backbone providers.
of course this all applies only to small/medium sized botnet attacks, if a server is hit by 100,000 bots it will affect the whole network infrastructure, such an attack can not be controlled anymore on software/host level, the only option is a hardware filtering in cooperation with the backbone providers.