tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Sat, 20 Apr 2013 11:22:16 GMT
Mark H. Wood wrote:
> On Wed, Apr 17, 2013 at 01:45:22PM -0400, Christopher Schultz wrote:
>> -----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:aw@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.
> 
> Good advice in general, but "what you want to do" depends on what you
> intend to accomplish.  If your objective is to carry on with
> legitimate business without too much interference from the bots, then
> the thing to do is to detect bots and stop listening to them.
> 
> I think that André's argument is that we might prefer a different
> objective:  to spend (a reasonable amount of) resources to harm bot
> performance so that people stop deploying the nasty things.  This is
> worth pondering.  It fits nicely with the view that "there are two
> classes of threats:  those properly dealt with, and those still
> alive."
> 
> The problem with active resistance is, of course, that when the bad
> guys stop deploying bots they'll start doing something else.  To be
> effective for more than a moment, we need to surround all the enemy's
> tactical options.  At that point a smart enemy will give up and go
> home, while a stupid (or desperate) one will come on and be destroyed.
> Either way, you win.  But this is very hard to arrange.
> 
> So we have to consider what going active will cost, and how the
> enemy's behavior will change.  The reward is still there for him if he
> can grasp it.  What's the next soft spot, and can we defend or harden
> it?  Can we afford to win the bot battle, or is it better to just
> shrug them off?
> 

Thank you Mark for expressing this better than I could do it myself.

I do realise that my proposal tackles only one small aspect of the general "battle against

bots".  It would be nice if someone could come up with the absolute all-encompassing 
defense, passive or active.  But I do not believe that this is going to happen, for the 
simple reason that no matter what, for a server to be useful for something, it needs to be

accessible in some way, so some avenues will always be open.
I was just reading a book in which the author quoted the 3 basic principles of computer 
security :
1. don't own a computer
2. don't connect it to the power
3. don't use it
(and lest anyone take this seriously, that was a jest; but like all good jests, it has a 
bit of truth in it)
And I have also often wished that when my server detects such a malicious scan, there 
would be some way by which it could retrace the origin (which it can) and go drop 
something there that would go "boom" (which is unfortunately problematic in several ways).

So we are left with just a few ways to make our servers - and HTTP servers in general - 
more secure against the malicious amd smart miscreants that are behind these bots.
Securing one's server individually will always be the best method.
My proposal does not in any way secure any server individually against bot attacks.
And from an individual server point of view, it is not the best nor the most efficient way

of fighting the scanning bots.
But so are many other measures on the WWW.  For example, why do HTTP servers generally not

enable PUT requests by default, or act as forward proxies by default ? Or why do standard

browsers not accept cookies that are for a domain different from the domain which sends them
?

My proposal is not about providing an absolute weapon, nor about winning the final battle

against bots. It is only about "chipping away" at one avenue by wich bots can currently, 
at low cost, scan millions of servers in the hope of finding a few that can then be used 
to do additional nefarious things (for example, mounting a DoS attack against /your/ server).
It would (hopefully) raise the cost for bots of using this particular method of attack.
Whether it raises the cost enough that they will abandon it, I wish so but I really don't

know.  Whether it actually costs something to the server which would implement it, I don't

know either.
But even if it has some (reasonable) cost for a server, I would nevertheless advocate this

as something for the public good, which is after all what open source is all about.

Let me just summarise my arguments then :
1) These scans are a burden for all webservers, not just for the vulnerable ones.  Whether

we want to or not, we currently all have to invest resources into countering (or simply 
responding to) these scans.  Obviously, just ignoring them doesn't stop them, and just 
protecting one's own servers against them doesn't stop them in a general sense.
2) there is a fundamental asymmetry between how bots access a server (and most of the 
responses that they get), and how "normal" clients access a server : "normal" clients 
receive mostly non-404 responses, while bots - by the very nature of what they are looking

for - receive many 404 responses. So anything that would in some way "penalise" 404 
responses with respect to other ones, should impact bots much more than normal clients
3) setting up a bot to perform such a scanning operation has a cost; if the expected 
benefit does not cover the cost, it makes no sense to do it.  Assuming that botmasters are

rational, they should stop doing it then. It is debatable what proportion of servers would

need to implement this proposal in order for this kind of bot-scanning to become 
uneconomical in a general sense.  What is certain is that, if none do and no better 
general scheme is found, the scans will continue.  It is also fairly certain that if all 
servers did, this particular type of scan would stop.
4) it is not obvious right now which method bots could use to circumvent this in order to

continue scanning HTTP servers for these known potentially vulnerable URLs. I do not 
discount that these people are smart, and that they could find a way.
But so far it would seem that any scheme thought of by people commenting on this idea, 
have their own costs in some way and do not invalidate the basic idea.
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.
It is just not obvious to me where they would move their focus, HTTP-wise. If their aim is

to find vulnerable URLs on webservers, what else can they do but try them ?
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.
8) an obvious drawback to this scheme, is that if it works, it would take a long time to 
show its effects, because
a) it would take a long time before a significant proportion of active servers implement 
the scheme
b) even then, it would probably take an even longer time for the bots to adapt their 
behaviour (the time for the current generation to die out)
So in politics, this would be a no-no, and I will probably never get a Nobel prize for it

either.  Damn. I would welcome any idea to spread this faster and allow me to gain a just

recognition for my insights however.

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


Mime
View raw message