netdev - Re: Passive OS fingerprinting.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 01 Jul 2008 11:34:08 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Patrick McHardy <kaber@...sh.net>
CC:	Evgeniy Polyakov <johnpol@....mipt.ru>, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Subject: Re: Passive OS fingerprinting.

Patrick McHardy wrote:
> Jeff Garzik wrote:
>> Patrick McHardy wrote:
>>> What about the use cases? I certainly like the idea you suggest in
>>> your blog ("Ever dreamt to block all Linux users in your network
>>> from accessing internet and allow full bandwidth to Windows worm?")
>>> :) But something this easy to evade doesn't seem to provide a real
>>> benefit for a firewall.
>>>
>>> I can see that something like "Block IE6 running on Windows version X"
>>> might be useful (NUFW can do this I think), but that needs support
>>> from the host.
>>
>> Not addressing Evgeniy's module but speaking generally...
>>
>> It sure would be nice for regular socket applications to have an easy, 
>> unprivileged way to query the OS fingerprint information of a given 
>> socket.
> 
> I'm not sure how much OSF depends on the TTL, but doing this
> more than one hop away from the host (or without knowledge of
> the number of hops) makes using the TTL basically impossible.

The userspace version works quite well over the Internet:
http://lcamtuf.coredump.cx/p0f.shtml


>> Speaking purely from a userspace application API perspective, it would 
>> be most useful for an app to be able to stop OSF collection, start OSF 
>> collection, and query OSF stats.  start/stop would be a refcount that 
>> disables in-kernel OSF when not in use.
>>
>> To present a specific use case:  I would like to know if incoming SMTP 
>> connections are Windows or not.  That permits me to better determine 
>> if the incoming connection is a hijacked PC or not -- it becomes a 
>> useful factor in spamassassin scoring.
>>
>> In this case, incoming SMTP is -always- TCP, thus being a TCP-specific 
>> module is not a problem.  You cover a huge swath of apps even if the 
>> module is TCP-specific.
>>
>> Another use case is validating whether a browser is "lying" about its 
>> OS, when parsing HTTP user-agent info, or in general when any remote 
>> agent is "lying" about its OS.  Security software can use that as an 
>> additional red-flag factor. 
> 
> I for one would be much happier to only have netfilter as a user
> of this :)

I'm not sure I understand?  When site A connects to site B via TCP, is 
there a problem letting site A know the OS of site B?

	Jeff



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html