Forgot your password?
typodupeerror
Security The Internet

DDoS Larger Than the Spamhaus Attack Strikes US and Europe 158

Posted by Unknown Lamer
from the do-not-stare-directly-into-the-udp-packet dept.
mask.of.sanity writes "CloudFlare has been hit by what appears to be the world's largest denial of service attack, in an assault that exploits an emerging and frightening threat vector. The Network Time Protocol Reflection attack exploits a timing mechanism that underpins a way the Internet works to greatly amplify the power of what would otherwise be a small and ineffective assault. CloudFlare said the attack tipped 400Gbps, 100Gbps higher than the previous record DDoS attack which used DNS reflective amplification."
This discussion has been archived. No new comments can be posted.

DDoS Larger Than the Spamhaus Attack Strikes US and Europe

Comments Filter:
  • Re:And yet... (Score:5, Informative)

    by Luckyo (1726890) on Tuesday February 11, 2014 @01:50AM (#46215491)

    The beauty of the first D in the DDOS is that it's in fact DISTRIBUTED denial of service. It's not coming out of single grandma, or even hundred grandmas.

    You may be forced to switch tens of thousands, maybe even hundreds of thousands of people off. Can you imagine the massive PR fallout? Mass media would LOVE the story.

    No one is going to go for that kind of PR disaster.

  • by Anonymous Coward on Tuesday February 11, 2014 @02:06AM (#46215531)

    It's not always laziness. I added outgoing filters to my routers so that it only allowed source addresses from my network. That was great at stopping DOS attacks, but as I found-out the hard way, several of my customers were sending outbound traffic with source addresses not on my network. That was in 1997. For the next several years, it was a huge hassle to keep adding additional source address ranges for customers. An ISP selling a high speed connection has to allow outgoing traffic from addresses they don't own. That's the entire point of selling transit.

  • Re:And yet... (Score:4, Informative)

    by justanothersysadmin (1750776) on Tuesday February 11, 2014 @02:26AM (#46215581)
    Except in this case (or other reflection attacks, i.e. you're dealing with source address spoofing), RPF [wikipedia.org] on customer-facing interfaces should prevent the attack from leaving the ISP's network in the first place. Note that I'm talking about the ISP of the original machine performing the request with the spoofed source IP here, not even even the ISP of the machine server that's being used for the reflection & amplification (which in this is a vulnerable or misconfigured NTP server). The affected NTP servers need to be cleaned up as well, but the sources of the original packets also should be preventing the spoofed traffic from leaving their networks.
  • Update your NTP sw! (Score:5, Informative)

    by Terje Mathisen (128806) on Tuesday February 11, 2014 @04:26AM (#46215895)

    I've been a member of the NTP Hackers team for more than a decade, the mechanism that is being abused for these attacks is in fact a very useful debugging/monitoring facility:

    You can ask an ntpd server about how many clients it has and how often each of them have been accessing the server. On old/stable ntpd versions this facility was accessed using a single pure UDP packet (ntpdc -c monlist), and in reply you got back information about up to 602 clients (the size of the monlist buffer), sent as a big burst of UPD packets.

    Researchers have developed maps of the entire publicly accessible NTP networks using this facility, I have personally used it to map the status of our fairly big corporate network. I.e. it can be extremely useful!

    A few years ago the development version of ntpd switched to a different protocol and method to query this information, using a nonce which meant that you can no longer spoof the source address: (ntpq -c mrulist). Since the mrulist buffer is configurable, I have setup my public ipv6 pool server (ntp2.tmsw.no [2001:16d8:ee97::1]) to keep monitoring info for the last 10K clients.

    Today we recommend that you either upgrade to ntpd v2.4.7, or if you really cannot do this, insert a 'restrict default noquery' option in the ntp.conf configuration file. The 'noquery' indicates that clients can still use the server for regular time requests, but the monitoring facility is disabled.

    Terje

  • by lowlands (463021) <smplx@@@hotmail...com> on Tuesday February 11, 2014 @05:44AM (#46216115) Homepage Journal

    Thank you for pointing that out. It would be great if sysadmins and vendors fixed their NTP config. Unfortunately i's not only NTP that gets abused. The script kiddies also use open DNS servers that do recursive searches. And I'm sure there are more ways kindly offered by ignorant sysadmins and vendors who just don't care. Just google for "TP-Link recursive DNS" to get an idea. The solution is to force vendors to fix recursive DNS and NTP on their Internet facing boxes (why stop there, just "disallow anything from WAN" by default) and make them liable for the default config. Educate and poke sysadmins to fix their badly configured crap if they do not want to get blocked by their ISP or upstream. Force local ISPs to drop packets with a non-local src IP address and block the idiot that sends those packets. And finally add to Spamhaus the IP addresses/ranges of idiots who just don't care. Let's see how quickly they fix their crap once their boss figures out he can no longer send email to the cute-cat-pic mailing list.

  • Re:And yet... (Score:5, Informative)

    by RabidReindeer (2625839) on Tuesday February 11, 2014 @08:36AM (#46216603)

    These computers are parts of botnets that exist for a long time. Send the infected customers an email about their infection, containing the offer to fix it (for a certain price) and a deadline when they will be cut off if they do not get this fixed.

    Because the offending packets are UDP, they can (and do) employ bogus response IPs. The IPs of their victims, in fact - which is how the reflection occurs. The botnet machines send out small judas packets to DNS servers all over the world. The DNS servers think that these are legitimate queries from the victim machine and send out large quantities of DNS data to the victims. Hence, the other name: amplification.

    The problem is, the fix I had to employ was to physically replace the co-opted DNS servers with more advanced equipment because the system software that was on them had no throttling capabilities nor was is capable of recognizing and rejecting suspicious queries.

  • by Soulskill (1459) Works for Slashdot on Tuesday February 11, 2014 @01:11PM (#46218929) Homepage

    It's more that any community, even Slashdot's, has a variety of interests and areas of expertise. You can be very educated and technically-minded, but still not know anything about NTP, in the same way a network engineer may not know offhand what solid rocket grain geometry is, or Sanger sequencing.

    It's a bit of a catch-22 -- when we post more explanatory summaries, people say that we're dumbing it down. When we post more complicated ones, people say they shouldn't have to turn to Google to figure out what the story is about.

COBOL is for morons. -- E.W. Dijkstra

Working...