Following the news that GitHub was downed by a DDoS attack, its second of the year, @DFMag gets expert opinions from Matt Watkins and Nick Le Mesurier, security consultants from MWR InfoSecurity:
Who might be responsible for the attack? Can the finger be pointed at China again?
Matt: It’s important to not just jump to conclusions. Last time Github saw a DDoS attack of a similar scale, it was attributed back to China and there was a clear motive behind it. This time however, things could be completely different. If we look at the user base of Github, a large proportion consists of US based IPs, any of whom could have a potential motive to perform an attack. Github is also ranked as the 86th most visited website as per Alexa in the globe. There’s therefore plenty of potential for this to be completely unrelated.
Can we speculate how the attack was carried out?
Matt: This kind of attack is likely to be some form a volumetric attack, however with so many types of attacks existing it’s impossible to speculate. This could be one of the more common DNS/NTP amplification attacks, or possibly one of the new and upcoming amplification protocol attacks.
How do we defend against such attacks?
Matt: There are lots of different techniques, but essentially with volumetric attacks it’s all down to bandwidth. The problem is it only takes a single point of failure to result in a Denial of Service situation occurring. Many specialist providers offer cloud based mitigation services whereby traffic can be redirected to specialist scrubbing centres which are specifically designed to deal with these attacks. The important thing is to not rely on traditional network defences such as firewalls or IPS/IDS as these systems can easily be overwhelmed.
Nick: Defending against DDoS attacks require a combination of actions;
– Use third party providers that specialise in DDoS prevention
– Ensure your infrastructure has high bandwidth inbound links
– Use a mutli-layered architecture of DDoS prevention hardware devices to manage inbound traffic
– Have a plan in place of how to respond to an attack and what actions to take in the event services are disrupted
– Have secondary systems in place in the event primary services are taken offline
What can organisations do to mitigate the effects of a DDoS attack?
Matt: Having a plan in place to deal with attacks is very important. The last thing a company wants to be doing is running around endlessly during a DDoS attack trying to work both what is happening and what actions to take. Many DDoS mitigation providers offer specialist response services that can quickly perform traffic redirection, but ensuring procedures are in place is key.
Why would GitHub be a target for a DDoS attack?
Nick: Purely speculative but this could be a demonstration of capability. GitHub is a large platform that supports high volumes of traffic, attacks against it could be used to gauge how effective an attacker’s DDoS capablity actually is.
Matt: Relating to Nick’s point: the Arbor Networks Worldwide Security Infrastruture Report 2014 found that in one of their surveys a target was more likely to be attacked by an attacker demonstrating capability than for extortion. Nihilism/Vandalism however remained the highest motive, with no direct financial benefit.
How easy / difficult it is for an attacker to perform a DDoS attack of this nature?
Nick: The difficulty depends on the size of an attack. For example, online DDoS services that can be bought by anyone have been used in the past to take small ISPs offline.
Matt: This kind of attack is fairly easy to perform, in terms of sophistication. There are a huge number of resources online that allow an attacker to buy booter or stresser services which could be used to perform this kind of attack. The issue is that these services are marketed as network stress testers and so do not take responsibility for how their services are used – i.e. for both legitimate and malicious purposes. Alternatively, with a strategic NTP amplification attack for example, the initial bandwidth requirements of a botnet are only minimal to have huge adverse effects on a target. Ultimately, this would depend entirely by how much bandwidth Github have, and what mitigation they have in place.