I'm wondering, from a regulatory perspective, what might be done to mitigate DDoS attacks in the future?
From comments made on this and other similar posts in the past, I've gathered the following:
1) Malicious traffic often uses a spoofed IP address, which is detectable by ISPs. What if ISPs were not allowed to forward such traffic?
2) There is no way for a service to exert back pressure. What if there was? e.g. send a response indicating the request was malicious (or simply unwanted due to current traffic levels), and a router along the way would refuse to send follow up requests for some time. There is HTTP status code 429, but that is entirely dependent on a well-behaved client. I'm talking about something at the packet level, enforced by every hop along the way.
3) I believe it is suspected that a substantial portion of the traffic is from compromised IoT devices. What if IoT devices were required to continually pass some sort of a health check to make other HTTP requests? This could be enforced at the hardware/firmware level (much harder to change with malware), and, say, send a signature of the currently running binary (or binaries) to a remote server which gave the thumbs up/down.
One thing that occured to me regulations wise is to require IoT devices to have some minimum level of security such as a unique hard password rather than it just being "admin" or some such. You could enforce it for items sold in the US or EU and the Chinese manufacturers would probably follow so their goods could be sold easily.
> What if IoT devices were required to continually pass some sort of a health check to make other HTTP requests?
Even better, what if IoT devices were required to pass some health check to operate at all. This could be as simple as a verified boot plus a forcible reboot every now and then.
Today the peering agreements are made so that ISPs get paid for whatever traffic they pass through. They have no financial motivation to change anything. And as the Internet is decentralized you cannot order them to do anything. So everyone has to protect from DDOS by themselves.
> Today the peering agreements are made so that ISP's get paid for whatever traffic they pass through. They have no financial motivation to change anything.
That seems believable.
> And as the Internet is decentralized you cannot order them to do anything.
...that doesn't. Being decentralized doesn't render them immune to regulation. If all major networks responsible for large scale peering were required not to pass on a certain type of traffic, it would be quite difficult to route around that. Yes, if only some did, this would be routed around.
Lets avoid giving ISP's more power than they have. Next thing we will see is "oh we thought that person was using a compromised device" for any disagreement.
Regarding point 2, I can think of a few ways to utilize that mechanism itself as a way to DDoS something. Sometimes the security mechanisms themselves are the attack vectors.
Well, it's similar to when a company tries to stop brute force by blindly blocking people who try 10 invalid passwords, but they have a CSRF on the login page (cross site request forgery). The problem is that I can craft a page to make a POST to their login page with invalid passwords repeatedly via ajax, and lock out legitimate users with a spam campaign pointing to my page on their user base. It seems far fetched until you consider something global like the internet. There are two ways I could see this failing on a global scale:
- Attackers figure out something similar to the attack described above and can entice large amounts of users to visit a page that repeatedly fires at something like s3.aws.com or w/e, the user is unaware but they're essentially DDoSing s3.aws.com via attacker.com's webpage, and in point 2 they would be banned.
- DRDoS is similar to whats described above, but in point 2 it kind of stands alone as the biggest issue. it can be mitigated to a certain level by ISP's, but not entirely. (https://en.wikipedia.org/wiki/Denial-of-service_attack#Refle...) . Point 2 would actually help attackers poison DNS.
From comments made on this and other similar posts in the past, I've gathered the following:
1) Malicious traffic often uses a spoofed IP address, which is detectable by ISPs. What if ISPs were not allowed to forward such traffic?
2) There is no way for a service to exert back pressure. What if there was? e.g. send a response indicating the request was malicious (or simply unwanted due to current traffic levels), and a router along the way would refuse to send follow up requests for some time. There is HTTP status code 429, but that is entirely dependent on a well-behaved client. I'm talking about something at the packet level, enforced by every hop along the way.
3) I believe it is suspected that a substantial portion of the traffic is from compromised IoT devices. What if IoT devices were required to continually pass some sort of a health check to make other HTTP requests? This could be enforced at the hardware/firmware level (much harder to change with malware), and, say, send a signature of the currently running binary (or binaries) to a remote server which gave the thumbs up/down.