Date:	Tue, 01 Jul 2008 15:41:58 +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 02:35:19PM +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.
>>     
>
> Actually worm detection is one of the use cases - I was told about
> successful installations several years ago.
>   

How does that work? I assume in combination with some kind of
rate-limit?

>>>> 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.
>>     
>
> OSF does increase expressiveness! :)
> '--genre Linux' is much more clear than... Do you want me to at least
> roughly draw mathing rules enciphered in u32 format?
>
> I agree that matching can be done with u32 (even private OSF TTL games),
> but it will much much much more ugly than simple module.
>
> I am also not sure OSF should live in kernel, but what it does it does
> good and there is no simple way to do the same with existing
> functionality. It is possible, but not simple, and definitely not
> trivial for administrator :)
>   

I don't like the current way such things are implemented in iptables
(have all logic in the kernel instead of just providing a mechanism
for implementing it in userspace and presenting a nice view to the
administrator). Thats not your fault of course and your module is
also not the first one to do this.

Unfortunately its most likely not possible to convince me to like
this, so lets just say that I'm fine with merging it if someone
speaks up in favour of it :)

>>> 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.
>>     
>
> IIRC there are at least threee: w1, various accountings and uvesafb.
> And I authored only the first :)
>
> There was no nfnetlink either 5 years ago, when OSF was created,
> this release is just subsequent update to the project.
> At some moment OSF shared netlink group with ulog, but it was
> considered harmful, so I dropped support. Netlink usage is
> rather trivial: it just sends information about matched packt to
> userspace, so it can block it on its own, rise a message in the window
> or perform some other steps. Nothing exceptionally complex :)
>   

Yes, but I don't want to add another interface netfilter userspace
has to know about. It should either use nfnetlink and remove the proc
interface, or remove the connector interface and use proc.
Preferrably the former.

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