Nftables issues with modular rulesets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all!

I've been evaluating nftables a bit for a modular firewall setup. The
modular setup means that I'm trying to allow different services to
change the base firewall configuration, for example by opening ports
for themselves. I've met a few issues which I would like to share. I'm
a new nftables user, so my questions and issues may be already answered
somewhere, but bear with me. :-) 

1. There is currently no way to stop processing lower-priority chains
and accept a packet. For example, consider the following file:

table inet filter {
    chain ssh {
        type filter hook input priority 0; policy accept;
        tcp dport ssh accept;
    }

    chain input {
        type filter hook input priority 1; policy drop;
    }
}

The ssh chain gets run first and accepts packets coming to ssh port,
but then the default rule kicks in and drops all packets. The earlier
chains can drop and reject packets, but they can't accept them. I'm
doing packet marking to get this to work right now. One solution would
be to have a new verdict "accept_and_stop", which would accept the
packet and stop processing lower-priority chains, being symmetric to
drop and reject.

2. It would be nice if there would be set operations available. For
instance, I'm having sets with network interfaces. It would be cool to
match to a union, intersection, and complement of two sets: "union @lan
@wan" or similar.

Btw, I think the difference between anonymous defined sets

define local_ifs = { lo, eth0 }

and named sets

set local_ifs {
    type iface_index
    elements = { lo, eth0 }
}

could be documented better. I noticed that at least I can't define
empty anonymous sets ("define local_ifs = {}" fails), so I guess I
can't add or remove elements to/from those either. I have some
situations where the interfaces are changing dynamically (such as vpn
interfaces), so mutable sets are a must.

3. I can't import rulesets twice on global level. I wanted to do a
"variables.ruleset" file, which would contain some packet marks and so
on that could be included to all the rule files that I wanted to load,
I would meet a lot of "redfinition of symbol" error messages. It would
be nice to have something like "#pragma once" for include files. There
is also a typo in the word "redfnition". :-)

4. Nft can't add two chains to the same table from two included files
(or one file with the table defined two times). However, this works
fine if the two files are loaded in sequence using to "nft -f"
commands.

For example, if I tried to load a rules.ruleset file that looked like
this with "nft -f rules.ruleset":

table inet filter {
    chain ssh {
        type filter hook input priority 0; policy accept;
        tcp dport ssh accept;
    }
}

table inet filter {
    chain input {
        type filter hook input priority 1; policy drop;
    }
}

I would receive an error message: "rules.ruleset:8:2-3: Error: Could
not process rule: No such file or directory." This error message is bit
odd, since it feels to the user that all necessary files and
directories are in place... However, if I had two files like this:

file rules.ruleset:

table inet filter {
    chain input {
        type filter hook input priority 1; policy drop;
    }
}

file ssh.ruleset:

table inet filter {
    chain ssh {
        type filter hook input priority 0; policy accept;
        tcp dport ssh accept;
    }
}

and then loaded those files with two "nft -f" commands, everything
would go fine and I would get the result I expected. This makes it
difficult to include configuration files into other configuration
files. A workaround is to define only chains in included files and
include them into the table, but this makes the included files to be
not able to be loaded individually.


I already submitted a patch for the include directory use case, which
was one of my issues, and Florian Westphal wrote a patch to allow sets
that contain interface names, which was another blocker for me. Nft
looks like a huge improvement to iptables for making a modular non-
centralized firewall rule set that doesn't need very much administrator
interaction. I think there could still be some improvement for the
modular configuration ability and possibly even some documentation for
especially this use case.

Ismo��.n��������+%������w��{.n����z��׫���n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux