Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Someoen from china with two different ip is downloading the same big file from my server. Their ip are:


They requesting this file and downloading more than 20 times per minute.

What Can I do to prevent this? (I am on gentoo with root access)

And WHY they do this to a site that doesn't have nothing to do with china ?


Other ips:



the stupid thing is they are requesting only 1 single file lol. Or they want that file removed (tho i don't see why) Or they are pretty stupid


Situation is getting worse. IP are spreading from other countries too (usa and korea if it's right) And now they are requesting another file.


it seems after they realized i removed that file they stopped attacking me. I will monitor the situation.

They started again after a sleep of 3-4 mintues with the same file (lucky me). Hard to say why this is happening

share|improve this question
We're going to need more details. What web server are you running, and what operating system? There are multiple methods for banning IP addresses. – Mark Henderson Feb 21 '11 at 1:16
LAMP and as I said before it's gentoo – dynamic Feb 21 '11 at 1:18
In regard to the "why", we have no way of knowing. It might be as simple as someone having a bit of "fun", or it might be someone trying to DoS your machine in a somewhat unconventional but very easily implemented way. My guess is that it's just some bored kid. Be grateful, it could be much worse. – John Gardeniers Feb 21 '11 at 1:27
@john: yes indeed it could be much worse.. I already removed that file and they are keeping requesting it like before lol – dynamic Feb 21 '11 at 1:33
up vote 4 down vote accepted

Just 2 IP addresses...You could easily block the IPs using iptables

iptables -I INPUT -s -j DROP
iptables -I INPUT -s -j DROP


Since the IP addresses are growing, you might want to consider doing something a bit more drastic. Do you have any need to service Chinese IP addresses? If not, you could try using the following site for help blocking the entire country. Just throw the results in your .htaccess file:

Another Edit

Is there something else that's common about all of the requests? Is the user agent the same? That could easily help in blocking the attacks.

share|improve this answer
@jason: thanks for that command I will read man, But requests' ip are growing, read first post – dynamic Feb 21 '11 at 1:20
@jason: blocking all chinese IP would be ok, but at that point if someone else attacks from another country? it's not that good solution imo – dynamic Feb 21 '11 at 1:31
@yes123 - No it's not a great solution. Mitigating DOS attacks are not easy, especially at the scale that you appear to be at. This solution will work, but it's not a full DOS prevention solution. – Jason Berg Feb 21 '11 at 1:41
@jason: they changed the file requested after I deleted it. I am on heavy attack. Please help :| – dynamic Feb 21 '11 at 1:42
@yes123 - Call your internet provider. They're in a much better position to help you out at this point than we are. – Jason Berg Feb 21 '11 at 1:44

I don't know what OS you're using on your server but I would guess it's a UNIX (Debian,Ubuntu,Slackware etc) distro.
The easy way to protect yourself from DoS is by installing Fail2Ban ( It's easy to install and use. I'm using it for SSH protection because I get loads of ssh dos attacks. The program scans log files and checks for repeating messages (i.e. failed login, many connections like in your situation).

You'll have to tune it a bit to read properly the log file of your web server. If you manage to do that you can limit the access - i.e. you can limit 50 attempts for GET requests in 1 second by 1 ip. When the threshold is reached the IP address is banned for X time. This will help you save your bandwith and not to worry if this attack will come from another address.

Hope this helps you :)

Edit 1:

I remembered there is a module for apache that could limit those things - mod_evasive. Personally I have never used it but many people refer to it as "good stuff". I found a tutorial for you that might help you - Check it out and see if that could suite your needs.

share|improve this answer
This maybe a good solution.. Problem is this server is high loaded even in normal situation. So I disabled the access log of apache to don't load it even more. I should reactive apache access log if I want use this – dynamic Feb 21 '11 at 11:35
@devil: are you sure fail2ban is a good product? In their news the development is on hold from 2009 – dynamic Feb 21 '11 at 11:40
Well everything works fine for me. I'm using fail2ban 0.8.3 on Slackware 12.1, Slackware 13.1x64 and I used to have it on a Debian server. The only problem is it doesn't accurately trigger itself. If you have a threshold 10 times, for a repeating message, it may take more times to activate the ban. The reason is that fail2ban scans the log files every 5-10 seconds (I'm not sure exactly how much time it's sleeping before checks). Beside this everything else works perfect for me. I don't know your OS and if this would work as well as It has for me. Could you please give some info? – tftd Feb 21 '11 at 16:19

What you need to do is contact your upstream provider. most will null route ddos attacks coming at you; as for the US IPs communicate to their ISP that those IPs are attacking you and they'll usually talk to the custom who is usually a bot casing your problems hence why it's coming mostly from Asian countries .

share|improve this answer

What effects is this DDoS causing?

If it's CPU usage, try switching over to something like nginx to serve your static content up.

If it's bandwidth, you can rate limit requests using something like mod_bandwidth.

One thing to keep in mind: I have seen situations like this before, they sometimes aren't attacks, but instead people using "download accelerators". These open a ton of connections to the server at once, based on the (faulty) idea that more connections = more bandwidth. To fix it, I installed nginx on port 81, and used some .htaccess rules to force the content to download via nginx only. Nginx handled the requests without breaking a sweat, and I didn't have to worry about web server reconfiguration, nor slowing down traffic for legitimate users.

share|improve this answer

iptables & ipset to the rescue!

First, make an IP Set:

ipset -N Attackers iphash
for ip in $LIST_OF_IP; do ipset -A Attackers $ip; done

Next, make rules:

iptables -t raw -I PREROUTING -m set --match-set Attackers src -j DROP

Or, if you're feeling evil:

iptables -t raw -I PREROUTING -m set --match-set Attackers src -g trap_attackers
iptables -t raw -A trap_attackers -j NOTRACK
iptables -t raw -A trap_attackers -j ACCEPT
iptables -I INPUT -m conntrack --ctstate UNTRACKED -j TARPIT

Whenever there's a new attacker, add its IP to the set:

ipset -A Attackers a.b.c.d

The above can be automated by using a combination of -m match, -m recent, and -j SET, e.g. -m match --string "GET http://url/to/offending/file" -m recent --seconds 60 --hitcount 2 -j SET --add-set Attackers src

Note: Make sure that support for raw table, ipset, and TARPIT are all compiled into your Gentoo kernel (or as modules).

share|improve this answer
@pepoluan: Should that last iptables be an ipset? – nickgrim Mar 10 '11 at 8:31
@nickgrim : gosh >.< ... fixed :P – pepoluan Mar 10 '11 at 8:41
This doesn't help him with his bandwidth issue... That data still flows down the pipe. – Jacob Mar 10 '11 at 11:46
@Jacob : only until the next TCP timeout. The 1st rule above is a raw block, it blocks everything including TCP ACKs. The 2nd rule (with the TARPIT) stops data flow, since TARPIT sets the TCP Window to 0. – pepoluan Mar 10 '11 at 11:52
attackers ip may vary – dynamic Mar 10 '11 at 14:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.