tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Wed, 17 Apr 2013 20:43:02 GMT
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message