Hacker News Reader

Comment by stingraycharles | Hacker News Reader

Since this is HN, it’s 2021 and DDoS’es are still a thing: why are they still a thing? Is there some fundamental “anonymity” to the Internet that makes it impossible to structurally prevent DDoS attacks? Apart from CloudFlare-like approaches, are there any R&D in the pipeline that may kill this type of attack once and for all?

To me it’s incredibly infuriating to see the damage that still happens with these extremely simple techniques. Will it ever end?

Edit: to elaborate, I know that there are tons of insecure Internet devices and whatnot. I’m more interested in standards, and core protocol improvements that can fundamentally rid the world of these types of attacks.

View on HN

DDoSes come from asymmetries in the difficulty of making a request and providing a response.

For example, a classic is the SYN flood. In this, the attacker makes many requests to open TCP connections (with a SYN packet) but does none of the rest of the handshaking. The server does the initial bookkeeping for setting up TCP connections, before eventually timing out and freeing the resources. The SYN packets are very cheap and easy to form (and the attacker can immediately free all the resources after firing them away), but the connection state information is a little bigger. This asymmetry builds up, making the server overloaded.

I believe that asymmetries in resource consumption are, at some point, unavoidable.

You also asked:

> are there any R&D in the pipeline that may kill this type of attack once and for all?

Note that DDoS attacks are a class of attacks. They're a description for a broad genre. It's kind of like how "bronchitis" actually just means "enflamed bronchial tubes" - it's a symptom, not a cause. Even if we permanently defeat SYN floods, there are a gazillion other DDoS-type attacks (UDP flooding, messing with ARP tables - its an almost endless list).

Yes, but these attacks are actually easy to detect if they all come from the same IP. Sending packages from a lot of different IPs actually is expensive.

That’s.. not what a Distributed Denial of Service does. They come from thousands of IPs.

That's the first 'D' in DDoS - distributed.

Most robots participating in this are unwitting. It's incredibly unlikely someone is paying... even with stolen funds.

Often a sort of malware that more or less sits dormant until command/control sends a target to attack

edit: To the individual machine, not a lot. The sum total is where the denial of service comes in - everything has a tipping point.

These days even peoples iot washing machines are being found to be participating in ddos attacks.

It's not expensive if you have a botnet, reflective attacks or L7 attacks. It's also not just one type of attack (overloading the target), the only thing in common is that it's a denial of service, and if you distribute it amongst many sources it's a distributed denial of service.

Distributed can mean different things, especially if you can spoof addresses, in which case you can do fake distribution (causing src based filtering to be useless). If you know it's just a single bad AS that is doing it, then you can block the AS, but if it's distributed amongst multiple AS'es that's harder. Same with reflective attacks, the source of the traffic might not be the source of the attack and might be a legitimate source which you cannot block because your internet wouldn't work anymore (i.e. when it's DNS servers or NTP servers doing the reflection, or a GCN address which would completely take an ISP's section offline).

It's not as simple as sending a large volumetric load from A to B. It used to be that way a decade ago and it can be effective today, but it's not the only way it's happening.

The attacks come from (up to) millions of different ip addresses, each one a different machine and often on a residential network.

This is the problem with botnets - all the connections look like real traffic at first glance.

The src ip can be spoofed and randomized if you don't care about getting the response (and to some degree, you care more about not getting it)

Why is this resource asymmetry unavoidable? It seems reasonable that a new protocol could solve it.

Consider augmenting TCP with a "pre-SYN" and "pre-SYNACK". Suppose you have to send a pre-SYN which declares your identity ip X. Then the server sends to X a "pre-SYNACK" encrypted message containing (X, t = timestamp()) based on a server-only key.

Afterwards, X may send the server a SYN for real. But then the server only allows a timeout of length, say, timestamp() - t, as of receiving the SYN back to maintain bookkeeping.

As benevolent cooperating clients, we may want to ourselves wait an exponentially-backed-off amount between receiving the pre-SYNACK from the server and sending our SYN back (such that in log-many rounds we establish our conn).

Then any malevolent actor must then keep a resource on X alive for at least half long as the server does (since the server requires zero bookkeeping after firing off the pre-SYNACK).

Edit: this is simplified, you could just own a machine at X which is far away from the ddos'd server and then have your botnet spoof requests from X; by augmenting this procedure with even more preamble rounds you could verify how long communication takes between the server and client X and subtract that out.

This method is basically already in use for DOS mitigation using a technique called a SYN cookie. But as the parent said, there is a huge spectrum of different ways to produce a DOS and so there is no single method of addressing them. The problem tends to be much harder as you get to higher levels, for example, requesting things from an HTTP server - there are mitigations available there as well such as Cloudflare's approach of capturing DoS like requests and subjecting them to CAPTCHA, but once again no one size fits all.

I guess the problem is "simply" the use of these resource-asymmetric protocols. As a server-owner, if there was a robust alternative protocol which ensured resource symmetry, wouldn't you be naturally incentivized to adopt it and reject all asymmetric ones?

It still feels like there's a way of specifying a protocol (which of course would need to be adopted) where (1) authentication is a first-class entity (2) all non-authenticated requests enforce resource symmetry at the protocol level, while still allowing asymmetric work to be done (after a resource-symmetric auth).

Edit: augmenting the rough outline of what I originally proposed you can essentially require an arbitrary amount of proof-of-work, however useless, on the requester side (e.g., literally request a nonce such that the hash of the packet is below some value). Since only auth needs to be symmetric the overhead doesn't seem too bad.

If we do some form of authentication it seems likely that the receiving side needs to do some kind of computation. What if I just sent garbage? Garbage is easy to create but the receiver needs to do some work to figure this out.

Hrm, I don't think you're engaging with the spirit of my proposal, which does require resource-symmetry to establish auth in the protocol.

I admit I haven't specified a full counterfactual protocol here, but see my edit for a rough outline of how you wouldn't just be able to generate garbage.

You said "I feel that..." so I suppose you're an mbti 'F' - excellent choice! But I feel you'll work on this idea for a bit and then throw your hands up.

The symmetry is irrelevant when the attacker has stolen someone else's resources. Granny may notice her computer is even slower than usual, what then?

If we stipulate a future where attackers cannot steal other people's resources, then work backwards, I can't see any internet with any degree of freedom.

It would be necessary for every system to be 100% watertight. Mathematically-provably so. Spectre/Meltdown demonstrates that this isn't just formal proof about software. Eradicating the pathways to ddos is an intractable problem. You'd need to seriously consider preventing all network access except through certified and regulated kiosks to which users do not have direct physical access. Like, hand a librarian a piece of paper with a URL on it and get a print out.

I'm not expert, you shouldn't have confidence that I'm correct.

On your somewhat off-topic meta-comment about my lack of due diligence: lucky for me I don't need to break out Coq to validate an RFC draft to post a comment on HN, which despite my mushy-gushy feelings has resulted in a productive, curious, and educational discussion, at least for me!

On the point of stolen resources, true, the attacker doesn't care, but I think if we get to the level of resource symmetry in a protocol we've effectively throttled a class of attacks. There are only so many grannies whom a given attacker can pwn. Symmetry is relevant because it makes it that much harder and that much more demanding of your botnet. Besides, like you mention at the end of your comment demanding some kind of additional Byzantine DOS-tolerance is likely too hard of an ask.

> There are only so many grannies whom a given attacker can pwn

And at how many millions does that number start to taper down? Plus, zombie devices of all sorts are being used of course, so while there certainly does feel like some sort of resource-symmetry scheme would be, if nothing else, a satisfying solution, its hard to see logically how that would really help all that much for these sort of attacks.

Yes, I think there is a lot of room for better protocols that reduce the asymmetry. A lot of our internet is built on protocols that assumed good behavior, since back in the 70s and 80s and even 90s that was plausible.

But I don’t think we will ever get to a point where we bring that asymmetry to zero. We often really do want complex tasks to be done by a server in response to a simple client request.

Software people rarely put this asymmetry in the front of their minds during design, so I think its something we will continue to see in new systems, even if we (magically) universally adopted better versions of the old, too-trusting protocols.

Not to mention, implementation of new protocols is one thing, adoption of such protocols is another - I would dare say the harder part of the two. If you are required to serve a population that won't keep up, its an uphill battle.

The problem with the proof-of-work concept, which is raised frequently, is that the vast majority of DoS traffic today comes from attackers that don't pay for their work. They're using botnets of compromised devices. So all a PoW requirement tends to do, in practice, is make their botnet run a little bit warmer.

Sure, you could crank up the difficulty until it makes the cost of the attack too high, but then all your users will get mad - that's basically what CloudFlare does and it attracts non-stop criticism.

Another way we could put this is that asymmetric work requirements are basically the definition of a network service. If we require the client to do enough computation that it expends as many resources as the backend, in a lot of ways there's no reason for the backend to even exist! People will be prone to migrate to a peer-to-peer or desktop solution instead of using your very very slow website.

Or a little more of a hot-take: the idea of proof-of-work requirements to prevent abuse of systems with asymmetric workload is almost as old as network systems. A prominent example is "hashcash" for email, introduced 1997. These have so routinely failed to gain any traction that we need to consider that the proof-of-work idea tends to come from a fundamental misunderstanding of the problem. Increasing the cost to the attacker sounds great until you consider that in most real-world situations, the attacker's budget is effectively infinite... because for a couple decades now these types of abuses have originated mostly from compromised systems, not from systems the attacker controls. Proof-of-work requirements still reduce the volume the attacker is capable of, but trends like IoT and the general proliferation of computing mean that the attacker's potential resources continually expand. More difficult PoW, in most cases, will only cause the attacker to make a relatively one-time investment of obtaining a new set of compromised resources (new botnet, new exploit to distribute existing botnet, etc). The increase in "per-item" cost to the attacker tends to never materialize.

> Sure, you could crank up the difficulty until it makes the cost of the attack too high, but then all your users will get mad - that's basically what CloudFlare does and it attracts non-stop criticism.

This is interesting, where can I read more about both sides?

I do think you hit the nail on the head here, with resource symmetry being the center of the give-get here and making the botnet run warmer is the win (because it requires larger botnets, because it's more detectable, etc.). I think that this might make me upset as a client, but if it's economically advantageous for the server, then I'd still tolerate it to get the server's content.

I think that's why you need auth to be first-class in such a protocol. Yes, auth might be painful and annoying and require that your browser essentially mines hashes for a while on connection setup, but then after that presumably your website would be as fast as usual, and perhaps there might be a way to safely cache such authentication with a lease for valid users. Perhaps this kind of approach is too anti-internet, though, since it basically says that to do any useful backend work you need to be a registered user for some backend service.

The server would still need to track some state.

Worse, the cost is another round trip delay. That's a problem for anyone with a high latency connection.

Right, under the previously unspecified constraint that you need a response in one round trip I agree there's a natural resource asymmetry.

You're too lazer focused on syn attacks, there are countless others. What it boils down to is the sheer size of the botnets. You stop syn? Great, I'll make it UDP with a max payload and send it from 500k hosts. You will eventually fall over if my botnet is big enough.

> Why is this resource asymmetry unavoidable? It seems reasonable that a new protocol could solve it.

Sending a HTTP GET is easy, but the server has to process the request and send the whole page... think a few tens of bytes of a request, and a whole webpage in a reply.

The server has to do an encryption and a decryption. A legit client has to do the pre-SYN dance. In your protocol, I don’t spam pre-SYNs; I spam SYNs with fake tokens. Thus I send only the same number of packets as before, but the server has to do these decryptions! Or I can mix and match spoofed SYNs with pre-SYNs and legitimate SYNs in whatever way finds the best leverage.

Your pre-SYN design is very close to the design of TLS 1.2, by the way. That’s how I knew how to attack it. TLS is attackable in just this way: open a real connection, then lots of fake handshake requests. No crypto required to generate them, but the server has to do lots.

Now that said, BCP 38 would go a LONG way towards addressing this. There will come a day when the well-behaved networks decide they’re not accepting traffic from non-compliant peers.

mind you BCP38 will do nothing against legitimate IP's used in DDoS attacks. (which are more and more common because of large botnets thanks to IoT devices and their abysmal security).

Are there legitimate reasons to spoof an IP?

You do bring a good point. Maybe outlandish, but see my sibling comment (https://news.ycombinator.com/item?id=28578832) where the server overhead for rejecting invalid packets which the attacker made for free goes down to performing a hash.

> Why is this resource asymmetry unavoidable? It seems reasonable that a new protocol could solve it.

There's some sense in which a little asymmetry is unavoidable -- a malicious attacker can always just send whatever bytes they want over the wire, and a server on the other end with any practical purpose must at a minimum receive each of those bytes AND perform some operation equivalent to determining if any more work needs to be done.

To the extent that any real work or state management needs to be done by the server, the only way to avoid much asymmetry is to use a protocol forcing the client calls to be artificially more expensive before the server will agree to respond.

Yes and... a botnet controller simply doesn't care anyway. She or he isn't spending their own resources.

So a bit like a proof of work concept for packets? Doesnt sound like such a crazy idea to me

The fundamental asymmetry is bandwidth. If you can overwhelm my incoming connection, I can't do much useful work.

I've got to pay for capacity, but a bot net controller doesn't need a whole lot of bandwidth to trigger a lot. If you control 10,000 hosts with 10Mbps upload, that's 100Gbps; and botnets are growing as are typical upload bandwidths.

And that's without spoofing and amplified reflection attacks. Some of the reflection attacks have high amplification, so if you've got access to 100Gbps of spoofable traffic, you can direct Tbps of traffic.

If my server has a 10G connection and you're sending me 1Tbps, there's just no way I can work.

Syncookies work pretty well for TCP, I had run into some effective SYN floods against my hosts I managed in 2017, but upgrading to FreeBSD 11 got me to handling line rate SYNs on a 2x 1Gbps box and I didn't take the time to test 2x10G as I wasn't really seeing that many SYN floods. I don't recall any more effective SYN floods after that point. We didn't tend to have dedicated attackers though; people seemed to be testing DDoS as a service against us, and we'd tend to see exactly 90 or 300 seconds of abuse at random intervals.

Our hosting provider would null route IPs that were attacked if the volume was high enough for long enough. Null routing is kind of the best you can hope for your upstreams to do, but it's also a denial of service, so there you go.

> Why is this resource asymmetry unavoidable? It seems reasonable that a new protocol could solve it.

Protocols are trying to avoid this problem. For TCP there exist SYN cookies to reduce the amount of work a host has to do. For QUIC retry packets exist, as well as anti-amplification rules. However applying those mechanisms also has a cost. One is you still get computational cost not to zero, since you still have to receive and reject packets. And the other cost is now your legitimate users are experiencing a latency penality due to potentially requiring another round trip.

The latter means you don't want to make those mechanisms the default, but rather use them selectively in certain situations.

The former means even if you apply countermeasures you are not fully protected. If you get flooded purely by the bare amount of packets and the system stalls just from handling them, all the higher level mitigations won't work very well anymore. That's the difference between a DDoS and a DoS - the DDoS might not even need an asymetry in cost, it just brute-forces the system down.

It seems like requiring the client to provide proof of work (e.g. Hashcash[1]) could be an easy way to help reduce the asymmetry.

[1] https://en.wikipedia.org/wiki/Hashcash

Seems like that's another benefit of IPv6.

Without needing NAT everyone can have their own IP address and biz will be able to ban individual machines instead of some giant NAT Network because one host using that IP address is compromised.

Doesn't it also mean addresses serving as the source of an attack become more disposable?

The hackers still have to compromise the host right?

if you are sending packets but don't care about the reply, you can spoof the from header.

The other form of ddos is udp amplification. you send a packet to a legit host and spoof the target ip as the from ip, the reply goes to your target and bam, ddos.

this could be solved in ipv6 by implementing ipsec in AH mode.

Yep but that never opens a full connection. You can filter on hosts who dont respond to an ACK after a certain amount of fails.

Most machines don't have UDP services open to accept packets.

all machines need udp opened to get response from ntp and dns.

moving these to tcp would actually seriously help with filtering ddos, but good luck.

Yeah but as I understand it, Port 22 doesn't just sit open on a machine waiting for any connection.

Running a quick netstat -p udp doesn't show any UDP entrys with LISTENING status.

A trillion hosts.deny entries?

How many hackers would it take to compromise a trillion hosts?

the hackers are better than I thought!

Most devices are configured to randomize part of the v6 address for privacy so you can no longer see more info than ipv4 would show.

Ban the prefix instead.

> Note that DDoS attacks are a class of attacks. They're a description for a broad genre.

While they may be a class of attacks, I would describe all of them as undesired requests. Sometimes, with some clever protocol design, you can, in fact, mitigate a whole class of problems.

But why can't you just block the offending IPs in iptables?

My router has some SYN flood protection is that useful at all?

High level these kind of attacks must be easily fixable, just remove the offending IPs of the countrys internet for a set amount of time... easy peasy.

The first 'D' of DDoS means distributed. Which means it is so broad. If you unplug yourself from the internet, yes you can block them... Also blackholing them like this won't be useful. Since attack is comming from multiple zombie clients (hundreds of thousands) and current internet structure is using IPv4 with CGNAT, you would block tens of millions of legitimate users at the expense of a small percentage.

Edit: Also, even though you blackhole them within your iptables, packages are still coming to you (routed) and filling up the bandwidth whether you like it or not.

And you pay your peers according to bandwidth you use. (eg. bytes in and out per month)

So, a proper solution is to use globally distributed system to broadcast specific routes so the attack gets stopped even before it reaches you. (eg. through their own ISP's route table blackholing your routes) But that means legit users from that ISP wont be able to access your network at all...

It's not that simple. Collecting 250Gbps of uplink is not that simple. The attack vectors are simple in principle, but carrying it out...

Here's next year's fine vector: You write a nice iphone or android app and persuade fifty million people to download it. But unknown to the owners of those mobile phones, it also has a hidden evil feature: If the phone has the screen off, is charging and is on a WLAN, then it can participate in a DDoS if you direct them to. The phone's owner won't notice, but if enough phones are charging and each can contribute 2Mbps of upload, you could collect 250Gbps at the target.

And tracing it back to that app will be very difficult.

Why would it be so hard to trace back?

It wouldn't be hard.

If you can examine traffic on a network from which attacking traffic originates, you can see that it's coming from a phone.

Then you could see which app by either limiting or deleting apps one at a time, or you'd need two sources, then just see which apps the two sources have in common.

When you have 250 Gbps, it'd be simple to capture a fraction of a second's worth of traffic, then write a script to fire off emails to network admins of every IP involved and ask them to look in to it. Out of hundreds or thousands of messages, you'll get a few humans who'd look in to it and would be helpful.

I should know, because I've done this very thing.

If your nontechnical neighbour's ISP calls and says "you're participating in a DDoS, will you please find out which device behind your NAT is sending the traffic and fix whatever the problem is", do you think your neighbour can fix it in five minutes?

They could remote stop the router?

A responsible ISP will block the user but this means the user is going to call the helpdesk which costs money.

An irresponsible ISP will stall the process to see if you give up, which is free.

They could, which mitigates the attack without locating the actual source (that is, your app) and leaves you free to use the same app again for another attack next week. Maybe even taking care to use a different subset of the devices where your app is installed.

because nothing says you have to include your real ip in the src header of the ip packet if you don't care about the reply.

rp_filter (reverse path) does. Problem is it's a leaf(ish) router solution: if the src ip is not in the locally attached subnet, drop it. Not every isp sets this up though, for whatever reason.

limiting your spoofability to ips by the same isp doesn't help, especially since many will have multiple subnets so it won't help your target's ability to filter the packets out

What's the solution to this? If millions of devices are each sending 2Mbps to some target, what can the target do? It doesn't sound like there's a program that would be able to identify something so diffuse.

remote triggered blackholing the networks from which the ddos comes is very effective for small DDoS's. but its a very crude methods that drops entire /24's from being able to reach you.

this doesn't work for massive ddos's.

I think you understand why edpnet.be has problems now.

What they usually do is try to write packet filter rules and drop packets as close to the millions of origins as possible, plus call the networks where the sending devices are and say things like "could you please call your customers and tell them to unfuck their {phones,dsl routers,…}"

It is intrinsic to the design.

The open nature of the protocol carries with it an implicit trust. Any client may join and speak to any other client and be heard. It is a social contract, just as we have "in real life."

Imagine someone knocks on your door. You can choose to not answer, but even considering the choice costs you cognitive bandwidth. As long as you're within earshot of your door, a knock will cost you attention.

We have solutions all across the spectrum, from putting up a "no soliciting" sign, to arresting bad actors. But what if you have a riot outside your front door (a DDoS)?

The rioters you mention are remote teleconference zombies. There are those that can stop them with only relatively small effort - ISPs and less directly transit providers, but it is against their interests.

Perhaps a better analogy may be robocalls with spoofed numbers.

The abuse system would need to detect that these ip addresses are sending a sustained amount of traffic abnormally and deny them.

I think part of the difficulty is that just receiving or denying the traffic can consume all of your resources. It really has to be denied at the ISP levels before it reaches your router.

(2015) Imgur was being used to create a botnet and DDOS 8Chan : https://news.ycombinator.com/item?id=10256942

It's not that easy to get 50 million people to download your app and if you pulled that off there are more profitable things you could do.

Why limit it to DDoSing? It could be just one feature, but an important one.

Toolbars did just that and been used for many "evil" things..

My point exactly.

These things are easy to do in principle (most readers here can write that evil payload, or learn how to do it quickly) but there are real practical challenges to getting the code to run on millions of strangers' computers/phones/dsl routers, so most of the code that's actually deployed that widely is beneficial. Happily.

Unpopular opinion and will get downvoted:

This is why the appstores do reviews etc. these kind of things dont happen because of that

... except that they most definitely do still happen in spite of that.

But yes, they do tend to mean less obviously-just-malware apps.

Sure, the official App store can do that but that does not mean the user should not have the option to side load apps.

Getting this kind of behaviour past review is simple, and malevolent apps do happen.

Google has a clever technique for detecting them (after review) and it's good, but slow. It has a decent chance of detecting the app after a few attacks, and works by analysing which apps were installed on phones just before a factory reinstall.

On iOS the OS does not allow apps to do this, you basically can only use the OS APIs to do networking in the background so clever tricks are right out, and it is throttled.

Google/Apple will catch you in hours/days and all your work goes down the drain. Also its hard to get 50M downloads, not worth the time.

There is already an established economy of botnets. They work like this:

1. There is a hacker group (usually ex-USSR or China) that is actively monitoring 0 day vulnerabilities. They usually target internet connected devices which are from companies that dont give a damn about updating them after they are released. This is the case for most budget routers, "smart" things (lamp, frigde, vacuum, doorbell,..).

2. If they find a nice one (e.g. one that affects millions of shit-tier $40 routers), they set up port scanners and infect as many as they can.

3. Rent the botnet on darknet sites, there is already an established pricing for them, for example $1000 for 1 hour of 1000Gbps DDOS. You just pay them in crypto and tell what to attack.

> Google/Apple will catch you in hours/days

Tell that to the Hola and Honey extensions. They're known to be a botnet and for this kind of abuse for years yet you can still find them everywhere in the App/Play Store...and _so_ many tech related youtube channels keep advertising for them blindly, it's ridiculous.

I had heard that Hola was possibly some kind of malware, but this is the first I'm hearing that Honey (I'm assuming we're both talking about the coupon-code extension) is like that too.

I just figured Honey was kind of like spyware, collecting information about what people bought online.

Honey redirects their users' traffic to their own ad-identifiers and replaces them in the codes/script tags. That's how they make money. Personally this kinda classifies as a CnC because they can redirect traffic at demand for websites remotely.

If you look at the extracted codebase, it reads like a malware implant that's designed to give some blackhat traffic for their own army of clickbots.

Hola on the other hand is basically an origin obfuscator, and they route traffic through other browser extension instances.

That's how they "unlock" websites and what their proxy feature is about. Note that this is an http proxy only, and hola sniffs all local passwords and cookies, too.

So they can abuse your user account for lots of stuff without your consent, and they did that in the past, too. (A search for DDoS and hola reveals lots of incidents and news reports)

While I agree that Honey is borderline spyware and extremely privacy invasive, that's a little different from claiming it is malware facilitating DDoS attacks.

Echoing the sibling comment, I knew Honey was WAY-too-good-to-be-true from the seemingly infinite marketing resources being poured into it - but I had no idea it was a botnet (?!). Further insight highly appreciated!

Simple - egress filtering:

https://en.wikipedia.org/wiki/Egress_filtering

If every large network operator did this, then shutting down abusive hosts used to generate the kind of traffic needed for attacks like these would be possible.

You'd make a list of all the IPs for each large provider from which excess traffic is coming, and you'd send them to each large provider, and they'd either block the IPs completely (requiring customers to fix their compromised machines before they could get back on the Internet), or at very least they would block all traffic to the destination of the attack.

Some silly people think this isn't possible, but if large providers are forced to do it, then they can easily tell smaller ones they'll be blocked if they don't also do this, and so on, and we'd have a slightly more responsible Internet again.

Too bad we have shitty, huge companies that don't care about doing the right thing :(

> Some silly people think this isn't possible, but if large providers are forced to do it, then they can easily tell smaller ones they'll be blocked if they don't also do this, and so on, and we'd have a slightly more responsible Internet again.

> Too bad we have shitty, huge companies that don't care about doing the right thing :(

There's no call to be dismissive of anyone who disagrees with you; maybe you're "silly" for believing that companies will threaten each other for no reason (that they care about).

Nope, they are basically right and it's a source of endless frustration to security researchers that these very simple problems are still thinks that have to be dealt with in 2021.

Usually I would agree. But not in this instance. It really is silly some isps are not doing this by default, just fixing this will reduce so many types of ddos attacks. The current size of ddos attacks are just insane. And thabks to these attacks decentralized nature of the internet is eroding everyday.

No, the solution is ingress filtering and a lot of ISPs do it these days, see bcp38.

Huh?

Ingress filtering is filtering traffic coming in to your network. How are you supposed to know whether traffic coming from a certain peer actually legitimately originates from that peer?

Egress filtering is filtering traffic that exits your network. It's your network, so you should know with absolute certainty whether it's real - either the source is one of your networks, or it isn't, and if it's not, you drop it.

Please explain how ingress filtering is supposed be the better solution.

We are almost talking about the same thing. But it's better to accomplish this on all your customer links, otherwise they can still spoof within your network.

Read up on bcp38? This is from the first hit on Google: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

You go ahead and force a large provider to do it, and let us know how. From what I can tell from reading NANOG mailing list posts off and on for decades is that most of the larger providers really won't be bothered to do this, and there's not any effective leverage to force them.

Telcos also tried claiming its impossible to secure SS7, and here we are in 2021 finally getting Stir/Shaken implemented https://www.fcc.gov/spoofed-robocalls

> Too bad we have shitty, huge companies that don't care about doing the right thing :(

The situation is not really different from dumping waste in the nearest stream. It’s naive to think that companies wont just act in their own best interest unless they are forced to clean up their act.

So what you’re saying is that legislation would help here?

As far as I know, a lot of DDoS attacks use UDP amplification, which can be prevented if every ISP implements BCP 38; i.e. drop UDP traffic at the edge of their network that has a source that cannot have come from within their network.

EDIT: To clarify, this won't stop layer-7 based DDoS attacks, or anything that uses TCP (like SYN flooding). Just UDP amplification.

BCP 38 would stop SYN flooding if it is using source address spoofing. It won't stop any attack not based on IP spoofing though.

>or anything that uses TCP (like SYN flooding)

Plenty of SYN floods spoof IP as well. If you don't need to get the response, and you're behind an ISP that doesn't bother blocking IP spoofing, why would you use your actual IP? It'll make it much harder to actually trace an attack to the actual device doing it. It won't work on devices behind NAT but neither will reflected UDP attacks.

Most/all ddos attacks come from unwitting people whose computers or iot devices have been taken over on the order of tens or hundreds of thousands of devices. So there isn't much that can be done beyond filtering or having a large enough pipeline to absorb the traffic.

Even if you had a central authority cutting off access from ip addresses, do you cut off whole university campuses because someone's "smart" coffee machine is participating in a ddos or entire businesses because there is a computer in a closet somewhere that is infected?

We talked about this problem when I worked at a telco. The problem isn't necessarily cutting of the devices that are part of the attack, it's dealing with the aftermatch.

As sad as it is, most people won't understand that their device have been effected, and the telcos won't be responsible, financially, for paying to do the cleanup or verification.

I feel like home router makers could intervene here and let their owners know when they’ve likely been hacked. Maybe even a regulation type deal?

> home router makers could intervene here and let their owners know when they’ve likely been hacked

How?

A couple of years ago I had an email from our ISP telling me that "common port X is open on your router" (forwarded to a box exactly as I set it up) and asking if I could "fix the problem".

Except it wasn't a mistake or a configuration error, I deliberately set it up that way.

I don't see how this would be feasible without giving them a backdoor to snoop around in my home network. No thanks.

That's never going to work but it very well could lead to ISPs very strongly herding customers to use their own managed routers. They already push for that for customer support purposes, using this to start automatically snooping on "malicious" traffic within a customer's network would be a big step in the wrong direction.

You could make a compromise here and require ISPs and network vendors to support a common notification protocol to identify devices sourcing malicious traffic. Most ISPs already have systems in place to send notification messages to customers that are sending botnet traffic. You could mandate it for all of them and let the customer decide if they want their router configured to automatically block a device they were notified about or just record the MAC address and send the ISP a URL the user can visit to view the device sending the traffic. You could make it friendly to the unwashed masses and still put detection on the ISPs and not give them privileged access inside every customer's network.

> Even if you had a central authority cutting off access from ip addresses, do you cut off whole university campuses because someone's "smart" coffee machine is participating in a ddos or entire businesses because there is a computer in a closet somewhere that is infected?

I think the solution is probably similar to the sorts of laws that we have for dealing with pollution and similar bad behaviour. Start with warnings and education, escalate to fines and other penalties, and only escalate to outright bans in the worst and most recalcitrant cases.

> do you cut off whole university campuses because someone's "smart" coffee machine is participating in a ddos

How about: use IPv6, and cut off just the coffee machine.

> do you cut off whole university campuses because someone's "smart" coffee machine is participating in a ddos

Yes?

That’s the only reasonable way to go about it. If you block only single clients you’ll just paint a large bullseye on universities.

With DDoS the problem is that botnets come from a bunch of random devices that were compromised (for example, your un-updated smart TV or old router could be contributing to the DDoS without your knowledge.)

With spam calls, ransomware, and most other forms of cybercrime, the problem is that Russia/China and many 3rd world countries don't extradite/cooperate or have the resources to work with international authorities.

I sometimes wonder how much safer the internet would be if China and Russia were cut off. Wouldn't be so great for the already poor state of liberty in either country, but the rest of the world would certainly benefit.

>Wouldn't be so great for the already poor state of liberty in either country, but the rest of the world would certainly benefit.

That's a pretty closed minded way of looking at things.

They are already doing it themselves...

How so? To me, closed-mindedness is shooting down an idea without a reason or alternative.

Cutting off countries will do very little. Compromised devices are spread evenly across the globe, and even if their puppeteers sit in China or Russia, you wouldn't be able to block them from issuing orders to botnets.

It's true that they often use botnets, but amplification attacks are more and more common, and an important component here.

In these, the attacker sends crafted requests to an unwitting third party, and that third party then floods the victim with traffic. DNS amplification is probably the best known, here, since DNS is (usually) over UDP which has no persistent connection for replies:

- Send a DNS query to a DNS server, using your victim's IP address as the "source IP" for the query. Make the query something with a huge response, like using "ANY".

- DNS server responds to the victim's IP address, sending many big UDP packets with the response. After all, it can't know any better - it must* just trust the claimed source IP!

- Victim gets a huge flood of UDP traffic, overwhelming IP-level infrastructure like routers and switches.

This lets a relatively small attacker multiply ("amplify") their impact - and they do it while traversing a third party, making them more hidden.

---

* If course, there actually are mitigations for this; it's possible to detect this spoofing. But this is how DNS operators have worked in the past.

"without your knowledge"... is there a way to check if my IP was participating in the DDoS? If they are filtering the traffic, they might be able to create a list of IPs that I can check. Or perhaps, an IP can be associated with a contact info so the if any of my devices would be infected and participate in DDoS, I would get notified by the victim and could take action.

That's the reason why my nextdns blocks all .ru and .ch domains.

I don't trust them + i don't speak the language. So entirely blocking it is an easy decision.

Nextdns on my router blocks generated domains, which could be used against c&c servers.

.ch is Swiss TLD ;)

Oh yeah, indeed. Verified it, it was .cn that is blocked ;)

Thanks for reminding me

> the rest of the world would certainly benefit

OTOH most pirate library sites are hosted in those countries for the same reason.

Imagine the real-world equivalent: someone spreads a rumor that the Fifth Avenue Apple store is giving away free iPhones at 6pm. Ten thousand people turn up and block the store, the sidewalk, the roads…

How should a business defend against that without losing legitimate customers?

The answer is probably along the lines of “educate people not to believe rumors” (:: “educate people not to run insecure software”).

How does secure software protect you from acknowledging perfectly innocuous requests?

It’s the zombie-botnet-machine owners who need to be running more secure software, not the botnet victims.

> (:: “educate people not to run insecure software”).

Some of these exploits uses zero day attacks, the users cannot do anything.

The issue is: bot nets. The attacks come from multiple sources worldwide. No anonymity, rather a swarm of legitimate hosts sending mass;requests. Research and development? Network connections come in, one way or another some devices have to filter them in or out. AFAIK it's an arm race. Large bot nets on one side, and hardware optimised to filter out certain requests on the other.

It's a simple technique but requires compromising enough networked resources to make the attack effective.

Cloudflare and other providers having large capacities are well armed to deflect DDoS that can't overwhelmed them, but even then, they aren't safe from a larger bot net than what their network resource can handle.

If someone knows more than I do, maybe they could elaborate on technologies I'm not aware of.

A DDoS attack is indistinguishable from a huge legitimate success. See Slashdot effect [1].

The very problem of a DDoS attack stems from that (1) each request is a small, fully legitimate request and (2) there are too many of them, coming from too many sources for filtering to be efficient. It is also mixed with indistinguishable non-attack requests by your normal customers.

So no, even the best authentication would help little.

[1]: https://en.wikipedia.org/wiki/Slashdot_effect

And which sometimes happens to sites with limited b/w when they trend on HN.

DDOS events typically use distributed botnets. Unless you analyze the CNC you’re probably asking for wide deployment of acls (flow spec or otherwise); and such agreements happen occasionally, as they operationally brutal but are slow (otherwise they would be subject to abuse).

You, right now, may be participating in a DDOS attack without knowing it. Should your ISP cut you off based on information from some Belgian ISP?

There are many parts to the answer of your question, but one part yet to be implemented in a meaningful manor is BCP38 [1]. The RFC's around BCP38 keep changing and that may be part of the issue. It is still too easy to spoof the source across ISP boundaries. Then of course there is also the issue of getting all the ISP's to work together to detect and mitigate these attacks and that involves cost that the tier 1 providers barely spend towards. There are so many more pieces to this problem and I am barely touching on it.

[1] - https://www.rfc-editor.org/info/rfc8704

It isn't anonymity. It's insecurity. Until you fix the human factor, bad code, weak passwords, shitty programming practices and minimum outsourcing to the worst vendors.

There are very little consequences.

Until states start doing s/sea/internet/g on their old-school maritime piracy laws[0] I don't think anything is going to change, except attacks are gonna get bigger and bigger.

Under current law, that's a lifetime sentence in many*(US[1] & Canada[2] at least) countries. It should do the trick if most states get onboard.

> Acts of piracy threaten internet security by endangering, in particular, the welfare of internetfarers and the security of navigation and commerce. These criminal acts may result in the loss of life, physical harm or hostage-taking of internetfarers, significant disruptions to commerce and navigation, financial losses to server owners, increased insurance premiums and security costs, increased costs to consumers and producers, and damage to the internet environment. Pirate attacks can have widespread ramifications, including preventing humanitarian assistance and increasing the costs of future connectivity to the affected areas.

[0] https://www.un.org/depts/los/piracy/piracy.htm [1] https://www.law.cornell.edu/uscode/text/18/1651 [2] https://laws-lois.justice.gc.ca/eng/acts/c-46/page-11.html#s...

>> Since this is HN, it’s 2021 and DDoS’es are still a thing: why are they still a thing? Is there some fundamental “anonymity” to the Internet that makes it impossible to structurally prevent DDoS attacks?

IMHO that is exactly what the problem is. Weather its malware, phishing scams, extortion schemes, the fundamental problem is knowing where stuff comes from.

I propose an IPv6 subnet that routes by using a portion of the IP address as lat/long coordinates as a starting point because routing tables are litterally a form of indirection.

> an IPv6 subnet that routes by using a portion of the IP address as lat/long coordinates

That seems like a rather large privacy problem.

You could for example protect all networked computers with single packet authorization. They will ignore all network traffic unless a signed packet is sent first. To the unauthorized it's like the computer is not even there.

this is basically how a vpn tunnel works in some way. (wireguard, ipsec if properly configured etc).

it has one, enourmous downside. it destroys reachability to your systems from the population at large because they need to trust some key, which is not universally distributed.

> it destroys reachability to your systems from the population at large

Indeed.

Sometimes I think it was never meant to be. We're allowing our computers to talk to untrustworthy strangers. It was always a matter of time before one of them sent a crafted payload...

Perhaps computers shouldn't be so reachable. Can't exploit a computer that's not even there, zero days or not.

ZERO monetary incentives to deploy technical solutions preventing DDOSes.

It would cost additional hardware, manpower, time and PR dealing with disconnected customers. Ignoring the problem lets you offer paid extra protection services.

Reply on news.ycombinator.com