Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



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:
  • by Cryacin (657549) on Tuesday February 11, 2014 @12:11AM (#46215349)
    When you approach the business and say that a zombie network is DDossing the website with a Reflection attack, and that's why no-one can access the website.
  • by Anonymous Coward

    The ISPs of the world keep letting this kind of crap happen.... It should be pretty obvious when someone is trying to DDoS a server. Even if they don't want to lose a "paying customer", simply cutting access to that server for x amount of time for that IP would be more than enough.

    • Re: (Score:3, Insightful)

      by jawnah (1022209)

      The ISPs of the world keep letting this kind of crap happen.... It should be pretty obvious when someone is trying to DDoS a server. Even if they don't want to lose a "paying customer", simply cutting access to that server for x amount of time for that IP would be more than enough.

      I understand where you're coming from but I think that may be a premature observation. I doubt this is just an attack against a single IP address. You should also remember that there comes a point where the incoming volume of traffic destined for the IP address(es) under attack overwhelms the upstream carriers prior to the null-routing of said addresses. The lower the null-route is set, the greater the chance for upstream impact. Mitigating heavy DDoS isn't always just a simple matter.

    • See right here, at http://tech.slashdot.org/story... [slashdot.org]

      Specifically, he noted that in http://archive.icann.org/en/co... [icann.org] that it's a simple task to check outbound packets and drop them if the return address is for someone else.

      The open question is ISP motivations: I used to work for Canada's first big ISP, and my management would have freaked out if they thought they were frivolously enabling a DDOS attack. See the queue article and comments for more info.

  • by Anonymous Coward

    I went to firstlook.org this morning to see Glenn Greenwald's latest NSA story, and was surprised to first see a page from cloudflare claiming to be checking if I was a legit visitor. Could this be related? Have the spooks struck again?

    • by Holi (250190)

      Why would you support a site that so flagrantly breaks the back button?

  • by Anonymous Coward on Tuesday February 11, 2014 @12:33AM (#46215429)

    Serious question. why are network providers allowing FORGED packets to leave their networks?

    • by Anonymous Coward

      good question.. this is like classifier rule #1(or damm near #1) at the ISP i work for. If its not in our block it doesn't leave.

    • A better question is why are ISP's allowing forged traffic ENTER their network from end users? If they drop grandma's traffic that doesn't have grandma's srcip then grandma won't complain and the WWW would be a little safer. Of course their will always be end users who transit legit traffic.

      • by DarwinSurvivor (1752106) on Tuesday February 11, 2014 @04:30AM (#46216073)
        Because it is VERY difficult to ascertain whether the source of an inbound packet is forged unless it is very obvious (like an IP that should be inside your network or on a private subnet). Outbound traffic on the other hand should almost always have a source IP that belongs to your assigned ranges (or configured private subnets).
        • Because it is VERY difficult to ascertain whether the source of an inbound packet is forged unless it is very obvious (like an IP that should be inside your network or on a private subnet). Outbound traffic on the other hand should almost always have a source IP that belongs to your assigned ranges (or configured private subnets).

          On the Internet there should also never be traffic with RFC1918 source IP addressing, which is easily filtered on ingress.

          • Filtering ingress packets with RFC1918 source IPs may be useful in some circumstances, but it doesn't help in amplified attacks.

            The source in these cases will always be a legitimate uninfected machine that is just doing its job (such as a DNS or NTP server). The source IP will be whatever IP the requester expects to see, such as the destination IP of the initial request.

            In amplified attacks, the forgery occurs in the initial request packets, all of which have the source IP of the DoS target, which must alw

            • Filtering ingress packets with RFC1918 source IPs may be useful in some circumstances, but it doesn't help in amplified attacks.

              The source in these cases will always be a legitimate uninfected machine that is just doing its job (such as a DNS or NTP server). The source IP will be whatever IP the requester expects to see, such as the destination IP of the initial request.

              In amplified attacks, the forgery occurs in the initial request packets, all of which have the source IP of the DoS target, which must always be an actual external IP. This is where egress filtering is useful, because none of these requests should have an IP outside of the subnet serviced by the egress filter.

              Agreed except that egress filtering is not practical for inter provider transit traffic and not all SPs filter their customers' traffic.

    • by Anonymous Coward

      I had that attack in my network last week. It's not based on ip spoofing. It simply expoilts open ntpd servers and send them the payload which targets many more servers (reflection and amplification). I had to mitigate the attack by filtering ntp port just to few credible servers from pool.ntp.org.

      • by pe1chl (90186)

        That is called ip spoofing. They send a request with a sender address of a victim, and the server sends the reply to the victim.
        This would not be possible when the attacker's ISP would not allow source address spoofing.

        • by Anonymous Coward

          You are right. But i can't beleive that there are still ISP's out there which do not put filters based on their routing objects on their border routers. It's insane. And on the other hand their upstream providers allowing it. What is BGP good for then? Are network guys that lazy?


    • Forgive me if I'm wrong but given large volumes of traffic that are sold at the lowest rate, providers are not about to add hassle and overhead to their filtering...

      So it's a "business decision" really. After all, is there anything to penalize network providers from not adding filters?

      Personally I think this should really be in everyone's best interest given the implications of inaction, but how to start the ball rolling?
  • I did have one site I normally visit (DPReview) get really slow, and then eventually go offline for a short time, I wonder if that was due to the attack.

    At this point it seems like even massive attacks are not really doing much of a job in slowing down companies using something like CloudFlare or other distributed CDN's. I wonder how much longer it is before people will give up on DDOS attacks as ineffective.

  • NSA and GCHQ when you need them?
  • Why does it always take a team of tech to manually block the spamming IP numbers? Why isn't this automated? When this sort of flooding action takes place it should be pretty obvious... respond.

    • by Anonymous Coward

      Our last inbound attack appeared to come from over 50 million very well spread out different IPs. Of course those are all spoofed IPs but either way you can't effectively block that many without blocking larger amounts of legit traffic.

    • IPS is sometimes great.

      However, if an attack occurs from thousands of IP-adresses and with random requests.
      Well, they fail and you fail.

      DDOS is terrible to defend against.

      DOS otoh is simple, just block the IP.

      • There has to be some sort of pattern. It can't be entirely random.

  • by andyn (689342) on Tuesday February 11, 2014 @03:09AM (#46215849)

    a timing mechanism that underpins a way the Internet works

    But how many LOCs is that? Joking aside, I would have thought that nobody had to dumb down things that much before posting to Slashdot.

    • Still not as bad as when they explained what whitelisting is [slashdot.org] a few days ago. Since this is starting to look like a trend, I'm beginning to suspect that the roadblock over the UI and UX stuff with the beta has led them to try rolling out their new, "more accessible" content independently of the redesign.

      • by Soulskill (1459) Works for Slashdot on Tuesday February 11, 2014 @12: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.

        • I understand that, and I also know you guys are in the unenviable position of getting unfairly dinged no matter what you do, particularly right now with the beta and everything related to that situation. At this point, you'll be taking flak no matter what you do.

          That said, isn't this exactly the sort of thing that links are for? Whitelisting shouldn't have needed an explanation, given that the concept can be inferred easily from the name itself (not to mention that it's a common topic here on Slashdot), but

        • by gmhowell (26755)

          One useful policy to adopt would be to include an expansion of acronyms when first used in a summary. With a link to the appropriate Wikipedia article?

  • Update your NTP sw! (Score:5, Informative)

    by Terje Mathisen (128806) on Tuesday February 11, 2014 @03: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) on Tuesday February 11, 2014 @04: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: (Score:2, Interesting)

      by Anonymous Coward

      Two key corrections:

      1. It's UDP (the protocol) not UPD. Contextually I understood though, and assumed typo until I saw...

      2. It's ntpd v4.2.7 not ntpd v2.4.7.

      Also, the recommended solution is not just to limit noquery, but others as well. This comes straight from the FreeBSD stable/9 ntp.conf as of 2013/12/27 [freebsd.org]:

      restrict default kod nomodify notrap nopeer noquery
      restrict -6 default kod nomodify notrap nopeer noquery

      restrict 127.0.0.1
      restrict -6 ::1
      restrict 127.127.1.0

      Last 3 lines are effectively "allow". For

    • by neurovish (315867)

      Thanks for the clarification...you need a +6 informative. The article was pretty light on how NTP was being exploited for a reflection attack.

  • by Anonymous Coward
    "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

    I would have thought the DDOS attack were facilitated by all those compromised Microsoft Windows desktop computers out there on the Intertubes ..
  • by pe1chl (90186) on Tuesday February 11, 2014 @04:09AM (#46216025)

    This case mentions the use of NTP, but the idea of reflection attacks by now has propagated to TCP as well, even without amplification it seems worthwile.
    Right now an attack is running on many webservers that sends SYN packets with source port 80 and 443 and destination port 80 from spoofed source address.
    Apparently they want to overwhelm the victim with SYN ACK packets from reflectors.
    However, those are the same size as the SYN packets sent by the attackers. Probably no issue, those attacks are likely sent from compromised systems and botnets as well.

    It is about time that a blacklisting system is setup for providers that allow source address spoofing, similar to how providers running open SMTP servers were tarred and feathered until they fixed it.

    • Re:Not only NTP (Score:4, Interesting)

      by ledow (319597) on Tuesday February 11, 2014 @07:32AM (#46216585) Homepage

      Yep.

      Source-address spoofing just shouldn't be happening. Whether on the smallest or largest networks, why would you let someone fabricate any IP address and pass it along as if it were part of your network?

      First rule on almost all firewalls is to block all such "foreign" packets.

      The big carriers are really the problem here - they should just turn off network access to anyone who provides traffic to/from systems that they are not registered in their AS for. After an hour of being offline, they'll soon push the message to clean up what IP's are talking out from your networks all the way down to individual leased line customers.

      • As someone above pointed out, load balancing and redundancy are valid reasons to send packets with source IPs not in the originating AS. That mostly doesn't apply to residential subnets where the zombies are, but one reason does. I sometimes use LTE tethering and my home internet connection simultaneously because the LTE is as fast or faster than my home connection during non peak hours. I don't know if it is doing load balancing between the two uplinks, but why shouldn't it?

        • The connection teaming/bonding firewall code should be able to mangle the source ip to match the outgoing connection's expected source IP. There should be no requirement to spoof the ip to go across a different network.

System going down in 5 minutes.

Working...