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 19:22:32 GMT
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier []
>> Sent: Wednesday, April 17, 2013 10:28 AM
>> To: Tomcat Users List
>> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>> 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 ?
> No, I honestly don't.  I was thinking like a miscreant in that I would do it intentionally
to force your server to queue for the next 2.5 hours to return 404 messages to those 10,000
requests for nothing.  Now I would have a new tool for DOS?  But you point out something interesting
further down...
>> (this is a real question; it might be that there is, and that would be a real flaw
>> to the
>> scheme)
>> 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.
> So you are saying it could be possible to know in advance that certain requests are for
repeated requests of nothing or being made by a bot, versus regular legitimate requests, in
order to move those bot requests off to another thread?

No, not at all. It would be nice but no.
What I mean is that any 404 response should be handed off to one of these lightweight 
processes, so that the real useful process doesn't have to handle it.
Of course some processing has already taken place to find out that the target resource of

this URL does not exist and that responding with a 404 code is appropriate.
But as soon as this is determined, the rest should be "sub-contracted" to a simple 
sidekick, which will do the 1 second wait and then send back the response on the 
connection and then close the connection.
In the meantime, the real useful webserver process can be available to process the next 
request (which can be bogus again, but nothing to do about this). No need for this real 
valuable complex process to spend his own time waiting for 1 second, sending the 404, 
closing the connection etc..
And we do not really care if this sidekick, 404-sending-only process has a backlog at some

times, and sometimes takes longer than 1 second to finish off this 404 response, do we ?


>> 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