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
