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
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 ?
No, I guess not.
And..
If I'm understanding the point you are making, you're saying that delaying the 404 response slows down the ability of the bots to collect
information. The bots will *still* collect data, it will just take them longer to get the
list of possible exploits?
Yes. /much/ longer. Hopefully so much longer that it would no longer be worthwhile for
them to try to collect it this way, and that in the end they will just stop trying.
Which would be to the ultimate benefit of /all/ websites on the web, which currently have
all to deal with these unsollicited requests.
Not knowing anything about the history of the HTTP 404 method, if a server does
not find a matching request URI, why was it decided that the protocol would
even respond at all? Seems like the request could have just been ignored or
dropped.
Because a legitimate client would then be severely inconvenienced, if a page that he got
before contained a link which (for whatever reason, probably an error from the site
designer) really does not lead to a real resource on the server.
This legitimate client (or rather the user using it) would click on a link; the browser
would issue the corresponding request to the server; and then the server would never
answer. But the client does not know if this is because the server is temporarily a bit
slower, or if the response is really taking a long time to be prepared by the server
(think of a heavy database request), or if this is just a bad request. So it would be
forced to wait, as long as is "reasonable" (10 seconds, 30 seconds, 2 minutes, ..?),
before it finally gives up. That would make navigating the web a painful experience.
Browsers do that; if they can connect to the server and send the request, but then they do
not get a response to the request (but the connection stays alive), they will generally
wait up to 5 minutes before giving up. Then you will get a message like "The server is
taking too long to respond. etc..".
So when the server receives a request, and it knows that this resource does not exist, it
responds right away with the appropriate response code, to be nice to the user and not
force him to wait. This is dictated by the HTTP protocol as being a response with a status
code "404", meaning in human terms "the requested resource is not available on this server".
[Way OT...]
If you get this to work, then the next place you can take this idea is to the
phone company. Why should my phone even ring at all if I know the caller is
from an 800 number... or from some other list of people I don't care to talk to
... I would love it if those guys had to wait 10 or 20 seconds between rings...
that would be great!!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
