DDOS Attacks: A game of cat and mouse

Unlike say, a ransomware attack, where there is a clear financial motive for a bad actor, DDOS attacks are not so clear cut. While sometimes they can be politically motivated, or acts of aggression by a nation state, often they occur for no reason other than the joy of creating chaos.

If you are affected by a DDOS attack, your only options are to ride it out, or to make your service available behind a company with a fatter pipe than your attacker. Cloudflare for example is a big player in this space, with a tremendous number of links across various physical locations. While at first glance it might seem like something such as FAIL2BAN or strategic firewall rules might help, unfortunately this is not the case. In order to make a decision regarding the traffic, your firewall must process that traffic! Worse, until the traffic can be inspected, your firewall cannot distinguish between legitimate and illegitimate traffic. As soon as an attacker has enough bandwidth to throw at you to overwhelm your edge router’s line speeds, you’re sunk – this is why only an upstream provider can prevent a DDOS attack of sufficient scale.

Unfortunately, DDOS attackers are extremely common. In October of 2016 (the same year it was acquired by Oracle) Dyn, a large DNS provider fell victim to a DDOS attack of massive scale. At the time, Brian Krebs of “Krebs on security” gave a phenomenal real-time recounting of the attack as it happened, detailing the ripples of its impact. Ultimately, even the likes of Twitter, Spotify, and Reddit were not immune since something somewhere in their supply chain relied upon Dyn.

In February 2018, Github was targeted in an attack sustaining a mind-blowing 1300 GBPS. How was this kind of packet rate achieved? Memcached, a popular in-memory caching layer used far and wide on the public internet, was susceptible to what’s known as an “amplification” attack. In an amplification attack, a relatively small number of requests to a system results in a relatively large number of requests to a different system chosen by the attacker’s initial request. (Perhaps the best known example of an amplification attack is DNS amplification, as DNS requests under a certain size rely on UDP traffic which does not require anything like TCP’s three-way handshake in order to initiate a connection.)

In February of 2020, a DDOS attacker brought everything relying on AWS to its knees. This too was the product of a service vulnerable to a an amplification attack, in this case a variant of LDAP (Lightweight Directory Access Protocol – used to store directory information). Traffic sent to vulnerable LDAP servers exposed to the public internet were tricked into sending up to 60 times as much traffic as they received. At its peak, Amazon saw 2300 GBPS of sustained traffic, almost twice that of the similar Github attack two years prior!

While the specifics vary, almost 100% of the time these sorts of attacks are preventable by good security practices. In the case of both the AWS attack and the Github attack, patches for Memcached and CLDAP were already available! Additionally, there is exactly zero reason to expose your Memcached servers directly to clients (they exist for the direct benefit of your other servers).

It is not only businesses making irresponsible decisions however. The advent of IOT (internet of things) devices has been perhaps the most devastating development in the history of DDOS attacks to date. These devices are quick to market, and patches are rarely if ever released. They are often open to the internet by their very design, or by whims of consumers who want to turn their lights on from the office, but don’t understand the implications of opening up ports on their router. Attackers can sit back and gather data on IOT devices that are known to be vulnerable and open to the internet. These devices unfortunately are the perfect jumpbox to initiate DDOS attacks. While the device might be small in size and low in computing power, most of them have 1 GBPS NICs which can take full advantage of the bandwidth available to the user! Couple this with an amplification strategy, and we can only expect this problem to get worse over time.

Unfortunately, in the grand scheme of things not much. It is extremely important as an individual to practice good IT security. Any services should only be exposed to the public internet as a last resort. (Authenticated reverse proxies are good, and VPNs are better). If a service MUST be exposed to the internet, it should be frequently updated. Personally, for any services I am responsible for either at home or at my employer, I religiously check CVE notifications on cve.mitre.org.