Join Our Popular Newsletter
Join 4,500+ Linux & Open Source Professionals!
2x a month. No spam.
Fighting Denial-of-Service at the Source
Denial of Service (DoS) attacks are a special type of cybersecurity threat. The attacker does not need to hack your systems or find a gap in your security posture. The attacker does not even need to have substantial knowledge or resources at his/her disposal to launch an effective DoS attack – they just need to pay 30 USD a month and they can rent a botnet to effectively take a small/medium business network off the Internet for some time.
DoS attacks – no, not MS-DOS, the venerable operating system of old – fall under two broad categories: overwhelming network traffic that effectively blocks legitimate traffic from reaching your systems and overwhelming requests that tie up a considerable amount of resources to respond and block legitimate requests from being serviced by your systems. There are some other edge scenarios that fall under the broad denial of service (say, physically damaging a server or communication line), but those are the odd cases rather than the norm.
There is also a distinction between a Denial of Service attack launched by a single individual and a single source system, or with a reduced number of source systems, and those launched by hundreds of thousands of systems concurrently against a target system or network (a Distributed Denial of Service attack, or DDoS).
In 2020, Amazon announced they had successfully defended against the largest DDoS attack publicly known at the time: 2.3 Tbps of traffic was hitting the AWS network, targeting a small subset of hosted services. That’s 2.3 Terabits of traffic per second, every second, for a period of time. That’s close to 300 gigabytes per second, or, in old person’s numbers, 67 DVDs worth of data per second, every second (if you’re unfamiliar, a DVD is like Netflix, but without the “net” part, and only containing one movie).
But that was 2020. In 2018, github had defended itself from another large-scale attack of roughly that size – 1.3 Tbps. Still a staggering amount of data, but in today’s terms, it’s like cave painting compared to the Mona Lisa.
Fast forward to 2023, and CloudFlare just announced that they had stopped a 71-million-request per-second DDoS attack. While we can’t exactly compare the numbers, as AWS reported their findings in network traffic and Cloudflare in requests per second (or, AWS attack was of the network flooding type and CloudFlare’s of the exhausting resources type), it’s still an insanely high number.
How is it even possible to launch attacks of this magnitude?
There are several contributing factors to the apparent growth in scale that DoS has been experiencing. First, and rather importantly, is the fact that the hyperscale cloud providers have the largest network connections in the Internet, so traffic of this magnitude will be able to reach their networks and hosted services. Secondly, launching a DoS attack does not depend on “just” the attacker’s own resources.
Launching successful DoS attacks usually means leveraging vulnerabilities across a multitude of unwilling systems. A common tactic is to find some type of service that responds to a request with more data than the one sent to it – for example, a DNS query for google.com responds with many more characters than were initially sent in the request. If you can also find a way to trick the DNS server into sending the response to your target, you just found the pawns you need to perform a DoS. This is called an “amplification DoS”.
There have been multiple services found to be vulnerable to amplification – i.e., vulnerable to being exploited by an attacker into flooding a target – like the BIND DNS servers or LDAP servers exposed to the Internet. Thus, a single attacker sipping coffee at home could compile a list of DNS servers (and there are thousands of them), write a simple script and, ta-da! – DDoS ready to go.
If an attacker isn’t willing to go through the hassle of doing a simple Shodan search for those DNS servers, perhaps he has 30 USD available to subscribe to a DoS-as-a-service offering. Yes, that’s right. With as little as 30 bucks per month, you can “rent” a botnet ready and willing to partake in such endeavors. Pay more for more bots or longer available periods for your attacks.
What is a botnet, you ask? Well, it’s a group of, usually enterprise, workstations or servers that have a hidden piece of software that lets them be remotely controlled – and therefore weaponized – by a malicious actor or threat group.
And what is the point of a DoS attack?
Financial gain or financial harm are usually the motivators. This can be done by either holding an organization hostage with threats of “pay us X amount of bitcoins or your systems go offline,” or causing direct financial harm by taking out systems that support a company’s ability to do business or sales.
Whatever the attacker chooses, the victim loses.
How can you fight it?
Other than relying on your ISP to filter traffic, or contracting some protection service like Cloudflare, there isn’t much else you can do. And even then, you’re not “solving” the problem, you’re just adding a (hopefully) large enough buffer between your network and the attacker. The moment your perimeter or application firewall cuts the DoS traffic, it’s already too late – the pipe is already clogged and it doesn’t matter if you plug the sink or not. And, even if you do somehow avoid the traffic reaching inside your network, it might be of such a scale that it floods your ISP’s network instead, and ends up affecting your availability regardless of your efforts.
And this is where a DoS attack is different from other vanilla cybersecurity threats, like ransomware or a hacker finding their way into a system. The attacker does not require any insider knowledge about your systems, does not need any hacking skills, per se, and even if you’ve patched on time to meet your compliance requirements, it doesn’t really make a difference.
Fighting Denial of service attacks effectively requires a broader effort into fighting botnets and patching amplification services directly, rather than operating at the target level. In a way, eliminating the weapons rather than protecting the targets.
Botnets are created when systems get infected, and this is the traditional approach – phishing, unpatched vulnerabilities, misconfigurations – and these can indeed be effectively patched. Amplification services are usually the result of bugs at the design or implementation of such services – and that can also be patched. This just reinforces the need for proper patching of all your systems. Not because you’re the victim of the DoS, but because your systems can be the weapon aimed at someone else’s systems.
The best option to fight this is at the source, and the “source” is any infected or unpatched system. Since it is not possible to guess which service is going to be found vulnerable to being used as an amplifier in such an attack, the best advice is to simply patch everything you can, everywhere you can, and do it all the time. If this is overwhelming because it’s disruptive, look for non-disruptive options, like live patching.
Keeping your own systems safe also helps to keep everyone else’s systems safe too.