How can an ISP with low bandwidth like 50 Gbps handle a DDoS attack with more than this? I know there is a solution called "Black Hole".
There are a number of strategies, each having their own costs and benefits. Here are a few (there are more, and variations):
blackholing
By blackholing traffic, you discard all traffic towards the target IP address. Typically, ISP's try to use RTBH (remotely triggered blackholing), by which they can ask their upstream networks to discard the traffic, so it won't even reach the destination network. The benefit here is that it will not saturate the ISP's uplinks then. The biggest drawback here is that you do exactly what the attackers want: the target IP address (and thus the services running on it) is offline. However, the rest of the ISP's customers will not suffer from the attack, and the costs are low.
selective blackholing
Instead of blackholing an IP-address for the entire internet, it may be useful to change BGP routing for the targeted address range so that it's only reachable for parts of the internet. This is typically called 'selective blackholing' and is implemented by a number of large carriers. The idea is that many internet services only need to be available in a specific region (typically being a country or continent). For example, using selective blackholing, a Dutch ISP under attack could choose to have it's IP-ranges blackholed for traffic coming from China, while European IP's would be able to reach the targeted address. This technique can work very well if attack traffic is coming from very different sources than regular traffic.
scrubbing
A nicer solution is to use a scrubbing center, usually hosted outside the ISP's network as a service. When under DDoS attack, the ISP redirects traffic for that IP-range to the scrubbing center. The scrubbing center has the equipment to filter unwanted traffic, leaving a stream of (mostly) clean traffic which gets routed back to the ISP. Compared to blackholing this is a better solution since the services on the target IP remain available. The drawback is that most scrubbing centers are commercial, and can cost quite a lot. Also, scrubbing is not always easy, there can be both false positives (wanted traffic being filtered) and false negatives (unwanted traffic not being filtered).
traffic engineering
ISP networks usually have a number of connections to the internet via transit providers and/or internet exchange points. By making these connections, as well as links within the backbone of the ISP, much bigger than is needed for normal traffic patterns, the network can cope with DDoS attacks. However, there's a practical limit to this, since unused bandwidth capacity is costly (for example investing in 100Gbps equipment and upstream connections is very expensive and cost-inefficient if you're only doing a few Gbps) and this usually only moves the problem to somewhere within the network: somewhere there will be a switch, router or server with smaller capacity, and that will become the choke point.
With some attacks, ISP's may be able to balance incoming traffic in a way so not all external connections will be flooded, and only one or a few will become saturated.
Within larger networks, it's possible to create a "sinkhole" router which only attracts traffic for the IP-range under attack. Traffic towards all other IP-ranges gets routed over other routers. This way, the ISP is able to isolate the DDoS to a certain degree by announcing the targeted IP-range in BGP only on the sinkhole router, while stopping announcement of that IP-range on other routers. Traffic from the internet to that destination will be forced through that router. This may lead to all uplinks of that sinkhole router being saturated, but uplinks on other routers will not be flooded and other IP-ranges will not be affected.
The big drawback here is that the entire range in which the targeted IP is (at least a /24) may suffer from this. This solution is often the last resort.
local filtering
If the ISP has enough capacity on its uplinks (so they won't be saturated), they can implement local filtering. This can be done in various ways, for example:
content delivery networks and load balancing
Web hosters can use content delivery networks (CDNs) to host their websites. CDNs use global load balancing and thus have enormous amounts of bandwidth and caching server clusters all over the world, making it hard to take down a website completely. If one set of servers goes down due to a DDoS, traffic gets redirected automatically to another cluster. A number of big CDNs also operate as scrubbing service.
On a somewhat smaller scale, local load balancing can be deployed. In that case, a pool of servers is available to host a website or web application. Traffic gets distributed over servers in that pool by a load balancer, thus increasing the amount of server capacity available, which may help to withstand a DDoS-attack.
Of course, CDNs and load balancing only work for hosting, it doesn't work for access ISP's.
Good question!
Let's talk from the context of a practical scenario of a web application deployed into production and it gets attacked by an adversary with 10,000 requests per second at the application-layer coupled by a huge network-layered attack which is still manageable.
Certainly, ISPs can handle a DDoS attack but again depends on their overall setup and resources, infrastructure.
Case Study -
So, to start off, I feel privileged to answer this question since one of my clients recently faced a DDoS attack on his web application yet, it seemed very difficult to mitigate ask why?
Because I discovered it was an "Application-layer DDoS attack" and the smart attacker was targetting different resources instead of particular end-points which were not rate-limited
As you can imagine, key takeaways from this proposition were not only to implement a powerful CDN but also to improve their -
At the ISP layer you can only control network-layer attacks viably without adversely affecting your users which also has some downsides. So blackholing may not be enough for your enterprise and on the other hand, might cause serious problems, usability issues in your application as this -
A key consequence of using blackhole routing when good traffic is also affected, is that the attacker has essentially accomplished their goal of disrupting traffic to the target network or service. Even though it can help a malicious actor accomplish their goal, blackhole routing can still be useful when the target of the attack is a small site that's part of a larger network. In that case, blackholing the traffic directed at the targeted site could protect the larger network from the effects of the attack.
This is what Cloudflare has to say in this regard. So blackholing essentially routes network traffic and drops it. But what about application layer or more deeper layered attacks which make use of multiple IP subnets? Traditional ways fail in those cases and you need to investigate and find the main vulnerability in your application which may be the fact that you are disclosing an internal server IP or a vulnerable endpoint though you are using Cloudflare, in which case Cloudflare fails too.
