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).

#26 10-08-2019 13:16:30

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

je surveille les logs (a priori la chaine forward peut être bloqué ? )


Sur un poste client l'ip forwarding n'est pas activé. Il ne devrait rien passé
dans cette chaîne. Ton log des paquets dans cette chaîne ne sert à rien.
C'est bien tout de même de garder sa policy sur drop.

Hors ligne

#27 10-08-2019 13:19:46

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

pour renforcer , je pourrais filtrer le output (en drop)
comme service:
dhcp client
dns
steam
http , https
smtp (25) exim4
et cups (imprimante)
je vois rien d'autres (machine de bureau)


Je pense que c'est inutile. En plus si un site utilise
un port non standard, ça va bloquer la communication.

Hors ligne

#28 10-08-2019 14:09:50

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

enicar a écrit :

ping6 lo


Ping sur un nom d'interface, ça marche ce truc ? (test chez moi : non mais c'est avec jessie)

Dernière modification par raleur (10-08-2019 14:11:09)


Il vaut mieux montrer que raconter.

Hors ligne

#29 10-08-2019 14:13:17

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

pour ceci , la commande ne fonctionne ni sur un client avec nftables ou un client sans pare feu


ping6 lo
ping: lo: Nom ou service inconnu
 



ceci fonctionne (sur la machine avec nftables )


ping6 -c4 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.042 ms
64 bytes from ::1: icmp_seq=4 ttl=64 time=0.041 ms

--- ::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 72ms
rtt min/avg/max/mdev = 0.026/0.037/0.042/0.009 ms
 



pour #26 et 27 ok  , pour le forward pas sur de moi donc je retire le log , et pour le output oui tu a pitié de moi  tongue  smile
bon je duplique ça sur tous les postes client et je continue les tests

merci smile

ps: j' ajoute ceci (avec l'ipv6 affecté a la carte )


ping6 -c4 fe80::6245:cbff:fe62:f693
PING fe80::6245:cbff:fe62:f693(fe80::6245:cbff:fe62:f693) 56 data bytes
64 bytes from fe80::6245:cbff:fe62:f693%enp6s0: icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from fe80::6245:cbff:fe62:f693%enp6s0: icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from fe80::6245:cbff:fe62:f693%enp6s0: icmp_seq=3 ttl=64 time=0.038 ms
64 bytes from fe80::6245:cbff:fe62:f693%enp6s0: icmp_seq=4 ttl=64 time=0.035 ms

--- fe80::6245:cbff:fe62:f693 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 82ms
rtt min/avg/max/mdev = 0.035/0.037/0.041/0.006 ms
 

#30 10-08-2019 14:33:50

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

raleur a écrit :

Ping sur un nom d'interface, ça marche ce truc ? (test chez moi : non mais c'est avec jessie)


Oh ! T'as raison je me suis trompé, il faut faire :


ping6 localhost
 


bien entendu !

Hors ligne

#31 10-08-2019 14:40:18

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

ceci fonctionne (sur la machine avec nftables )


C'est sans table pour l'ipv6, ça prouve que par défaut l'ipv6 passe
quand il n'y a que des règles pour le filtrages de l'ipv4. Ce qui n'est pas
très étonnant. À toi de voir, si tu as envie de laisser les choses comme ça
ou pas. Personnellement, je me protégerais aussi en ipv6 rien que pour
être cohérent.

Hors ligne

#32 10-08-2019 14:59:27

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

pour l'ipv6 pour l'instant je laisse ouvert , je risque quoi , la passerelle ne laisse rien passer du net en ipv6 , et aucun routeur en annonce ipv6 sur le sous réseau
je n'ai que des fe80xxxxxxx  comme ipv6
d un client vers un autre un ping ipv6 passera pas ......
ps: de ce qui me reste des explications de raleur et des tests effectué en ipv6 sous le sous réseau il y a déjà quelque temps
je fais ma pause aussi , et oui ça m'interresse si tu a du nouveau , sur client ou serveur (passerelle )
si tu a besoin de tester quelque chose je suis dispo aussi (tu connais un peu ma configuration maintenant  wink  )
a tout a l'heure peut être .....

#33 10-08-2019 15:17:42

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

je n'ai que des fe80xxxxxxx  comme ipv6
d un client vers un autre un ping ipv6 passera pas


Ben si, on peut faire un ping (et bien d'autres choses) avec des adresses link local en fe80. Il faut juste spécifier l'interface de sortie. Selon la commande et la variante, il peut y avoir deux syntaxes :
- en suffixe de l'adresse avec le symbole "%", par exemple

fe80::xxxx%enpXsY


- dans une option séparée, par exemple

-I enpXsY fe80::xxxx

Dernière modification par raleur (10-08-2019 15:24:18)


Il vaut mieux montrer que raconter.

Hors ligne

#34 10-08-2019 16:02:37

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

j'ai deux fois tord  hmm


ping -c4 fe80::2e4d:54ff:fe54:68ea
PING fe80::2e4d:54ff:fe54:68ea(fe80::2e4d:54ff:fe54:68ea) 56 data bytes
64 bytes from fe80::2e4d:54ff:fe54:68ea%enp6s0: icmp_seq=1 ttl=64 time=0.649 ms
64 bytes from fe80::2e4d:54ff:fe54:68ea%enp6s0: icmp_seq=2 ttl=64 time=0.336 ms
64 bytes from fe80::2e4d:54ff:fe54:68ea%enp6s0: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from fe80::2e4d:54ff:fe54:68ea%enp6s0: icmp_seq=4 ttl=64 time=0.448 ms

--- fe80::2e4d:54ff:fe54:68ea ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 62ms
rtt min/avg/max/mdev = 0.336/0.442/0.649/0.129 ms
 



le ping a été fait de :


inet6 fe80::6245:cbff:fe62:f693/64 scope link
 


l'interface "enp6s0"

le client qui a répondu au ping a l'interface "enp0s31f6" et l'adresse "fe80::2e4d:54ff:fe54:68ea"

comme certitude la passerelle isole bien l'ipv6 de la livebox (et du net)?
si je dois filtrer aussi l'ipv6 pas cool

j'ai testé comme ceci , ça fonctionne


ping -c4 fe80::2e4d:54ff:fe54:68ea%enp6s0
 


et comme ceci aussi correct


ping -c4 -I enp6s0 fe80::fe80::2e4d:54ff:fe54:68ea
 

Dernière modification par anonyme (10-08-2019 16:17:30)

#35 10-08-2019 16:29:39

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

Tiens, contrairement à la mienne ta commande ping n'a pas besoin de spécifier l'interface avec une adresse link local. Ça doit dépendre des variantes ou de la version du noyau.

anonyme a écrit :

comme certitude la passerelle isole bien l'ipv6 de la livebox (et du net)?


Oui, si elle ne route pas l'IPv6 (net.ipv6.conf.all.forwarding=0) ou le filtre en FORWARD.

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


Il vaut mieux montrer que raconter.

Hors ligne

#36 10-08-2019 17:19:15

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

je suis en testing , mais très peu de différence avec buster , bientôt le noyau 5.xx (actuellement dans sid ) et en mesa 19.xx mais rien de neuf sur cette machine .
le noyau actuel en 4.19 (celui de buster)
si tu a l'occasion de tester sur buster a mon avis c'est correct . (je peu le faire aussi la machine ou j'ai envoyé  le ping est une stable (buster)

pour net.ipv6.conf.all.forwarding=0 oui par défaut , je vais rajouter forward a drop  sur la table ipv6 de la passerelle  tongue (si ce n'est pas déjà le cas )
uniquement l' ipv4 en forwarding
comme cela je peu laisser les clients du sous réseau sans filtrage ipv6 , on verra plus tard. roll (j'ai la main sur ce qui se connecte a ce sous réseau )

#37 11-08-2019 13:50:03

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

je commence a migrer les clients de iptables a nftables
avec ceci


#!/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;
    #log prefix "FORWARD_DROP "
  }

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

table ip6 filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif lo accept
  }

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

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



mail et ping fonctionnent (sauf ipv6 tout en drop)

Dernière modification par anonyme (11-08-2019 16:54:58)

#38 11-08-2019 14:18:54

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :



chain forward {
    type filter hook forward priority filter; policy drop;
    log prefix "FORWARD_DROP "
}
 


Tu n'as pas besoin de mettre « log prefix "FORWARD_DROP " ».
Sur tes postes clients, l'ip forwarding est désactivé (c'est la valeur par
défaut dans les noyaux debian). Donc, rien ne devrait passer dans la chaîne
forward. C'est bien de garder la chaîne forward avec la policy sur drop.

C'est pour éviter de se poser la question quand on regarde les règles quelques mois
plus tard.

Hors ligne

#39 11-08-2019 16:54:33

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

Pour le log forward c'est noté
les sites des imprimantes fonctionnent (en local , niveau encre et autres) .
l'impression fonctionne chemin => client => cups => switch => imprimante .
je suis en train de tester FAH (il utilise plusieurs moyen (ip , nom.domaine ) pour joindre les serveurs
ps: envoie et reception de fichier c'est en http je suppose (ou via une ip peut être en ftp )
aucune idée  roll

sur deux clients j'ai un souci , sur forward l'option "filter" est refusé , "0" est accepté


systemctl restart nftables.service
Job for nftables.service failed because the control process exited with error code.
See "systemctl status nftables.service" and "journalctl -xe" for details.
 



L'unité (unit) nftables.service a commencé à démarrer.
août 11 19:46:06 debian21 nft[1408]: /etc/nftables.conf:17:51-56: Error: syntax error, unexpected string, expecting - or number
août 11 19:46:06 debian21 nft[1408]:                 type filter hook forward priority filter; policy drop;
août 11 19:46:06 debian21 nft[1408]:                                                                 ^^^^^^
août 11 19:46:06 debian21 systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit nftables.service has exited.
 




#!/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;
    #log prefix "FORWARD_DROP "
  }

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

table ip6 filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif lo accept
  }

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

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



avec ceci ça fonctionne


chain forward {
    type filter hook forward priority 0; policy drop;
    #log prefix "FORWARD_DROP "
  }
 

Dernière modification par anonyme (11-08-2019 22:14:49)

#40 12-08-2019 00:38:10

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

sur deux clients j'ai un souci , sur forward l'option "filter" est refusé , "0" est accepté


Normal, la priorité c'est un nombre, plus il est petit plus la chaîne est prioritaire.
On peut avoir des priorités négatives. Ça ne sert que lorsqu'on attache plusieurs chaînes
au même hook. Donc dans ton cas ça ne sert à rien, mais c'est nécessaire pour la
syntaxe de déclaration du hook auquel la chaîne est attachée.

Hors ligne

#41 12-08-2019 02:18:48

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

pourquoi le premier fonctionne avec le paramètre "filter" en fin de ligne , et les 3 suivant non , uniquement avec une valeur numérique.
j'ai pas compris et j'ai pensé a une corruption du nftables.conf
je dois mettre un reject  pour le port 138 sur les clients , le temps de purger "samba client"

#42 12-08-2019 02:45:51

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

pourquoi le premier fonctionne avec le paramètre "filter" en fin de ligne , et les 3 suivant non , uniquement avec une valeur numérique.


De quoi tu parles exactement ? Dans toutes tes chaînes
je vois que la priorité est exprimé avec un nombre.

Je crois me souvenir que l'on peut utiliser autre chose qu'un nombre
il faut que je retrouve cette explication dans le wiki de nftables.

Hors ligne

#43 12-08-2019 11:26:23

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

c'est pas grave en #39 tu m'a donné ceci pour le premier client


chain forward {
    type filter hook forward priority filter; policy drop;
    #log prefix "FORWARD_DROP "
  }
 


qui a toujours fonctionné et actuellement encore
je fais trois autres machines
ne me prend que ceci


chain forward {
    type filter hook forward priority 0; policy drop;
    #log prefix "FORWARD_DROP "
  }
 


tu me dit que sur un client la chaine forward n'est pas utilise (une seule carte réseau ) mais qu'il vaut mieux la fixer a drop
quelle différence entre le client raven2200g avec "filter" et les trois autres clients avec "0" sinon le nftables bug
si tu regarde ce fil , la chaine forward est a "filter" , pour la passerelle a "1"

ps: regarde en #1 la fin de la chaine forward est a "filter" depuis le début , c'est une erreur de ma part ? (et ça fonctionne pour cette machine  roll )

sinon voila avec ma petite modification pour filtrer netbios (port 138)


#!/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
    udp dport {137, 138} reject
    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;
    #log prefix "FORWARD_DROP "
  }

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

table ip6 filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif lo accept
  }

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

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



ps: pour enlever le client samba , il faut que je change de bureau , passer de mate a xfce4
la passerelle et le raven2200g sont en xfce4
pour les autres machines je suis en mate donc avec des annonces en port 138 et 192.168.10.255

#44 12-08-2019 12:04:33

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

Bon, j'ai regardé. J'ai du mal me souvenir. Ici ils parlent
de la création des chaînes. Après avoir lu le paragraphe sur les priorités
des chaînes,  on doit utiliser des nombres pour ces priorités.

J'ai l'impression que tu fais une confusion. D'une part on la création de
table que l'on appelle comme on veut. Là on l'a appelé filter pour rassembler
les chaînes de type filter. Mais on aurait pu l'appeler ma_super_table.  la
syntaxe pour créer une table est la suivante :


table [famille] <nom_table>
 


Si [famille] est omis, ip sera utilisé (c'est à dire que les règles dans cette
table opérerons sur des paquets qui ont une adresse en ipv4). Voir ici
pour les familles disponibles. Les familles servent lors de la
création des tables.


La création des chaînes de base est différente. On précise leur type, le hook
auquel elles sont rattachées, leur priorité et enfin optionnellement la police
par défaut (accept par défaut, sinon drop).
En résumé on a :


chain <nom_de_chaine> {
type <type_de_la_chaine> hook <hook> priority <un_nombre>; policy <accept|drop>;
# …
}
 


Le nom de la chaîne est absolument libre. On met le nom que l'on veut. Au sein
d'une même table il doit être unique. Cependant un même nom de chaîne
peut-être utilisé dans des tables différentes ; ce sont alors des chaînes
différentes. Le hook peut prendre les valeur suivante : prerouting,
postrouting, input, output et ingress.

Toute les combinaisons famille/type ne sont pas possible. Ainsi, le type
ingress ne peut être utilisé que dans une table de la famille netdev, c'est un
cas particulier.
Bref, ça fait beaucoup de briques différentes que l'on doit utiliser d'une
manière précise.
Les règles sont incluses dans des chaînes qui sont incluses dans des tables.
J'espère que c'est plus clair à présent.

Hors ligne

#45 12-08-2019 12:05:49

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

tu me dit que sur un client la chaine forward n'est pas utilise (une seule carte réseau ) mais qu'il vaut mieux la fixer a drop


Sur le wiki de nftables, j'ai même lu que dans ce cas on pouvait omettre cette chaîne.

Hors ligne

#46 12-08-2019 12:12:01

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

c'est pas grave en #39 tu m'a donné ceci pour le premier client


En fait, le post #39 c'est toi qui l'a écrit. Et je viens de regarder
cette priority filter pour la chaîne forward était déjà présent dans ton post #1.

Si c'est moi qui a écrit cela, je me suis trompé. Si nftables l'accepte parfois et parfois pas,
je ne comprends pas pourquoi.

Hors ligne

#47 12-08-2019 12:47:56

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

Après lecture rapide des différents fils de discussion, il semblerait
que c'est nft lui même qui a utilisé « priority filter ».
Voir https://debian-facile.org/viewtopic.php … 23#p307423.

Hors ligne

#48 12-08-2019 12:54:54

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

On c'est bien compris , pour moi "0" ou une autre valeur numérique plus logique.
je suis loin de comprendre comme toi le cheminement du réseau (pour preuve sur la passerelle wink  )

#49 12-08-2019 12:59:54

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

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

je suis loin de comprendre comme toi le cheminement du réseau (pour preuve sur la passerelle wink )


Ça viendra, c'est une question de pratique. Il faut aussi du temps pour intégrer
ces histoires, je n'ai pas compris la première fois que je l'ai lu lors du passage à
iptables dans les noyaux 2.4.

Hors ligne

#50 12-08-2019 13:17:51

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

juste comme explication , voila un exemple du programme FAH sur le lancement .


11:58:37:FS01:Unpaused
11:58:37:WU00:FS01:Connecting to 65.254.110.245:8080
11:58:38:WU00:FS01:Assigned to work server 155.247.166.220
11:58:38:WU00:FS01:Requesting new work unit for slot 01: READY gpu:0:GP106 [GeForce GTX 1060 3GB] 3935 from 155.247.166.220
11:58:38:WU00:FS01:Connecting to 155.247.166.220:8080

11:58:41:WU00:FS01:Downloading 2.47MiB
11:58:46:WU00:FS01:Download complete
 



il contacte un serveur
il a en réponse une ip d un serveur disponible pour le téléchargement
une requette pour ma carte graphique
connexion et téléchargement
début du calcul  wink
dans l'autre sens idem , récupérer une nouveau calcul , envoie du résultat du calcul terminé  etc ....

ps: a partir du client ça fonctionne , la passerelle accepte les requêtes

Dernière modification par anonyme (12-08-2019 13:22:58)

Pied de page des forums