tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Sat, 20 Apr 2013 23:03:28 GMT
On Sat, Apr 20, 2013 at 7:22 AM, André Warnier <> wrote:

> 5) if the scheme works, and it does the effect of making this type of
> server-scanning uneconomical, bot developers will look for other ways to
> find vulnerable targets.

IMHO, I don't see why bots will get 'turned off' by having to wait longer
for a response from (potentially vulnerable) targets. I know that we are
talking a 'numbers game', and the more vulnerable targets that are
compromised, then I'm sure the developers of these bots "+1 Like" that, or
"mission accomplished". It is my assumption that these bots are automated
and can run 'for life', why would they stop doing what they are doing just
because of a delayed response. I'm sure these bots are already facing a
delayed response. I'm quite sure many web servers and/or web applications
do not respond that well/fast.

6) intuitively, it seems that implementing this would not be very
> complicated, and that the foreseeable cost per server, in terms of
> complexity and performance, would be quite low.  The burden imposed on
> normal clients would also seem to be small.
> Maybe this should be evaluated in terms of a comparison with any other
> method that could provide some similar benefit at lower costs.
> 7) once implemented, it would be something which does not require any
> special skills or and special effort on the part of the vast majority of
> people that download and install tomcat.  Which means that it has a real
> chance to automatically spread over time to a large proportion of servers.
> This is quite unlike any other bot-fighting measure that I have seen
> mentioned so far in this thread.

+1 I like the fact that a scheme is proposed that would require 'no
learning curve' and no required 'standard procedure' to be implemented when
attempting to adapt or take advantage of the solution/scheme.

But I still think that if all /tomcat/ users were informed via an 'ANN'
(announcement) email to deactivate or remove /tomcat/ manager app(s), and
somehow a survey is made available a few weeks/months /later/, where
cooperative /tomcat/ users can report-on how many 'attempted attacks'
showed up in their access logs after removing /tomcat/ manager app(s), and
then somehow publicize the survey results to the world, especially, in a
way that bot-developers can see that they are wasting their time, because
/tomcat/ users have made a concerted effort to /declare war against/ these
bots /and bot developers/.

also, if an 'ANN' email was sent, where /expert tomcat/ users can
derive/develop a list of the popular/frequent URLs that bots use when
attempting to compromise /tomcat/ servers.

also, for a certain amount of time, /immediate/ future releases of tomcat
should have manager app(s) as a separate download /available/, and 'ANN'
email will inform them that this is a change as we are attempting to ward
off the ongoing/obvious bot attacks against /tomcat/.

Yes, I know this will require additional steps and probably be rejected by
some/many tomcat users, especially those that are very very 'dependent' on
tomcat manager apps. manager apps are probably the 'primary' target, so
remove it from the install package, and make it a separate install, and ask
users for an honest effort to participate in this effort for the reason(s)
discussed in this thread.

we are a village, we have to start with tomcat, first, and then other app
servers can adapt 'schemes' that work...especially after it become a known
fact that bots are 'not' compromising tomcat servers anymore, /or/ they are
compromising less tomcat servers, because tomcat users are tired of these
bot attacks, and have made a concerted effort to stop/end

Whatever scheme is implemented, if the survey results are positive and the
implementation meets the requirement/goal, then other servers will hear of
this good news, and adapt the scheme/solution, accordingly.

/my two cents/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message