100

I'm a moderator of a major bulletin board. When a baddie shows up, we block their IP address; it works, at least until they find a new one. Why can't a protocol be developed for the world's routers to combat DDoS, whether by IP addresses or message content or something else, to stop DDoS in its tracks? There's clearly an answer, or else it would have already been done. Can someone give an executive summary of why it can't be done? E.g., it would require some central authority that doesn't exist.

  • 24
    Just to throw something out there. There is no way to block a DDOS attack, period. The issue is that the hardware of the server is overloaded via high traffic. You have two solutions: 1. somehow lower the speed at which the traffic can reach the server (i.e. make the bandwidth of the internet low enough to not be capable of asking for enough to overload the server) or 2. block large swaths of traffic. However, this is problem. – The Great Duck Oct 22 '16 at 4:20
  • 29
    Take the following example: a large media entity releases an incredible digital product wanted by hundreds of millions and only available for five hours at a special one dollar sale price, after which it will jump to 100$. What do you think is going to happen during that five hours? You're gonna essentially get a "DDOS" attack without any malice whatsoever. Natural flows of traffic can also crash a server. If a guy hires 50 cars to drive on a highway and attempt to slow traffic to a halt, how do you know it's not just construction, rain, an accident, or just horrible traffic? You don't know. – The Great Duck Oct 22 '16 at 4:23
  • 7
    Suppose there are 100000 originating IP addresses. How much memory does the upstream router doing the blocking have to spare? You could also potentially have 1 entry each on 100000 routers, but you'd have to contact 100000 ISPs. – immibis Oct 22 '16 at 10:49
  • 26
    If you are fixing the problem by blocking a single IP address then you are not experiencing a DDOS attack. There are several IP reputation databases online. – symcbean Oct 22 '16 at 16:57
  • 7
    There is a way to kill many DDoS attacks. It's called BCP 38. Unfortunately it requires every ISP in the world to implement it, and even 16 years later most have not done so. – Michael Hampton Oct 23 '16 at 17:10

11 Answers 11

198

Let's say that you run a shop. Every day, you might get a few hundred customers.

One day, you get tens of thousands of people coming in, who get in the check-out line, buys a trinket, and then gets right back in line to repeat.

Obviously, you are losing business from authentic customers who must wait hours in line.

Now, you hire a security guard at the entrance to verify that these customers satisfy some criteria.

However, there's still tens of thousands of people who want to get in. The only difference is that now, everyone must go through security.

You notice that, from the authentic customer's perspective, you still wait hours in line, just that now it's just to get through security!

  • 67
    Although in a DDoS hopefully the outside check is moving faster than inside purchasing queue. – Tim Oct 22 '16 at 10:02
  • 50
    Most common DDoS mitigation strategy like Cloudflare is to employ distributed entry points, so the guards are close to the users. In the analogy, this is like having your security guards on departure airports checking people that want to go to your destination airport. Since you distribute your checking points to large number of queues, each queue is smaller and therefore hopefully more scalable. And by doing the checks before departure, they also won't choke down the air (backbone internet). – Lie Ryan Oct 22 '16 at 18:24
  • 2
    This seems pretty inaccurate. One IP can sends a lot of traffic(or stand in many positions in a line that is moving very fast), they don't take up one spot in the queue, and it's an ongoing effort, you have to keep putting more traffic in. And that's the point, if you have to keep putting more traffic in to make it work, and you get blocked.... – Jake Sellers Oct 24 '16 at 16:13
  • 2
    Apple does something like this at major stores (e.g. NYC's 5th Ave store) when a new iPhone comes out. If you want an iPhone, you wait in a long line to the side. If you want something other than an iPhone, you're free to enter the store (though you may receive warning once or twice that iPhone-buyers have to wait in the long line). The strategy works pretty well with people and stores— so I don't think your analogy works. – Slipp D. Thompson Oct 25 '16 at 1:32
  • 1
    In the case that it is a botnet used, then the analogy would be more like someone maliciously telling a whole bunch of people that a shop is giving away free trinkets at a certain date and time. The shopkeeper then has to tell each person that there is no free trinket but it wouldn't be a good idea to bar them from the shop just they were tricked by a third party because you could potentially miss out on future sales. – Mr Wilde Oct 25 '16 at 12:29
116

TL; DR The multiple source IPs are what makes them so hard to defend against.


For the longer answer we look at the name. DDoS attack. That first D stands for distributed. In other words, there is no one IP to block. Or two, or three, or even four.. There are hundreds or thousands of unique IPs.

Usually DDoS attacks originate from a hacker in control of a botnet or network of zombie machines. The attacker will issue a command to all the bots instructing them to make requests for a particular resource / URI. The large number of requests overwhelms the server and takes it down.

  • 21
    Sometimes more than thousands. In the attack in Dyn today, first indications at that as many as 10 million individual IP addresses may have been involved. – Xander Oct 22 '16 at 1:31
  • 61
    Just to make the implication clear, these hosts are devices that could be legitimate traffic, so even if blocking them all was feasible, which it isn't, it would deny traffic to many (many many) legitimate users. @vonlost – INV3NT3D Oct 22 '16 at 1:55
  • 10
    @vonlost, there are limits to how many individual addresses can be added to most blocklists. Especially where the device doing the blocking is a router, it has limited resources... there have been problems with organizations needing to aggregate their routing because their routing tables had too many network entries, much less entries for individual hosts... Most network and security devices are simply not designed to block millions of individual addresses. – gowenfawr Oct 22 '16 at 1:57
  • 5
    @vonlost, the targeted device can never block DDoS, because by the time the attack packets reach the targeted device, they've already saturated some choke point. The fix needs to incorporate the sources, a la BCP 38 – gowenfawr Oct 22 '16 at 2:05
  • 4
    @vonlost, "vast capabilities" you just described the DDoS mitigation services being provided by Akamai/Prolexic and others... – gowenfawr Oct 22 '16 at 2:08
27

In addition to @Hollowproc's excellent answer, the actual "addresses" being used as sources are often spoofed in an attack like this. An attacking host can pretend to be any number of other IPs, especially in a UDP-based attack such as is used against DNS providers.

There's a solution for this called BCP 38, or Network Ingress Filtering. If all the world got together, had a coke, and implemented controls to block spoofed addresses where they enter the network, these attacks couldn't spoof traffic any more. The Dyn folks themselves mention it as a helpful defense.

Note that implementing a defense at many source points has the advantage of being scalable; the individual block requirements are not onerous in size. However, they are onerous in that more people must do the right thing about something that does not directly and negatively impact them... human nature has, for over a decade, prevented this solution from reaching critical mass.

It is possible that the growing impact of DDoS attacks will spur greater adoption of Network Ingress Filtering... The Internet treats damage as censorship, and routes around it :)

  • 4
    Doesn't help much with botnets, of course, since then you have lots of real source addresses. – immibis Oct 22 '16 at 10:57
  • 2
    @immibis it is true that this will not help with non-spoofed addresses; however, spoofed addresses are also used in botnet-sourced attacks... why should the attackers make it easy for the defenders to map the botnet, if it's possible to spoof (e.g., with UDP attacks)? – gowenfawr Oct 22 '16 at 15:31
8

The problem with a DDoS is two part:

1) Since the bots are so many, they don't have to have a request throttle as high as a single bot, and are therefore not as easy to recognize as bots.

2) All you see is IP addresses (and User-Agents depending on how you filter bot traffic). Any IP address could be a DDoS bot and any IP address could be a legitimate visitor. Some IP addresses will have both a DDoS bot and a legitimate visitor. What do you do?

Let's say your site can handle 1000 req/s and a visitor never makes more than 10 req/s. One bot at 100 req/s is easy to block, ten bots at 100 req/s are easy to block. But 200 bots at 5 req/s are difficult to block, because they are behaving properly.

200 bots at 100 req/s are difficult to block too, because they can't even make more than 5 req/s, making it appear that they behave properly. This situation is far worse than 200 bots at really 5 req/s, because a visitor is now 10 among 10010 requests trying to squeeze into the connection rather than the more manageable 10 among 1010 that are successfully reaching the server.

1000 bots at 100 req/s would make it improbable for each real visitor to connect to the site at all. And an attack of this magnitude is going to cause trouble along elsewhere as well.

A strong defense for your site is a strong weapon for an attacker:

If your site blocks IP addresses (or even specific browsers on the IPs) if they misbehave, someone might decide to abuse your defense to cause a DoS attack on the client side.

Example: Mallory creates a webpage that has a hundred "images" with margin-left: -1000em; width: 1px; height: 1px; and all of those images are some "sensitive" URLs on your site. When a visitor visits Mallory's page, they will send 100 abusive requests to your server and will therefore become blocked.

So getting a more aggressive defense against (D)DoS attacks will also cause another vulnerability.

A "smart" defense such as CAPTCHAs (to give the visitors a chance to prove that they are also visitors and not just malicious bots) will also have the side effect of actually requiring resources of the server.

Uploading images when the connection is clogged up doesn't sound like a very good idea. Neither does remembering a huge number of sessions for the CAPTCHAs, CAPTCHAs that won't be answered, partially because the images couldn't get sent, partially because the majority of visitors are non-human.

And on a (highly or uncached) dynamic site, you'd be fighting fire with gasoline.

7

Suppose you are hosting a service of some kind, whose main purpose is to serve a particular geographic location, and let's assume you did this by some access rules based on IP addresses.

UDP

Now if UDP is taken in that context, anyone with a knowledge of a packet crafting tool (e.g. scapy) can spoof the legitimate IP that are allowed access, and if you opt for the blocking approach, you will be blocking the legitimate users from the accessing the service.

TCP Similarly spoofed TCP (e.g. syn flood) DDoS attacks can make a genuine user suffer if the active blacklisting approach is followed.

So to deal with DDoS it's better to apply careful filtering, using devices intelligent enough to distinguish between genuine and attack traffic by DPI or some other algorithms.

CDN, NAT, PROXY

If users are behind a CDN or something like that, blocking one user may make the whole bunch behind the proxy suffer.

Moreover, "whether by IP addresses or message content or something else," as you mentioned, for routers to be capable of filtering on a content basis, that would hinder its routing performance. But yes, there are still in routers to do that (e.g. NBAR), and all which one can apply inside his premises.

And blocking should be on a more specific basis.

3

Others have made great answers regarding the technical challenges around mitigating DDoS, my answer here though is going to focus on what happens once you've built the capability to filter the DDoS by blocking large number of IP addresses onto your site.

Blocking large number of IP addresses is not always desirable. By blocking large number of IP addresses due to a large DDoS, you could be blocking a large number of legitimate users who might share those IP address as an undesirable side effect (e.g. Tor, proxy users, universities, shared household, ISPs that use NAT to save public IP addresses).

This might not be so much of a problem for small personal sites, but for a number of sites where the users have legitimate need for serious anonymity, say sites catering to political activists, LGBT, female services in oppressive countries, domestic abuse, etc. Simple IP blocking is essentially falling into the attacker's ploy for these sites. By denying service to anonymity users from accessing your service, you may be preventing your most vulnerable legitimate users from safely accessing your site, and that achieves the attacker's goal just as well as the original DDoS.

3

There isn't a simple or single solution to DDOS attacks, because they can be performed in lots of different ways. The nature the technology behind the Internet doesn't lend itself to anything but being wide open. There are a lot of patches and work arounds to try and shore up security and mitigate a lot of problems. In the balance, it's a lot more difficult to protect a site or network against an attack than it is to attack. That's just the state of security today.

For network level attack (like again DNS most recently for Dyn), Network Ingress Filtering as mentioned before, would've been helpful. That at least helps with the spoofing problem.

A more pressing issue with this type of attack, though, is the scale. With the number of infected systems in a botnet for a sizable attack reaching tens of thousands, if not hundreds of thousands of systems, doing IP-based blocking is not reasonable. Have far up the network chain will you need to block to survive if you do blocking? The Krebs DDOS attack was claimed to be in the 600Gbs range. Can you or your provider handle that (or even just a more typical in my experience 10-120Gbs) Regardless, you are just playing whack-a-mole at that point, since once blocked your attacker will likely switch to another set of exploited machines with different IPs.

If you do decide to play the IP reputation game <cough>CloudFlare<cough>, you can do stupid things like end up blocking large providers- e.g. Pokemon Go dropping most/all traffic from Belgium. Again, this is just whack-a-mole and not a viable solution.

Let's talk higher up the stack. Web service attacks, like credential stuffing or scraping, will frequently look like legitimate traffic. Junior-league script kiddies will have out of whack browser signature you could look for, but things like Sentry MBA or even PhantomJS will mimic proper browsers that will defeat this simplistic HTTP header/browser ID finger printing. Better attackers will even simulate proper mouse and keyboard use, further obscuring their automated nature.

Captchas are expensive both from an implementation standpoint (either resources on your servers, or outsourcing $$). Simple ones can be defeated with reasonable image detection algorithms. More complex captchas start pissing off users and may cause accessibility issues for visually impaired users. There are also systems that effectively defeat captchas through mechanical turk either directly (hoards of people paid pennies on the captcha) or indirectly (captcha from your site being answered by an unsuspecting user on another site).

Anyway, as attacks are multi-pronged, you need a multi-pronged approach to defense. Large operators have even gone on the offensive, as Microsoft has worked with the FBI to take over and shutdown botnets. Unfortunately, IoT has just opened up a whole new set of systems that come out of the box open for exploitation.

  • You are confusing ingress (incoming traffic) with egress (outgoing traffic) filtering. In order to be effective, traffic filtering must be done near the source. That requires egress filtering; the origin ISP must set up their systems such that only packages claimed to come from their own IP addresses are allowed to get out of their network. The receiving ISP can only block traffic from obviously bad source addresses, which means "anything not claiming to be from us must be allowed through" instead of "anything not claiming to be from us must be dropped". – a CVn Oct 26 '16 at 9:20
  • @MichaelKjörling: the RFC calls it ingress filtering, I suppose since it targets traffic entering the network. – Dining Philosopher Jul 4 '17 at 20:28
3

The genius of DDoS attacks stems from the fact that the traffic comes from potentially LEGITIMATE IPs of real customers.

Let's say a normal person living in the US could have his router compromised and have it used for DDoS. The victim company blocked the IP address completely, now that person cannot connect to the company's web service at all because the company blocked the IP entirely, cutting off a potentially valid IP from ever accessing their servers again.

This was a simple example but imagine a university having a few NAT IPs for web browsing and a company blocked some of those NAT IPs during a DDoS mitigation. Now tens of thousands of people on that campus could lose connectivity to that company's servers which is catastrophic for business.

Not to mention large enough DDoS attacks can employ a crazy amount of different IP addresses.

3

It is not easy to distinguish between a normal traffic and a DDoS traffic.

DDoS can be explained in easy words as -
As a human being, i can only discuss (have a chit chat) things with one person at a time and if 10's of people speaks to me at a same time, then i will not be able to answer any of them and i will be in not available state for all of them.

Attackers usually generate the DDoS attack from compromised machines (also known as **bot). It may be case that at the time of writing the answer of your question, my machine may involve in ddos attack to some destination (if my machine is compromised, although chance of its is very less).

As explained, there is no black and white solution available for controlling (or blocking) ddos attack.

As explained by @gowenfawr, if ddos attack pattern is of udp, then implementation of URF at the ISP level across the internet, can help in blocking the spoofed traffic and hence help in controlling the ddos attack.

  • 12
    Same here as on other sites: please do not abuse quotes for formatting. Thanks. – Arjan Oct 23 '16 at 17:51
1

True story here

We used to sell a small camera system. Was by a big name brand and the camera wasn't spectacular, but still cost a decent amount. One day, we had someone call us up about a charge on their credit card. Turned out someone had gotten it and used to buy one of these cameras and had it shipped to someone who probably aggregates them and either fences them directly or bulk ships them to the frausters.

Being an enterprising admin, I dug into the logs to figure out where the fraud was coming from. I found one from an African IP, but the rest of the suspicious orders all had American IPs. In fact, they were all being proxied through compromised servers in the same datacenter our web servers were in. Beyond reporting it to the host, there wasn't anything to be done. Whomever did this was pulling the strings via compromised machines. There's just no way to guard against this sort of thing by looking at the network source itself. You never know where or when someone will get compromised and their IP turned into a weapon.

The recent attack on Dyn showed just how stupid simple that is now

The botnet, made up of devices like home Wi-Fi routers and Internet protocol video cameras, is sending massive numbers of requests to Dyn's DNS service. Those requests look legitimate, so it's difficult for Dyn's systems to screen them out from normal domain name lookup requests.

And

They're tough attacks to stop because they often get channeled through recursive providers. They're not cacheable because of the random prefix. We started seeing random prefix attacks like these three years ago, and they remain a very common attack. If IoT devices are being used, that would explain the size and scale [and how the attack] would affect: someone the size of Dyn.

With IPv6 taking off, soon you could have billions of devices, each with its own IP, to work with. The scope is too large to effectively filter against.

0

A protocol that allows "someone" telling internet infrastructure/backbone parts to stop accepting/forwarding traffic from certain addresses just means that this "someone" would not even need to employ DDOS techniques to put anyone they want off line. Without a "central authority that doesn't exist", it would be hard to agree on who should be trusted with that kind of power.

protected by AviD Oct 23 '16 at 8:37

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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