[13423] in bugtraq
Re: usual iploggers miss some variable stealth scans
daemon@ATHENA.MIT.EDU (Hank Leininger)
Wed Jan 19 12:53:21 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <10001181343490.19485-100000@interpage.progressive-comp.com>
Date: Tue, 18 Jan 2000 14:10:02 -0500
Reply-To: Hank Leininger <hlein@PROGRESSIVE-COMP.COM>
From: Hank Leininger <hlein@PROGRESSIVE-COMP.COM>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
On 2000-01-18, Simple Nomad <thegnome@NMRC.ORG> said on bugtraq:
> > On Mon, 17 Jan 2000, vecna wrote:
> >
> > the five type of packets that can be used for stealth scanning, and
> > isn't logged from the normal tcplogd/scanlogger have this flag:
> This and all other TCP stealth scans can be eliminated by modification
> to most open source kernels. By adding code to the parts of the kernel
> that handle TCP input, you can look to see if a packet is a part of an
> existing conversation. If not, drop it (and perhaps log it).
[ snip - note that it is often exactly bugs in the is-this-an-existing-
connection lookup that os detection code exploits. ]
> This is basically taking advantage of a kernel's state table.
Hm, that sounds mighty familiar ;)
I've been maintaing a set of Linux kernel patches for a while now that do
exactly this, among other things:
http://www.progressive-comp.com/~hlein/hap-linux/
Documentation is guaranteed to be out of date; the curious should read
the code. Basically: before incoming packets are checked against the
kernel's state table looking for an active connection or a listening
socket, the flagset is sanity-checked and the packet is dropped & logged
on failure. Then, if the state-table-lookup fails, where normally an RST
would be silently sent, a rate-limited log message is generated along with
the RST. Something similar is done for unsolicited UDP traffic.
The patches need Solar Designer's Openwall patches to be applied first;
they rely on and add to some of his code as well. They do things besides
breaking the TCP stack, like enable some other additional logging, enforce
some protections from chroot(2)'ed processes, etc.
I'd be interested in comments on the ideas and/or code quality (which is
guaranteed to be lacking -- I'm a shitty coder). Various flavors of this
patch have been in use on a number of high-volume sites for some time but
of course YMMV. I've wanted to port this (or the appropriate parts) to a
couple of the BSDs as well but lack sufficient (time|clue|motivation).
Hank Leininger <hlein@progressive-comp.com>
