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]
Message-ID: <486A2487.2010303@trash.net>
Date:	Tue, 01 Jul 2008 14:35:19 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
CC:	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: Passive OS fingerprinting.

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.

>> I'm also wondering whether this couldn't be implemented
>> using the u32 match.
> 
> I'm not sure it is that simple. OSF uses common rules database
> shared with OpenBSD (and other *BSDs as well), so converting it into u32
> match would require noticeble efforts. But in theory it is probably
> doable.

This would be preferrable in my opinion since they both allow
programmable filters, but u32 appears to be more flexible. I'm
very reluctant to add new iptables modules that don't increase
expressiveness or provide other clear benefits since we already
have an insane amount of modules.

 From the fingerprint file:

# Fingerprint entry format:
#
# wwww:ttt:D:ss:OOO...:OS:Version:Subtype:Details
#
# wwww     - window size (can be *, %nnn, Snn or Tnn).  The special values
#            "S" and "T" which are a multiple of MSS or a multiple of MTU
#            respectively.
# ttt      - initial TTL
# D        - don't fragment bit (0 - not set, 1 - set)
# ss       - overall SYN packet size
# OOO      - option value and order specification (see below)
# OS       - OS genre (Linux, Solaris, Windows)
# Version  - OS Version (2.0.27 on x86, etc)
# Subtype  - OS subtype or patchlevel (SP3, lo0)
# details  - Generic OS details

MSS can be matched using the tcpmss match, options (but not order)
using the tcp match, TTL using the ttl match, DF using the IP flags
match, packet size using the length match. That leaves WS for u32
(or adding support to the tcp match).

The conversion looks pretty easy actually.

>>> # iptables -I INPUT -j DROP -p tcp -m osf --genre Linux --log 2 \
>>> --ttl 2 --connector
>> And I don't think it should be using connector. AFAIK we
>> only have a single user in the tree currently and new
>> stuff usually uses genetlink (which is pretty similar),
>> so we might be able to remove connection in the future
>> unless we add new users. But netfilter modules should
>> use nfnetlink anyway.
>  
> This module was created way before genetlink was ever designed (on
> behalf of connector btw :)

Yes, I know.

> Also I do not know why we want to remove connector in favour of
> genetlink, since the former is much simpler to work with. Connector
> logging is optional in OSF.

I'm not sure if we want to, but they appear to provide similar
functionality and connector only has a single user in the tree
so far. But thats a different discussion, for netfilter related
things nfnetlink should be used.
--
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