logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 10-08-2019 09:14:21

llwynrt
Membre
Lieu : Angers
Inscription : 10-08-2019

[résolu] Migration d'iptables à nftables

Bonjour

suite à la mise à jour de mon serveur vers debian 10, j'ai essayé de configurer nftables à la place d'iptables.
il n'y a plus aucunes règles dans iptables :

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination



j'ai configuré nftables au minimum : ssh, https et le port 22317 dont j'ai besoin :

nft list table inet filter
table inet filter {
        chain input {
                type filter hook input priority 0; policy accept;
                tcp dport ssh accept
                tcp dport https accept
                tcp dport 22317 accept
        }

        chain forward {
                type filter hook forward priority 0; policy drop;
        }

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



nftables est bien démarré à priori :

systemctl status nftables.service
 nftables.service - nftables
   Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)
   Active: active (exited) since Sat 2019-08-10 09:56:07 CEST; 14min ago
     Docs: man:nft(8)
           http://wiki.nftables.org
  Process: 10151 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=0/SUCCESS)
 Main PID: 10151 (code=exited, status=0/SUCCESS)

août 10 09:56:07 eeebox-serveur systemd[1]: Starting nftables...
août 10 09:56:07 eeebox-serveur systemd[1]: Started nftables.




mon problème est que si je scanne les ports ouverts, ça ne correspond pas du tout :

PORT    STATE    SERVICE

22/tcp  open     ssh
25/tcp  open     smtp
80/tcp  open     http
110/tcp open     pop3
143/tcp open     imap
443/tcp open     https
993/tcp open     imaps

on dirait mon ancienne config d'iptables. je suis coincée sos.gif

merci de votre aide !

Dernière modification par llwynrt (15-08-2019 17:35:37)

Hors ligne

#2 10-08-2019 10:27:25

anonyme
Invité

Re : [résolu] Migration d'iptables à nftables

Bonjour
je comprend rien a nftables mais il me semble que un drop serait pas mal comme ceci sur input


nft list table inet filter
table inet filter {
        chain input {
                type filter hook input priority 0; policy drop;
                tcp dport ssh accept
                tcp dport https accept
                tcp dport 22317 accept
        }
 


et sûrement autoriser d'autres services comme le DNS et autres
en "accept" tes règles au dessous ne servent a rien , tout passe

#3 10-08-2019 10:38:32

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

1) Tu ne devrais pas charger iptables si tu utilises nftables. Le simple fait d'exécuter

iptables -L


a pour effet de charger la table "filter" d'iptables si elle ne l'est pas déjà. Pour lister les règles iptables sans charger les tables d'iptables il vaut mieux utiliser

iptables-save



2) Tu as défini la politique par défaut de la chaîne input à accept. Accepter des ports spécifiques alors que la politique par défaut est déjà accept n'apporte rien.
Quand tu mettras la politique par défaut à drop ou ajouteras une règle drop pour les autres paquets en fin de chaîne, tu devras ajouter une règle pour autoriser les paquets de réponse aux paquets de requête émis par la machine en utilisant le suivi de connexion (established, related).

anonyme a écrit :

et sûrement autoriser d'autres services comme le DNS et autres


Pourquoi ?

Dernière modification par raleur (10-08-2019 10:41:00)


Il vaut mieux montrer que raconter.

Hors ligne

#4 10-08-2019 11:01:00

llwynrt
Membre
Lieu : Angers
Inscription : 10-08-2019

Re : [résolu] Migration d'iptables à nftables

en "accept" tes règles au dessous ne servent a rien , tout passe


Tu as défini la politique par défaut de la chaîne input à accept. Accepter des ports spécifiques alors que la politique par défaut est déjà accept n'apporte rien.


justement tout ne passe pas, les seuls ports ouverts sont ceux cités précédemment. s'il n'y a plus rien dans iptables et si nftables ne filtre rien, pourquoi tous les ports ne sont-il pas ouverts ? (le pc est configuré en dmz sur la box, donc pas de filtrage à ce niveau là)

iptables-save

# Generated by xtables-save v1.8.2 on Sat Aug 10 11:48:04 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:f2b-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22,115 -j f2b-ssh
-A f2b-ssh -s 112.80.124.141/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-ssh -s 112.85.42.173/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-ssh -s 221.212.112.148/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-ssh -j RETURN
COMMIT
# Completed on Sat Aug 10 11:48:04 2019
 



il y a bien un reste de config de iptables, mais rien sur les ports à ouvrir, non ?

Dernière modification par llwynrt (10-08-2019 11:01:16)

Hors ligne

#5 10-08-2019 11:06:59

anonyme
Invité

Re : [résolu] Migration d'iptables à nftables

il ne faut pas utiliser iptables et nftables en même temps
ce fichier au dessus en #4 ne devrait plus exister
tout ce passe dans /etc/nftables.conf
le paquet nftables installé
le paquet iptables désinstallé

#6 10-08-2019 11:13:20

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

llwynrt a écrit :

pourquoi tous les ports ne sont-il pas ouverts


Tu confonds fermé et filtré/bloqué.
Les autres ports sont fermés (et non filtrés) parce qu'aucun service n'écoute dessus.

llwynrt a écrit :

il y a bien un reste de config de iptables


Ces règles iptables sont apparemment créées par fail2ban, qu'il va falloir modifier pour utiliser nftables.

Dernière modification par raleur (10-08-2019 11:23:15)


Il vaut mieux montrer que raconter.

Hors ligne

#7 10-08-2019 11:21:00

anonyme
Invité

Re : [résolu] Migration d'iptables à nftables

@raleur

anonyme a écrit :

et sûrement autoriser d'autres services comme le DNS et autres


Pourquoi ?



c'est en test , mais par exemple  le contenu de mon /etc/nftables.conf


#!/usr/sbin/nft -f

flush ruleset

table ip filter {
        chain input {
                type filter hook input priority 0; policy drop;
                iif lo accept
                ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop
                ct state established,related accept
                icmp type { echo-request, echo-reply } accept
                icmp type { destination-unreachable,time-exceeded, parameter-problem } accept
                log prefix "INPUT_DROP "
        }

        chain forward {
                type filter hook forward priority filter; policy drop;
                ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop
                ct state established,related accept
                log prefix "FORWARD_DROP "
        }

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


le input " type filter hook input" bloque tout
ceci me permet de laisser passer les services en output en réponse en input  =>  "ct state established,related accept"
sinon il faut une règle pour autorisé les ports en entrée
c'est une ébauche et en test , je suis pas très a l' aise , enicar m'a donné un sérieux coup de main sur ce coup la roll

Dernière modification par anonyme (10-08-2019 11:25:49)

#8 10-08-2019 11:25:09

anonyme
Invité

Re : [résolu] Migration d'iptables à nftables

a ma connaissance , il n'y a pas d' utilitaires graphique pour nftables , et a mon avis il faut supprimer et purger ceux utilisé avec iptables.
la documentation de nftables est a lire avant de ce lancer  =>  https://wiki.nftables.org/wiki-nftables … /Main_Page

#9 10-08-2019 11:27:50

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

anonyme a écrit :

ceci me permet de laisser passer les services en output en réponse en input  =>  "ct state established,related accept"


Tu ne parlais donc pas d'autres services en entrée. Tu aurais pu être plus explicite.

anonyme a écrit :

sinon il faut une règle pour autorisé les ports en entrée


Sûrement pas pour des requêtes sortantes. Ce serait une très mauvaise idée.

anonyme a écrit :

a ma connaissance , il n'y a pas d' utilitaires graphique pour nftables , et a mon avis il faut supprimer et purger ceux utilisé avec iptables.


C'est graphique, fail2ban ?

Dernière modification par raleur (10-08-2019 11:29:03)


Il vaut mieux montrer que raconter.

Hors ligne

#10 10-08-2019 11:55:31

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

llwynrt a écrit :

on dirait mon ancienne config d'iptables. je suis coincée


Tu n'as pas décrit ce dont tu avais besoin, quels sont les services qui vont être
disponibles sur ce serveur depuis l'extérieur ?
Dans un premier tu devrais arrêter fail2ban pour éviter qu'il crée de nouvelles règles
iptables à la volée.

Tu pourrais aussi nous montrer qu'elles étaient les règles du pare-feu avec iptables.

Hors ligne

#11 10-08-2019 11:58:34

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

enicar a écrit :

Tu n'as pas décrit ce dont tu avais besoin, quels sont les services qui vont être
disponibles sur ce serveur depuis l'extérieur ?


Il me semble que le post initial était suffisamment explicite :

llwynrt a écrit :

j'ai configuré nftables au minimum : ssh, https et le port 22317 dont j'ai besoin :


Il vaut mieux montrer que raconter.

Hors ligne

#12 10-08-2019 11:59:50

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

raleur a écrit :

Il me semble que le post initial était suffisamment explicite :


bof…

Hors ligne

#13 10-08-2019 12:11:19

anonyme
Invité

Re : [résolu] Migration d'iptables à nftables

moi je me retire pas assez bon en réseau
mais c'est clair
plus d'iptables , on oublie
il est possible de convertir une table iptables en nftables avec le risque que ça coince pour certaines règles.
virer tous les utilitaires lier a iptables (console ou graphique) et le paquet iptables
après jouer au ping pong avec les mots pas trop mon truc

le titre du post est clair "Migration d'iptables à nftables"
la seule chose de vraiment clair

#14 10-08-2019 12:26:58

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

À ce compte là je proposerai bien :


#! /usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif lo accept
        ct state invalid drop
        ct state related,established accept
        ct state new tcp dport {ssh, https, 22317} accept
        icmp type { destination-unreachable,time-exceeded, parameter-problem } accept
        ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, echo-request, nd-router-advert, nd-neighbor-advert } accept
    }

    chain forward {
            type filter hook forward priority 0; policy drop;
    }

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


Si le serveur est exposé je rajouterais bien les trois règles suivantes dans la chaîne
input de la table inet filter, juste après « iff lo accept :


    tcp flags & (fin|syn|rst|psh|ack|urg) < fin log prefix "INPUT_NULL " drop
    tcp flags & (fin|syn|rst|psh|ack|urg) > urg log prefix "INPUT_XMASS " drop
    ct state new,related tcp flags & (fin|syn|rst|psh|ack|urg) != syn limit rate 4/second burst 5 packets  log prefix "TCP INPUT without SYN " drop
 


Les deux premières c'est pour bloquer les scans utilisant des paquets tcp NULL et
XMASS. La troisième c'est pour filtrer les paquets tcp new et related qui
n'ont pas de syn activé.

Remarquez que la famille utilisé ici est « inet ». Ça permet de regrouper les
règles pour ipv4 (famille ip) et ipv6 (famille ip6).

On peut aussi ajouter ou supprimer des logs… mais si la machine à une adresse
publique, il vaut mieux être parcimonieux avec les logs.

Edit : puisque, on autorise le traffic ipv6, j'ai rajouté une règle
autorisant les messages icmpv6 nécessaires. J'ai trouvé cette règle dans les exemples
du wiki de nftables : https://wiki.nftables.org/wiki-nftables … orkstation

Dernière modification par enicar (10-08-2019 12:40:51)

Hors ligne

#15 10-08-2019 12:39:33

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

enicar a écrit :

tcp flags & (fin|syn|rst|psh|ack|urg) < fin


Ce ne serait pas plus clair avec "= 0" ?

enicar a écrit :

tcp flags & (fin|syn|rst|psh|ack|urg) > urg


Tu es sûr de cette expression ?
Si je ne m'abuse, un paquet "Xmas tree" a tous les flags TCP activés. Si j'interprète correctement ton expression, la correspondance se fait si au moins un autre flag que URG est activé, ce qui est différent. D'autre part le flag URG ne peut pas être activé seul, il doit au moins y avoir ACK (seul le paquet SYN initial n'a pas ACK, tous les autres doivent l'avoir) donc pour moi cette expression n'a aucun sens.


Il vaut mieux montrer que raconter.

Hors ligne

#16 10-08-2019 12:59:58

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

raleur a écrit :

enicar a écrit :

tcp flags & (fin|syn|rst|psh|ack|urg) < fin


Ce ne serait pas plus clair avec "= 0" ?

enicar a écrit :

tcp flags & (fin|syn|rst|psh|ack|urg) > urg


Tu es sûr de cette expression ?
Si je ne m'abuse, un paquet "Xmas tree" a tous les flags TCP activés. Si j'interprète correctement ton expression, la correspondance se fait si au moins un autre flag que URG est activé, ce qui est différent. D'autre part le flag URG ne peut pas être activé seul, il doit au moins y avoir ACK (seul le paquet SYN initial n'a pas ACK, tous les autres doivent l'avoir) donc pour moi cette expression n'a aucun sens.



Absolument pas sûr, c'est un truc que j'ai trouvé sur une doc que je trouve
très approximative (et fausse donc !) : c'est ici https://www.it-connect.fr/chapitres/ger … -nftables/
J'avais compris qu'il jouait avec l'ordre des bits.
Mais effectivement, pour les tcp NULL  il vaudrait mieux :


tcp flags & (fin|syn|rst|psh|ack|urg) == 0
 


Pour les XMASs  je ne sais pas trop ce qu'il faudrait mettre.
Dans la doc de nmap ils disent que les flags FIN, URG et PUSH sont activés
pour ces paquets. Ce qui ne correspond pas à « tous les flags sont activés ».
Si tous les flags sont activés, alors une expression comme :


tcp flags & (fin|syn|rst|psh|ack|urg) == 63
 


devrait convenir.
Il faut que je réfléchisse à tout ça wink

Dernière modification par enicar (10-08-2019 13:11:49)

Hors ligne

#17 10-08-2019 13:09:39

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

enicar a écrit :

Dans la doc de nmap ils disent que les flags FIN, URG et PUSH sont activés
pour ces paquets. Ce qui ne correspond pas à « tous les flags sont activés ».


En fait j'ai mal lu, il est dit « In this type of scan, Nmap will send the packets with URG, FIN, and PSH, and flags activated.» Ce qui correspond à tous les bits à 1.

Hors ligne

#18 10-08-2019 13:23:32

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

enicar a écrit :

Dans la doc de nmap ils disent que les flags FIN, URG et PUSH sont activés
pour ces paquets. Ce qui ne correspond pas à « tous les flags sont activés ».


En effet, je vois ça. Sur Wikipédia (https://en.wikipedia.org/wiki/Christmas_tree_packet), c'est un peu contradictoire : l'article commence par dire que tous les bits d'option sont activés, puis mentionne les même flags que nmap.
EDIT : la section "talk" de la page aborde cette contradiction.

La RFC 1025 (https://tools.ietf.org/html/rfc1025) mentionne SYN,URG, PUSH, FIN comme exemple de paquet "christmas tree", laissant entendre que la définition n'est pas figée.

enicar a écrit :

tcp flags & (fin|syn|rst|psh|ack|urg) = 63


Un nombre, ce n'est pas très lisible. Il vaudrait mieux utiliser une expression de la même forme que le masque (flag|flag|...).

Avec cette expression :

tcp flags & (fin|psh|urg) = (fin|psh|urg)


on devrait détecter aussi bien les scans Xmas Tree de nmap et les paquets ayant des flags en plus.

Dernière modification par raleur (10-08-2019 13:31:15)


Il vaut mieux montrer que raconter.

Hors ligne

#19 10-08-2019 13:40:28

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

raleur a écrit :

Un nombre, ce n'est pas très lisible. Il vaudrait mieux utiliser une expression de la même forme que le masque (flag|flag|...).

Avec cette expression :


tcp flags & (fin|psh|urg) = (fin|psh|urg)
 


on devrait détecter aussi bien les scans Xmas Tree de nmap et les paquets ayant des flags en plus.


Bonne idée. Je vais l'écrire comme ça dorénavant, et aussi je mettrai ces règles après
la règle « ct state invalid  drop », et avant « ct state related,established accept » ça permet un premier filtrage avec le suivi de connexion.
Aussi avec nftables il faut utiliser « == » ou « eq ». Il me semble qu'avec iptables c'était « = ».
https://wiki.nftables.org/wiki-nftables … xpressions

Hors ligne

#20 10-08-2019 13:42:05

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

enicar a écrit :

En fait j'ai mal lu, il est dit « In this type of scan, Nmap will send the packets with URG, FIN, and PSH, and flags activated.» Ce qui correspond à tous les bits à 1.


Où as-tu lu cette phrase ? Sa formulation est bizarre, j'ai l'impression que soit il manque quelque chose juste avant "flags", soit ", and" est en trop.
La page de manuel et la documentation en ligne de nmap sont sans ambiguïté : "Sets the FIN, PSH, and URG flags".


Il vaut mieux montrer que raconter.

Hors ligne

#21 10-08-2019 13:43:14

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

raleur a écrit :

on devrait détecter aussi bien les scans Xmas Tree de nmap et les paquets ayant des flags en plus.

La question que je me pose : est-il possible que certains
paquets faisant partie d'une connexion déjà existante puissent avoir ces bits de
positionnés en même temps ?

Hors ligne

#22 10-08-2019 13:44:23

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

enicar a écrit :

Aussi avec nftables il faut utiliser « == » ou « eq ». Il me semble qu'avec iptables c'était « = ».


Possible, je ne connais pas encore la syntaxe de nftables. En revanche iptables n'utilisait pas du tout ce genre d'expression, la syntaxe était complètement différente.

--tcp-flags flag,flag... flag,flag...


Il vaut mieux montrer que raconter.

Hors ligne

#23 10-08-2019 13:46:25

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

raleur a écrit :

Où as-tu lu cette phrase ?


ici :   https://www.konsecurity.com/nmap-advance-scanning/
Mais ce n'est pas la doc de nmap comme je l'ai prétendu…
Encore une doc approximative… j'en  trouve tellement de mal faite
sur ce sujet que les bons documents sont précieux.

Hors ligne

#24 10-08-2019 14:00:16

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [résolu] Migration d'iptables à nftables

raleur a écrit :

Possible, je ne connais pas encore la syntaxe de nftables.


Moi, je n'ai jamais maîtrisé la syntaxe iptables, je trouve la syntaxe nftables plus
facile à retenir et surtout à lire.

Hors ligne

#25 10-08-2019 14:03:55

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] Migration d'iptables à nftables

enicar a écrit :

La question que je me pose : est-il possible que certains
paquets faisant partie d'une connexion déjà existante puissent avoir ces bits de
positionnés en même temps ?


Normalement non, à ma connaissance. FIN annonce la fin de la connexion, et PSH et URG ne sont normalement utilisés que si le segment contient des données. Mais je ne suis pas sûr à 100% qu'un paquet FIN ne peut pas contenir de données. Ceci dit FIN implique PUSH, donc il ne devrait pas y avoir de PSH avec FIN.


Il vaut mieux montrer que raconter.

Hors ligne

Pied de page des forums