OS signature with wierd TTL

[nstylepro]

"Android 4.1.x" in tcp.xml has TTL of 60 - is this something that is implemented OS wise? this issue creates a problem when computing near TTL, as sometimes a packet can be 5+ hops away from the recording device. how do you treat that possibility?

[xnih]

Typically TTL's: 255 128 64

There are some one offs for sure like 16, 32 (old windows and other devices from the 90's), and 60 that are the starting TTL on the device. So anything over 3 hops away can be problematic for sure, for any devices with an actual TTL of 64.

https://github.com/xnih/satori/blob/master/satoriTCP.py

computerNearTTL attempts to handle the general change in TTL due to hops, but is not perfect by any means: def computeNearTTL(info): if (info>0) and (info<=16): ttl = 16 ethTTL = 16 elif (info>16) and (info<=32): ttl = 32 ethTTL = 43 elif (info>32) and (info<=60): ttl = 60 #unlikely to find many of these anymore ethTTL = 64 elif (info>60) and (info<=64): ttl = 64 ethTTL = 64 elif (info>64) and (info<=128): ttl = 128 ethTTL = 128 elif (info>128): ttl = 255 ethTTL = 255 else: ttl = info ethTTL = info return [ethTTL, ttl]

So devices that have a real TTL of 64, but are 5 hops away are going to be checked in the fingerprint file for 60, so it won't be found.

I'm not sure how many devices that are "current" would actually have a 60 TTL, it may be worth tweaking that code to something more like this:

elif (info>32) and (info<=64): ttl = 64 ethTTL = 64

Doing this will of course break any detection of fingerprints that have a value of 60 in it. So I'll have to either tweak those fingerprints or just accept that they aren't useful anymore.

Another possible fix would be to actually have anything that gets flagged as a nearTTL of 60 to be run through a 2nd time with a nearTTL of 64. No fingerprints would have to be updated, but this may give a bit more possible OS's that get spit out.

I'll have to think more on this, for all my setups with Satori I don't think I've ever been more than 3 hops away, but with networks the way they are anymore I can see where this could cause problems!

[xnih]

So for fingerprints with 60 for the TTL the ones that wouldn't work if over 3 hops away: AIX 5.2 Android 4.1.x Brother MFC 7820N Cisco ATA 186 FreeBSD 3.4, 4.2-4 Linux 2.2.x and 2.4.x Mac OS X 10.10.x (and others) etc...

Note many of those have some 64 TTL fingerprints in them too.

So yeah definitely something I'll need to look at a bit more. Thanks for bringing it up. Hadn't run it at all any any networks with more than 3 hops from where the device was and where I was capturning from.

[nstylepro]

thanks for the detailed explanation! waiting to see what you decided about those values

[xnih]

As I haven't seen anything new with the TTL of 60 in a long time, I updated satoriTCP.py today with the fix outlined here:

I'm not sure how many devices that are "current" would actually have a 60 TTL, it may be worth tweaking that code to something more like this:

elif (info>32) and (info<=64): ttl = 64 ethTTL = 64

Doing this will of course break any detection of fingerprints that have a value of 60 in it. So I'll have to either tweak those fingerprints or just accept that they aren't useful anymore.

I may revert at a later date, so I just commented out some lines, but I don't believe this will break much. My main goal has always been local network stuff though, not internet hosted ones per se, so this issue wasn't one that affected local inventory issues, which is why it has been slow in being fixed as I wanted to ensure local inventory over internet based ones.