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).

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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

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

the hackers are better than I thought!

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.

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.

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

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.

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.

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 just figured Honey was kind of like spyware, collecting information about what people bought online.

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)

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.

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

Perhaps a better analogy may be robocalls with spoofed numbers.

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,…}"

this doesn't work for massive ddos's.

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.

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

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

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.

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

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 :(

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.

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.

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.

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

> 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).

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

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.

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?

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

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

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.

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.

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

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.

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

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.

Thanks for reminding me

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

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”).

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

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.

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

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?

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

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

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.

That seems like a rather large privacy problem.

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.

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.

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