Leo Donahue - RDSA IT wrote:
-----Original Message-----
From: André Warnier [mailto:a...@ice-sa.com]
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
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.
But I am sure that the tomcat gurus here will have some good ideas for that
part.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
