[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <486A4E70.3000603@garzik.org>
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
Powered by blists - more mailing lists