Move to nftables, patches welcome?

Status
Not open for further replies.
P

pbxcom

New Member
Sep 15, 2021
13
0
1
Hi,

As you all know nftables is the default in Debian 11, looking at the Fusion install script one sees that iptables (legacy) is set as an alternative to nftables.

The rules that Fusion installs are not complicated and can be translated with a script using default tools available in Debian, and fail2ban can be made to work with nftables. I wonder why the need to use the legacy tools?

Is this something on a to do list or "when the time comes", or is there a reason/deps/scripts iptables still being used?

Just wondering, and if patches are welcome I will look into it. Thanks to devs/community for the nice project.
 
I would guess the primary reason the scripts still use iptables is because no one has spent the time to update it. I'm sure it is on a to do list for the developers but from what I've seen the list is long and who knows where this feature lands on the list.

Pull requests for contributions are often welcomed and accepted. Click here for more info on how to submit changes

Keep in mind an updated install script to use nftables should detect which version of Debian is being used so the correct firewall and fail2ban rules are created. There are many people who use the install scripts on earlier versions of Debian for various reasons.
 
I am also now working with nftables, primarily on our SIP platform, but I'm sure it is equally applicable to FusionPBX.

The iptables-translate function is helpful, but we do need to look at how differently nftables works, especially areas around ipsets which is now a builtin with nftables. It is now very easy to implement whitelists and blacklists as sets.

Also the Python interface is very useful (apt install python3-nftables).
 
markjcrane said:
I have actually started it by using tools that converted iptables commands to nftables
- https://github.com/fusionpbx/fusionpbx-install.sh/blob/master/debian/resources/nftables.sh

Its not finished yet as I haven't had time yet to do so. However I'm interested to finish it. Will also need to update fail2ban to use nftables for those that use fail2ban.
Click to expand...

@markjcrane I had a look at the link on github. I appreciate that it is a work in progress and not finished yet. It may be better to look at this fresh rather than try to adopt the iptables style. Whilst iptables-translate is a useful tool, it may not produce the best outcome. What you currently have in the github link could be written as an /etc/nftables.conf script like so:

Code: 
#!/usr/sbin/nft -f

flush ruleset

table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;

        iifname lo accept
        ct state { related, established } counter accept
        tcp dport { 22, 80, 443, 7443, 5060-5091 } ct state { new } counter accept
        udp dport { 1194, 5060-5091, 16384-32768 } counter accept
        icmp type { echo-request } limit rate 5/second accept

    }

    chain output {
        type filter hook output priority 0; policy accept;

        udp sport 16384-32768 counter ip dscp set 0x2e
        udp sport 5060-5091 counter ip dscp set 0x1a
        tcp sport 5060-5091 counter ip dscp set 0x1a

    }
}

Then issuing an sudo systemctl enable nftables will ensure the rules are loaded at server boot time.

I used ip because that is what you have done, but I prefer to use inet, because then the same rule set and be used for both IPv4 and IPv6. In the example above the port lists are implemented as anonymous sets, I would probably make the named sets so I can dynamically add or removed ports without reloading the rule set. White and black list are also very easy to implement as named sets. Also I would not use counter unless I needed the count for some reason.

Below is a very simple example configuration that allows whitelists. blacklists and services to be dynamically added or removed:

Code: 
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set black4list {
        type ipv4_addr
        comment "drop all packets from these hosts"
    }

    set white4list {
        type ipv4_addr
        flags interval
        comment "accept packets from these hosts"
        elements = { 192.168.22.0/24,
                     192.168.55.0/24,
                     192.168.4.10,
                     192.168.4.15 }
        }

    set services {
        type inet_service
        comment "ports for general services we offer"
        elements = { 22, 80, 443 }
    }

    chain input {
        type filter hook input priority filter; policy drop;
        iifname "lo" accept
        ip saddr @black4list drop
        ct state { established, related } counter accept
        icmp type { echo-request } limit rate 5/second accept
        ip saddr @white4list tcp dport @services accept
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

In the above example the forward and output chains are hooked but not used.
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

You can add or remove items from the named sets with commands like:
nft add element inet filter white4list { 192.168.88.5 }
nft delete element inet filter white4list { 192.168.88.5 }

I will be interested to see how this develops, and, of course, I'm always happy to help if I can.
 
Last edited:
Status
Not open for further replies.
Top Bottom