mailing list archives
Re: Identifying Kernel 2.4.x based Linux machines using UDP
From: Charles-Edouard Ruault <cruault () 724 com>
Date: Tue, 19 Mar 2002 11:09:05 -0800
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
. 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
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 (ofir () atstake com)
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
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
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
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
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
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.