Re: POM Xtables???

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> James King wrote:
>> On Wed, Jul 23, 2008 at 4:21 PM, Patrick McHardy wrote:
>>
>>> Just send it to netfilter-devel. If its the thing with lots
>>> of hard-coded binary matches full of magic values I'm not
>>> interested :) I'd be more interested in a discussion what
>>> would be necessary to represent all those matches through
>>> the FSM textsearch match or something similar.
 >>
>> ipp2p is the one with hard coded magic values.
>>
>> What are your feelings on the kernel version of l7filter (regex
>> patterns loaded from the filesystem)?  Currently it requires a patch
>> to add a structure to nf_conn, but I've been meaning to rewrite it to
>> use ct_extend so that it could at least be included into xtables-addon
>> and used with a stock kernel, although if there's interest in having
>> it merged into mainline I'd be willing to focus on that.

That is definitely a much better way than to hardcode the
matches. I think there is some interest in having this in
the kernel, yes.

>> One thing
>> I'm not sure of is whether the license used by the Henry Spencer regex
>> library it depends on is acceptable by kernel standards (or whether
>> it's permissive enough to relicense under GPL, as IANAL).

I know of the regexp.old.zip library, which IIRC used a GPL
compatible license (and a non-POSIX conform interface).

> If we want to do this in-kernel I think that it's better if it must use
> the textsearch infrastructure. Probably it would require some patches to
> extend the existing infrastructure.

I'd also prefer that over adding a regex library to the kernel.
I think one of the bigger problems is that there are dependencies
in the match that can't be easily expressed, like "byte 4 has
skb->len - 10". At least ipp2p does something like that. But
maybe thats not necessary, since l7filter already uses regexes
there's apparently a different method for doing this.

It would be useful if someone could post an excerpt from the
l7filter expressions or simply the entire patch.

> The other choise is userspace by means NFQUEUE. If we use some
> heuristics, we may try to classify the traffic by means of the initial
> data packets and then mark the connection. Thus, the number of packets
> that go to userspace would be small and the classification logic is
> implemented in userspace using whatever regex
> engine/aho-corasick/bit-wise/boyer-moore/bayes whatsoever...

Yes, thats another possibilty (and a lot of people are doing
that), but it would still be nice to have a mechanism for
doing this in the kernel.