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: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.
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
