How to Prevent & Mitigate DDoS Attacks

A little over 23 years ago, the first documented distributed denial of service (DDoS) attack was launched. The University of Minnesota found itself under attack from 114 computers, which managed to knock out their system for 2 days.

Fast-forward to today and we still see DDoS attacks, so routine that few manage to be note-worthy. As I type this, I checked the Netscout system (https://horizon.netscout.com) to see how many attacks are currently underway. The count quickly soared to over 250 ongoing attacks globally (peaking at 283). Netscout’s Threat Report

https://www.netscout.com/threatreport) identified over 9.5 million attacks for 2021, with the largest attack throwing 612 Gbps at its target.

It’s clear that DDoS isn’t going away. Despite over 2 decades, DDoS attacks and how defenses are built appear to be poorly understood by many.

How defensive strategies for DDoS differ from other cyberthreats

Before we get into the weeds, there’s an important aspect to address – prevention. As we’ll cover shortly, once a DDoS attack starts, it’s too late to prevent. That’s just a fact of life. If you let your car run down a hill, it’s extremely unlikely that you can erect an effective impromptu barrier to stop it. The same is true of a DDoS attack—the attack itself is out of your hands so prevention is key.

Where prevention differs for DDoS compared to other cyber-threats is in what you are preventing. The only thing you can actively prevent is becoming part of an attack.

There are two sides in any battle, the attackers and the defenders.

DDoS attacks are unusual in that, for the majority of attacks, the ammunition comes not from the attacker, but rather from an army of compromised, innocent parties – a botnet. Often, participants in a botnet are doing so without their knowledge. That is, until someone tells them that their systems are attacking others.

It’s next-to-impossible to provision sufficient equipment across enough locations to launch a 612 Gbps DDoS attack through legitimate channels. If you are a malicious actor and enjoy your freedom, this isn’t an attractive approach. However, compromising hundreds, even thousands, of individual endpoints that can be used to launch a coordinated attack can be surprisingly easy. The key here is that the compromised endpoints are not attacked further. Rather, they sit idle, like sleeper agents awaiting the trigger that will launch them into action.

The compromise of an endpoint isn’t likely to survive the first reboot of the system without some additional work. Without it, the attacker will find their DDoS assault faltering as systems are shut down for the day, or restarted. They would need to re-compromise every system again, or add new victims to the mix. It’s much easier to compromise the assets a single time and then use elevated privileges to leave the tools in place ready for the attack to start later.

Much like many bacterial infections, the DDoS attack cannot start until there’s critical mass, i.e., sufficient numbers to overwhelm the target. Building an army and launching a DDoS attack within a day is highly unlikely to be successful. Growing the botnet quietly, accruing greater forces slowly over weeks or months brings the necessary volume of endpoints, both in numbers and in geography, into reach.

Enforce least privilege to avoid conscription into a botnet army

Preventing direct access to privilege in your systems is a powerful defense against becoming part of a DDoS attack. Indirect access does not mean friction or complexity, it can actually mean the opposite for your users, but it will entail some change within your organization. Change is always difficult, despite what everyone puts on their CVs, but the benefits are undeniable.

If we can (and we can) control access to legitimate privileged accounts through privileged access management (PAM) solutions such as Privileged Account and Session Management (also called Privileged Password Management), we eliminate users logging on directly with the credentials for those accounts. This allows us to have longer, more complex, and more frequently changed passwords for those accounts, while still making access to them easier and more robust.

Having controlled, contained, just-in-time privilege for those applications that require it, that users must use as part of their roles, means we operate at the lowest level of risk within our environments. This is the Principle of Least Privilege (PoLP), or as I like to think of it, the Principle of Least Risk.

Least risk isn’t no risk, and that’s important to recognize. Most operating systems manage privilege through inheritance, with each process or application inheriting the privilege level of the process or user that launched it. Good tools that help you implement the Principle of Least Privilege will guard against this inheritance for applications that have been launched with elevated privilege, reducing those new processes to standard user access, or even preventing their starting altogether.

With all that said, it’s very unlikely that the privileges needed by most applications will be useful to a DDoS tool. However, even if it were the case, the defenses against such misuse are built into the Endpoint Privilege Management, another type of PAM solution.

How to protect your organization from a DDoS attack

“That’s all well and good, Brian,” I hear you saying, “but assuming I’m not part of the problem, how can I defend against a DDoS attack?”

Here’s where it gets tricky. There isn’t a single solution to the problem of a DDoS attack. This is the reason DDoS attacks are so successful, the whole premise is to be unstoppable. To explain the situation, a common analogy used is to talk about water and hoses, and I’m not going to be any different here.

For any single endpoint, a DDoS attack is like trying to take a drink from a fire hose running at full pressure. You might think of any number of clever ways to extract enough water to drink without drowning. However, there’s an important concept to be clear on with networking technology – you have to receive the data before you can decide to ignore it.

For our analogy, the water must be in your mouth before you can attempt to effectively spit it back out, which is impossible. Before you can consider acting, gallons and gallons of additional water will have entered your mouth. This is why the water analogy is so apt for networking.

Lengths of hose, just like segments of network, have a fixed capacity, a hose diameter or a bandwidth. Only so much data or water can flow through the hose over any period. You can’t compress water. While you can compress data, it’s the equivalent of taking the bubbles out of the water, what’s left can’t be compressed further!

If someone is consuming all the bandwidth to your endpoint, there’s no space left for you to send data out or, in many cases, reliably receive legitimate data. It doesn’t matter what your endpoint does with the incoming data, even by effectively dropping it on the floor. The bandwidth was consumed by simply receiving it in the first place. There is no premise of having a peek before receiving it either, that’s not how the physics works.

It's not all doom and gloom, however. Layering defenses where traffic can be identified as malicious and diverted, often to nowhere, reduces the flow, step by step, until the endpoint can operate, despite the DDoS attack. This necessarily operates all the way into (and out of) the core of the Internet, where bandwidths are huge, allowing the Telcos to take action without links becoming saturated. Each layer of defense syphons off a little more of the traffic, until it becomes a trickle, or ceases.

As you can imagine, this layered approach isn’t cheap. The only way to stop DDoS being a useful attack is to eliminate the foot soldiers.

Appropriately securing our endpoints (including our infrastructure endpoints) to prevent them being co-opted into the army will help everyone avoid the devastating nature of a DDoS attack. While, at the same time, providing a secure foundation on which our own businesses can operate resiliently.

The link between good privilege access management (PAM) and DDoS attacks might have not been immediately obvious, but you can now see how PAM technologies can protect devices, at all scales, from becoming the unwitting minions of a bot master.