3 ms·
The problem needs fixed from both ends. Developers that write and maintain programs with bad defaults should be named and shamed as well. Their software has a s
by Sanddancer 10y ago
The problem needs fixed from both ends. Developers that write and maintain programs with bad defaults should be named and shamed as well. Their software has a security flaw that allows these problems to be exploited. Back in the 90s, the default configuration for most mail servers was to allow relaying from all and sundry, until the spam problem made people realize that an open relay was a bad thing that would be abused by malicious actors. Saying developers' time shouldn't be "wasted" on this is like saying automakers' time shouldn't be wasted on airbags and people should just drive better.
- hueving 10y agoNo, this is a completely false equivalence (the spam comparison). An open relay is the equivalent to ISPs allowing people to put whatever IP they want in the header. People are operating completely sane services and anti-UDP warriors suggesting they change them because they appeared in a ddos is idiotic and harmful to the Internet. You can completely eliminate all UDP services and the untraceable DDoS problem won't go away, you've just eliminated some amplification avenues. The 1.5tbps attack didn't even use UDP so this "solution" is dead in the water and whoever is pushing it is misinformed. Do you realize that every public DNS server in the world (root servers, recursive revolvers, Google.com NS servers, etc) can be used in an amplification attack? According to you we should name and shame every DNS developer, domain name owner, and operator. We essentially couldn't have functioning DNS if we operated under your plan to 'fix this from both ends'. I suggest you read up on amplification attacks because I think you misunderstand how they actually work and think there is a way to 'configure' your way out of them. This problem absolutely should not be "fixed from both ends". The right hand side (eliminate all amplifying UDP protocols) is massively disruptive (bye bye DNS) and doesn't actually fix the root issue (attackers just spoof TCP instead with a reduced amplification factor). The left hand side (BCP 38) requires fewer participants (ISPs vs server operators) and it completely solves the problem even without the slightest adoption of the stupidity on the right hand solution. If you have ever suggested that a dns operator disable recursive resolving, you are perpetuating the problem by making people participate in an idiotic ritual that does almost nothing to improve the security of the Internet. It's the equivalent of restaurants not serving glasses of water to reduce the water shortage while farmers grow rice patties in a desert with essentially unlimited water rights.
- fanf2 10y agoDNS servers have in fact been modified to make it much harder to use them in amplification attacks, by adding response rate limiting - see http://www.redbarn.org/dns/ratelimits http://www.redbarn.org/dns/ratelimits
- hueving 10y agoThat does much less than you would think. Attackers just spread the packets out over more DNS servers and still get the same amplification factor. See why trying to 'fix' this at the DNS level is stupid?