7

I am wondering how do you mitigate a ddos attack which is coming from a botnet and hitting random URLs on a website.

If there was a consistent URL it was hitting then it would be fairly simple, and wouldn't matter that it is coming from random IPs.

How do you prevent an attack which is random IPs and URLs?

Zippy Zeppoli
  • 365
  • 1
  • 2
  • 10
  • If the URLs are random, they are probably resulting in HTTP 404, is this correct? You imply that you know how to block a consistent URL, do you? If so, do you mind letting us know what tool you would use? This would give us some context as to what tools you currently have at your disposal. – 700 Software Feb 06 '13 at 00:25
  • 1
    All I have at this point is apache access logs. The next part is determining a solution to prevent it from happening, which will have to be a software solution since it's in Amazon's cloud. – Zippy Zeppoli Feb 06 '13 at 00:26
  • Do you have a performance or bandwidth usage problem yet? Is your system responding with 404 pages, or are the bots accessing real stuff? How random are the URLs, is it complete gibberish, or only partial gibberish? Do you have access to the user-agent header? Would you be interested in a solution that allows the bot to get through for the first few hits, and then completely blocks the IP for limited time (to reduce the problem, without completely stopping it.)? I ask all these questions because they could contribute significantly to giving you a better answer. Please answer what you know. – 700 Software Feb 06 '13 at 00:32
  • Forgive me if my questions seem obvious. I personally ask theoretical questions all the time on this site. So, there is no point in asking for details if it is theoretical question, and there is no point in avoiding specifics if the problem is real. Further, please forgive my long list of questions. You have not stated the severity of your problem yet, and you have not posted sample access logs. While we might still make a good answer based on what you have stated, the best possible answer will come from having specifics. – 700 Software Feb 06 '13 at 00:39
  • @GeorgeBailey Bottleneck is CPU at the moment. They are using a user agent header that resembles a real browser. I appreciate your help and am happy to answer any questions. – Zippy Zeppoli Feb 06 '13 at 02:03

6 Answers6

9

The tricky part is to distinguish between requests from the botnet, and requests from humans who actually want to read the pages. There is no 100% reliable way to do that in all generality, because some DDoS tools are quite good at imitating humans, and also because most humans appear to be quite good at behaving like mindless drones. Nevertheless, that's the gist of the issue: you must find a distinguishing characteristic between botnet requests and non-botnet requests (and if you find one, next month's botnet will have adapted -- this is an endless race).

One possible defence is to require a Proof of Work from clients. Embed in your site some Javascript code which performs a relatively complex computation, the output of which being embedded in the next request from that client. If done properly, then you could make sure that the botnet burned at least some substantial amount of CPU in the process; the idea being that if DDoSing your server is too expensive, then the botnet master will direct his wrath to another target. After all, he is a businessman...

I have not seen PoW deployed in a Web context, and the Javascript idiosyncrasies may make it difficult to do (a browser with a Javascript interpretor will not make that much "work" per second), but the concept seems sound.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
7

Do a little bit of work to figure out if there are commonalities - common headers that uniquely identify the bots, etc.. Don't forget to look for things the bots don't have - a number leave out fields like Host and Accept-Encoding because they concentrate on the minimum HTTP request to maximise their effectiveness.

You're either going to hit a bandwidth or a compute cap - determine which you're up against because you're likely able to trade one off against the other.

From there, you have a few options. I'm going to assume that DNS changes aren't quick enough, you're using hosting that makes changing IP hard and that load balancers, etc. are out of the price range (otherwise, you're likely to know your coping options):

  1. Talk to your ISP; they may have mitigation options they can enable for you. If you can give them a signature, they may be able to simply block it. They may be able to temporarily increase your available bandwidth to simply absorb the DDoS.
  2. Set a cookie on every legitimate page. Check for the cookie on the 404 page. If you don't see that cookie, blacklist (if you're at a compute cap) or blackhole (if it's bandwidth you're running out of) the IP.
  3. Blacklist whole countries that you've never seen in your logs before.
  4. Proof Of Work is an idea; it could be very simple - work out the time of day in JavaScript in UNIX time and set a cookie with that value. Check on every page for that cookie, if you're within 600 seconds, reset cookie to current time. If you're not, execute while(1); in your backend at the very end of your page. Minimal user impact (page functional, but seems to load for some reason forever).
  5. Optimise your pages. If you can, switch over to a totally static HTML setup temporarily (it's pretty good practice to have a switch that does this anyway on a large site, in case of sudden popularity). This may well bring your compute time down enough so the DDoS doesn't toast the server. This trades off compute time in favour of bandwidth, so will increase your throughput.
  6. Do the opposite of 5 - if you have plenty of compute time available, slow down your 404 response. Add a 60s sleep into whatever you're using to generate the page, keep the socket open as long as you can. This trades off bandwidth in favour of compute time, so will decrease your bandwidth use and drive up load.
Bob Watson
  • 2,856
  • 17
  • 29
  • Do you have any techniques/open source software that works on the network level (layer 3/4)? ive been looking at snort but looking for others so i can compare them. – octo-carrot Oct 20 '15 at 21:21
3

DDoS attacks primarily succeed by exhausting your bandwidth, not by avoiding detection by your application or infrastructure. The best way to defeat DDoS attacks, therefore, is to catch them upstream, and many ISPs offer DDoS mitigation products specifically designed for this.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • Besides being upstream of the bandwidth chokepoint, the other advantage of the carrier services include: (1) they have a preestablished blacklist from analyzing the bots and controllers across their entire network (and pay for threat intel services), (2) they can 'afford' fancier detection and scrubbing algorithms because it's a shared service – Duncan Feb 08 '13 at 11:38
  • What do you mean by catch them upstream? – Pacerier Aug 16 '13 at 04:39
1

If you run your own DNS, "views" (or split-horizon DNS) can be very useful as a first defence, you really need to have a whitelist though, which is where your historic web server logs come in. You could also build a blacklist, if you can recognise the problem clients. The suspect or non-whitelisted clients get 127.0.0.1 (or somewhere unroutable) to talk to, everyone else gets the real IP address(es).

The next step is make sure you have read these:

Depending on your platform you may also be able to optimise your system (SYN cookies, HTTP accept filtering, Apache's mod_reqtimeout or 3rd party options like mod_security).

Community
  • 1
mr.spuratic
  • 7,937
  • 25
  • 37
0

It would be better if you could use a hardware firewall. Otherwise, you will need a software option like this http://blog.solidshellsecurity.com/2012/05/21/barf-block-apache-request-flood-script-block-ddos-based-script/

700 Software
  • 13,807
  • 3
  • 52
  • 82
Travis Thompson
  • 539
  • 1
  • 5
  • 9
0

A few people have suggested a Javascript proof-of-work scheme.

I've actually seen a proof-of-work scheme in the wild. The British supermarket Sainsbury's use one on www.sainsburys.co.uk.

The big problem with it is that hackers are free to use whatever tools they like, so they can write a cracking tool that runs at native speed. Meanwhile, legitimate users may well be stuck using an outdated version of IE.

On the Sainsbury's site, native crackers were around 100x faster than IE6, so it's not much of an advantage.

There's some more info on this blog post.

James_pic
  • 2,520
  • 2
  • 17
  • 22