[ntp:questions] Re: Fingerprinting hosts by clock skew

Brian Utterback brian.utterback at sun.removeme.com
Thu Mar 10 15:20:51 UTC 2005


John Pettitt wrote:
> mayer at gis.net wrote:
> 
>>----- Original Message Follows -----
>>
>>
>>>At 4:52 PM -0500 2005-03-09, mayer at gis.net wrote:
>>>
>>>
>>>
>>>>It's not worth bothering with all this. I've seen code that use two
>>>>or three ICMP messages to fingerprint your system and tell exactly
>>>>what you're running for O/S and hardware. You don't even need to
>>>>worry about the clock. It can tell just be looking at how it
>>>
>>>handles the message.
>>>
>>>   I know about nmap, and I have some idea of how it works.  One 
>>>problem is that a lot of places block ICMP, and many host-level 
>>>firewalling implementations will do the same.  Operating systems like 
>>>OpenBSD will randomize certain aspects of any response packets that 
>>>do get sent back, and the result will be a machine that will be 
>>>difficult or impossible to determine what they're running.
>>>
>>
>>
>>This technique has nothing to do with nmap. It's something else
>>entirely.
>>Unfortunately I don't remember any of the details.
>>
>>Danny
> 
> 
> 
> It's not about fingerprinting operating systems - it's about
> fingerprinting specific machines but their clock skew - ntp would
> render the technique unworkable except that the clock used by the tcp
> stack is not the kernel clock that's disciplined by ntp.
> 
> It's an interesting technique that should be relatively easy to defeat
> if the people maintaining the TCP stack choose to do so (either by
> introducing some random jitter or by using an ntp disciplined clock or
> both).
> 
> John

I don't think random jitter would do it. The technique described
involves plotting an actual time interval versus the time interval
as measured from the TCP timestamp option. to be useful, the timestamp
option must be monotonically increasing (modulo the wraparound) and
represent something like the actual time interval. This limits the
amount of jitter you can apply, and if the random jitter is applied
to the counter already used, then it just "fuzzes" the band that
is plotted. The band will still have the same long term slope,
which is what is used for identification purposes.

What you really need is random, per connection "skew factor", some
number that you multiply the counter by to change the frequency
of each connection.

Or, better still, get the multipler from the current in core value
for the clock frequency correction set by NTP so that whatever
is being counted by the counter, it is adjusted to match the actual
interval expected.  The problem with the NTP approach is that the
factor chnages with time is NTP is in use, so you need to be careful
that the counter doesn't go backward if you are multiplying, and
what do you do if NTP is not in use?

-- 
blu

I voted electronically...I think.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom



More information about the questions mailing list