Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a form of victim blaming. We have hoards of people chasing down any developers that have written a fast response UDP protocol and any operators running them. Yet the cause is incompetent ISPs that fail to implement BCP 38.

Even if the crusade to end useful UDP protocols is successful, all of that short-sighted behavior is for nothing because untraceable DDoS attacks are still a problem. Someone with a spoofing capable, 100,000 node botnet (or the bitcoin required to rent on) with or without reflection capabilities is going to be able to saturate 40gb links.

Name and shame ISPs that allow spoofing, stop wasting developers' time with this crap.



This is precisely the point of this article. The only real long term solution to stop large DDoS is to stop spoofing.

The only way to stop IP spoofing is to shame misconfigured networks. For that you need attribution.


Recent HTTP DDoS attacks have shown that there is no dependency on spoofing. The problem will be there as long as there's insecure hardware out there.


The footnote says:

this presentation was prepared before the Krebs On Security DDoS attacks which had a different profile and did not use Spoofed IP addresses. Krebs's DDoS attacks launched by internet-of-things devices were unusually large. Most of the non-spoofed attacks were way smaller. This does not invalidate this talk. Non-spoofed attacks are easier to block - since the source addresses are known. It is also possible to fight and eventually destroy the botnets. This is much harder when the IP's are spoofed.


Once spoofing is solved, you have attribution. Once you have attribution, you can use blacklists, notify ISPs, etc. Cleaning up or isolating infected machines becomes tractable at that point.


Blacklists and attribution do not hold that much value.

Blacklists are only useful to stop only a few DDoS attacks mainly amplified ones like the ones that abuse open DNS resolvers which should be cleaned up on their own, in which case you want to be blacklisting the resolvers not the machines that use IP spoofing since they do not attack you directly.

Many (heck most) DDoS attacks do not use IP spoofing, the recent and largest recorded in history just used 145,000 IP enabled cameras, and this isn't even remotely the largest botnet out there, blacklisting an entire botnet is effectively DDoSing yourself since many of those machines can be on a network with 100's or 1000's of other computers behind the same IP which many of them would be legitimate users of your service.

Notifying ISP's also doesn't help, some ISP's can do some preventative measures but what often they do is simply kill routes to your service, again it would work if you are dealing with some ISP in Slovakia if you aren't serving any customers there (granted they actually respond to you in due time) but if you are dealing with large ISP's there is little they could do and cutting them off isn't an option.

And as for as cleaning and isolating these machines this is laughable, you aren't going to be tracking down customers, even the ISP won't do that for you, and even if it did what would it do send and email that would likely be ignored? Even if you identify customer the IP belongs to it doesn't tell you anything about the device, not to mention that the customer would likely have no capability of cleaning up their machines to begin with.

IP spoofing is a problem because there are currently ways to abuse IP spoofing to amplify the attacks, if you aren't amplifying your attack using UDP protocols you will usually not going to be using IP spoofing in the first place, and automatically banning IP addresses might sound like a good tactic until you are hit with DDoS from a big botnet within your market region at which point you can't use that any more, you might ban a few IP's that seem to have access to excessive bandwidth but even that might be problematic since it can affect legitimate users.


>Blacklists and attribution do not hold that much value

Only because spoofing prevents them from being reliable in any way.

>in which case you want to be blacklisting the resolvers

This approach is idiotic and its the reason these attacks are still a problem. EVERY DNS SERVER can be used if it resolves anything, not just if it's an open resolver. So your blacklist would have to include the root name servers, the .com names servers, etc.

>if you aren't amplifying your attack using UDP protocols you will usually not going to be using IP spoofing in the first place

Completely false. SYN floods and non amplified UDP floods very frequently spoof because it makes pruning attacks upstream by source impossible.

I'm not sure where you got this information, but stop spreading it. It's protecting incompetent network operators, harassing service operators, and doing little to improve the security of the Internet.


Currently DDoS requires insecure hardware.

If it didn't, we're one step closer to fixing it.


This statement is simply not true.


Sorry, missing word.

Currently, DDoS doesn't require compromised hardware, because of spoofing.

But if there were no spoofing, compromised hardware would be a requirement, and we're one step closer.


You need to go one step beyond attribution. You need to make BCP 38 and other 'behave nicely' protocols /requirements/; and to block any ISP that isn't following them.


> It's a form of victim blaming.

1. Victim blaming is when you excuse someone's bad behaviour with the justification that the person(s) negatively affected by it could have protected/tried to protect themselves against it. That doesn't have anything to do with the question whether you should try to protect yourself, or whether you might have some obligation to try and protect others.

2. Based on your logic, what you are doing would be victim blaming: Incompetent ISPs don't perform DDoS attacks, and yet you seem to see some sort of obligation on their part to implement BCP 38 to protect others from that bad behavior of others. The ISP is just as much a victim in a position where they can help and protect others as people running UDP services.


Services used in amplification attacks are victims because their services are being DoS'ed as well and their IPs are the ones that end up on flowspec block lists.

They are also victims from the second order effects of idiots in prominent places claiming that their services are the source of the Internet's woes (e.g. Cloudflare's ridiculing of dns resolver operators).

Your entire second point is nonsensical because they aren't impacted by DoS attacks. They aren't 'victims' in any sense.

Also, people running UDP services cannot stop source spoofed DDoS attacks. You can block the entire UDP protocol today and the problem of untraceable attacks will be just as prevalent tomorrow. The largest attack observed (>1tbps didn't use amplifying UDP services at all).

BCP 38 would end this problem, full stop. ISPs complicit in what amounts to fraud deserve no sympathy. On most routers, ingress filtering is a one line option. Yet people like you promote breaking changes to UDP protocols as a half-baked solution that doesn't do anything to actually stop source spoofed DDoS attacks. It baffles me.


I agree that vilifying UDP doesn't really help anyone, but that's kindof besides the point.

Victim blaming is wrong because you divorce someone's intentional decision to cause harm from their responsibility for the resulting harm. To take the classical example: It's not inherently wrong to tell people that they should avoid situations that empirically have an increased risk of being raped. It's only wrong if you then claim that the perpetrator is not responsible for what they did because the victim didn't heed that advice.

Now, whether ISPs are victims isn't really that clear. First of all, the DDoS packets consume bandwidth, which can cause increased expenses without corresponding increased income. Secondly, at least the very moment you expect them to implement BCP 38, they absolutely are. Implementing BCP 38 is additional work that's only required in order to handle the bad behavior of other people that the ISP is not responsible for, aka harm due to someone else's malicious actions.

But also, the comment that you responded to above was about DNS cache poisoning, not about DDoS. By randomizing DNS transaction IDs, you absolutely can make DNS cache poisoning harder, and I think the responsible thing to do is to protect against that attack vector. ISPs should be doing more to prevent spoofing, but that doesn't mean that it's responsible to leave your users open to spoofing-based attacks that you should be able to relatively easily prevent.


  Implementing BCP 38 is additional work that's only required [..]
That's like saying that the fact that I need to lock my door makes me a 'victim' of the existence of thieves, because otherwise I wouldn't need locks. That's not how the word 'victim' is used, either in general or in this particular context. Insisting on some extremely literal interpretation on the word 'victim' is entirely unhelpful here.


It's victim blaming in the sense that an ISP which should have taken the correct steps to number their endpoints (BCP 38) is not being harassed by companies like cloudflare for DDoSes while DNS server operators are.

"Yeah, this guy stole your car by asking nicely for an extra set of keys from the manufacturer. Even though the manufacturer shouldn't have allowed him to do get a key, we're holding you responsible since you technically could have kept your car in a locked garage."

Also, the gp was taking about cache poisoning, but it was only exploitable in the presence of spoofed IPs.


Using this definition, another example of victim blaming is telling children to look both ways before crossing the street.


No, it's telling a child that has been hit by a car repeatedly to look both ways next time, when you know it would definitely reduce their chance of getting hit.

Performing edge ingress traffic filtering of known-trunked node addresses (i.e. BCP 38) has a high likelihood of reducing the effectiveness of DDoS attacks.


No, the equivalent would be telling children they can't have toys because someone might steal a toy gun from them and use it to hold up a bank.


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.


No, 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.


DNS 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


That 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?


> the crusade to end useful UDP protocols is successful

What? What crusade? I love UDP, use it every chance I get.

Who is "crusading" to end UDP on the Internet?


It's fine to have a public UDP server on the internet. Just make sure it can't be used to amplify/mirror attacks.

QUIC uses tokens for example. https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...


That's not even enough. The token generation can be used as an amplification vector.

That's why this approach of attacking UDP instead of spoofing is misguided.


All the orgs suffering from amplification attacks from services using UDP. DNS, NTP, chargen, etc.


Is udp/chargen really a useful publically exposed protocol? Does it provide a benefit over tcp/chargen?

Most of the fine people running chargen servers seem to be running the server from Microsoft services for UNIX package which is configured to send giant fragmented responses, and then they have a firewall that drops the first fragment. Thanks a lot guys.


Those organizations are unfortunately confused and are not directing their frustrations towards the real cause (ISPs which allow spoofing).


... do people still use chargen? Are there seriously still chargen servers in the world?


Oh man they are rare but they are definitely still out there. Think printers from the 90's that came with chargen & usually telnet enabled by default, and for some reason are publicly accessible.


> Someone with a spoofing capable, 100,000 node botnet

Does not exist and if it did, it's the unspoofed traffic you should be worried about.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: