4 ms·

Does this mean that proper egress filtering would solve this? Because that seems like a more feasible solution. Having a bunch of large ISPs and datacenter oper

by pedrocr 14y ago

Does this mean that proper egress filtering would solve this? Because that seems like a more feasible solution. Having a bunch of large ISPs and datacenter operators block outgoing packets with sources outside their own IP ranges sounds much easier than having many more home users reconfigure their routers.

peterwwillis 14y ago
Home users reconfiguring routers would not really resolve the issue, but yes, egress filtering would be effective in theory. Unfortunately that's a maintenance nightmare and costly and there's no incentive to do it. Besides closing down open resolvers, the real solution to this particular DDoS lies in the DNS protocol. The attack's practicality comes from RFC 2671. If that were amended to either return the maximum size of a packet to 512 bytes for UDP packets (but allow TCP packets to be any size), there would be no benefit at all to this attack. For existing resolvers this would require either DNS services being upgraded or firewall rules being put in place to limit UDP packets on port 53 to 512 bytes. Shutting down open resolvers is about as much work, but unfortunately still leaves the attack possible because it's inherent to the protocol.
bodyfour 14y ago
Yes, egress filtering is the only solution. I personally think that the focus on open recursive resolvers is misplaced. All authoritative nameservers have to be "open" to queries for the domains they serve. So instead of the amplifying by doing: $ host -t any random-site.com. ns1.example.org. you can just as well do: $ host -t any example.org. ns1.example.org. Even if all nameservers supported good per-IP throttling (far from the case), there are still enough valid nameservers on the internet to stage a decent amplification I think. So once all of the open resolvers are shut down, the DDoS pricks will just target more important infrastructure to accomplish the same goal. It might be that we'll have to switch all authoritative DNS requests to be TCP-only but I can't imagine what a pain that transition will be. The worse news is that egress filtering has been something we've clearly needed for 15+ years and it doesn't seem we've gotten very far. Part of the problem is that these amplification attacks usually don't cause much pain to the real source of the attack. Plus since it's very hard to tell where the true source is, they don't even get publicly shamed for it. It's so much easier to point a finger at the middle man in this case. For egress filtering to be effective protection, it needs to cover nearly all of the network. As long as a botnet can get their hands on a decent amount of unfiltered bandwidth to amplify it's game on. I'm not optimistic.
- ChuckMcM 14y ago
  For egress filtering to be effective protection, it needs to cover nearly all of the network. As long as a botnet can get their hands on a decent amount of unfiltered bandwidth to amplify it's game on. The question is can it be done without the ISP's co-operation. For example, I've got transit service from XO (a Tier-2 provider) and they could conceivably port-mirror the inbound side from my connection, do a source IP check on packets, (even statistical would be fine) and then raise a flag if anything came out smelly. Since we're comparing a 32 bit number, and we can construct a logic gate which defines 'legal' values for that number, even a modest FPGA implementation could just sink (equivalent to /dev/null) all traffic and generate a pulse when the match failed. Its been a while since I was in a company building DSLAMs and edge gear but up to a 10Gbit pipe that isn't a killer problem.
  - bodyfour 14y ago
    Near the edge, it's just a matter of using the same silicon you have for routing and ask the question "would I have routed a packet to this claimed source IP down the pipe I'm receiving it from?" In cisco-speak this is "ip verify unicast source reachable-via rx" Once you move further towards the core, the problem becomes exponentially more complex. Asymmetric routes are common, so it's not weird at all to get a packet handed to you from a different ISP than you would reply to it. Any filtering there would break a large percentage of valid traffic. The problem is that there are a hell of a lot of "edges", you need nearly all of them to be fixed, and they don't have the motivation to do much about the problem.
    - vy8vWJlco 14y ago
      If anycast is a valid use of IP, why isn't source spoofing at the edge? Spoofing can be used for load balancing too.
- peterwwillis 14y ago
  It's not a solution at all because it will never happen. You'd need every network on the internet to spend money and time to fix a problem that nobody is holding them responsible for and they have no monetary incentive to fix. The solutions are clear. They happen to be doing the laziest of them which is close the open resolvers.

by pedrocr 14y ago

peterwwillis 14y ago

Home users reconfiguring routers would not really resolve the issue, but yes, egress filtering would be effective in theory. Unfortunately that's a maintenance nightmare and costly and there's no incentive to do it. Besides closing down open resolvers, the real solution to this particular DDoS lies in the DNS protocol. The attack's practicality comes from RFC 2671. If that were amended to either return the maximum size of a packet to 512 bytes for UDP packets (but allow TCP packets to be any size), there would be no benefit at all to this attack. For existing resolvers this would require either DNS services being upgraded or firewall rules being put in place to limit UDP packets on port 53 to 512 bytes. Shutting down open resolvers is about as much work, but unfortunately still leaves the attack possible because it's inherent to the protocol.

bodyfour 14y ago

Yes, egress filtering is the only solution. I personally think that the focus on open recursive resolvers is misplaced. All authoritative nameservers have to be "open" to queries for the domains they serve. So instead of the amplifying by doing: $ host -t any random-site.com. ns1.example.org. you can just as well do: $ host -t any example.org. ns1.example.org. Even if all nameservers supported good per-IP throttling (far from the case), there are still enough valid nameservers on the internet to stage a decent amplification I think. So once all of the open resolvers are shut down, the DDoS pricks will just target more important infrastructure to accomplish the same goal. It might be that we'll have to switch all authoritative DNS requests to be TCP-only but I can't imagine what a pain that transition will be. The worse news is that egress filtering has been something we've clearly needed for 15+ years and it doesn't seem we've gotten very far. Part of the problem is that these amplification attacks usually don't cause much pain to the real source of the attack. Plus since it's very hard to tell where the true source is, they don't even get publicly shamed for it. It's so much easier to point a finger at the middle man in this case. For egress filtering to be effective protection, it needs to cover nearly all of the network. As long as a botnet can get their hands on a decent amount of unfiltered bandwidth to amplify it's game on. I'm not optimistic.

ChuckMcM 14y ago
For egress filtering to be effective protection, it needs to cover nearly all of the network. As long as a botnet can get their hands on a decent amount of unfiltered bandwidth to amplify it's game on. The question is can it be done without the ISP's co-operation. For example, I've got transit service from XO (a Tier-2 provider) and they could conceivably port-mirror the inbound side from my connection, do a source IP check on packets, (even statistical would be fine) and then raise a flag if anything came out smelly. Since we're comparing a 32 bit number, and we can construct a logic gate which defines 'legal' values for that number, even a modest FPGA implementation could just sink (equivalent to /dev/null) all traffic and generate a pulse when the match failed. Its been a while since I was in a company building DSLAMs and edge gear but up to a 10Gbit pipe that isn't a killer problem.
- bodyfour 14y ago
  Near the edge, it's just a matter of using the same silicon you have for routing and ask the question "would I have routed a packet to this claimed source IP down the pipe I'm receiving it from?" In cisco-speak this is "ip verify unicast source reachable-via rx" Once you move further towards the core, the problem becomes exponentially more complex. Asymmetric routes are common, so it's not weird at all to get a packet handed to you from a different ISP than you would reply to it. Any filtering there would break a large percentage of valid traffic. The problem is that there are a hell of a lot of "edges", you need nearly all of them to be fixed, and they don't have the motivation to do much about the problem.
  - vy8vWJlco 14y ago
    If anycast is a valid use of IP, why isn't source spoofing at the edge? Spoofing can be used for load balancing too.
peterwwillis 14y ago
It's not a solution at all because it will never happen. You'd need every network on the internet to spend money and time to fix a problem that nobody is holding them responsible for and they have no monetary incentive to fix. The solutions are clear. They happen to be doing the laziest of them which is close the open resolvers.