Even though not all of us like Microsoft, you still shouldn't do this. The best way to handle this is to send random data at 10b/s and slow down the bots.
It'd be interesting to keep a list of the bots, and randomly redirect the traffic back at them. My first thought was that this would mess up people who unknowingly have a bot on their computer, but then I realized this might actually make them look into getting their computer fixed.
Am I missing something here, or is this actually a decent idea?
I suppose you could always redirect to 127.0.0.1. Maybe even go for a port that's likely to be open on a statistically random compromised system, like 135 (Windows DCOM, can't close it to localhost without breaking like half the system).
Edit: I just tried this in IE on my Win box; the connection even stayed open for a good long time! Firefox blocked it, though, which is probably good.
I doubt these bots can handle the redirect request. Its js and I don't see why someone would code to support it. Maybe someone better informed than me can say whether curl or wget respect redirect by default.
Yeah, I'm not sure that kernel.org is the right way to go here... plus, I'm pretty sure they'll not be happy.
But, I do wonder if there is some other way to do the same thing. Perhaps we could setup some kind of tarpit like server that sends out a file very slowly... like .1K / sec (~1 packet every 10 secs). Just enough to keep their connection alive, but slow enough to not use too much bandwidth.
But, I'm not sure if this would be any better than just sending a 404 quickly.
RewriteRule \.(asp|aspx|php|jsp)$ - [F,L,NC]
RewriteRule (w00tw00t) - [F,L,NC]
RewriteRule (phpmyadmin) - [F,L,NC]
RewriteRule (php-my-admin) - [F,L,NC]
That cuts off those requests before they hit a Rails process and suck up any additional resources.