Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <516D7E93.5020006@ice-sa.com>
Date: Tue, 16 Apr 2013 18:38:43 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
 HTTP/1.0"
 404
References: <70C3D7FF9B194C1587F273ADE1623698@HP6910P>
 <-8374468888202311141@unknownmsgid>
 <A11B65D6015C49A0832B6AD82B735E7A@HP6910P> <516BD58F.2060207@pidster.com>
 <2AFD2E9D75D24E1FB992619D3549F388@HP6910P> <516BE951.7000106@pidster.com>
 <516C2133.8090703@ice-sa.com> <516C262F.6040007@ice-sa.com>
 <CAHjMPQzf=rBtjPSeo1+6KBv+sMGdQ9eW0c7m0ki3COvO6TrXmQ@mail.gmail.com>
 <516C359F.4030506@ice-sa.com> <20130416152152.GE13819@IUPUI.Edu>
In-Reply-To: <20130416152152.GE13819@IUPUI.Edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Mark H. Wood wrote:
> On Mon, Apr 15, 2013 at 07:15:11PM +0200, Andr� Warnier wrote:
>> Neven Cvetkovic wrote:
>>> How about creating a fake manager application :)))
>>>
>>> That takes X minutes/seconds to get back a 404 ;)))
> [snip]
>> Of course at the moment I am just fishing here for potential negative side-effects.
> 
> Search for "tarpit".  There should be a lot of discussion.
> 

Thanks, that was a good tip.  Amd me thinking I had an original idea here...

However, I will keep insisting on my main point : all the tools which I have read about so 
far are great, and much more sophisticated than my crude 404-delay proposal.  But they all 
require additional components, and quite a bit of dedication and expertise, in order to 
take advantage of them.  And, when installed somewhere, they only protect the systems on 
which they are installed.
Which, given the relative complexity of doing so, is likely to remain a small proportion 
of webservers on the www.

Which still leaves it "economical" for these scanning bots to keep scanning, because they 
will still find enough vulnerable servers within a reasonable amount of time spent scanning.
After all, these tools have existed for a while already, and my servers are still being 
scanned every day, so it must still be worthwhile to do so, right ?

My point is that if this were really simple to install (such as installed by default, and 
optionally disabled) then over time a large proportion of webservers would implement the 
scheme, and this would make it uneconomical for these bot scanners to scan, because it 
would take a prohibitive amount of time and/or resources, compared to the number of 
vulnerable servers to be discovered.

And then, because it would be uneconomical, one might hope that this line of attack would 
just disappear.  And then *all* servers would benefit, even the ones which have never been 
"vaccinated" in the first place.

In order to determine the potential benefits or pitfalls of something like this, it is 
often useful to make some back-of-the-envelope calculations, to get a rough idea.
I have done so, and although there is probably much to criticise in my methodology, the 
results tend to suggest something like this :
- given a bot that scans 100,000 IP addresses to try to find servers running webservers 
which have one of these vulnerabilities, with a guessed 2500 such vulnerable servers among 
them :
   - without a delay on the 404 responses, it would take this bot about 2 1/2 hours to 
find the 2500 vulnerable servers among the original 100,000 IP addresses
   - with a 1 s delay for 404 responses, it would take that same bot 93 hours for the same 
result
That is 40 times longer.

Or, another way of looking at this would be that for every 40 servers scanned without a 
404 delay, the same bot infrastructure within the same time would only be able to scan 1 
server if a 1 s 404 delay was implemented by 50% of the webservers.
In other words, now 39 of each 40 servers would be left alone, whether they implement the 
404 delay or not.

I am willing to submit my calculations for criticism or demolition.  But it seems to me 
that the kind of numbers above should at least warrant some interest from the 
powers-that-be, for a parameter that might be as simple as
<Connector delay404="1000" ...>
(of course, I am not talking about the implementation)


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