Hi, now that you're bringing the subject on the table, i'll follow up with a small bug i've discovered yesterday ... On Linux you can "customize" the default ttl that will be used in all the IP packets that the box will be sending ( using /proc/sys/net/ipv4/ip_default_ttl ) . One of the main reasons to do that , as it has been said in many articles, is to make your machine a little bit more difficult to fingerprint. However, while playing with this feature, i've discovered that the current kernel ( 2.4.18 ) and probably earlier versions, don't use this default value when generating the following packets : - ICMP reply ( of any kind ) - TCP RST . Therefore, changing the ip_default_ttl on a standard kernel might do the opposite of what you're trying to achieve : make it much easier for an attacker to fingerprint your os.... I've written a small patch ( against kernel 2.4.18 ) that fixes this behaviour. I'm attaching it to this email ( i've also posted in on the linux-kernel mailing list ). comments are welcome. Ofir Arkin wrote: > Subject: Identifying Kernel 2.4.x based Linux machines using UDP > > Author: Ofir Arkin (ofirat_private) > > > Linux Kernel 2.4.x has a bug with the UDP implementation which allows > both active and passive fingerprinting of Linux machines based on the > 2.4.x Kernel. > > The following is a simple nslookup query initiated from my Kernel > 2.4.10 based Linux machine: > > 03/16-11:49:41.531642 192.168.1.200:1024 -> x.x.x.x:53 UDP TTL:64 > TOS:0x0 ID:0 IpLen:20 DgmLen:63 DF > Len: 43 > BC 0D 01 00 00 01 00 00 00 00 00 00 03 77 77 77 .............www > 03 63 6E 6E 03 63 6F 6D 05 6C 6F 63 61 6C 00 00 .cnn.com.local.. > 01 00 01 ... > > The IP Identification field value with the UDP datagram is zero (0). > The value will be constant and will not be changed for future UDP > datagrams I will be sending. > > The problem is not only with generating UDP datagrams, but also with > answering UDP queries. With the following example I have sent a UDP > datagram to the ECHO service on a Linux 2.4.18 based machine: > > 03/16-12:13:17.388211 192.168.1.200:1775 -> y.y.y.y:7 > UDP TTL:64 TOS:0x0 ID:28256 IpLen:20 DgmLen:28 > Len: 8 > > 03/16-12:13:17.547636 y.y.y.y:7 -> 192.168.1.200:1775 > UDP TTL:50 TOS:0x0 ID:0 IpLen:20 DgmLen:28 DF > Len: 8 > > The IP identification field value with the answer is zero (0). It will > also be constant and will not changed if we further query the target. > > The biggest problem is the ability to use legitimate applications, > such as DNS queries with nslookup, and by sending and receiving one > packet only to have the ability to fingerprint the 2.4.x Kernel branch. > > The 2.2.x kernel branch seems not to be affected according to my tests. > > Combined with another fingerprinting method using ICMP this time > (http://www.sys-security.com/archive/bugtraq/ofirarkin2001-03.txt), we > are able to fingerprint the 2.4.x kernel branch and divide it into two > groups - 2.4.0-2.4.4 kernels, and the 2.4.5-2.4.18 kernels. > > -- Charles-Edouard Ruault
This archive was generated by hypermail 2b30 : Wed Mar 20 2002 - 23:15:32 PST