Recently the largest Code repository, GitHub has revealed that this week it gone through a gigantic DDoS attack. GitHub was hit by a DDOS attack of 1.3 terabits per second Between 17:21 and 17:30 UTC on February 28th. As a result GitHub was offline for five minutes between 17:21 to 17:26 UTC, with intermittent connectivity between 17:26 to 17:30 UTC due to a distributed denial-of-service (DDoS) attack.
The attack originated from over a thousand different autonomous systems (ASNs) across tens of thousands of unique endpoints. It was an amplification attack using the memcached-based approach described above that peaked at 1.35Tbps via 126.9 million packets per second.
GitHub has been a common target by the Chinese hackers. This isn’t the first time, GitHub faced a similar type DDoS attack back in the March of 2015 which lasted for around six days. But this recent GitHub DDOS attack was the biggest in history.
Recently GitHub has published an article regarding the recent DDoS attack. Manager of Site Reliability Engineering said,“The first portion of the attack peaked at 1.35Tbps [between 17:21 and 17:30 UTC] and there was a second 400Gbps spike a little after 18:00 UTC,”.
The result was a huge influx of traffic. GitHub and their DDOS protection service Akamai Prolexic seem to be a step ahead when it comes to security to filer off this type of malicious traffic. With a downtime of just a few minutes, surprisingly GitHub servers were able to withstand despite of this gigantic attack. All thanks to their attention to network security and the quick response of Akamai Prolexic.
Akamai took steps to mitigate the effect of GitHub DDOS attack. Akamai has seen multiple attacks, some in excess of 190 Gbps, with the potential for much larger attacks. As per reports GitHub said that the attackers used memcached amplification attack technique, which produces many thousands of bytes of UDP response to a very short UDP request. The purpose of memcached is to deliver popular content quickly and without much warning, memcached servers aren’t supposed to be accessible to the general public And if there is lack of some security practices then these requests can be easily spoofed and leveraged by attackers with low skill and few resources, and does not require any authentication. In this instance, the memcached systems used amplified the data volumes by around 50 times
Around 17:21 UTC GitHub’s network monitoring system detected an anomaly in the ratio of ingress to egress traffic. At the start, GitHub briefly struggled with several different outages as a system on the website tried to diagnose the situation. At 17:26 UTC the command was initiated via their ChatOps tooling to withdraw BGP announcements over transit providers and announce AS36459 exclusively over their links to Akamai. At which point it reached out to a DDOS mitigation service – Akamai Prolexic, It intermediary routed all of the traffic coming into and out of GitHub, and used their capabilities in order to weed out and block malicious data. Even After the DDOS attack ended, GitHub proceeded to rout their traffic through Prolexic for another few hours which rerouted traffic to GitHub through its “scrubbing” centers to remove and block data deemed to be malicious in order to determine there wouldn’t be a second wave of damage. The impact was minimal because GitHub was prepared to survive an attack much larger than this. Transit bandwidth levels and load balancer response codes indicated a full recovery at 17:30 UTC. At 17:34 UTC routes to internet exchanges were withdrawn as a follow-up to shift an additional 40Gbps away from their edge.
In a statement GitHub stated,“We’re investigating the use of our monitoring infrastructure to automate enabling DDoS mitigation providers and will continue to measure our response times to incidents like this with a goal of reducing mean time to recovery.”
After surpassing from this gigantic DDoS attack Github has more than doubled its transit capacity which will help to resilient certain volumetric attacks without any impact to users. The Hackers behind this are still known but it’s sure that their mission was to take the site down. But when the hackers realized their efforts were futile, so the left their mission on the half way.