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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:30:30 PDT