--xdWF/UuCWMRSqXrg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

If I'm remembering my TCP correctly, it's difficult to see how this
"attack" could be implemented.  Before your server can have a large
Send-Q, it needs to have received an HTTP request over an established
TCP connection.  Before you can get an established TCP connection, you
need a 3-way handshake to happen.  For the 3-way handshake to happen,
the client either needs to be able to receive your first ACK packet --
meaning they have to actually exist at the IP they claim -- or the
client needs to be able to predict your TCP sequence numbers, so it
can forge a valid response.

Am I getting this right?

I was under the impression that our TCP sequence numbers were
reasonably randomized, for recent versions of NetBSD.

Somebody please correct me if I've got this wrong.

Chris

On Fri, Sep 07, 2001 at 01:26:53PM -0500, Stephen M Jones wrote:

> So it continues .. I forgot to mention that I'm using apache 1.3.20 and
> I have tried using the Limit* directives in the past.  Those are more=20
> for bandwidth tuning and not really a defense against a DOS attack.  I've
> logged 461 random/spoofed IP addresses that had large Send-Qs .. new ones
> pop up every second so following them is a bit futile.  Writing ipf rules
> isn't really the solution.  I've got apache stopped once again which of
> course ceases all flooding.  I'm looking into using tcpdump to listen to
> the port and see if I can get any clues that way.  Any other clues or
> suggestions would be greatly appreciated.

--=20
---------------------------------------------------- chris@cjones.org
Chris Jones                                          Mad scientist at large
  www.netbsd.org www.postgresql.org www.schemers.org www.python.org

--xdWF/UuCWMRSqXrg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (NetBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjuZNvAACgkQDPY2T8RzaD+T/ACeMOtnwlgDSgLapwPRhafeEI01
dpIAn2vhqVCZwBLVMchq7btIbJV0qSEd
=MwQq
-----END PGP SIGNATURE-----

--xdWF/UuCWMRSqXrg--