{"id":70,"date":"2020-09-23T11:50:13","date_gmt":"2020-09-23T10:50:13","guid":{"rendered":"https:\/\/www.xciv.org\/blog\/?p=70"},"modified":"2020-09-23T15:19:42","modified_gmt":"2020-09-23T14:19:42","slug":"debian-migration-to-nftables","status":"publish","type":"post","link":"https:\/\/www.xciv.org\/blog\/2020\/09\/23\/debian-migration-to-nftables\/","title":{"rendered":"Debian migration to nftables"},"content":{"rendered":"\n

If you have upgraded to Debian 10 buster you will know (if you have read the release notes<\/a>) that Debian has now migrated to the nftables filtering framework.<\/p>\n\n\n\n

See 2.2.6. Network filtering based on nftables framework by default<\/em><\/p>\n\n\n\n

What is not covered is how you do this and what it really means.<\/p>\n\n\n\n

The release notes say “nftables provides a full replacement for iptables<\/em>” and this is almost true but not quite and I’ll come on to that at the end.<\/p>\n\n\n\n

First off, it should be noted that what we’re actually really doing is changing our filtering ruleset from being defined in iptables format to being defined in nftables format.<\/p>\n\n\n\n

To convert our existing iptables ruleset to nftables we first need to save a copy of our iptables rulesets:<\/p>\n\n\n\n

iptables-save > iptables-active.txt
ip6tables-save > iptables6-active.txt<\/code><\/p>\n\n\n\n

Once we have these we can convert them to nftables:<\/p>\n\n\n\n

iptables-restore-translate -f iptables-active.txt > nftables-active.txt
ip6tables-restore-translate -f iptables6-active.txt > nftables6-active.txt<\/code><\/p>\n\n\n\n

You can use these auto translated rulesets, or…<\/p>\n\n\n\n

Now comes a big change, nftables is dual stack v4\/v6 capable so you can merge a lot of your rules into single statements rather than have two completely separate sets of rules.<\/p>\n\n\n\n

However, the new functionality can’t cope with a completely combined ruleset if you are doing more complex filtering, simply because IPv4 and IPv6 work differently.<\/p>\n\n\n\n

That said, I have managed to condense two completely separate rulesets down to one ruleset with three duplicate rules in one file. This is definitely easier to manage.<\/p>\n\n\n\n

The new rulesets live in the \/etc\/nftables.conf<\/code> file and this is an executable \u2014 it’s actually a script to perform an atomic update, that is, when you run it the rules are parsed and if there are any errors the whole ruleset update is rejected.<\/p>\n\n\n\n

This is a useful change as it means that you can’t apply half a ruleset if you have a typo or syntax error. Either the rules install in whole or they don’t.<\/p>\n\n\n\n

On my system I moved the stock empty rules file to \/etc\/nftables.conf.clear<\/code> to retain a quick fallback script to clear the whole ruleset if ever needed.<\/p>\n\n\n\n

If you are using iptables-persistent<\/code> to install your old iptables rulesets you should now remove this package (or your alternative startup method) and reboot.<\/p>\n\n\n\n

Once you’ve confirmed that the iptables rules are no longer loaded from startup you can run \/etc\/nftables.conf<\/code> to load your new nftables ruleset.<\/p>\n\n\n\n

(if you aren’t 100% sure about your new nftables ruleset it might be an idea to run a sleep 30; \/etc\/nftables.conf.clear<\/code> in a screen session to automatically clear the rules to prevent you being locked out)<\/p>\n\n\n\n

Once this is all working you can use systemd to load the nftables rules at boot:<\/p>\n\n\n\n

systemctl enable nftables.service<\/code><\/p>\n\n\n\n

Finally there is a proper built-in method of installing filtering rules at boot! You have to wonder why that has taken so long.<\/p>\n\n\n\n

At this point having migrated to nftables it’s tempting to remove the iptables package and you can do so, but there is a problem. As soon as you do this apt will start telling you that none of the nftables packages are needed and that they can be removed with apt-get autoremove.<\/p>\n\n\n\n

This is why this ‘migration’ to iptables is not quite how it seems, you do need to retain the iptables package if only for one reason.. to keep the nftables packages installed.<\/p>\n\n\n\n

One side effect of retaining the iptables package is you can end up with an empty ruleset in nftables that is not used.<\/p>\n\n\n\n

# nft list tables
table inet Firewall
table ip filter<\/code><\/p>\n\n\n\n

This all seems slightly strange. Intentional? Oversight? I don’t know but my limited testing shows that nftables works fine without the iptables package, it’s just a risk that you’ll end up losing all your nftables packages through apt-get autoremove if you don’t retain the iptables package.<\/p>\n\n\n\n

Aside from that nft seems to work well, for me the ruleset syntax is better and easier to manage.<\/p>\n\n\n\n

I’ve included an example v4\/v6 combined ruleset below.<\/p>\n\n\n\n

#!\/usr\/sbin\/nft -f

# Define intefaces
define LAN_EXT = eth0

# Flush everything
flush ruleset

# Defaults
add table inet xciv
add chain inet xciv OUTPUT { type filter hook output priority 0; policy accept; }
add chain inet xciv INPUT { type filter hook input priority 0; policy drop; }
add chain inet xciv FORWARD { type filter hook forward priority 0; policy drop; }

# Don't filter loopback interface
add rule inet xciv INPUT iifname \"lo\" counter accept

# Allow all ICMP incoming
add rule inet xciv INPUT iifname $LAN_EXT ip protocol icmp counter accept

# Allow incoming connections (DNS)
add rule inet xciv INPUT iifname $LAN_EXT udp dport { 53 } counter accept
add rule inet xciv INPUT iifname $LAN_EXT tcp dport { 53 } counter accept

# Allow incoming connections (HTTP\/SSL)
add rule inet xciv INPUT iifname $LAN_EXT tcp dport { 80 , 443 } counter accept

# Allow incoming connections (SMTP\/SSL)
add rule inet xciv INPUT iifname $LAN_EXT tcp dport { 25, 587 } counter accept

# Allow incoming established traffic (stateful inspection)
add rule inet xciv INPUT iifname $LAN_EXT ct state related,established counter accept

# Block all other IPv4 traffic (send rejects rather than drop)
add rule inet xciv INPUT iifname $LAN_EXT ip protocol udp counter reject with icmp type host-prohibited
add rule inet xciv INPUT iifname $LAN_EXT ip protocol tcp counter reject with tcp reset

# IPv6, allow ICMP incoming and reject other ports
add rule inet xciv INPUT iifname $LAN_EXT ip6 nexthdr ipv6-icmp counter accept
add rule inet xciv INPUT iifname $LAN_EXT ip6 nexthdr udp counter reject with icmpv6 type admin-prohibited
add rule inet xciv INPUT iifname $LAN_EXT ip6 nexthdr tcp counter reject with tcp reset <\/code><\/p>\n","protected":false},"excerpt":{"rendered":"

If you have upgraded to Debian 10 buster you will know (if you have read the release notes) that Debian has now migrated to the nftables filtering framework. See 2.2.6. Network filtering based on nftables framework by default What is not covered is how you do this and what it really means. The release notes say […]<\/p>\n","protected":false},"author":1,"featured_media":73,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"twitterCardType":"","cardImageID":0,"cardImage":"","cardTitle":"","cardDesc":"If you have upgraded to Debian 10 buster you will know (if you have read the release notes) that Debian has now migrated to the nftables filtering framework.","cardImageAlt":"","cardPlayer":"","cardPlayerWidth":0,"cardPlayerHeight":0,"cardPlayerStream":"","cardPlayerCodec":"","footnotes":""},"categories":[7,19,18,11,3],"tags":[4,22,21,20,6],"class_list":["post-70","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-computing","category-internet","category-security","category-software","category-technology","tag-computing","tag-internet","tag-security","tag-software","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/posts\/70","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/comments?post=70"}],"version-history":[{"count":4,"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/posts\/70\/revisions"}],"predecessor-version":[{"id":75,"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/posts\/70\/revisions\/75"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/media\/73"}],"wp:attachment":[{"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/media?parent=70"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/categories?post=70"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xciv.org\/blog\/wp-json\/wp\/v2\/tags?post=70"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}