Fingerprinting Hardware over the Internet??

I agree, Interesting read indeed. The paper was rather large ( 10.2 meg )

Quote:

Anonymous Internet access is now a thing of the past. A doctoral student at the University of California has conclusively fingerprinted computer hardware remotely, allowing it to be tracked wherever it is on the Internet.

Can you say sensationalism ?

Discounting the above statement, I am in no way bashing the author. I really did enjoy the paper.

My first question that came to mind when reading the article concerned NTP.

After reading through the paper I did not have my question answered.

Although they show a test of two Operating Systems ( RH 9.0 and XP SP2 ) from a single machine, both with and without NTP, they do not indicate the length of time over which this comparison was done for the RH 9.0 machine, only that the Windows machine was up for an hour. NTP will, if no DRIFT file is present, take upwards of an hour to settle down and write a DRIFT file.

( Interesting too in the above is that two operating systems from the same machine have very different " skew estimates" , for both TCP and ICMP Timestamps, and very large differences when comparing the ICMP timestamps within each OS with and without NTP enabled. )

What would happen if all " fingerprintees " in their HOMOGENOUS LAB used NTP ? Would there still be " unique" fingerprints? And how does updating NTP more frequently affect the outcome? As suggested in the paper they used the fact that all the OSs tested do not use NTP in a default install. How would this affect their “ counting the number of devices behind a NAT “ ?

From what I read, the ICMP Timestamp method requires that
a) does not maintain its system time via NTP or does so infrequently
b) the subject ( " fingerprintee " ) must reply to ICMP Timestamp Requests

Again, the default installs used adhere to this. As noted, firewalls could easily defeat this method.

My observation of this ( and I could be wrong ) is the only real use of this is identifying virtual hosts ( especially honeynets ), and apparently some developers are already taking steps ( the authors indicate because of their correspondence ) to mitigate this.

And here is one for M$: The Windows machines tested ( Win2k and XP ), by default, are less prone to the " TCP Timestamp " fingerprinting because they don't include the " TCP Timestamp option from RFC 1323 " by default. Although they mention a way to " trick " them into using it, it is no longer a " passive " scan, but I don't think they elaborated on that enough.

( By the way, to my first question above: my first thought was to set up a script to stop NTP, rewrite the DRIFT file with some random number within tolerance, then restart NTP. Although that now seems unnecessary, any thoughts on that ? )