tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Donahue - RDSA IT <>
Subject RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Wed, 17 Apr 2013 19:45:03 GMT
>-----Original Message-----
>From: André Warnier []
>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
>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
>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.


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?

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.

[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!!
View raw message