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 for Android: free password hash cracker in your pocket

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

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

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.

> 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 :)

--
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