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 Wed, 17 Apr 2013 17:27:55 GMT
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier []
>> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>> That's the idea.  That is one reason why I brought this discussion here : to
>> check if, if the default factory setting was for example 1000 ms delay for each
>> 404 answer, could anyone think of a severe detrimental side-effect ? 
> What if I send 10,000 requests to your server for some file that is not there?

Then you will just have to wait 10,000+ seconds in total before you get all your 
corresponding 404 responses.
Which is exactly the point.

Do you know of a real legitimate scenario in which a HTTP client (or more of them) would 
issue lots of requests for resources which they know might not be there ?
(this is a real question; it might be that there is, and that would be a real flaw to the


More details :

- legitimate, well-written applications should not normally be returning pages to the 
user, which contain lots of links which lead to nothing and result in 404 errors.
So once a browser got to one of your normal pages, he should be able to continue 
navigating your site by clicking on links that work, not links that result in 404.
So adding a 1 second delay before returning a (legitimate) 404 response should not bother

legitimate users of legitimate applications too much.
Even genuine legitimate and useful bots (like the Google ones), get your home page, and 
then (unless you tell them not to), they follow the links that they find there to get more

pages and index your site. So they too should not get much inconvenienced by a delay in 
the 404 responses.

- on the contrary, the way hacking bots work is that they are purposely trying to find, on

your server, specific links which are known to sometimes correspond to generic 
applications which have security flaws.  On most servers, these links do /not/ correspond

to real available resources, so they result in 404 errors.  That is what the bots expect,

so when they get a 404 for one such link, they immediately try the next buggy one in their

list, etc.  If they get 404's for all of them, then they will give up, and switch to 
scanning some other server.
In that case, by returning the 404 response quickly, you are actually helping them to 
spend little time on a non-existent flaw and to be able to try the next one sooner.
But if for each 404 response, you force them to wait 1 second instead of 10 milliseconds,

then you immensely slow them down.  They will have to wait that 1 second, because 
otherwise they could never be sure if your server (or the network at that moment) is 
really slow, or if this is a deliberate delay.
(And if you're really into making this even more annoying for them - hehe - you could even

slightly vary the delay for each 404, say between 0.5 and 3 seconds, to make it even more

unlikely that they will figure out some pattern).

A vital part is to design an implementation for this, that from the point of view of your

own server, is as lightweight as possible.  You do not want to force one of your real 
working threads or instances to have to sit there during the 1 s delay doing nothing.
You'd want to hand off this connection and response to some specialised lightweight 
thread, and go handle the next real worthy request.
But I am sure that the tomcat gurus here will have some good ideas for that part.

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

View raw message