[...] He lurked on Russian-language bulletin boards and followed instructions to download software that would allow him to participate in distributed denial of service attacks against Georgian websites. Some were simple webpages with a few lines of javascript designed, essentially, to press the reload button over and over. Others were slightly more sophisticated, written as .BAT files, but essentially using the same methodology. [...]
Out of context, I know, but the essence is that denial-of-service attacks are executed regularly by botnets, malicious websites, and even dedicated political nutjobs. Why isn’t there some internet protocol option that the affected server can use to signal routers that it has stopped accepting packets from a certain address? Enormous amounts of bandwidth could be saved at the ISP even before attack packets reach the open internet. So this is the idea:
- Server gets hammered, sends signal to its operating system to ban an IP address.
- OS sends ban signal piggyback with the last return data along the chain of routers
- each router on the way can optionally observe the ban signal and implement it
- next time, the attacking system is blocked from reaching that destination early in the chain
Of course, the ban shouldn’t last longer than a few hours at most. But heck, even a few minutes (to keep local storage requirements for routers low) would be plenty enough to reduce the impact of those attacks – considering that each system can send well over a hundred malicious requests per minute. The potential for abuse is not really significant, since the user is only banned from reaching that particular host, but users behind public proxies will effectively be screwed.
Possibly Related Posts:
More:
Mac Neophyte Tips: Clearing the local DNS directoryCan’t log on to your favorite website? Google.com went down?...
There *is*. Almost any protocol layer of the ISO/OSI stack (apart from MAC and PHY) have something to offer. Want it simple? Use a little log-file analyzer and an iptables-like solution. Bascially, you’re off with 200 lines of python/perl/shell script code. Want it more sophisticated? Set up SNMP together with another ban solution, e. g. Cisco’s IP-level firewalls on their routers. If you have a more complex environment, implement it in the load balancer, e. g. when a server’s maximum capacity is reached, set the load balancer to not return that server’s IP address upon a DNS query. There’s plenty of solution.
Now what, why aren’t they implemented? I don’t know. I hestitate saying that alot of people care as much as journalspace.com cared about their backups.
But the thing is, if you browse common admin forums and read threads that start with “oh my god, my ssh daemon gets hammered!”, most often the very first answer is “make it listen on another port.” I guess that it’s just hard to distinguish web hosters with a really sophisticated solution to the problems surrounding web site hosting from the guys that just set up apache, perl, php and mysql on a virtual server and call it a day.
I get that it’s trivial for the ISP (even though MediaTemple wasn’t too helpful when my site was under attack, I’m guessing that’s a common pattern in ISPs). This idea is different.
See, ISPs don’t have an incentive to implement blocking because they don’t get anything out of it. They still pay for the bandwidth of the attack since it reaches their datacenter anyway. So it makes little sense for them to protect the individual customer’s server (makes even less sense for MediaTemple because they’re operating a cluster that can’t really be harmed by small DOS attacks).
No, this idea moves the ban further down the stream towards the node where the attacking system is attached. So basically, ISPs, infrastructure providers and hosting companies would have to *agree* on a ban system. Some might say that’s even more improbable to happen (and they may be right), but it’s worth considering how the entire infrastructure profits from that.
However, while thinking more thoroughly about it, it’s now clear to me that this would be the end of P2P: ISPs would abuse the system to ban all peer connections “on behalf” of the customer’s IP address.
Well, I wrote about the actual node, e. g. the very webserver that gets hammered. The ISP, meaning the carrier, doesn’t have to do anything with the traffic it routes. (Well, ideally.) It’s the job of the guy who actually administers the machine. And I cannot see how a web hosting company doesn’t get profit (even though not immediately material) out of such a service.