Messages in this thread | | | Date | Wed, 20 Mar 2002 16:56:52 -0800 | From | Charles-Edouard Ruault <> | Subject | [UPDATED] Problem on Linux 2.4 with usage of ip_default_ttl |
| |
attached is an updated patch fixing the following problem ( i missed one place where a change was needed in the patch that was posted yesterday ... )
--------------------------------original message -----------------------
Here's a small bug i've discovered yesterday in linux 2.4.18 :
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 ) and ICMP error messages - TCP RST .
They instead use hardcoded values ( MAXTTL ). From what i've seen all the other IP packets are using the value set by /proc/sys/net/ipv4/ip_default_ttl ( provided that the socket has been created after changing the value ).
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.... By sending a few packets to the target host, you can see wether the default ttl has been changed on the machine and therefore enforce other findings about the host.
I've written a small patch ( against kernel 2.4.18 ) that fixes this behaviour. I'm attaching it to this email. comments are welcome.
PS : please CC me in replies to this email, i have not subscribed to the list.
-- Charles-Edouard Ruault
[unhandled content-type:application/x-gzip] | |