Support nftables

[ghost]

Hello, after Debian Buster was released a few days ago and iptables has now been switched to nftables, it would be nice if OSSEC also switches to nftables. Have you got anything planned?

[ddpbsd]

Not at the moment. What does nftables add above and beyond iptables?

[ghost]

I don't know, but the Debian team switched to nftables with buster. Does that make a difference for OSSEC?

[ddpbsd]

From the netfilter site:

Moreover, there is a backward compatibility layer that allows you run iptables/ip6tables, using the same syntax, over the nftables infrastructure.

So it sounds like iptables should still work while we figure out what needs to be done for nftables

[jskp4]

RHEL 8 also comes with nftables. In OSSEC, it should be enough to add a few lines to the firewall-drop.sh file.

[ritzmann]

Looks like this mostly works thanks to the iptables compatibility layer but I found that firewall-drop.sh ends up adding an additional rule "table ip filter" to the nftables ruleset, which is IPv4 specific, and renders my IPv4/6-agnostic "table inet filter" rule ineffective.

[kanyck]

I also vote for nftables support. The important difference is that nftables does not have rigid predefined structure that iptables has and allows creating arbitrary tables/rules etc. on demand. Therefore, compatibility layer will only work if nftables mimics iptables' structure, which is usually true if someone just translated existing iptables installation to nft, but is quite unlikely for a new installation. If so, using the compatibility layer may not work or even break the working firewall (which is the last thing I'd willing to happen) as in @ritzmann's report hereabove. So, as migration to nftables is going further, the nft integration's importance is growing. Otherwise instead of security enhancement one may eventually get unnoticed security breakage. Don't let this happen!

[ddpbsd]

@kanyck How can I help you get started?

[kanyck]

@ddpbsd Dunno yet... Just a little bit short-handed at the moment, and I haven't decided yet about what system I want to try out. Ossec seems probably the best choice at the moment, but yes, I'm slightly discouraged with necessity to (re)write all these actions to nft. Haven't looked in there yet, so I have no idea how difficult it may be (a good set of iptables rules makes me dizzy... so I jumped from shorewall that has hit its end-of-the-road to nft lately). At least fail2ban was quite easy to adopt for my need, yet it already has had properly configured nftables actions, I just slightly adopted them (like placing the ban rules to prerouting instead of input chain, because I use lxc, so, e.g. posfix-related packages never get into input chain). And if I understand correctly, f2b may be fully replaced with ossec, like few other things. If yes, it's a significant advantage. Nevertheless, your proposal is gratefully accepted and I'll let you know if I need help, thanks!

[ChristianBeer]

I took the liberty of changing one of my old scripts to support nftables. See PR #2029 for a script. Let me know if there are problems.

For the record this is my current very simple nftables configuration:

table inet filter {
        set ossec_ar4 {
                type ipv4_addr
                comment "ossec active response"
        }

        set ossec_ar6 {
                type ipv6_addr
                comment "ossec active response"
        }

        chain INPUT {
                type filter hook input priority filter; policy drop;
                ct state invalid counter packets 4 bytes 160 drop
                ip saddr @ossec_ar4 drop
                ip6 saddr @ossec_ar6 drop
                ct state established,related counter packets 307 bytes 27477 accept
                ip protocol icmp counter packets 0 bytes 0 accept
                ip6 nexthdr ipv6-icmp counter packets 0 bytes 0 accept
                iifname "lo" counter packets 0 bytes 0 accept
                tcp dport 443 counter packets 1 bytes 60 accept
                tcp dport 80 counter packets 0 bytes 0 accept
                #some more accept rules omitted
                meta nfproto ipv4 counter packets 37 bytes 1615 reject with icmp type host-prohibited
        }

        chain FORWARD {
                type filter hook forward priority filter; policy drop;
                meta nfproto ipv4 counter packets 0 bytes 0 reject with icmp type host-prohibited
        }

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