[42752] in North American Network Operators' Group
Re: Pattern matching odd HTTP request
daemon@ATHENA.MIT.EDU (Karsten W. Rohrbach)
Thu Sep 20 14:02:34 2001
Date: Thu, 20 Sep 2001 20:02:06 +0200
From: "Karsten W. Rohrbach" <karsten@rohrbach.de>
To: Noah <sitz@onastick.net>
Cc: Bill McGonigle <mcgonigle@medicalmedia.com>,
Brian Behlendorf <brian@collab.net>, Jake Khuon <khuon@GBLX.Net>,
mike@biggorilla.com, nanog@merit.edu
Message-ID: <20010920200206.A84680@mail.webmonster.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.32.0109201033010.24889-100000@stanis.onastick.net>; from sitz@onastick.net on Thu, Sep 20, 2001 at 10:36:17AM -0400
Errors-To: owner-nanog-outgoing@merit.edu
--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Noah(sitz@onastick.net)@2001.09.20 10:36:17 +0000:
> On Thu, 20 Sep 2001, Bill McGonigle wrote:
>=20
> >
> > Thanks for all your work on this one, Karsten, and I hope you had a good
> > nap. :)
> >
> > mod_throttle looks like it will stop a DOS from one client effectively,
> > though the configuration is a bit complex for just that use of it. I
> > plan to implement it for that. It doesn't appear to be useful though
> > for the type of DDOS that seems to be brewing (which I hope fizzles and
> > dies).
>=20
> I haven't tried it myself (yet... it's on the plate), but mod_tsunami
> (http://bert.tuxfamily.org/mod_tsunami/) may work better. It limits the
> number of connections on a per-directory basis, using the apache
> scoreboard. The primary issue I had with mod_throttle when I was looking
> at it (a few months back) was that it was fairly CPU intensive. This may
> or may not be an issue depending on how much traffic you push on a
> "normal" day (whatever that is).
ALL modules that use directory/location base config for resource
limiting won't work, because they start processing the reuqets after the
request is in. to be more verbose:
1 client connects to server
2 when socket is connected, client send http headers (accept/host/...)
3 client issues a request (see rfc2616 for that) like GET / HTTP/1.1
followed by two carriage returns
4 server starts processing the request (filtering headers and uri
information through the stack of configured modules)
richt after step 2, there is no per-directory/per-location handler
trigger, since the request has not yest triggered the corresponding
handler because it was not issued by the client.
the malicious client would just open a lot of sockets and wait.
mod_throttle is the only implementation that could process those
connections because it has an additional 'fixup' handler that gets
called _before_ request processing has begun.
the ideal location for some logic limiting incoming dead connections is
in the core itself, because the api is somewhat limited in what you can
do before the request processing an a module.
i hope this shed a little light on the issue.
take care,
/k
--=20
> Q: What do you get when you cross Dracula with a used car dealer?
> A: autoexec.bat
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD4DBQE7qi8eM0BPTilkv0YRAuqLAJjpXheUHbUwIcXnPXi6vij9IMp7AKCsiOMO
zf466Ur0K1b8wIut1JxsBw==
=47l7
-----END PGP SIGNATURE-----
--3MwIy2ne0vdjdPXF--
