Talking about recent (was: Re: [PATCH] 2.4.x new amanda conntrack + NAT support)

[Martijn Lievaart <m@rtij.nl>]

>
>
>Harald, what is the state of ipt_recent?  Will I see it soon?
>
>  
>

Talking about recent, I'm not completely happy with the way it is now. 
If I understand things correctly the rcheck decission on matching source 
or destination is not done based on the commandline, but on 
tables->side. But iirc the rsource/rdest argument is happily accepted on 
the rcheck and subsequently ignored. This could be a useful feature, let 
the user decide. In fact, I think the table->side is unneeded, it can 
always be specified at the cost of a little work from the user. I'm 
running such a patch at home, but it is incompatible with existing 
ipt_recent as it ignores table->side. Such would break existing 
installations. I think I see a way of making this work without breaking 
any compatibility. I'll submit a patch once I have it working, based on 
the new recent module.

Why is this useful? F.i. track all outgoing connections and reject with 
tcp reset incomming idents that match the table. Otherwise fall through 
to the default drop. This would need a reversing of source and 
destination between the --set and the --rcheck. This would allow a real 
stealthy firewall that still handles idents in a sane way. I once looked 
at creating a helper for this, but that would need some major surgery on 
the iptables core I think. Using the recent match would be a rather 
clean solution at the cost of some additional memory used. Also, other 
dynamic protocols could be made a little safer by this as well, pending 
a real contrack helper.

(Yes, I know there is a feature freeze, but I'm not in a hurry)

Martijn Lievaart