chris derham wrote:
Or, another way of looking at this would be that for every 40 servers
scanned without a 404 delay, the same bot infrastructure within the same
time would only be able to scan 1 server if a 1 s 404 delay was implemented
by 50% of the webservers.
This assumes that the scanning software makes sequential requests.
Assuming your suggestion was rolled out (which I think is a good idea
in principal), wouldn't the scanners be updated to make concurrent
async requests? At which point, you only end up adding 1 second to the
total original time? Which kind of defeats it.
Again I'd like to state that I think you are onto a good idea, but the
other important point is that some (most?) of these scans are run from
botnets. These have zero cost (well for the bot farmers anyway). My
point is even if the proposal worked, they don't care if their herd is
held up a little longer - they are abusing other people
computers/connections so it doesn't cost them anything directly.
Sorry but those are my thoughts
Don't feel sorry at all. The purpose of flating this idea here on the list, is to get as
many reactions (and objections) as possible. I am not quite sure either that the idea is
really practical, just that it might be.
Let me tackle the objections that you mention above :
First, the zero-cost one.
I have to imagine that there are some costs into creating, maintaining and deploying a
botnet. First, there is the cost of possibly getting caught doing it, and possibly paying
a big penalty. That must be compensated by some possible benefit, but if at some point
the possible cost outweighs the possible benefits, there will be less botnets.
Second, although when the botnet is deployed, it does not cost much to the deployer to
actually run it, it does cost something to the system hosting it (bandwidth, cpu cycles
etc), so the likelihood is that at some point it will be discovered and eliminated. So it
will have costs in terms of re-deployment. To prove this ad-absurdum, if it did not cost
anything, then there would also not be a market for selling botnets or botnet code for
money; and there is. See the article mentioned in an earlier message in this thread.
Second, the concurrent async requests :
What I am seeing on my servers at the moment are sequential requests, separated by a few
seconds each. I'll get some 30 requests in a row like that, then nothing for a while, then
again a batch of sequential requests originating from another IP, etc.. And this all day
long. On 20 servers, this amounts to several thousand requests per day in total.
But even if the requests were made simultaneously, the cost *per request*, for the "botnet
host" issuing the requests, would be the same. And the more resources are consumed by the
botnet on its host (cpu time, connections, memory, bandwidth), the more noticeable it
becomes. Even if this is a criminal botnet server dedicated to this task instead of being
an infected third-party server, there is a limit as to how many requests one server can
issue, whether they are simultaneous or not.
Also on the target host, if there is a batch of 30 simultaneous requests for 30 different
URLs, all coming from the same client IP, it becomes more noticeable, and easier to
distinguish from genuine client requests.
So all in all, I think you have a point, but I believe that it is not overwhelming, and
that the basic assumptions that I made still hold up.
I will another possible objection of my own (and my answer), to save someone the task (or
the pleasure) of doing it : if we block this avenue for infecting webservers and make it
uneconomical, then the botnet authors will re-direct their infrastructure to other
targets. For example, they would re-target their botnets to trying to connect via SSH and
try more userid/password combinations, like here :
http://www.bbc.co.uk/news/technology-22152296
But in my egotistical view, that's fine. In this particular case, it bothers me to see a
part of my webserver's resources being wasted by these scans, so it they disappear and go
somewhere else, that's good enough for me at the moment.
(And maybe I'll think of something for SSH next..)
What we are facing is something like a (biological) virus : each new infected host can
scan for more victims, which then become infected in turn and help spread the epidemic.
So we are looking for something like a vaccine : if enough servers become resistant, then
the virus cannot spread as easily anymore, and eventually it dies out. Not all webservers
need to implement this, just enough of them.
The trick is to make the vaccine cheap enough and easy enough to administer, so that there
will be a significant enough proportion of "vaccinated servers" to make the virus
statistically ineffective.
Maybe if we find a simple patch to Tomcat to introduce this 404-delay, we could hire a
botnet to distribute the patch ?
Mmmm, maybe there is another idea there : how about an anti-botnet botnet ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
