[118243] in Cypherpunks
Re: KISA Attack
daemon@ATHENA.MIT.EDU (Greg Broiles)
Wed Sep 22 18:43:05 1999
Date: Wed, 22 Sep 1999 15:22:33 -0700
From: Greg Broiles <gbroiles@netbox.com>
To: cypherpunks@cyberpass.net
Message-ID: <19990922152233.A16092@ideath.parrhesia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <199909220936.FAA05047@smtp5.mindspring.com>; from John Young on Wed, Sep 22, 1999 at 05:25:40AM -0400
Reply-To: Greg Broiles <gbroiles@netbox.com>
> Any suggestions for ways to ebola the invaders?
While John notes later that the attack has been suspended, it might be
interesting to explore this question further.
In particular, several people wrote to suggest stopping the traffic
before it hits the webserver (though firewall/router/kernel configs)
which is useful, sort of - it protects the webserver, but may allow the
requests to use valuable bandwidth before being dropped.
Also, those changes may require activity on the part of others (like
sysadmins or netadmins) who can be uncooperative unless it's their ax
being gored.
I thought of a few approaches - probably not possible where the website
is hosted on someone else's webserver, but perhaps still of interest.
1. Client-side buffer overflows; in particular, this attack
apparently came from some sort of spider software, which may be poorly
written such that it's susceptible to buffer overflows in some part of
the returned data.
2. "Teergrube" (sp?) - I believe the word is German, and refers to
intentionally slowing something down. This technique has been used
against spammers; instead of blocking their traffic, one accepts it
very, very slowly, which ties up their machines. In this case, where
repeated requests are seen, I wonder if simply holding open the HTTP
connection - without sending data - would block the process on the other
side from making further requests until the first completes. Perhaps
they've multithreaded their repeated requests, but my hunch is that they
accidentally left a zero or two off of a refresh field, such that they
were getting results once per second instead of once per minute or
whatever.
3. Targeted DNS misinformation - when a DNS server for a domain
receives a request for information from a prohibited party, it returns
the loopback address (or other unhelpful information) instead of the
address of the webserver. (this might work for mail abuses, too.)
Is there an Apache module which allows redirection based upon requestor
address? I've been thinking about writing one, but my C is rusty.
--
Greg Broiles
gbroiles@netbox.com
