Leo Donahue - RDSA IT wrote:
-----Original Message-----
From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com]
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
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.
Wouldn't this depend on what user applications are deployed on the Tomcat server? By
default, I thought we concluded that Tomcat "out of the box" is not
compromised? Did I mis-read something?
I don't think you did.
And I believe that if there was any knowledge that Tomcat "out of the box" was
compromised, the Tomcat developers would instantly set everything else aside and plug the
hole.
About this "/manager" access which started this thread : a long time ago, maybe as far
back as Tomcat 4.0 or Tomcat 5.0, I believe that the manager application was by default
enabled, and the tomcat-users.xml file that was shipped with it, also enabled the default
user-id and password that allowed to login to it and run it.
Then someone found a way to use this, to inject a rogue application into running and
web-accessible Tomcats. That hole was soon plugged, and hasn't been part of the default
distributed Tomcat for years. But apparently, there are still some bots on the www which
try it out, just in case there would still be one of these vulnerable old versions still
in activity (as there probably are; "never fix a running system", he ?).
That's all there is to it, as far as I know.
Now if you are running Tomcat as an internet-facing webserver on port 80, that Tomcat is
likely to be submitted to regular bot scans which are really targeting vulnerabilities in
applications which are relatively widespread on Apache httpd and IIS. These correspond to
URLs like "/phpadmin", "/mysqladmin", "/vti_bin" and the like, which do sometimes exist
under Apache httpd and/or IIS and sometimes do have security weaknesses, but which are
very unlikely to be installed in a Tomcat webserver (because they are not Java
applications, for one).
Thus you would see these accesses also in Tomcat access logs, because the bots are not
always discriminating enough to first check the type of webserver that they scan. But
under Tomcat, it would be very unlikely that you would have a webapp which actually
responds to one of these URLs, and consequently most of these attempted accesses would be
met with a 404 "Not Found" response.
Do not take the above as a recommendation to forget about it and to not regularly inspect
your webserver logs though. It is perfectly possible to create a Tomcat webapp which will
open up a huge security hole, and give it a context name that will be irresistible to the
first bot that notices it ("/secret" and "/private" come to mind).
If you set up an Apache httpd as a front-end to Tomcat (with an Apache/Tomcat Connector
such as mod_jk or mod_proxy), it is also quite easy to configure Apache httpd so badly
that it will provide access to files within Tomcat, which contain things that you would
never want an external client to see. The main example of this kind of bad configuration
consists of making the Apache httpd DocumentRoot and the Tomcat webapps directory overlap,
as mentioned here, in red characters :
http://tomcat.apache.org/connectors-doc/reference/apache.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
