Nftables: a new packet filtering engine
Nftables: a new packet filtering engine
Posted Mar 25, 2009 0:07 UTC (Wed) by herge (guest, #57423)Parent article: Nftables: a new packet filtering engine
- no session replication between two firewalls.
- rule-matching should be done only for the first packet of a connection. Actually it is done per packet when using the filter table. While you can do this with PREROUTING, it should be done as a standard.
- RELATED state whould be handled natively, ne need to add RELATED rules for this.
- matching TIME_WAIT state as a default is dangerous : a short-lived TCP connection will be maintained in the connections' table for too long.
- using macro for rule maintenance, as done by pf.
pf and most commercial firewalls perform that way. Iptables' design is way broken.
Posted Mar 25, 2009 1:12 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
you can match on every packet of the connection. most people don't bother, but all you have to do is to not put 'if established allow' at the top of your ruleset.
the question of what is done automaticaly and what should be done explicitly can be argued forever, I see this as significantly weakening your RELATED complaint.
where does it match TIME_WAIT by default?
as for macros for rule management, with iptables you can use whatever tools you want in userspace to create your rules.
the things you are listing as drawbacks don't seem as drastic to me as they seem to appear to you.
Posted Mar 25, 2009 10:50 UTC (Wed)
by herge (guest, #57423)
[Link]
Once a connection has reached the TIME_WAIT state, it will be kept in the connection table for 120s.
Posted Mar 25, 2009 2:16 UTC (Wed)
by bduncan (subscriber, #6886)
[Link]
I for one, am eagerly awaiting nftables!
Posted Mar 28, 2009 3:57 UTC (Sat)
by rusty (guest, #26)
[Link]
Well, that's not really a core iptables responsibility, IMHO.
> - rule-matching should be done only for the first packet of a
Um, this is pretty trivial to set up. You probably want something like:
Then put your rules in the NEWPKTS chain. (For simpler setups, you
> - RELATED state whould be handled natively, ne need to add RELATED rules for this.
But if someone wants to log related packets, such an implicit rule would be a PITA.
> - matching TIME_WAIT state as a default is dangerous : a short-lived TCP
There's an argument that the assured bit should be reset for TIME_WAIT conns (which makes the eligible for reaping if we need to make space), but you have to keep tracking conns through TIME_WAIT; the state is there in TCP for a reason!
> - using macro for rule maintenance, as done by pf.
This, I think, is your real issue: iptables is too low-level. I agree, but it was a deliberate decision to leave building the higher levels to someone else. As I've alluded elsewhere, it didn't really work.
> pf and most commercial firewalls perform that way. Iptables' design is
See above.
Hope that clarifies,
Nftables: a new packet filtering engine
Nftables: a new packet filtering engine
# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
120
While it can be tuned down, thei behavior should be dropped IMHO.
Nftables: a new packet filtering engine
Nftables: a new packet filtering engine
> - no session replication between two firewalls.
> connection. Actually it is done per packet when using the filter table.
> While you can do this with PREROUTING, it should be done as a standard.
iptables -N NEWPKTS
iptables -A INPUT -m state --state NEW,INVALID -j NEWPKTS
can just have your first rule accept all ESTABLISHED and RELATED packets).
> connection will be maintained in the connections' table for too long.
> way broken.
Rusty.