Ceci est une ancienne révision du document !
Nftables
Passer de iptables à nftables
Déjà, sur toute nouvelle version de Debian, par défaut c'est nftables derrière (commande nft
). Ensuite, même si on installe le paquet “iptables” en vrai c'est une surcouche à présent, qui traduira les règles de façon invisible pour l'utilisatrice. Ce qui permet de continuer à utiliser ses config iptables sans rien changer quand on n'a pas le temps, et c'est cool. Mais il faut aussi varier ;)
Installer le paquet iptables permet d'avoir accès à un outil intéressant : iptables-translate. Cette commande nous permet de savoir comment une règle iptable se traduit en terme de syntaxe pour nftables. Cela permet d'adapter les anciens tutoriels plus rapidement…
Plus d'infos ici : https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables
nftables.conf
Ce fichier /etc/nftables.conf
est un peu l'équivalent du fichier de conf de “iptable-persistant”. Il faut quand même déclarer qu'il faut le charger automatiquement, mais une fois fait, il va lire les règles là lors du redémarrage du serveur.
Fichier par défaut sur ma Debian :
#!/usr/sbin/nft -f flush ruleset table inet filter { chain input1 { type filter hook input priority filter; } chain forward1 { type filter hook forward priority filter; } chain output1 { type filter hook output priority filter; } }
Organisation de ce fichier :
- Il doit commencer par
#!/usr/sbin/nft -f
qui précise le programme à exécuter - On peut mettre une commande directement (pas n'importe quoi bien sûr). Généralement on commence avec
flush ruleset
qui purge tout vieux truc précédent. table
: c'est là qu'on déclare les tables, c'est à dire une catégorie pour organiser des lots de règles.inet
: famille d'adresses ipv4/ipv6- Ici “filter” est le nom de la table. On peut donner le nom qu'on veut à une table.
- Les chaines sont une suite de règles à appliquer dans un contexte précis. Ici, les noms “input1, forward1 et output1” sont juste des conventions (auquel j'ai rajouté “1” pour éviter toute confusion), on peut aussi les appeler comme on veut. Là où elles agissent est défini ensuite avec
type filter hook input
(et là, par contre, les mots-clés sont importants et figés).- Les type peuvent être :
filter
,route
,nat
. - Les hook peuvent être :
prerouting
,input
,forward
,output
,postrouting
.
priority filter
: quand tu ne sais pas, tu met filter, mais y'a d'autres options.filter
ça précise les règles qui vont suivrent et qui ici sont donc de filtrer… Sinon il y a des chiffres (voir la doc) pour préciser dans quel ordre tout va s'appliquer.- Peu importe l'ordre des
chain
et destable
. Par contre il faut déclarer le type de filtre dans les chaines, même si d'autres type de règles sont possibles.
Ça c'est donc la version de base et terriblement trop permissive ; suivant les cas d'usages on va choisir diverses options.
Quelque soit la version, je préfère une politique où je refuse tout, en dehors de ce qui est explicitement autorisé.
Pour un serveur derrière un routeur
Cas quand on est chez soit, avec une box en amont qui gère le bazar.
Option : quand il faut gérer un bridge (Xen par exemple) sur la machine.
Pour un serveur qui doit gérer le routage
Cas des proxmox, xen etc quand on loue ça à distance.
Vérification et mise en place
Pour vérifier ce fichier une fois modifié, avant de le mettre en place :
sudo nft -cof /etc/nftables.conf
La commande va donner des informations si y'a besoin.
- -c : vérifier s'il y a des erreurs syntaxes
- -o : optimiser les règles
- -f : indique le fichier à lire (ici l'emplacement par défaut sur debian).
Une fois qu'on a configuré son fichier :
sudo systemctl enable nftables.service sudo service nftables start