So I have a server that is under attack I think its a bot-net. What can I do to protect my server?
I was thinking about blocking all the ip-addresses any other ideas?
A server is under attack...?
- floodhound2
- ∑lectronic counselor
- Posts: 2117
- Joined: 03 Sep 2006, 16:00
- 17
- Location: 127.0.0.1
- Contact:
A server is under attack...?
₣£ΘΘĐĦΘŮŇĐ
- bad_brain
- Site Owner
- Posts: 11636
- Joined: 06 Apr 2005, 16:00
- 19
- Location: In your eye floaters.
- Contact:
I hope it's a Linux server...
so, what service is attacked? web server?
if yes find out what kind of DDoS it is, SYN flood or connect, or maybe just a poopy slowloris attack.
if it's a SYN flood (loads of SYN requests in netstat) best use my little script:
http://code.suck-o.com/36286
simply replace the IP (also the port if needed) and run it repeatedly, of course a little collateral damage can appear, but it's a very quick solution where you can ban loads of bots at once. it uses the route command instead of iptables, that way your i/o-waits will stay low even when you have to ban thousands of bots.
if it's a connect attack where the bots load the site (loads of connected or waiting requests in netstat):
you can analyze the access_log and look which IPs cause the most requests:
http://code.suck-o.com/36287
it will list the IPs and the number of requests made, of course you can also automate the banning with it again:
http://code.suck-o.com/36288
if it's a slowloris attack:
simply check the IP running the attack via netstat -tn, it's easy to identify because of the loads of connections, there is also an Apache module out (mod antiloris), it's experimental but works well for me.
if you need help let me know, you can also always contact me on YIM...
so, what service is attacked? web server?
if yes find out what kind of DDoS it is, SYN flood or connect, or maybe just a poopy slowloris attack.
if it's a SYN flood (loads of SYN requests in netstat) best use my little script:
http://code.suck-o.com/36286
simply replace the IP (also the port if needed) and run it repeatedly, of course a little collateral damage can appear, but it's a very quick solution where you can ban loads of bots at once. it uses the route command instead of iptables, that way your i/o-waits will stay low even when you have to ban thousands of bots.
if it's a connect attack where the bots load the site (loads of connected or waiting requests in netstat):
you can analyze the access_log and look which IPs cause the most requests:
http://code.suck-o.com/36287
it will list the IPs and the number of requests made, of course you can also automate the banning with it again:
http://code.suck-o.com/36288
if it's a slowloris attack:
simply check the IP running the attack via netstat -tn, it's easy to identify because of the loads of connections, there is also an Apache module out (mod antiloris), it's experimental but works well for me.
if you need help let me know, you can also always contact me on YIM...
- floodhound2
- ∑lectronic counselor
- Posts: 2117
- Joined: 03 Sep 2006, 16:00
- 17
- Location: 127.0.0.1
- Contact:
Thanks fells,
Quite frankly I am in the process of getting logs and processes that the server is running / allowing in and out etc. The server is in Seattle and I am in Spokane WA so the complexities are unknown to me at this time other than the server is being attacked and they think that its a bot-net.
Its strange because it brings down the web server and a gaming server at times. There is one small catch that I think makes me believe that the attack is not just a bot-net. The attacker is able to edit "system" files however when the server reboots the "Game" for example, system file are /is restored. Web server is not altered but crashes as if it is bot-attacked.
I will get more information and update you all.
Thanks Big-e for the personal help on yahoo!
B_B I will try some of the mentioned above as well.
Quite frankly I am in the process of getting logs and processes that the server is running / allowing in and out etc. The server is in Seattle and I am in Spokane WA so the complexities are unknown to me at this time other than the server is being attacked and they think that its a bot-net.
Its strange because it brings down the web server and a gaming server at times. There is one small catch that I think makes me believe that the attack is not just a bot-net. The attacker is able to edit "system" files however when the server reboots the "Game" for example, system file are /is restored. Web server is not altered but crashes as if it is bot-attacked.
I will get more information and update you all.
Thanks Big-e for the personal help on yahoo!
B_B I will try some of the mentioned above as well.
₣£ΘΘĐĦΘŮŇĐ
- bad_brain
- Site Owner
- Posts: 11636
- Joined: 06 Apr 2005, 16:00
- 19
- Location: In your eye floaters.
- Contact:
@floody
when the web server is not configured well a DDoS attack against it can crash the whole server, a single Apache process (with php) needs between 10-20 MB....often the max. clients setting is too high in the Apache config.
for example, if the server has 2GB RAM and max. clients is set to 200 a DDoS against the web server can spawn 200 processes where each process needs 10-20 MB == 2000-4000MB.
so if you suspect the web server as target (should be easy to find out by netstat -tn, check the local ports) best decrease max clients to a safe level first, this enables you to work without interruptions by a freezing system.
if the problem persists don't hesitate to ask me for active support...
@lilrofl
it's not good to use iptables to block botnets, at least not if the amount of zombies is more than just a few hundred.
let's say there is a botnet of 2000 zombies, and you have blocked 500 zombies yet with firewall rules....1500 zombies still fire requests at the server, and each request has to process 500 firewall rules. the effect will be that apache (for example) and the assigned CPU resources have to wait until each request has processed the firewall rules, this will cause a severe i/o-wait ratio which will make things even worse.
using the route command as basic firewall will not cause such an i/o-wait and you can still block single IPs and whole ranges:
of course many route entries will slow down the overall routing a little, but even after 6500 entries it wasn't noticeable for me (while after 2000 firewall rules the i/o-waits reached 100% and the system froze completely)
when the web server is not configured well a DDoS attack against it can crash the whole server, a single Apache process (with php) needs between 10-20 MB....often the max. clients setting is too high in the Apache config.
for example, if the server has 2GB RAM and max. clients is set to 200 a DDoS against the web server can spawn 200 processes where each process needs 10-20 MB == 2000-4000MB.
so if you suspect the web server as target (should be easy to find out by netstat -tn, check the local ports) best decrease max clients to a safe level first, this enables you to work without interruptions by a freezing system.
if the problem persists don't hesitate to ask me for active support...
@lilrofl
it's not good to use iptables to block botnets, at least not if the amount of zombies is more than just a few hundred.
let's say there is a botnet of 2000 zombies, and you have blocked 500 zombies yet with firewall rules....1500 zombies still fire requests at the server, and each request has to process 500 firewall rules. the effect will be that apache (for example) and the assigned CPU resources have to wait until each request has processed the firewall rules, this will cause a severe i/o-wait ratio which will make things even worse.
using the route command as basic firewall will not cause such an i/o-wait and you can still block single IPs and whole ranges:
Code: Select all
route add -host 192.0.0.1 reject
route add -net 192.0.0.1/24 reject
- bad_brain
- Site Owner
- Posts: 11636
- Joined: 06 Apr 2005, 16:00
- 19
- Location: In your eye floaters.
- Contact:
SYN cookies only help against really small botnets where the amount of connections is not exceeding max. clients all the time. and even if it helps, the person running the attack might notice it and simply switch to a connect flood....this happened on the 6.5k botnet attack in may 2009 against suck-o:
- it started as connect flood
- I placed a blank index.html with a simple link to index.php in it so the connects didn't caused mysql queries anymore
- attacker switched to SYN flood
- I began to ban the bots with my syn-script
- attacker switched back to connect attack, this time by loading /index.php directly
there are also apache modules like mod evasive that are supposed to prevent DDoS attacks, but imo they are pointless because they don't block the connections itself, they only reply with a 403 for example if a specific connections/sec-rate is exceeded....which still occupies web server processes.
so after all getting rid of a DDoS attack is something that have to be done manually, but with my scripts and a little experience it should be no problem to ban a 1k botnet in 1-2 hours (depends of course also on the connection cycle rate of the zombies).
you can additionally use a firewall rule that limits the connection rate of an IP as support:
http://www.debian-administration.org/articles/187
- it started as connect flood
- I placed a blank index.html with a simple link to index.php in it so the connects didn't caused mysql queries anymore
- attacker switched to SYN flood
- I began to ban the bots with my syn-script
- attacker switched back to connect attack, this time by loading /index.php directly
there are also apache modules like mod evasive that are supposed to prevent DDoS attacks, but imo they are pointless because they don't block the connections itself, they only reply with a 403 for example if a specific connections/sec-rate is exceeded....which still occupies web server processes.
so after all getting rid of a DDoS attack is something that have to be done manually, but with my scripts and a little experience it should be no problem to ban a 1k botnet in 1-2 hours (depends of course also on the connection cycle rate of the zombies).
you can additionally use a firewall rule that limits the connection rate of an IP as support:
http://www.debian-administration.org/articles/187