Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Networking Botnet Security

200-400 Gbps DDoS Attacks Are Now Normal 92

An anonymous reader writes "Brian Krebs has a followup to this week's 400 Gbps DDoS attack using NTP amplification. Krebs, as a computer security writer, has often been the target of DDoS attacks. He was also hit by a 200Gbps attack this week (apparently, from a 15-year-old in Illinois). That kind of volume would have been record-breaking only a couple of years ago, but now it's just normal. Arbor Networks says we've entered the 'hockey stick' era of DDoS attacks, as a graph of attack volume spikes sharply over the past year. CloudFlare's CEO wrote, 'Monday's DDoS proved these attacks aren't just theoretical. To generate approximately 400Gbps of traffic, the attacker used 4,529 NTP servers running on 1,298 different networks. On average, each of these servers sent 87Mbps of traffic to the intended victim on CloudFlare's network. Remarkably, it is possible that the attacker used only a single server running on a network that allowed source IP address spoofing to initiate the requests. An attacker with a 1 Gbps connection can theoretically generate more than 200Gbps of DDoS traffic.' In a statement to Krebs, he added, 'We have an attack of over 100 Gbps almost every hour of every day.'"
This discussion has been archived. No new comments can be posted.

200-400 Gbps DDoS Attacks Are Now Normal

Comments Filter:
  • Well (Score:5, Insightful)

    by The Cat ( 19816 ) on Saturday February 15, 2014 @11:38AM (#46254857)

    The obvious solution is to unplug the Internet. I'm sure the government and the movie people will be thrilled.

    • Re:Well (Score:5, Funny)

      by Travis Mansbridge ( 830557 ) on Saturday February 15, 2014 @11:41AM (#46254867)
      Then wait 10 seconds before plugging it back in.
    • by Burz ( 138833 )

      Notice the sidebar to the Krebs article: "The value of a hacked PC".

      I say unplug Windows from the Internet. The world has had enough of this already.

    • How can you push out propaganda if your main distribution method goes away?

      • How can you push out propaganda if your main distribution method goes away?

        By continuing to use your multiple other methods of distribution?

        One system may be fastest or cheapest, but you have to be really, really sure that you're never going to need what you used previously before you unplug it and sell (or throw away) the hardware.

        Case in point : I'm working on a 100-million dollar ship equipped with around ten million dollars of the best shiniest and newest of equipment for robotically handling one of t

        • by nurb432 ( 527695 )

          By continuing to use your multiple other methods of distribution?

          That wont be effective on the next generation ( kids today ). Time has moved on, the method must too.

          • ( kids today )

            Part of the job of us grey-beards is to make sure that when (not if) the things that the kids depend on get broken (including by other kids), then there's a backup system in place. You see, kids today haven't seen things fuck up completely. So they know that it's not going to happen to them because they're immortal and of infinite intelligence.

            When (not if) the "kids" encounter their first major fuck up - they have friends killed in a car crash ; their employer goes bust because of something

  • by silas_moeckel ( 234313 ) <silas AT dsminc-corp DOT com> on Saturday February 15, 2014 @11:42AM (#46254873) Homepage

    Hosting/Colo/Transit providers are the real core issue. There is absolutely no reason that URPF or similar or at least ingress ACL's are not in place. Lets face it if your limiting the prefixes announced you should be filtering on them as well. Anything even close to core can do this in hardware, URPF and similar there is generally no config required more than turning it on. At Hosting/Colo levels do you still have something on the public side that can not do at least ACL's in hardware? Plenty of automation packages can do this stuff in an automated fashion. The root cause is lazy and broken providers that just do not care, DDOS traffic can make some of them piles of cash directly in transit billing or indirectly as the only people with a big enough pipe to do ddos protection.

    • by BSAtHome ( 455370 ) on Saturday February 15, 2014 @11:50AM (#46254907)

      Indeed, reverse path filtering should be mandatory, especially because it is so easy.

      Also, RFC3514 should become a part of the IP standard. Not setting the appropriate bit from the sender side should then be punishable with eternal flogging.

    • Exactly ... is there some perverse incentive at work which makes backbones not try to implement ingress/egress filtering at the internet edge?

      AFAICS it would be trivial for them to require it through new contracts, put some fines on not implementing it and all this disappears ... I'm sure there are some owned computers on core networks but I doubt the owners would want to expose them on a vindictive DDOS attack.

      • by Zocalo ( 252965 )
        Laziness on behalf of end user ISPs, mostly, but also because BCP38 / RFC2827 [bcp38.info] is harder to implement for larger customers that do their own routing from multiple subnets and might legitimately start to send traffic from an IP allocation you have no idea about and thus have blocked because one of their upstream links with a different provider went down. Still, there's no real excuse for not doing this on the edge of networks that are only ever going to have a single known block of IPs behind them though. J
        • It would be hard to do ingress filtering by the backbones for those larger companies, but the companies can surely do egress filtering at each edge of their networks ... just a question of sufficient (financial) incentives.

          Most of the internet edge could be ingress filtered by the core, the rest should do it's own egress filtering.

          • by AK Marc ( 707885 )
            Working for a company with 4,000,000 users, we are ingress filtered (but only over a very tiny subset of links). It works fine. Why would it fail for a larger company? We know every "legitimate" IP on or through our network, and notify those, when required. IP address ranges are static. They don't change who they are assigned to. And the number of changes to providers for those ranges is low, easily manageable for providers and users alike.
            • Well if those companies want to have completely control and just add IP address ranges willy nilly without dealing with admins of their providers it becomes impossible, maybe just more for political reasons than technological but that doesn't really matter.

              So I say fine ... if they don't want to let the providers do ingress filtering for them, just make it mandatory for the companies to have egress filtering on their network (with fines for non compliance/due diligence). If there are real financial risks th

              • by AK Marc ( 707885 )
                You *can't* add addresses "willy nilly" You need applications and justifications for new blocks, at this point, it's almost easier to buy a company that owns IP blocks. But, as you imply, someone that doesn't want to be filtered, and refuses to filter themselves, should be kicked off the network.
        • by sjames ( 1099 )

          In cases of multi-homing or failure recovery, the customer has to let their providers know what routes they will/may be announcing in order to get the BGP filtering set up correctly. Might as well set up the source address filtering at the same time.

          • The problem with this becomes what if you're a transit provider yourself. The logistics of managing that kind of fitering suck. It's why most peers don't.

            There needs to be a middle ground between loose and strict like feasable. I don't want to accept packets for any route I have, nor do I want to drop any packet that doesn't head back the same direction. For reasonable filtering at that level, it needs to be "allow any packets that should reasonably come from this peer per their advisement that I can filter

            • by sjames ( 1099 )

              That sort of transit is a level above edge. In such a case it is probably sufficient to stipulate in any contract that the transit customer has fully implemented source filtering. Of course, if there is ever any abuse, they'll have to pay penalties and face stricter filtering.

              That is already dealt with for BGP.

              • The problem is you have to trust that peer to police their network.

                It leads to a situation where one bad actor network with content can make it never successful.

            • by Cramer ( 69040 )

              As one who has maintained an ISP's peering, it is no where near as complicated as you make it sound. Enterprise class hardware (from Cisco, Juniper, etc.) have builtin support for unicast reverse path filtering (uRPF) that's effectively processing free -- based on the routing table ("FIB" -- forwarding information base) -- very effectively preventing traffic from entering (or leaving) your network that doesn't belong there.

              (As an end user, uRPF presents a small problem as the ISP DHCP server is a 10-net ho

              • As one who has maintained an ISP's peering, it is no where near as complicated as you make it sound. Enterprise class hardware (from Cisco, Juniper, etc.) have builtin support for unicast reverse path filtering (uRPF) that's effectively processing free -- based on the routing table ("FIB" -- forwarding information base) -- very effectively preventing traffic from entering (or leaving) your network that doesn't belong there.

                (As an end user, uRPF presents a small problem as the ISP DHCP server is a 10-net host and I null route 10/8.)

                Yes obviously, which can be implemented in 2 modes: strict, which is useless as an upstream peer because you don't necessarily have best path down to them for everything you're hearing, or as loose, which is again useless as an upstream peer because you might as well turn it right off.

                Dude, clearly you have no idea what you just read.

                • by Cramer ( 69040 )

                  Incorrect. I'll say it again: It's not as complicated as the "haters" claim. I've maintained "BCP38" in an ISP network with transit links (aka. isp-edge routers with default routes.) While it's not perfect -- because "everything" is potentially on the other side, there are steps to be taken. (I ultimately cannot prove a packet with a source address of paypal actually came from them unless I'm directly peered with them.) You know what's inside your network (read: as the network operator, you d*** well bett

                  • Let me try this as simple as I can. Just because you ran BGP with your provider, does not make you a peer or transit network.

                    You just said default route. That is a leaf node. You're at the end of the world. You are not peering. uRPF is useful when you're a leaf. It is *completely useless as a real peer* in it's current form.

                    Let me illustrate this for you with a completely made up scenario: You are Telia, you peer with Abovenet in 3 places, how do you configure uRPF on those links so that it keeps spoofed pa

                    • by Cramer ( 69040 )

                      (per peer interface) "ip verify unicast source reachable-via any" This is the less desirable "loose" method, and doesn't work if you have a default route (with 0/0 matching everything.) It won't necessarily stop all spoofing, but it will significantly cut it down. "via rx" is always preferred, but in this case, each site may not prefer a given network through it's local connection, instead crossing an internal link to another site. (this is also asymmetric routing.)

                      Once again... the only way to completely e

        • by AK Marc ( 707885 )

          r larger customers that do their own routing from multiple subnets and might legitimately start to send traffic from an IP allocation you have no idea about and thus have blocked because one of their upstream links with a different provider went down.

          Assuming they aren't relying on asymmetric routing (a bad thing), if you don't know about a range being sent to you by a customer, how can they receive a reply?

          Still, there's no real excuse for not doing this on the edge of networks that are only ever going to have a single known block of IPs behind them though.

          Works for dynamically routed networks as well, if they aren't advertising the range through you, don't accept it. That's not going to block any legitimate traffic unless you have route filters and the customer didn't follow the process to get new ranges added to your filters.

          The customers and edge ISPs should stop all this. If they don't, they sh

        • by DarkOx ( 621550 )

          I agree for edge networks there is no good reason for RPF not being enable but you hit the nail on the head when it comes larger customers that have an AS or multiple AS allocations and ip addressing they may not share with you. Its not really as simple as just throwing a switch at most of the sites which really matter.

          As far as the home and SoHo users I don't know how the rest of the world is but I don't know any main stream ISP that isn't doing some kind of reverse filtering. I have not been able to get

          • All it takes is to kick those handful of sites off the internet and problem solved.

          • RPF wont, ACL's will and it's trivial to take a BGP prefix list and turn it into an ACL. The more it's implemented the better it works, 100% penetration is not required for it to be effective though. As you push these attackers to use the undefended spaces more and more pressure is put on them to clean up there act. Most of the source points for this seem to be Hosting/Colo where the filters are pretty trivial to get in place even if it's just on your own edge outbound.

            • by DarkOx ( 621550 )

              I agree that will help a lot but it still won't solve the problem. The problems is the size of the sub that's through skateboarders just upset on out there. You can always weapon eyes local subnet cause her is no router to enforce ACL hosts and talk to each other directly. You spoof a few packets 100 or so little Soho routers out there each with 5 Mb upload and you got quite a lot of bandwidth right there. All of that traffic will indeed be sourcing local network with both the ACL's OraVerse path filter

      • Is transit billing not a good enough one for you? Selling there own DDOS protection or transit bandwidth to others to do the same. Seems like good reasons for them to not want to.

        There are potentially serious issues with tier 1's putting this in place today with there peers etc. Anything that is not a BGP speaker should have his on today, BGP speaking clients should be given a timeline to be ready for this to be turned on (there is some broken bits out there). Tier 1 peers is another story but if everyt

  • So why don't NTP servers limit their responses to, say, 1 per 10 seconds per IP address? Even if spoofing, it would not take that long to exhaust the subnet of the attack target.

    • by Pinky's Brain ( 1158667 ) on Saturday February 15, 2014 @11:56AM (#46254935)

      They're all buggy commodity routers which are never getting updates.

      • by mysidia ( 191772 )

        They're all buggy commodity routers which are never getting updates.

        Relatively recent Juniper JunOS versions respond to ntpdc monlist, as well, so they're vulnerable. The only way to address these, I found.... was to completely firewall off NTP on the loopback interface.

        The same for a number of other appliances, that are still technically supported, but the vendors seem uninterested and unconcerned about NTP issues, so much so, that they are only suggesting workarounds such as "turn off NTP", no i

        • i see you've also had to deal with this plague. stupid juniper switches are unable to work as ntp clients only. as soon as you configure ntp settings, they reply to client requests. a few weeks ago, i learned this the hard way when all my switches suddenly became overloaded and all my bfd sessions started flapping.

        • by klui ( 457783 )

          Juniper advisory:
          http://kb.juniper.net/InfoCent... [juniper.net]

          JunOSe and ScreenOS unaffected.

    • by Gerald ( 9696 )

      Most modern servers don't respond to the offending command (monlist) at all. Older/misconfigured servers are the problem and there are enough of them to cause trouble.

    • by mysidia ( 191772 )

      So why don't NTP servers limit their responses to, say, 1 per 10 seconds per IP address?

      You couldn't bother spending 5 minutes reading to learn that the issue only exists on NTP implementations that allow administrative queries, and on modern NTP implementations that's off by default?

      By the way, NTP servers CAN [redhat.com] be configured with 'discard' and 'restrict limited' statements, to restrict the rate at which clients can query, and send KOD packets if a client is querying too often..

      But that's not the

  • Maybe this is another reason to use TOR or something more generic to mask IP? Not for privacy, but to hide in the crowd. Google wants to know everything anyway....maybe they should offer a service to be a web-proxy-server.

  • These services are available for any kid with five dollars. The last one that hit my network knocked us off and our upstream provider. They use spoofed packets to machines with services such as chargen/echo to amplify the attacks. If you contact one of these services they will threaten or try to extort money from you.

    • No $5 booter is going to do anything close to this kind of damage. A gigabit maybe, but that's about as high as it would go, despite their claims.

      However I'm sure some will be adding NTP amplification to their "services."

      • I tried one against myself for a minute last year and saw about 4Gbit/second of port 53 UDP traffic. Enough to cause problems for an amateur-hour webhosting service. Any half decent webhost can handle that these days.

        • 4Gbit? Did you have a 10 gigabit port or something?

          Even so that's not even in the same league as what we're talking about.

  • I can't help but notice all the comments so far are about technical prevention. If it is possible, well, that would be great. But for those who dodge all technical barriers and pull this off, maybe its time for some laws equivalent to those insanely high penalties for file-sharing. It's not like a 200Gbps attacks are inadvertent or accidental; they take some deliberate effort. Make it a criminal-record, no-passport, ruin-your-employability, year-in-jail kind of crime. I suppose the 15-year-old in Ill

    • Re: (Score:3, Interesting)

      The problem with that approach is that a lot of those internet criminals are actually just immature teenagers - all they really need is a slap on the wrist to scare them straight and a good talking-to by their parents. Throwing them in jail is a good way to make sure they turn into real career criminals - if you can't get employment in legitimate work, what other choice is there? It's the same problem with heavy sentences for drug possession.

      Almost every decent computer security expert dabbled in black-hati

      • "Almost every decent computer security expert dabbled in black-hating a little"

        Oh, my. I had no idea that the computer security field was so rife with racists.

        • Since you care to differentiate a hatter from a hater, perhaps the word you're looking for is "blackhatting". Note the spelling.

      • by Anonymous Coward

        Almost every decent computer security expert dabbled in black-hating a little when they were learning

        Nope, I was never racist about it.

      • by jafiwam ( 310805 )

        The problem with that approach is that a lot of those internet criminals are actually just immature teenagers - all they really need is a slap on the wrist to scare them straight and a good talking-to by their parents. Throwing them in jail is a good way to make sure they turn into real career criminals - if you can't get employment in legitimate work, what other choice is there? It's the same problem with heavy sentences for drug possession.

        Almost every decent computer security expert dabbled in black-hating a little when they were learning, if only to prove to themselves what they could do or for the fun of adventuring into forbidden places. I used to port-scan for open netbios shares back in the win9x era - found a lot of people who had their entire C: drive open to the world. I left text files on their desktops warning them about the open access.

        Ok, public caning in the town square. One lash for each gigabit of wasted bandwidth, plus $100 fine for each of the same.

        • by rbrander ( 73222 )

          Appropriate to what 1961 would have called a science-fiction crime, the punishment taken from Starship Troopers. I like it.

    • by jythie ( 914043 ) on Saturday February 15, 2014 @12:40PM (#46255091)
      We already have pretty strict (and overused) laws involving cybercrime.

      Problem is, people who do this stuff professionally are pretty much immune from being caught, and the people who do get caught are usually teenagers which, while we like talking about personal responsibility, biologically young brains really do have physical issues when it comes to impulse control and risk analysis. So punishing them harshly does not actually do any good other then satisfying a certain bloodlust.
      • Punishments often do not help the criminal but they certainly do knock down impulses in friends when they see what happens to the violator. The IRS thrives off of the same tactic. Catching one tax cheat probably represents an expense to the IRS less than the recovery. But everyone who sees the cheat tossed down the rabbit hole suddenly becomes more honest in their reporting. The catch is that sometimes simple errors cause the violation other than a deliberate notion to commit the act.
  • by jythie ( 914043 )
    While we patch and patch, we might be getting close to the point where a real restructuring or protocol update needs to happen. Various researchers have proposed technologies that could make the internet far more resilient to stuff like this, and maybe it is time we switch over.

    But I am not thinking some nice gradual switch over, but a nice 'if you don't upgrade by X time you loose your insurance and can no longer peer'. If nothing else we could kill at least two birds with one stone... think about the
    • But I am not thinking some nice gradual switch over, but a nice 'if you don't upgrade by X time you loose your insurance and can no longer peer'. If nothing else we could kill at least two birds with one stone... think about the massive economic fallout from the Y2K update, all the money that flowed into tech and job for that had a ripple effect through the economy. Requiring a complete upgrade of the internet would put a real dent in the current economic downturn.

      Another benefit: we can see the sequel, Office Space 2, and see how Initech inflates the work needed to solve the spoofed-source problem. Will it end in another fire? Will Milton come back?

  • by Anonymous Coward

    Require ISPs to do checks on IP spoofing. Case closed for most DDoS attacks. Optimization always comes at a cost of security. I'm not even an expert and still know the solution, just like a kid can read and click through a premade tool, fill out some forms and do attacks.

    Kids don't have the moral subroutines to understand restraint. Anyone with a minimum amount of knowledge can fire off attacks these days, it seems.

  • Compared with the mostly unsolvable new normal of having most of basic internet infrastructure backdoored by a government i'd say that is pretty benign. You can diminish a lot asking administrators to fix their NTP servers or ban their IPs. But no matter how much you try, internet as a worldwide network is broken beyond repair, you can choose to ignore that fact (as much you can ignore to being hit by a 400gbps attack), but it will still be broken.
  • Then make the originating network legally and financially responsible for not filtering the spoofed packets originating from their network with a IDP (Internet Death Protocol) for any networks which do not fix their network within 3 days following a attack launched from their network.

  • DDOS causes more lost money than other "security" breaches. Therefore it is a top priority of companies and by extension public/private partnerships.

    Of course, this is an asymmetric attack and you can't stop it. In other words, it is a democratizing attack.

    When I worked with the FBI on security issues in the financial sector, I was disgusted by how little attention and funds were available to fix problems like unauthorized transactions but attention is available for issues like this.

Keep up the good work! But please don't ask me to help.

Working...