* Jan Engelhardt wrote, On 09/03/07 10:19:
quoted text
> Hello,
>
> On Mar 9 2007 09:35, Amin Azez wrote:
>   
>> * Jan Engelhardt wrote, On 08/03/07 20:26:
>>     
>>> xt_portscan needs to keep track of what packets the machine has already 
>>> seen. So on the first SYN, the connection is marked with "1". (Then we 
>>> send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
>>> packet that is received will be an ACK or an RST. But it must come 
>>> _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
>>> state which can be remembered is required. For that, an automaton is 
>>> used, whose state is saved in the connection mark.
>>>       
>> There would me more point in having this as a new match if it didn't
>> trample on the connection mark, but used it's own slot or flag-bit.
>>     
For the record, I support inclusion of this extension in general.
It is true to say "but a netfilter guru could craft together a sequence
of mark-consuming rules to do something somewhat similar" the same is
also somewhat true for connlimit (packet limits) and so on. The point of
this match is that people don't have to.
quoted text
> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct would
> increase the struct sizes, and that would penalize users who do not intend
> to use xt_portscan.
>   
I understand what you say but it sounds a bit like saying: "but we
didn't make it very good because so few people would use it anyway"
which of course makes it even less attractive. I realise you have your
own interpretation but this is how it reads to me.
quoted text
> I do not see why the packet/connection marks should not be used to record
> additional information
...
quoted text
> Almost never I required connection marking myself 
I guessed as much. I use it heavily, with my xml rule generators.
quoted text
> except for this
> portscanning automaton and perhaps a little MARK here and there for
> finely-tuned SNAT. Again, things might look different on your side(s).
>   
There's too many things fighting over the same few bits of the mark, and
in your case you are using it to track internal state of a connection
that has no relevance to the rest of the iptables/ebtables rules.

I'm suggesting that some of the people who would want to use the chaos
match, won't because of the mark issue.

This is not a new problem.

http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217
quoted text
> From: Tom Eastep <teastep <at> shorewall.net>
> Subject: Re: RFC: Disable defered bridge hooks by default
<http://news.gmane.org/find-root.php?message_id=%3c44AEFE20.3020307%40shorewall.net%3e>

quoted text
>
> Once again, netfilter marks are the solution of last resort. This is
> becoming very painful for those of us who produce general Netfilter
> configuration tools. The situation is exacerbated by the fact that
> ebtables doesn't support modifying the mark value via logical AND/OR and
> the other fwmark consumers (tc, ip) don't allow a mask when testing the
> fwmark value.

I suggested one solution
http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16244

and Patrick McHardy has suggested using ct_extend.

I've not looked into this further because I'm too busy doing xml
versions of iptables, ebtables, iproute anc tc.

[There's an ip route<->xml at:
http://mailman.ds9a.nl/pipermail/lartc/2007q1/020376.html
iptables now has xml<-> convertor ]

Sam
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/