Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday March 02 2018, @12:46PM   Printer-friendly
from the quick-reaction dept.

GitHub has been hit with the largest-ever DDoS attack, and it was only down for a few minutes:

On Wednesday, February 28, 2018 GitHub.com was unavailable from 17:21 to 17:26 UTC and intermittently unavailable from 17:26 to 17:30 UTC due to a distributed denial-of-service (DDoS) attack.

[...] Cloudflare described an amplification vector using memcached over UDP in their blog post this week, "Memcrashed - Major amplification attacks from UDP port 11211". The attack works by abusing memcached instances that are inadvertently accessible on the public internet with UDP support enabled. Spoofing of IP addresses allows memcached's responses to be targeted against another address, like ones used to serve GitHub.com, and send more data toward the target than needs to be sent by the unspoofed source. The vulnerability via misconfiguration described in the post is somewhat unique amongst that class of attacks because the amplification factor is up to 51,000, meaning that for each byte sent by the attacker, up to 51KB is sent toward the target.

[...] Between 17:21 and 17:30 UTC on February 28th we identified and mitigated a significant volumetric 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.

Also at Wired and The Register.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by VLM on Friday March 02 2018, @03:15PM (3 children)

    by VLM (445) Subscriber Badge on Friday March 02 2018, @03:15PM (#646406)

    As the g-g-great-grandpost specified, why don't the edges work properly, and the answer as always is its cheap and lazy.

    If your cablemodem doesn't sniff DHCP traffic and try to dynamically insert firewall rules to only forward legit src addrs, then it can not have bugs related to that code nor can it be late to market due to dev and testing time nor will it get blamed for being in a DDOS attack because every other piece of edge gear is trash so its not any worse and its all the big bad hacker's fault anyway plus or minus some victim shaming.

    So to circularize the argument and answer g-g-grand OPs post, the edge sux (doesn't block bad traffic) because the edge sux (its gotta be cheap and no one cares if it works "right" as long as the customers pay their bills).

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by c0lo on Friday March 02 2018, @03:25PM

    by c0lo (156) Subscriber Badge on Friday March 02 2018, @03:25PM (#646412) Journal

    If your cablemodem doesn't sniff DHCP traffic

    Hang on! You or the OP imply that the haxors would be stopped by their cablemodem?
    Especially the gov-sponsored chinese haxors?

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
  • (Score: 3, Interesting) by BsAtHome on Friday March 02 2018, @03:40PM (1 child)

    by BsAtHome (889) on Friday March 02 2018, @03:40PM (#646424)

    The cable-modem is normally not involved in RPF because of dynamic IPs. Therefore, the first convenient place to enable RPF is the router (often L2/3 switch) at the ISP side (the one the cable-modem connects to). There you simply filter the local network segment as valid source.

    As a network provider you know where your IP segments are and it is a matter of standard procedure to do proper setup at the right place. Yes, there are a lot who don't care, but that does not mean that we cannot reduce the problem quite easily. This can additionally be solved by ingress/egress verification at the BGP border. Any egress out of the first AS hop is always determinate (which equals the ingress of the second AS).

    • (Score: 2) by VLM on Friday March 02 2018, @08:58PM

      by VLM (445) Subscriber Badge on Friday March 02 2018, @08:58PM (#646626)

      Yes thats the longer more professional answer. With a side dish that adding filtering creates a possible failure mode where you move an IP segment from here to there and forget to update the filtering leading to mysterious phone call complaints from end users.

      IPv6 will fix everything when you can allocate such giant chunks of space you'll never wiggle /25 from here to there to make things fit.