tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Tue, 23 Apr 2013 01:46:40 GMT
Hash: SHA256


On 4/22/13 6:44 PM, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> Chris,
>> On 4/20/13 6:08 PM, chris derham wrote:
>>> I think that you have articulated your suggestion very well. I 
>>> think you have weighed the pros well and been open to debate. 
>>> Personally I just don't think what you propose will have the
>>> effect that you desire.
>> I agree. Most of these scanners only scan a few URLs every few
>> seconds in order to avoid being branded as
>> vulnerability-scanners, so adding a delay to them won't really
>> change anything.
> Chris, with respect, I believe that you are mistaken.  My own
> server logs, over a quite long period of time, show that the
> majority of these scans happen according to a rather systematic
> pattern like the one I posted earlier in this thread, with a
> relevant portion re-posted below.
> That is : - one origin IP per scan - approximately 3-4 requests per
> second - 10 to 30 URLs per "session"
> The particular scan shown below started at 00:52:32 and ended at 
> 00:52:49, after scanning 36 different URLs.  In elapsed time,
> including the pauses that it undeniably makes, that is 17 seconds.
> The server in question normally responds to such requests in less
> that 10 ms.  Excluding the pauses thus, it took this bot 36 x 10 ms
> = 0.36 s "real time" to scan the 36 URLs (excluding network
> latency, which is probably about 50 ms per URL). If the server
> added an average 1 s pause to each 404 response, it would have
> taken the bot 36 seconds "real time" to make the same scan.  That 
> is 100 times more.

Yes, but the attacker has more source ports than you have destination
ports, can run in parallel, and doesn't really care if you delay him.

Your proposal, while interesting in an academic sense, is IMO unlikely
to deter anyone.

> Now, no matter how smart the bot is in doing this kind of scan, if
> the 404's are delayed, the fact of the matter is that it will
> always cost the bot these extra 36 seconds to finish the same job.

If an infinite number of monkeys continues typing, Macbeth will
eventually emerge... infinite time times 4 seconds is still infinite time.

As for your solution, it sounds (relatively) easy to implement, but of
course requires all those people out there you are talking about (lazy
system administrators) to upgrade to the latest Tomcat, etc. Doesn't
it mean that only the admins who are really proactive about this kind
of thing will actually benefit? Those are the ones who don't really
need it because they are being proactive in other ways. Yes, maybe in
10 years everyone will have upgraded to a version that stymies the
attacks you propose, but by then (if not now), the mitigation will be

Feel free to give this kind of implementation a shot. I won't stand in
your way, but I still don't think it's going to be at all effective.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message