151 lines
6.4 KiB
Markdown
151 lines
6.4 KiB
Markdown
---
|
||
title: "From Stretch to Buster : How to migrate from iptables to nftables ?"
|
||
date: 2020-01-17
|
||
url: from-stretch-to-buster-how-to-migrate-from-iptables-to-nftables
|
||
layout: post
|
||
category: Tutorials
|
||
image: /img/blog/from-stretch-to-buster-how-to-migrate-from-iptables-to-nftables.png
|
||
description: "A step-by-step tutorial for a(nother) not-so-guided Debian migration"
|
||
---
|
||
|
||
[](/img/blog/from-stretch-to-buster-how-to-migrate-from-iptables-to-nftables.png)
|
||
|
||
### Introduction
|
||
|
||
So here is a hot take : You have just ended your migration to Debian Buster and were pretty chocked by some warnings about firewall deep changes ?
|
||
Well, [you're right](https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#nftables).
|
||
|
||
There is plenty of documentation addressing this deprecation on the WWW, but what about a step-by-step guide summing up the whole idea behind this migration ?
|
||
|
||
### The procedure
|
||
|
||
#### `nftables` installation
|
||
|
||
{% highlight bash %}
|
||
apt install nftables
|
||
{% endhighlight %}
|
||
|
||
Pretty easy for a first step, huh ?
|
||
|
||
#### Convert your existing _legacy_ rules
|
||
|
||
{% highlight bash %}
|
||
(iptables-save ; ip6tables-save) > iptables.rules
|
||
iptables-restore-translate -f iptables.rules > some_unreadable_rules.sh
|
||
{% endhighlight %}
|
||
|
||
#### (Re-)write your own rules
|
||
|
||
The step above is actually a "stupid" syntax converter from `iptables` to `nft`, without a real extensive "processing" to _optimize_ them.
|
||
So at this moment, you may wanna **rewrite your existing rules**.
|
||
|
||
I'd advise you the [official guide](https://wiki.nftables.org/wiki-nftables/index.php/Main_Page), some of the [below examples](#sources-as-long-as-some-inspiring-examples) and some others packaged and already available right from your shell :
|
||
|
||
{% highlight bash %}
|
||
nano /usr/share/doc/nftables/examples/*.nft
|
||
{% endhighlight %}
|
||
|
||
> OMG, did that guy really used `nano` in its snippet ? :fearful:
|
||
>> 1) I don't care very much about what people think ;
|
||
>> 2) `nano` got [by default](https://git.savannah.gnu.org/cgit/nano.git/tree/syntax/nftables.nanorc) a syntax highlighting for `nftables` :stuck_out_tongue:
|
||
|
||
> EDIT 2020-03-07 : I've (finally) written a syntax definition for Sublime Text 3+, it's available [here](https://github.com/HorlogeSkynet/Nftables).
|
||
|
||
#### Jump in
|
||
|
||
At this step, I assume you got some ~~pretty clean~~ `nftables` rules set under `/etc/nftables.conf` (the default packaged location).
|
||
We will first be checking whether they actually pass the `nft` validation procedure :
|
||
|
||
{% highlight bash %}
|
||
nft -c -f /etc/nftables.conf
|
||
{% endhighlight %}
|
||
|
||
If that's the case :
|
||
|
||
{% highlight bash %}
|
||
systemctl enable --now nftables.service
|
||
{% endhighlight %}
|
||
|
||
> If you're working on a remote server, at this step, I really hope that your SSH connection is still running :smile:
|
||
|
||
#### Post-configuration : The whole system
|
||
|
||
Well, you got brand new rules set and running, but there may be some cave-eats : Other pieces of software.
|
||
Typically, you are maybe running a quiet Fail2Ban instance, and on its side, it will be still using the legacy `iptables` layer.
|
||
|
||
Fixing this issue is pretty straightforward (if you got a `filter` _table_ with an `input` _chain_ already defined) :
|
||
|
||
{% highlight bash %}
|
||
nano /etc/fail2ban/jail.local
|
||
: '
|
||
# ...
|
||
banaction = nftables-multiport
|
||
# ...
|
||
'
|
||
|
||
# You will maybe have to restart it completely, as...
|
||
# ... its chain(s) might have disappeared when you flushed your iptables rules.
|
||
systemctl restart fail2ban.service
|
||
{% endhighlight %}
|
||
|
||
You got the point : This was a friendly reminder for the _other_ services, that will probably keep messing with `iptables` behind your back...
|
||
|
||
**EDIT 2020-03-25** : If you are a virtualization guy, please notice that [libvirt does not support nftables yet](https://www.redhat.com/archives/libvirt-users/2018-October/msg00046.html). Docker is working well on Buster, but [full nftables support is still expected](https://github.com/moby/moby/issues/26824).
|
||
|
||
#### Getting rid of _legacy_ `iptables`
|
||
|
||
{% highlight bash %}
|
||
# If you used the handy `netfilter-persistent` package :
|
||
apt autoremove --purge iptables-persistent
|
||
|
||
# Kernel modules
|
||
nano /etc/modprobe.d/iptables-blacklist.conf
|
||
: '
|
||
blacklist x_tables
|
||
blacklist iptable_nat
|
||
blacklist iptable_raw
|
||
blacklist iptable_mangle
|
||
blacklist iptable_filter
|
||
blacklist ip_tables
|
||
blacklist ipt_MASQUERADE
|
||
blacklist ip6table_nat
|
||
blacklist ip6table_raw
|
||
blacklist ip6table_mangle
|
||
blacklist ip6table_filter
|
||
blacklist ip6_tables
|
||
'
|
||
{% endhighlight %}
|
||
|
||
#### (Optional) Make _Buster_ "nickel-chrome"
|
||
|
||
When we upgrade from _Stretch_ to _Buster_, the upgrade process might have tweaked a bit your setup to keep it backward compatible with potential existing `iptables` rules.
|
||
As we now use the default framework shipped in and advised by the Debian community, we may rollback to what a fresh _Buster_ should look like :
|
||
|
||
{% highlight bash %}
|
||
# The idea is to make `*tables` scripts now (re-)pointing to `*tables-nft` ones.
|
||
# From official documentation : <https://wiki.debian.org/nftables#Current_status>
|
||
update-alternatives --set iptables /usr/sbin/iptables-nft
|
||
update-alternatives --set ip6tables /usr/sbin/ip6tables-nft
|
||
update-alternatives --set arptables /usr/sbin/arptables-nft
|
||
update-alternatives --set ebtables /usr/sbin/ebtables-nft
|
||
{% endhighlight %}
|
||
|
||
### Conclusion
|
||
|
||
Well, you'd have understood, the real idea behind this is to take some time to **fully rewrite** its own firewall using this "new" tool.
|
||
It might also be a good time to review existing rules, to decide whether they are still required or not, and maybe to optimize them with [the awesome features brought by `nftables`](https://home.regit.org/2014/01/why-you-will-love-nftables/).
|
||
|
||
### Sources (as long as some inspiring examples)
|
||
|
||
* [Moving from iptables to nftables](https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables)
|
||
|
||
* [Quick reference-nftables in 10 minutes](https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes#Chains)
|
||
|
||
* [Explaining My Configs: nftables](https://stosb.com/blog/explaining-my-configs-nftables/)
|
||
|
||
* [Setting up a server firewall with nftables that support WireGuard VPN](https://xdeb.org/post/2019/09/26/setting-up-a-server-firewall-with-nftables-that-support-wireguard-vpn/)
|
||
|
||
* [Migrating my iptables setup to nftables](https://developers.redhat.com/blog/2017/01/10/migrating-my-iptables-setup-to-nftables/)
|
||
|
||
* [Bulletin d’actualité CERTFR-2017-ACT-030](https://www.cert.ssi.gouv.fr/actualite/CERTFR-2017-ACT-030/)
|