What are we talking about when we are talking about DDoS protection?

Those who have survived a few DDoS attacks will probably know the answer, but for the rest of us, it’s worth asking: should we be wary of such incidents? Our view is that it is best to be aware of the nature of DDoS attacks and to be prepared to avoid the damage they can cause, and to deal with emergencies quickly and effectively.

There’s not much you can do on-premise against large high-bandwidth (volumetric) attacks saturating your internet connection, but many ISPs provide DDoS protection services, or you can use a cloud-based protection to pull out the poison ivy, so it’s worth thinking about multi-layered protection from the beginning.

While volumetric attacks are the easiest to make news headlines, equally dangerous can be state exhaustion and application-level attacks. These can usually be handled appropriately on-premises. Note that the proportion of DDoS attacks that use multiple attack vectors simultaneously or alternating is growing rapidly.

Some questions and common misconceptions that we often encounter:

• There are rate limits set at several points in the perimeter, is this enough for DDoS protection?

No, such limits will lead to random packet drops, real clients will ask for more retransmissions, causing additional load. Rate limits are great to keep the infrastructure operational, but if you think in terms of service, you need to distinguish between bad and valid traffic, block as much of the bad as possible, and let the good traffic through as much as possible. In fact, this is what we call DDoS protection.

• The ISP or hosting provider provides routing to blackhole (RTBH) protection.

The good news is that your service provider can protect its own network. However, your IP address that was attacked will disappear from the map, so the attack has succeeded. If possible, use more sophisticated tools.

• If the attack does not produce excessive traffic and the attacking clients behave quite similar to valid clients, DDoS protection is not effective.

Dedicated DDoS protection also has tools for such cases, e.g., authenticating clients, blocking based on packet payload, and using signatures to detect attacking bots and typical attack patterns. In fact, the more sophisticated the attack, the better to differentiate the protection: a WAF can be required, and it is also good to be able to coordinate the operation of different systems (e.g. via API or TAXII feeds).

• Is it enough to protect public services?

It depends on what you call a public service. You may consider only your web server to be public, but an attacker may also target the neighboring IP addresses, this is a type of attack that is now enjoying a renaissance called carpet bombing. In addition, since the COVID lockdowns and the rise of telecommuting, attacks against VPN concentrators have become a particular favorite. In the eyes of the attacker, any resource with an Internet connection will therefore be a public service, a potential target.

• Connection tables cannot be overloaded with UDP-based attacks.

Undoubtedly, such attacks are typically TCP-based and are directed against TCP-based applications. But just think what your firewall does with each new UDP flow if it is not explicitly instructed to drop them – yes, it registers them in its connection table and it takes time, in bad cases a few minutes, to saturate.

Overall, it is important to understand how DDoS attack methods work and how to defend against them at different layers of the network infrastructure – in order to build and operate an effective, complex protection system.