In the latest sign that large-scale distributed denial-of-service attacks aren't going away, a security vendor...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
this week reported what's believed to be the largest publicly confirmed DDoS attack in history.
Matthew Prince, CEO of San Francisco-based DDoS mitigation provider CloudFlare Inc., confirmed late Tuesday that his company fought off a huge DDoS attack this week that peaked just below 400 Gbps, making it one of the largest recorded DDoS attacks ever.
Prince noted that the attack appeared to peak around midday Tuesday. He said the traffic was distributed around the world, but that the effects of the attack seemed to have mostly been felt in Europe.
Though Prince declined to identify the target of the attack, Octave Klaba, founder of French Web hosting service OVH.com, commented on Twitter that his company had experienced a DDoS attack exceeding 350 Gbps in bandwidth. He said that the attack included IP addresses from his network, but that the company was a victim.
Darren Anstee, a solutions architect for Burlington, Mass.-based Arbor Networks, said that Arbor observed a DDoS attack Monday against a target in France, with peak traffic hitting 325 Gbps.
"I would suspect [the attacks] were likely related due to the similar timing and scale," Prince said via email. "However, I don't have direct evidence of that."
As for just how attackers achieved that extreme level of bandwidth, which surpassed the massive 300 Gbps DDoS attack against nonprofit Spamhaus in March 2013, CloudFlare said it targeted vulnerabilities in the Network Time Protocol (NTP), an Internet standard that is used to synchronize time across networks of computers.
In January, CloudFlare's John Graham-Cumming wrote a blog post warning of the dangers of NTP reflection attacks, which he described as being similar to the more well-known DNS reflection attack technique. Basically, an attacker sends a request to a server that appears to be coming from the intended victim's IP address, with the goal of having the server send a reply larger than the original request back to the victim. Of course, with the reply being sent back to the victim, the source of such attacks can be difficult to trace.
To generate the amount of traffic CloudFlare spotted in this instance, though, an attacker would need to amplify the traffic being sent to the victim. This can be done by finding protocols and servers that return much larger responses than the initial request. Graham-Cumming noted that that DNS replies are eight times as large, in terms of bandwidth, as the correlating responses, which has led to its use in many recent amplification attacks, including against Spamhaus.
In comparison, he witnessed one NTP server on which the responses were a whopping 206 times as large, mainly due to the MON_GETLIST command.
"Unfortunately, the simple UDP-based NTP protocol is prone to amplification attacks because it will reply to a packet with a spoofed source IP address and because at least one of its built-in commands will send a long reply to a short request," Graham-Cumming wrote. "That makes it ideal as a DDoS tool."
On Jan. 2, 2014, US-CERT issued a warning that MON_GETLIST could be used in amplified DDoS attacks, though despite garnering an exploitability subscore of 10.0, the highest possible rating on the Common Vulnerability Scoring System ranking scheme, the vulnerability only achieved a 5.0, or a "medium" overall score. In a Jan. 13 follow-up alert, US-CERT said the attack technique was "emerging" and advised those in control of NTP servers to either upgrade from previously vulnerable versions of the protocol to 4.2.7 or disable the GET_MONLIST monitoring functionality.
Worryingly, Prince described the nearly 400 Gbps NTP reflection attack as "nothing new" on Twitter and told SearchSecurity via email that this technique will definitely be utilized more frequently by attackers in the future due to the large amplification factor of NTP responses. He also advised network administrators to ensure they're not running misconfigured and vulnerable servers by visiting OpenNTPProject.org.