It was known that it could happen and it happened, but it was predictable. That’s why GitHub survived the largest DDoS attack in history. A distributed denial of service attack that reached a peak of 1.35 terabits per second sent through 126.9 million packets per second. Despite this, it only dropped ten minutes.
The good news is that solving a similar situation is possible, as the platform demonstrated; The bad news is that these attacks can be repeated on a larger scale if nothing is done. The responsibility, in part, belongs to many.
Large previous DDoS attacks like the one suffered by the company Dyn in 2016, the biggest recorded until then, which caused problems in services such as Twitter, Reddit and precisely GitHub, among others, can be almost anecdotal compared to those who take advantage of the enormous power of amplification used by the one we met yesterday. The figures that have been provided frighten.
The reason for the biggest DDoS attack
On February 27, just three days ago, Cloudflare security researchers described an abuse of Memcached servers to amplify DDoS attacks by an unprecedented 51,200. These are machines with a distributed cache system that use sites like Reddit, YouTube, Twitter, Facebook or Wikipedia.
The abuse is possible due to the unsafe implementation of the support for the UDP protocol and the exposure to external connections of the mentioned protocol port, the 11211, in the default configuration. As in other methods of amplification, attackers send a small request from a false IP address in order to get a much greater response in return.
In this case, they send a request to port 11211 using a false IP that matches the IP of the victim . With only a few bytes sent to the vulnerable server, according to the researchers, they receive a response thousands of times larger. “Launching such an attack is easy,” they say.
The set of these servers is not vulnerable, but many are. Although Cloudflare only saw 5,729 unique IP addresses from Memcached machines when they published these reports, they claimed that Shodan reported 88,000 open servers. Other sources raise the figure to 100,000. They are distributed throughout the world, but where they have a greater concentration is in North America and Europe . In addition, according to Cloudfare, “most of the vulnerable servers are in the main hosting providers.”
The great defense of GitHub (and Akamai)
A day after this announcement, also made by other security firms such as Arbor Networks , Qihoo 360 or Akamai , the attack against GitHub took place . The surprising thing is that despite the magnitude, few realized what was happening. GitHub.com was not available between 17:21 and 17:26 UTC and there were intermittent problems between 17:26 and 17:30 UTC. It is done.
After, everything returned to normal. They succeeded thanks to the help of their DDoS attack mitigation service, precisely the company Akamai , one of those that investigated this type of abuse. They knew the problem perfectly.
“Given the extension of the incoming traffic bandwidth to more than 100 Gbps in one of our facilities, the decision was made to move the traffic to Akamai, which could help provide additional edge network capacity,” they explain from GitHub .
That’s when Akamai’s specialists took over, they explain , “filtering all traffic from UDP port 11211, the default port used by Memcached.” After eight minutes, the attackers gave way and the attack ceased . ” We modeled our ability based on five times the largest internet attack ever seen , ” said a Wired vice president of Akamai Web Security, Josh Shaul. They were prepared and won.
Why can the largest DDoS attack in history be repeated? It can be fixed?
As we said at the beginning, the good news is that it is possible to stop these big attacks. If you are sufficiently prepared, of course. The bad news is that they can be repeated even bigger. And we do not say it, say those responsible for mitigating what suffered by GitHub. “It is very likely that this record attack is not the biggest in a long time,” they said yesterday after presenting the details of their performance on the great DDoS attack.
Memcached can have UDP and TCP listeners and does not require authentication. Because UDP is easily falsifiable, it makes this service vulnerable to being used as a reflector. Worse still, Memcached can have an amplification factor of more than 50,000, which means that a request of 203 bytes results in a response of 100 megabytes.
In addition, as they explain, many other organizations have experienced similar attacks since last Monday. This makes them predict potentially larger attacks in the near future .
Due to their ability to create such massive attacks, attackers are likely to quickly adopt the Memcached amplification as a favorite tool. In addition, as the lists of usable reflectors are compiled by the attackers, the impact of this attack method has the potential to grow significantly.
That it is not like that happens by taking precautions at different levels . The most immediate, they explain, is that “providers can classify the traffic from the port of origin 11211 and prevent traffic from entering and leaving their networks”. Although taking these measures they say it will take time. Another good precaution to take may be to disable UDP support if it is not used, as suggested by Cloudflare. Hiding servers behind a firewall would also be a good and obvious idea.
Solutions to the abuse of Memcached servers also respond from them with a smaller package size than the request as a preventive measure if you can not stop using UDP, fix vulnerable protocols and the possibility of impersonating IP. Solutions, as we see, there are . It is missing that they are implemented.
About2ZF77
