[13514] in bugtraq
Re: usual iploggers miss some variable stealth scans
daemon@ATHENA.MIT.EDU (antirez)
Sun Jan 23 19:42:07 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000122150248.A226@nagash.suidshell.net>
Date: Sat, 22 Jan 2000 15:02:48 +0100
Reply-To: antirez@invece.org
From: antirez <antirez@INVECE.ORG>
X-To: bugtraq@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <4036B8ED3AAED3118F9E00A0CC58F9F1864F@MAIL>; from
OFriedrichs@SECURITY-FOCUS.COM on Wed, Jan 19,
2000 at 11:36:01AM -0800
On Wed, Jan 19, 2000 at 11:36:01AM -0800, Oliver Friedrichs wrote:
> variables in a stack unrelated to TCP state that can be used to identify
> an OS - and are also virtually impossible for someone to fix. Virtually
> every commercial and free OS supports different IP otions, and will
> handle them in different ways. It would be virtually impossible to get
> every vendor to synchronize what they support. TCP options give you
> even more variety. CyberCop Scanner 5.5 uses a variety of these methods
> to identify the target OS.. Anthony Osbourne can probably comment more
Also it's possible to use the ID field of the IP protocol to check if
some host are Win*, OpenBSD > 2.5 or Other using a few of often not logged
packets. the Win* ID has different byte ordering, OpenBSD is truly-random
and others incremental. IMHO it's a lot important that OS detection is
done using few often not logged packets. For example the algorithm used
in nmap and in queso does a fixed number of tests and checks if the profile
match a table. A better algorithm may do an initial test using only
not logged packets and do all tests only if required. A lot of people think
that OS detection is just a joke but think at buffer overflows: what shell
code the attacker will use?
About the flags not logged by iplogger the correct way to avoid this is
to log all packets that does NOT match a list of "sane" packets.
The 'unclean' module of Netfilter do a lot of checks in order to discard
all not standard packets: it's a good idea if you are frustrated by
TCP/IP-stack attacks. Anyway since using IP ID you are able to do a SYN
scan using a fake IP address maybe it's more important to fix the
ID predictability issue than iplogger.
Finally: if OS TCP/IP stacks synchronization is so hard to reached maybe
we need some RFC that comments all not clear TCP/IP issue? I want hope
that vendors (except Microsoft...) will follow the RFC.
antirez
