Esmond Pitt wrote:
The hack attempts that started this thread aren't denial of service attacks
at all.
Who said that they were ?
They are attempted penetration attempts which if successful lead to
installation of a viral servlet.
They were HEAD requests, which just indicate whether this URL actually responds.
And installing an application via the Tomcat manager requires additional steps, and is not
possible (since at least Tomcat 5.5) unless you have explicitly allowed it by providing
access to it without properly securing it, which is not the default Tomcat configuration.
The way I fixed them was to put an Apache
HTTPD in front with a whitelist so that only known management IP addresses
can even connect to /manager, let alone access it.
Good for you, and that will undoubtedly work if done correctly.
But if that was the only reason to install httpd in front of Tomcat, that's like using a
B-52 to kill a mouse. Why not just properly shielding the manager application at the
Tomcat level ?
Apache HTTPD doesn't give
a 404, it just closes the connection.
Would you kindly explain how you got Apache httpd to do that ?
Off the top of my head, I do not know of any standard way in which one can configure
Apache httpd to close a connection in response to a request.
No exposure, no wasted threads, no
wasted sockets, nothing.
That is conveniently skipping the fact that you installed a 50 MB footprint webserver in
front of Tomcat, plus (presumably) an Apache/Tomcat connector, which is adding 2 sockets
and two protocol stacks to the configuration.
And again if this was only to shield the manager application of Tomcat, then for all the
other Tomcat applications you are now executing a few thousand additional CPU instructions
for every other access to Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
