The program LOIC (in the news a lot the last days) causes a lot of damage. What can I do on my server to prevent this kind of attacks? Auto-block ip when receive a strange connection? Because mostly it will be a single user.

Are there already solutions for this?

  • 9
    The best way to prevent a DDOS attack of any kind? Don't piss people off. Dec 10, 2010 at 22:05
  • 1
    @TomO'Connor except script kiddies and the pathological, who do this kind of things for nothing sensible. In this case you could say "Don't get caught in IP scanners" :) Jan 13, 2012 at 12:40
  • 1
    The majority of LOIC attacks (at the time I wrote that comment) were targetted by Lulzsec because of "crimes against the internet" Jan 13, 2012 at 13:05

8 Answers 8


Over at the ISC SANS Diary entry for this topic, there is a very strong clue in one of the comments.

By DarkFiber:

I used to work with an organization that came under constant attack from anonymous and their LOIC tool. It's very easy to mitigate these DoS attacks as they're not particularly bandwidth intensive. Simply limiting the connections per IP per interval at the firewall was enough to thwart the attack. I believe properly configured Checkpoints are able to detect and drop these attacks altogether. But listening in to their IRC channel is the best way to stay one step ahead of this group. It's not often attackers broadcast their targets and vectors before firing.


To limit traffic by source IP, based on what @sysadmin1138 says, there's a great iptables module called "hashlimit". Here's an example set of rules:

iptables -A INPUT -p tcp --dport 80 -m hashlimit --hashlimit-upto 50/min \
    --hashlimit-burst 500 --hashlimit-mode srcip --hashlimit-name http -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

What this does is allows up to 500 packets (not connections, because HTTP can do multiple transactions per connection you have to consider whether you want to do this on all packets or SYN packets only). If there are more than 500/min, it will then throttle it down to 50/min until the rate drops. Anything outside of these limits get the DROP.

Though usually you want to whitelist some IPs, so you probably want to create a table and jump to that if it's port 80, then have your whitelist rules in there, and a final drop. That way non-HTTP packets don't check those whitelist rules and you could have several services all call that whitelist ruleset.

Also, you probably want to enable SYN cookies, so that if the DoS is sending SYN packets it has very little impact on your system.


I have worked with a couple of global banks and their ISPs to look at the effectiveness of DDoS mitigation techniques. It is very difficult to do by yourself, but what we saw working well was when the ISPs teamed up with DDoS mitigation partners. Your best bet is to look at the answers to this question on IT Security Stack Exchange as David's answer says it all.

Oh, and the reason it has become much harder to block LOIC is the initial ones were run from volunteer networks, which were fairly small. The more recent ones are also tapping into illegal botnets so they have scaled up by a significant factor, adding 30,000-odd machines per botnet.


I would imagine the bandwidth consumed depends on the size of the botnet directed at your site.

From http://www.theregister.co.uk/2010/12/09/twitter_api_wikileaks_ddos/

"The most crippling attack on Visa started a little before 1pm California time on Wednesday, when organizers transmitted a command over IRC to flood the site with more traffic than it could handle."

As Rory previously pointed out, it is very difficult to mitigate against a deluge of seemingly legitimate requests without help from upstream providers and often your tier 2 or 3 isp will need to help from their providers. A coordinated effort between yourselves and you ISP and their upstream provider, not withstanding a lot of capital investment is required to effectively mitigate a serious attack.

Traffic floods are also but one vector of attack and require a decent botnet to pull off effectively. SYN flood attacks only need to come from a handful of hosts and can quickly cripple your front end servers however you are able to do something about these by ensuring your tcp stack is hardened, look at security application modules for your web servers and ensure such filters are enabled at your perimeter network kit.

There's ddos mitigation devices such as toplayer that you can buy and DDoS mitigation managed services such as the one Prolexic offer.

Multi-layer approach is the only way to mitigate, on your own you're toast.


Fundamentally, such denial of service attacks involve sending the server more requests than it can handle. It can be a large number of bots sending simple requests (though it does not require billions to bring down a single server - a few thousand tops) or a handful of bots sending requests that are notoriously long to execute.

The second attack type is the most vicious, because a single bot could conceivably bring down a server. For instance, MySQL's LIMIT N OFFSET M is notoriously slow when M becomes large, so a simple attack would be to request pages 200-300 out of 500 in quick succession, clogging all the MySQL worker threads. On an unprotected server, this can be done with firebug. The only solution is to identify costly operations and then either optimize the hell out of them, make them sequential (so that clogging that part of the site does not bring down the rest of the site), or detect IPs that ask for costly operations and refuse to perform that operation unless a certain wait interval is respected.

The first attack type is harder to pull off, because you need many bots. On the other hand, it's also harder to stop from the server: if you have thousands of bots sending you data as fast as they can, your bandwidth will be eaten up by the flood and there's nothing the server can do about it (even if it flat out refuses 99% of those requests), so a router with flood prevention is a good bet if you think you might be a target.

Source :stackoverflow.com


It is easier than all of these suggestions.

-A INPUT -d {your_server_ip} -p tcp -m connlimit --connlimit-above 8 --connlimit-mask 24 -j REJECT --reject-with tcp-reset

or DROP, but both have their consequences that will never be the same.


Here is a tool that can mitigate some DDOS attacks by limiting the number of connections per IP on Linux servers http://www.ddosattack.info



As the negative rating probably hints, this approach is not popular. It's extreme - it may do more damage then you are already experiencing. On the other hand, if your server goes 100% down as a result of the DDOS then the following Lock-down approach will provide some relieve to your situation.

Try this only if nothing else helps.

The Lock-down approach

Set a temporary firewall rule that will drop new incoming connections by destination (your server's IP). Your server will drop new connections during the attack time period.

What would this achieve

It will keep the server load down. Let you manage the server during the attack. Keep the service available to a white-list of valid customers.

Resuming Service Periodically

You would want to remove the firewall rule periodically for a short period of time. This will provide a chance to detect when the attack is over or when it becomes reduced. Once the attack is over your script should remove the firewall rule permanently.

White Lists

You can white-list your and you supervisor's workstations so that both of you can access the server during the attack.

Infer a list of IPs of real customers (a good thing to do in general) and white-list that set.

  • Parse out the IPs of users prior the start of the DDOS from your access logs.
  • Keep a list of those IP for which at any point of time there was a Captcha solution.

Some of the legitimate customers will have the server available to them. Go for more true positives - if you white-list some of the DDOSers then no big deal.

You can try adding large chunks of IP spaces to the white-list. See how many DDOSers you can handle before you server starts to slow down again.

Another white-listing idea

  1. White-list's a large chunk of IPs. Let's call it Region A.
  2. Figure out what are the most IPs
  3. Block Region A and wait for 20 minutes (most real users will give up trying by that time)
  4. White-list Region A again an get the list of active users again.
  5. Compare the 2 lists - the IP that are still pounding are most likely the DDOSers - block them and white-list everything else in the State A.
  6. Repeat steps 1 through 6 for the next large chunk of IPs (Region B).
  • 1
    That will not mitigate - you will still have no service, so it will be a successful attack.
    – Rory Alsop
    Dec 10, 2010 at 13:19
  • Mitigating the attack by making it 100% successful doesn't really make any sense.
    – Chris S
    Dec 12, 2010 at 21:36