Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
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 c0lo on Friday March 02 2018, @02:45PM (7 children)

    by c0lo (156) Subscriber Badge on Friday March 02 2018, @02:45PM (#646383) Journal

    Reverse path filtering is about deciding whether a packet you've recieved is sporged.

    You receive an IP packet which passed to 15 routers before reaching you, with the source IP (reply address) being sporged - how would you know it was sporged?
     

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by VLM on Friday March 02 2018, @03:15PM (3 children)

    by VLM (445) 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).

    • (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) 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.

  • (Score: 2) by FatPhil on Friday March 02 2018, @03:37PM

    by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Friday March 02 2018, @03:37PM (#646421) Homepage
    Would you be prepared to receive the response and forward it on to the next hop?

    If you're an edge router, that's a very easy question to answer, and if the answer's "no", you don't let it out.
    If you're backbone, it's also very easy to answer, the answer's very unlikely to be "no".
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
  • (Score: 2) by bob_super on Friday March 02 2018, @05:56PM

    by bob_super (1357) on Friday March 02 2018, @05:56PM (#646501)

    You could imagine a protocol where the first packets you receive from a brand-new return IP range get challenged before being forwarded. If the sender pretending to be at that address doesn't respond to a challenge, you discard. The challenge has to be a small packet, on the edge of the network (a tiny ping), to avoid adding congestion.
    That wouldn't stop state-sponsored attacks, but script kiddies playing with Memcached would be limited to bugging their neighbors.

  • (Score: 2) by sjames on Friday March 02 2018, @06:52PM

    by sjames (2882) on Friday March 02 2018, @06:52PM (#646537) Journal

    The idea is for the ISP that owns the edge routers to do the egress filtering. And if they don't, de-peer them.

    The closer you get to the core, the harder it is to get right. Right in the core, the list of plausible addresses is nearly the entire address space, so it's not feasible there.