Leo Donahue - RDSA IT wrote:
-----Original Message-----
From: André Warnier [mailto:a...@ice-sa.com]
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 [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 ?
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 ?
And..
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
