-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 4/17/13 1:27 PM, André Warnier wrote:
> Leo Donahue - RDSA IT wrote:
>>> -----Original Message----- From: André Warnier
>>> [mailto:a...@ice-sa.com] Subject: Re: Tomcat access log reveals
>>> hack attempt: "HEAD /manager/html HTTP/1.0" 404
>>> 
>>> 
>>> That's the idea.  That is one reason why I brought this
>>> discussion here : to check if, if the default factory setting
>>> was for example 1000 ms delay for each 404 answer, could anyone
>>> think of a severe detrimental side-effect ?
>> 
>> What if I send 10,000 requests to your server for some file that
>> is not there?
> 
> Then you will just have to wait 10,000+ seconds in total before you
> get all your corresponding 404 responses. Which is exactly the
> point.

Sounds like a DOS to me. What you really want to do is detect an
attacker (or annoying client) and block them without having to use
your own resources. Maintaining a socket connection for an extra
second you don't otherwise have to do is using a resource, even if the
CPU is entirely idle, and even if you can return the
request-processing thread to the thread-pool before you wait that 1
second to respond.

What I describe above is a great case for using fail2ban (not sure if
it exists in the Windows world): you watch a log file (e.g. access
log) and lots of 404s coming from a single place and then ban them at
the firewall-level. That's much more efficient than sleeping for a
second for each 404.

I'm sure you'll lock-out most web spiders pretty quickly, though ;)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRbt+yAAoJEBzwKT+lPKRY1+8P/3inLMorUT8mA2jG0u9whRVm
h20ypC+zDLAxEWM75IKkQCwGZKpAvhBbrasXVOEi+aBYLO7sSBW9PRn1PQibsWlW
taILaKnBf9dF5/ZX9yxjiYx+15WAhz5i7PnaQpPaebYqPa1Bm5S+UQsOQ6jEzAM2
eWouNmYL+3qpYlw0akR12b2fZ+x0l0NLbLRYvKi2ttKNwpX86yQOZ/xjuY6XMFfK
FOhzPMZ9NvoYLvnrA31w6gj+EFHkC1anaSpap2hAGTI5JSSIAk9vQyShH9jJd/yY
9agodQBkS4Z4qthD5WKOWvhsQoEKDufaFikPme70TwGnpB4URlRIl3O5h5UeQIHc
ktPiU7+N0kMMU5GS184dyMf99N1ILjxEM6Yp/56Iiy7Hahral1THNjlAz84kfUCA
7v5X3AkxffZmRrEzCOfYn3SZ971ylJnoNMtQ2acEFO6mCAvvoNur1yz0ZCDb7T+k
g96d/5MbXpbm64P+31fgce1w2iLQg+BogGgZzodvrzyZ1NA3i7EEPffUoRnGxw3x
bmf7ylqGD5cOHBal11BozTfOPkZfZmhvy2bVsys5jv6uZePXPA+7ijzJFCeIh2zC
xQNQLc8WxaXGlT8qUVDoTYBWw6DalE435wJPDmHik5j6FNlwDINfsda6IvJMYCgu
1Yfz70ESuJ8SwjH8iJhF
=C6iu
-----END PGP SIGNATURE-----

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

Reply via email to