Re: xt_connlimit 20070620_2

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> On Jun 22 2007 13:43, Patrick McHardy wrote:
> 
>>I didn't realize that. Still, why doesn't it support all protocols?
> 
> 
> It suppers all protocols that Netfilter supports, surprise surprise :)
> -A OUTPUT -p udp -m connlimit uses what Netfilter considers an UDP
> connection. /proc/net/ip_conntrack shows that. Of course these UDP
> "connections" expeire within 30 seconds by default, but that's another problem. 


OK, that fine then.


> 
> 
>>>>Also nothing guarantees that you're looking at a TCP connection here.
> 
> 
> Which is why I asked how to find out I am actually looking at TCP.
> There's tuple.proto or the proto field in struct nf_conn, but the question is,
> which one should I use, or are both the same?
> 
> 
>>>True that. What is the SCTP state (include/linux/netfilter/nf_conntrack_tcp.h)
>>>I am looking for? (And DCCP does not seem to have states.)
>>
>>SCTP states are defined in the .c file itself I think.
> 
> 
> Conntrack states are needed. For TCP this is TCP_CONNTRACK_TIME_WAIT.
> Hence I think all states that could possibly exist (as far as conntrack is
> concerned) are listed in netfilter/nf_conntrack_<proto>.h


Indeed, its in include/linux/netfilter/nf_conntrack_sctp.h.
I'm wondering why its looking at the states though, a conntrack
in TIME_WAIT state is still a conntrack.

>>>Sorry, what state?
>>>Each rule keeps its own list of known connections, yes :-/
>>
>>Thats the state. It will forget them every time you change _anything_
>>in the ruleset. On second though, I guess it doesn't matter because
>>the state can be entirely reconstructed at runtime?
> 
> 
> Yes there is a user-administrator race. For example,
>  * host opens N connections (and hits the connlimit limit) and new
>    connections are rejected
>  * administrator reloads ip tables
>  * now, the next N that are seen -- which may not even be the *original*
>    connections -- are allowed, so the older ones could get magically
>    disconnected.


That sucks a bit.

> And: a lot more netfilter matches might be affected by this. hashlimit 
> comes to mind. I'd say this is an administrator issue and a justified 
> sacrifice to take.


No, hashlimit looks up the state from a global list. It behaves
strangely when changing parameters without deleting the table
first though.