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: local policy)
Date: Fri, 19 Apr 2013 11:42:21 -0400
From: "Mark H. Wood" <mwood@IUPUI.Edu>
To: users@tomcat.apache.org
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
 HTTP/1.0" 404
Message-ID: <20130419154221.GC30307@IUPUI.Edu>
References: <20130416152152.GE13819@IUPUI.Edu>
 <516D7E93.5020006@ice-sa.com>
 <CAG6aRdWapRh+WDwH926Q8FxV7-o-k1cWA8UKyFS2UGHe452Fag@mail.gmail.com>
 <8000842584522301737@unknownmsgid>
 <10884071.5855.1366137501706.JavaMail.mobile-sync@vemw20>
 <-3567947474235942048@unknownmsgid>
 <516DB043.2080409@ice-sa.com>
 <D72C174D3CAC0A4E812FAD012D646E9F25107124D3@CMS1.enterprise.maricopa.gov>
 <516EDB9B.7030700@ice-sa.com>
 <516EDFB2.6030103@christopherschultz.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="yVhtmJPUSI46BTXb"
Content-Disposition: inline
In-Reply-To: <516EDFB2.6030103@christopherschultz.net>
User-Agent: Mutt/1.5.21 (2010-09-15)

--yVhtmJPUSI46BTXb
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 17, 2013 at 01:45:22PM -0400, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>=20
> Andr=E9,
>=20
> On 4/17/13 1:27 PM, Andr=E9 Warnier wrote:
> > Leo Donahue - RDSA IT wrote:
> >>> -----Original Message----- From: Andr=E9 Warnier
> >>> [mailto:aw@ice-sa.com] Subject: Re: Tomcat access log reveals
> >>> hack attempt: "HEAD /manager/html HTTP/1.0" 404
> >>>=20
> >>>=20
> >>> 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 ?
> >>=20
> >> What if I send 10,000 requests to your server for some file that
> >> is not there?
> >=20
> > 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.
>=20
> 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=E9'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?

--=20
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Machines should not be friendly.  Machines should be obedient.

--yVhtmJPUSI46BTXb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEAREIAAYFAlFxZd0ACgkQs/NR4JuTKG+gzwCffqrzndMhsmgBA9/z9FjrJZ48
2FwAn2iqDI3UFa0fvmWtd3NNm39+q8r0
=OWMk
-----END PGP SIGNATURE-----

--yVhtmJPUSI46BTXb--