[SOL]nftables - managing .conf with dynamic ruleset compared to ipset?

drankinatty · Yesterday 07:48:14

[SOLVED]

My Arch server suffered a hardware POOF after 12 years of service[2]. Moved to backup box, but used nftables instead of iptables/ipset this time. nftables works well, but one issue is saving the config file.

With ipset, you simply used ipset -o save save > /etc/ipset.conf and it would save the sets in a form to be loaded by ipset on restart/reboot. With nftables, the wiki[1] suggests nft -s list ruleset > filename (/etc/nftables.conf). However this doesn't store the full config or preamble to destroy the current ruleset before reloading, e.g.

#!/usr/bin/nft -f
# vim:set ts=2 sw=2 et:

destroy table inet filter
...

The wiki does note

nft list does not output variable definitions, if you had any in your original file they will be lost. Any variables used in rules will be replaced by their value.

, and that is the point.

While you can script the preamble inclusion relatively easily, is there a better, more standard way to handle writing the config file after updating the ruleset so that all the original config is preserved?

I currently just cat the preamble and the ruleset to make the updated config -- and if there is no more standard way, that works fine

The other issue with capturing the ruleset as the next config is that it also captures all Fail2Ban additions as well, which can be lengthy. It works fine, so no complaints whether it's captured or not, but with iptables/ipset Fail2Ban additions were not captured but simply restored by Fail2Ban on restart/reboot. There doesn't seem to be a problem capturing the Fail2Ban additions in the nftables.conf. On restart/reboot Fail2Ban sees what it expects to be in the ruleset and from what I can tell is happy with it. Is there a problem with doing it this way that I may be overlooking?"

Sorry if that seem obvious, but I tend to want to double and triple check anything that I do that is exposed to the wider internet. Any advise/experience you can share on these issues would be appreciated.

[1] https://wiki.archlinux.org/title/Nftabl … t_rule_set
[2] it is a voltage issue somewhere, either MB/capacitor or in the processor itself. Verified with multiple power-supplies.

Last edited by drankinatty (Today 07:30:41)

dimich · Yesterday 08:37:51

drankinatty wrote:

it would save the sets in a form to be loaded by ipset on restart/reboot.

Not the answer to your question, but just reflection: isn't the point of dynamic rules precisely to fill it dynamically at runtime? I.e. default ruleset is written by user and stored in /etc/ntfables.conf once. After it is loaded, services extend the ruleset with their rules as they start, generating rules from own configs/databases etc.

seth · Yesterday 18:23:11

You're aware that https://wiki.archlinux.org/title/Iptables is just a shim wrapping nftables?
You can technically just continue to use it resp. configure nftables through it, https://wiki.archlinux.org/title/Nftabl … tables-nft

If you don't want to use that or some higher level abstraction like UFW you'd configure it w/ a text editor.
https://wiki.archlinux.org/title/Nftabl … t_rule_set is kinda more for transient preservation in persistent memory (at least afaiu)

Edit: this tab was kept open waaaaay too long

Last edited by seth (Yesterday 18:37:47)

-thc · Today 06:27:26

Are you aware that nftables supports dynamic sets and rate limits natively and that you can write a rate limiter? This somewhat replaces fail2ban (on a packet level).

This is a HTTP/S rate limiter I wrote for a small site:

        set ratelimit_block {                                                    # dynamic IPv4 set that is blocked for 15 minutes
                type ipv4_addr
                flags dynamic,timeout
                timeout 15m
        }
        chain prerouting {
                type filter hook prerouting priority -150; policy accept;        # the very early hook ensures the blocking decision is made before routing/NAT
                ct state established,related counter accept                      # AFAIK the connection state is established earlier than "prerouting" and we want "new/untracked" connections only
                iifname "enp3s0" ip saddr @ratelimit_block counter drop          # Any member of the dynamic block list is dropped here
                iifname "enp3s0" tcp dport { 80, 443 } ct state new,untracked limit rate over 30/second burst 20 packets counter update @ratelimit_block { ip saddr } log prefix "HTTP rate excess: "
                                                                                 # these HTTP/HTTPS rate limits are for a small self-hosted site
        }

And no - I never bother to save the dynamic table - in a worst case scenario it has to be "rebuild" by still ongoing port flooding.

Last edited by -thc (Today 06:30:08)

drankinatty · Today 07:29:09

Thanks dimich, selth, -thc, and "yes" pretty much to all, the interplay with iptables/ipsets and the rate limiter. (though I'll go back through the wiki, I know its all kernel filtering, but was a bit confused by the push to replace iptables/ipset with nftables, both as Arch defaults and in general) The ipset config just saves the commands to add IPs/CIDRs to the various sets.

My purpose is slightly different, I take a fairly proactive approach with the logs and journal. For brute-force attempts that don't resolve back to some rent-a-server (or many that do if from known abused registration areas) I manually add the IP or CIDR to one of two blocklists. Fail2Ban compliments that with it's own entries. What I want to make sure I'm doing is preserving my additions to the ruleset.

Rate limiting and Fail2Ban all rely on at least 2-strikes before you're out. For known problem IPs or Netblocks, I make it permanent, so there are no more strike-one's.

I guess for this I either have the option of just using a basic nftables.conf and then executing the file containing the list of commands to add the blacklist elements to the ruleset, e.g.

nft add element inet filter blacklist_net { xxx.xxx.xxx.xxx/ab, ... }
...

or, do as we were discussing by prepending the interpreter line and preliminary nft destroy ruleset to the output of nft -s list ruleset. What prompted the choice was a preference for the read of to total config at startup being more efficient than reading the basic config and then executing all the nft add instructions to add the rules. (I haven't tested load or time, so it may not be worth worrying about) But, that is why I was asking.

I'll go back and revisit the iptables wrapper and may just continue that way. This whole iptables/ipset to nftables move came after my server hardware just went POOF! (some thermal expansion triggered voltage instability, and after only 12 years of continual service too...) So internals will be here in the next day or so and when that system comes back up it will be using iptables/ipset. I'll do a side by side then.

Thank you all, that pretty much answers my question. I'll mark this solved.

Last edited by drankinatty (Today 07:34:46)

Arch Linux

#1 Yesterday 07:48:14

[SOL]nftables - managing .conf with dynamic ruleset compared to ipset?

#2 Yesterday 08:37:51

Re: [SOL]nftables - managing .conf with dynamic ruleset compared to ipset?

#3 Yesterday 18:23:11

Re: [SOL]nftables - managing .conf with dynamic ruleset compared to ipset?

#4 Today 06:27:26

Re: [SOL]nftables - managing .conf with dynamic ruleset compared to ipset?

#5 Today 07:29:09

Re: [SOL]nftables - managing .conf with dynamic ruleset compared to ipset?

Board footer