NFTABLES : version compilée tests
NFTABLES : version compilée tests jppCette petite série de tests a été conduite avec la version compilée localement de "nft" car les autres versions essayées ne "comprenaient" pas certaines nouvelles fonctionnalités.
Premier test : réaliser du NAT :
Si la table existe un petit "flush" remet tout dans l'ordre, si la table n'existe pas cela déclenche une erreur fatale et rien n'est fait ! C'est très dommage pour l'atomicité des opérations.
Pour être tranquilles il faut donc tester l'existence de la table et la créer (vide) si besoin. Cela peut se faire avec le petit bout de script suivant :
# # On teste l'existence de la table ! # nft list table ip POSTROUTE 2>/dev/null >/dev/null ret=$? # # On crée la table si elle n'existe pas !!! # if [ $ret -ne 0 ] then nft add table ip POSTROUTE fi On peut maintenant lancer la suite du script avec : nft -f Mon fichier contient dans notre cas : flush table ip POSTROUTE; table ip POSTROUTE { chain DEFAUT { type nat hook postrouting priority 0; ip saddr 192.168.2.0/24 masquerade; ip saddr 192.168.3.0/24 masquerade; } } |
On peut noter la création d'une table avec un nom "en français" pour faire plus beau !
Deuxième test, effectuer une redirection transparente de HTTP/HTTPS :
Tous les "clients" HTTP à destination de l'extérieur sont "interceptés". Seules les adresses précisées subissent une redirection du HTTPS, le "set" GO_HTTPS contiendra les adresses sélectionnées.
On ajoute des compteurs pour suivre le travail.
flush table ip PREROUTE; table ip PREROUTE { chain DEFAUT { type nat hook prerouting priority 0; ip daddr != 192.168.2.1/24 tcp dport 80 counter redirect to 3127 ip daddr != 192.168.2.1/24 ip saddr @GO_HTTPS tcp dport https counter redirect to 3129 } set GO_HTTPS { type ipv4_addr; }; } |
Ensuite on ajoute les adresses au set :
nft add element PREROUTE GO_HTTPS { 192.168.2.9 } nft add element PREROUTE GO_HTTPS { 192.168.2.10 , 192.168.2.8} et on vérifie : nft list set PREROUTE GO_HTTPS set GO_HTTPS { type ipv4_addr elements = { 192.168.2.9, 192.168.2.8, 192.168.2.10} } |
Troisième test : envoyer des paquets vers une "queue" en espace utilisateur par exemple pour un IPS :
Ici l'IPS est Suricata, on mettra un compteur sur chaque règle.
On utilise la "famille" inet pour intercepter aussi IPV6 et une priorité de -100 pour passer avant les autres chaines. On ne peut pas utiliser le type "route" qui ne fonctionne pas avec un autre "hook" que "output".
delete table inet IPS; table inet IPS { chain ENT_150 { type filter hook input priority -100; counter queue num 0 } chain SOR_150 { type filter hook output priority -190; counter queue num 0 } chain FOR_150 { type filter hook forward priority -100; counter queue num 1-2; } } |
Après quelques accès internet la commande " nft list table inet IPS " renvoie :
table inet IPS { chain ENT_150 { type filter hook input priority -100; counter packets 1676 bytes 490186 queue num 0 } chain SOR_150 { type filter hook output priority -190; counter packets 1969 bytes 398894 queue num 0 } chain FOR_150 { type filter hook forward priority -100; counter packets 0 bytes 0 queue num 1-2 } } |
Des paquets "locaux" sont bien passés dans la queue 0 et l'un d'entre eux a été "repéré" par Suricata car il contenait un mot de passe de connexion sur un site WEB.
A suivre ....