Make `custom_tables` for nftables smarter
Opened this issue · 0 comments
DFW has to be able to act on traffic when it traverses any one of the input
or forward
hooks. This can be achieved in one of three ways:
-
Have no other tables that hook
input
orforward
, leaving only DFW's table.This is not really feasible, because that would leave you with an entirely open firewall, at least until DFW has run.
-
Ensure that any existing tables that hook
input
orforward
don't drop the traffic before it reaches DFW's tables.This is not great if you want your
input
hook to have adrop
policy, which I personally would always want, just to make sure I don't accidentally expose any port I didn't intend to expose. -
Let DFW know about any existing tables and chains that hook
input
orforward
.This is what the
custom_tables
setting does and it give us the best of both worlds: we can ensure that DFW can correctly accept traffic it is responsible for while still being able to defaultdrop
traffic in theinput
hook.
It is fair to assume that most default nftables installations will have the inet
table with chains that hook input
and forward
, so it would be nice if the user didn't have to specify the custom_tables
configuration.
One way to not require the user to do this would be to run nft --json list ruleset
within DFW, parse the JSON output and identify the chain that acts on the traffic first (i.e. the one with the highest priority value). DFW can then hook into these chains as it does when custom_tables
is defined.
(Relates to #705.)