3 ms·

This is not true. I work for a major DDoS mitigation equipment company and we see SYN floods all the time. And you CAN block one million users from all openin

by Nrsolis 16y ago

This is not true. I work for a major DDoS mitigation equipment company and we see SYN floods all the time. And you CAN block one million users from all opening up one connection. Our software/hardware makes this happen. There are MANY MANY ways that DDoS can be dealt with; the biggest hurdle in many cases is convincing a customer that they might be next. Until then, they often don't see the need to spend the money on sufficient capacity or properly test their system against the range of "probable" attack vectors. That's likely what you're seeing here. It /is/ true that attacks are becoming more sophisticated and targeting applications rather than just pure network resources (e.g. b/w). A big part of our efforts are trying to abstract away the potential attack vectors common to several application stacks rather than developing solutions for each one at a time. P.S. Paypal seems to work fine for me right now.

jrockway 16y ago
Yeah, it's hard to speculate as to what's going on, because we are not Paypal or Mastercard. Maybe someone from Anonymous works there and changed their uplink media to 10BaseT :) So about the SYN floods you see in real life, how do those work? Do routers not do SYN proxying for the servers behind them? Do SYN cookies not work? Are sequence numbers being forged? Is the link saturated? Something else?
- Nrsolis 16y ago
  Routers don't do SYN proxying. SYNs are just regular packets and are passed along to a host. FIREWALLs on the other hand, might use a SYN to make an entry in a table that's used to track connection state. That table might be overloaded by a SYN flood. Same thing applies to load balancers. SYN cookies work just fine at the ENDPOINTs.
tptacek 16y ago
Well, I worked for Arbor, and while it's true that you can readily block packet-y attacks even from a million sources (as long as you can characterize the attack), you're kind of missing 'jrockway's point. During the Olympics in Korea, which Arbor ran DDoS protection for, attackers set up web pages that simply directed hundreds of thousands of computers at URLs on the MSNBC sites. How are you going to filter against that? If you have a botnet, you can saturate a target with totally legitimate traffic. You can talk all you want about anomaly detection and attack characterization, but if your attacker has a botnet that generates totally legitimate traffic patterns, you have a very hard problem to solve. It isn't intractable, but probably will require code changes to your application to address. A lot of anti-DDoS gear that gets sold to enterprises is snake oil. Most companies aren't in a position to filter their own traffic.
- Nrsolis 16y ago
  I'm not going to get into specifics but I'd like to address your points. The problem of distinguishing between legitimate traffic and attack traffic gets harder when the attack starts to look more like legitimate traffic. It doesn't get impossible. You can have a more effective attack if you have a LOT of machines you can use to generate legitimate requests. Of course, after a short while, it's going to be possible to determine which of those hosts are part of the botnet because you can build a history of their requests over time. So it's not an impossible problem to solve; just a hard one. Most enterprises don't really want to pay the money necessary to protect the bulk of their enterprises. I don't think I missed jrockway's point, but I do think you're missing mine: namely, that effective DDoS protection is expensive and time-consuming from a training standpoint relative to any individual company's exposure. That's why we don't see more anti-DDoS features in high-profile websites, not because it's ineffective. Even so...we STILL see lots of packet-y type attacks. It's often overlooked but crafting effective attacks requires really good programming skills. Such skills are often unevenly distributed in script-kiddie kommunities.
  - jrockway 16y ago
    I agree that you missed my point :) My point is, any finite limit can be exceeded. In days of old, it was state tables and file descriptors. Now it's bandwidth. Filtering doesn't matter once the packet has traveled down your finite link to your packet filter. That bandwidth has been used, and denied service to a legitimate user that wanted his packet to go to your server. Mostly, you're right, it comes down to luck. Attackers don't get the chance to do a daily dev / qa / release cycle. They write something, push it to a bunch of users who hate Amazon and Paypal today, and that's the end of it. If they wrote good code, the attack will be good. If they need to tweak something, they missed the opportunity. That's what's saving everyone here -- luck.
    - Nrsolis 16y ago
      Filtering of DDoS attacks is moving into the network. The days of sorting attack traffic at the destination have always been numbered. Current best practice has been to use technologies like FLOWSPEC to get the traffic off the network much closer to the origin.

by Nrsolis 16y ago

jrockway 16y ago

Yeah, it's hard to speculate as to what's going on, because we are not Paypal or Mastercard. Maybe someone from Anonymous works there and changed their uplink media to 10BaseT :) So about the SYN floods you see in real life, how do those work? Do routers not do SYN proxying for the servers behind them? Do SYN cookies not work? Are sequence numbers being forged? Is the link saturated? Something else?

Nrsolis 16y ago
Routers don't do SYN proxying. SYNs are just regular packets and are passed along to a host. FIREWALLs on the other hand, might use a SYN to make an entry in a table that's used to track connection state. That table might be overloaded by a SYN flood. Same thing applies to load balancers. SYN cookies work just fine at the ENDPOINTs.

tptacek 16y ago

Well, I worked for Arbor, and while it's true that you can readily block packet-y attacks even from a million sources (as long as you can characterize the attack), you're kind of missing 'jrockway's point. During the Olympics in Korea, which Arbor ran DDoS protection for, attackers set up web pages that simply directed hundreds of thousands of computers at URLs on the MSNBC sites. How are you going to filter against that? If you have a botnet, you can saturate a target with totally legitimate traffic. You can talk all you want about anomaly detection and attack characterization, but if your attacker has a botnet that generates totally legitimate traffic patterns, you have a very hard problem to solve. It isn't intractable, but probably will require code changes to your application to address. A lot of anti-DDoS gear that gets sold to enterprises is snake oil. Most companies aren't in a position to filter their own traffic.

Nrsolis 16y ago
I'm not going to get into specifics but I'd like to address your points. The problem of distinguishing between legitimate traffic and attack traffic gets harder when the attack starts to look more like legitimate traffic. It doesn't get impossible. You can have a more effective attack if you have a LOT of machines you can use to generate legitimate requests. Of course, after a short while, it's going to be possible to determine which of those hosts are part of the botnet because you can build a history of their requests over time. So it's not an impossible problem to solve; just a hard one. Most enterprises don't really want to pay the money necessary to protect the bulk of their enterprises. I don't think I missed jrockway's point, but I do think you're missing mine: namely, that effective DDoS protection is expensive and time-consuming from a training standpoint relative to any individual company's exposure. That's why we don't see more anti-DDoS features in high-profile websites, not because it's ineffective. Even so...we STILL see lots of packet-y type attacks. It's often overlooked but crafting effective attacks requires really good programming skills. Such skills are often unevenly distributed in script-kiddie kommunities.
- jrockway 16y ago
  I agree that you missed my point :) My point is, any finite limit can be exceeded. In days of old, it was state tables and file descriptors. Now it's bandwidth. Filtering doesn't matter once the packet has traveled down your finite link to your packet filter. That bandwidth has been used, and denied service to a legitimate user that wanted his packet to go to your server. Mostly, you're right, it comes down to luck. Attackers don't get the chance to do a daily dev / qa / release cycle. They write something, push it to a bunch of users who hate Amazon and Paypal today, and that's the end of it. If they wrote good code, the attack will be good. If they need to tweak something, they missed the opportunity. That's what's saving everyone here -- luck.
  - Nrsolis 16y ago
    Filtering of DDoS attacks is moving into the network. The days of sorting attack traffic at the destination have always been numbered. Current best practice has been to use technologies like FLOWSPEC to get the traffic off the network much closer to the origin.