tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Tue, 16 Apr 2013 18:26:26 GMT
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 :

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:
For additional commands, e-mail:

View raw message