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 09:32:47 -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:
> Evgeniy Polyakov wrote:
>> On Tue, Jul 01, 2008 at 01:53:43PM +0200, Patrick McHardy 
>> (kaber@...sh.net) wrote:
>>> My two main objections are that this only works for TCP and
>>> can be trivially evaded. What use cases does it have?
>>
>> Yes, it is TCP specific module.
> 
> 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.

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.

	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

Powered by Openwall GNU/*/Linux Powered by OpenVZ