autoriser réseau local ipV6 sur un port avec nftables
8 réponses
yamo'
Salut,
Je filtre l'accès Í bind9 et en ipV6, plutÍ´t que de lister toutes les
adresses ipV6 comment autoriser le réseau local sur le port 53?
J'utilise nftables qui est censé être plus simple qu'iptables.
Comment autoriser, cette classe d'adresses :
2a01:e0a:21:ea80::/64 ?
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Est-ce utile au niveau sécurité de fermer les ports pour l'accès Í
distance de bind9?
Je filtre l'accès Í bind9 et en ipV6, plutÍ´t que de lister toutes les adresses ipV6 comment autoriser le réseau local sur le port 53?
Pas compris la question, merci de reformuler.
nftables qui est censé être plus simple qu'iptables.
La bonne blague.
Comment autoriser, cette classe d'adresses : 2a01:e0a:21:ea80::/64 ?
C'est un préfixe, pas une classe. Nftables peut prendre un préfixe comme source ou destination.
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Quelle est-elle ?
Est-ce utile au niveau sécurité de fermer les ports pour l'accès Í distance de bind9?
L'accès de quoi Í quoi exactement ? Quels rÍ´les ce BIND est-il censé jouer ?
yamo'
Salut, Pascal Hambourg a tapoté le 28/05/2022 10:30:
Le 28/05/2022 Í 09:47, yamo' a écrit :
Je filtre l'accès Í bind9 et en ipV6, plutÍ´t que de lister toutes les adresses ipV6 comment autoriser le réseau local sur le port 53?
Pas compris la question, merci de reformuler.
Oui, en relisant ce n'est pas clair. Je voudrais n'autoriser que mon réseau local (et localhost) pour accéder Í bind9. Je sais le faire en ipV4 mais en ipV6 je me perds dans les documentations...
nftables qui est censé être plus simple qu'iptables.
La bonne blague.
Si tu as une alternative plus simple...
Comment autoriser, cette classe d'adresses : 2a01:e0a:21:ea80::/64 ?
C'est un préfixe, pas une classe.
En fait toutes les adresses commençant par : 2a01:e0a:21:ea80: C'est mieux dit?
Nftables peut prendre un préfixe comme source ou destination.
Il faudrait que je ré-essaie ; Í chaque fois j'ai eu des soucis pour lui faire accepter ma configuration.
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Quelle est-elle ?
Celle de base sur debian. Il me sert juste de cache DNS. Et je me demande si ce ne serait pas plus simple de laisser n'importe quel client le consulter. -- Stéphane
Salut,
Pascal Hambourg a tapoté le 28/05/2022 10:30:
Le 28/05/2022 Í 09:47, yamo' a écrit :
Je filtre l'accès Í bind9 et en ipV6, plutÍ´t que de lister toutes les
adresses ipV6 comment autoriser le réseau local sur le port 53?
Pas compris la question, merci de reformuler.
Oui, en relisant ce n'est pas clair.
Je voudrais n'autoriser que mon réseau local (et localhost) pour accéder
Í bind9.
Je sais le faire en ipV4 mais en ipV6 je me perds dans les documentations...
nftables qui est censé être plus simple qu'iptables.
La bonne blague.
Si tu as une alternative plus simple...
Comment autoriser, cette classe d'adresses :
2a01:e0a:21:ea80::/64 ?
C'est un préfixe, pas une classe.
En fait toutes les adresses commençant par :
2a01:e0a:21:ea80:
C'est mieux dit?
Nftables peut prendre un préfixe comme source ou destination.
Il faudrait que je ré-essaie ; Í chaque fois j'ai eu des soucis pour lui
faire accepter ma configuration.
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Quelle est-elle ?
Celle de base sur debian.
Il me sert juste de cache DNS.
Et je me demande si ce ne serait pas plus simple de laisser n'importe
quel client le consulter.
Salut, Pascal Hambourg a tapoté le 28/05/2022 10:30:
Le 28/05/2022 Í 09:47, yamo' a écrit :
Je filtre l'accès Í bind9 et en ipV6, plutÍ´t que de lister toutes les adresses ipV6 comment autoriser le réseau local sur le port 53?
Pas compris la question, merci de reformuler.
Oui, en relisant ce n'est pas clair. Je voudrais n'autoriser que mon réseau local (et localhost) pour accéder Í bind9. Je sais le faire en ipV4 mais en ipV6 je me perds dans les documentations...
nftables qui est censé être plus simple qu'iptables.
La bonne blague.
Si tu as une alternative plus simple...
Comment autoriser, cette classe d'adresses : 2a01:e0a:21:ea80::/64 ?
C'est un préfixe, pas une classe.
En fait toutes les adresses commençant par : 2a01:e0a:21:ea80: C'est mieux dit?
Nftables peut prendre un préfixe comme source ou destination.
Il faudrait que je ré-essaie ; Í chaque fois j'ai eu des soucis pour lui faire accepter ma configuration.
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Quelle est-elle ?
Celle de base sur debian. Il me sert juste de cache DNS. Et je me demande si ce ne serait pas plus simple de laisser n'importe quel client le consulter. -- Stéphane
Pascal Hambourg
Le 29/05/2022 Í 18:04, yamo' a écrit :
Le 28/05/2022 Í 09:47, yamo' a écrit :
Je voudrais n'autoriser que mon réseau local (et localhost) pour accéder Í bind9. Je sais le faire en ipV4 mais en ipV6 je me perds dans les documentations...
Les options allow-query* de BIND ne suffisent pas ? Elles supportent les préfixes IPv6. Il te faut vraiment un filtrage des paquets IPv6 en amont de BIND ?
nftables qui est censé être plus simple qu'iptables.
La bonne blague.
Si tu as une alternative plus simple...
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Comment autoriser, cette classe d'adresses : 2a01:e0a:21:ea80::/64 ?
C'est un préfixe, pas une classe.
En fait toutes les adresses commençant par : 2a01:e0a:21:ea80:
C'est ce que je disais, un préfixe.
Nftables peut prendre un préfixe comme source ou destination.
Il faudrait que je ré-essaie ; Í chaque fois j'ai eu des soucis pour lui faire accepter ma configuration.
Il n'est pas interdit de la montrer.
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Quelle est-elle ?
Celle de base sur debian.
Ça ne m'éclaire pas des masses. J'ai installé mon BIND sur Debian il y a un paquet d'années, je ne me souviens pas bien de la configuration par défaut et elle a peut-être changé depuis. Il me semble que c'était en cache récursif avec accès depuis les préfixes locaux (localnets).
Il me sert juste de cache DNS. Et je me demande si ce ne serait pas plus simple de laisser n'importe quel client le consulter.
Risque d'abus en tous genres, déni de service, empoisonnement de cache...
Le 29/05/2022 Í 18:04, yamo' a écrit :
Le 28/05/2022 Í 09:47, yamo' a écrit :
Je voudrais n'autoriser que mon réseau local (et localhost) pour accéder
Í bind9.
Je sais le faire en ipV4 mais en ipV6 je me perds dans les documentations...
Les options allow-query* de BIND ne suffisent pas ? Elles supportent les
préfixes IPv6. Il te faut vraiment un filtrage des paquets IPv6 en amont
de BIND ?
nftables qui est censé être plus simple qu'iptables.
La bonne blague.
Si tu as une alternative plus simple...
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Comment autoriser, cette classe d'adresses :
2a01:e0a:21:ea80::/64 ?
C'est un préfixe, pas une classe.
En fait toutes les adresses commençant par :
2a01:e0a:21:ea80:
C'est ce que je disais, un préfixe.
Nftables peut prendre un préfixe comme source ou destination.
Il faudrait que je ré-essaie ; Í chaque fois j'ai eu des soucis pour lui
faire accepter ma configuration.
Il n'est pas interdit de la montrer.
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Quelle est-elle ?
Celle de base sur debian.
Ça ne m'éclaire pas des masses. J'ai installé mon BIND sur Debian il y a
un paquet d'années, je ne me souviens pas bien de la configuration par
défaut et elle a peut-être changé depuis. Il me semble que c'était en
cache récursif avec accès depuis les préfixes locaux (localnets).
Il me sert juste de cache DNS.
Et je me demande si ce ne serait pas plus simple de laisser n'importe
quel client le consulter.
Risque d'abus en tous genres, déni de service, empoisonnement de cache...
Je voudrais n'autoriser que mon réseau local (et localhost) pour accéder Í bind9. Je sais le faire en ipV4 mais en ipV6 je me perds dans les documentations...
Les options allow-query* de BIND ne suffisent pas ? Elles supportent les préfixes IPv6. Il te faut vraiment un filtrage des paquets IPv6 en amont de BIND ?
nftables qui est censé être plus simple qu'iptables.
La bonne blague.
Si tu as une alternative plus simple...
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Comment autoriser, cette classe d'adresses : 2a01:e0a:21:ea80::/64 ?
C'est un préfixe, pas une classe.
En fait toutes les adresses commençant par : 2a01:e0a:21:ea80:
C'est ce que je disais, un préfixe.
Nftables peut prendre un préfixe comme source ou destination.
Il faudrait que je ré-essaie ; Í chaque fois j'ai eu des soucis pour lui faire accepter ma configuration.
Il n'est pas interdit de la montrer.
Question subsidiaire, j'ai laissé bind9 dans sa configuration initiale.
Quelle est-elle ?
Celle de base sur debian.
Ça ne m'éclaire pas des masses. J'ai installé mon BIND sur Debian il y a un paquet d'années, je ne me souviens pas bien de la configuration par défaut et elle a peut-être changé depuis. Il me semble que c'était en cache récursif avec accès depuis les préfixes locaux (localnets).
Il me sert juste de cache DNS. Et je me demande si ce ne serait pas plus simple de laisser n'importe quel client le consulter.
Risque d'abus en tous genres, déni de service, empoisonnement de cache...
yamo'
Salut, Pascal Hambourg a tapoté le 29/05/2022 18:34:
Les options allow-query* de BIND ne suffisent pas ? Elles supportent les préfixes IPv6. Il te faut vraiment un filtrage des paquets IPv6 en amont de BIND ?
Merci, je vais creuser cette piste.
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Il n'est pas interdit de la montrer.
Merci avec tes conseils, ça fonctionne : J'ai dans /etc/nftables.conf #!/usr/sbin/nft -f #Les lignes sont trop longues, j'espère que ce sera lisible.. flush ruleset table inet filter { chain input { type filter hook input priority 0; # allow from loopback iif lo accept ip6 saddr ::1 accept iifname lo accept ip saddr 192.168.0.0/24 accept # des tonnes de ip saddr **** drop # idem ip6 saddr ******** drop ct state invalid drop ct state related,established accept ct state new tcp dport {#serveurs usenet, apache} accept ct state new tcp dport {113, 137, 138} log prefix " REJECT " reject with icmpx type port-unreachable ct state new udp dport {113, 137, 138} log prefix " REJECT " reject with icmpx type port-unreachable ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, echo-request, nd-router-advert, nd-neighbor-advert } accept udp dport mdns ip6 daddr ff02::fb accept udp dport {bootpc, bootps} ip6 daddr ff02::fb accept ip daddr 255.255.255.255 accept ip daddr 224.0.0.251 log prefix " accept daddr 224.0.0.251 " accept ip6 saddr 2a01:e0a:21:ea80::/64 accept ip6 saddr fe80::/10 accept log prefix " INPUT DROP " drop } chain forward { type filter hook forward priority 0; log prefix " FORWARD DROP "; policy drop; } chain output { type filter hook output priority 0; policy accept; } }
Risque d'abus en tous genres, déni de service, empoisonnement de cache...
C'est ce qu'il me semblait! Merci! -- Stéphane
Salut,
Pascal Hambourg a tapoté le 29/05/2022 18:34:
Les options allow-query* de BIND ne suffisent pas ? Elles supportent les
préfixes IPv6. Il te faut vraiment un filtrage des paquets IPv6 en amont
de BIND ?
Merci, je vais creuser cette piste.
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Il n'est pas interdit de la montrer.
Merci avec tes conseils, ça fonctionne :
J'ai dans /etc/nftables.conf
#!/usr/sbin/nft -f
#Les lignes sont trop longues, j'espère que ce sera lisible..
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
# allow from loopback
iif lo accept
ip6 saddr ::1 accept
iifname lo accept
ip saddr 192.168.0.0/24 accept
# des tonnes de ip saddr **** drop
# idem ip6 saddr ******** drop
ct state invalid drop
ct state related,established accept
ct state new tcp dport {#serveurs usenet, apache} accept
ct state new tcp dport {113, 137, 138} log prefix " REJECT " reject
with icmpx type port-unreachable
ct state new udp dport {113, 137, 138} log prefix "
REJECT " reject with icmpx type port-unreachable
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit,
echo-request, nd-router-advert, nd-neighbor-advert } accept
udp dport mdns ip6 daddr ff02::fb accept
udp dport {bootpc, bootps} ip6 daddr ff02::fb accept
ip daddr 255.255.255.255 accept
ip daddr 224.0.0.251 log prefix " accept daddr
224.0.0.251 " accept
ip6 saddr 2a01:e0a:21:ea80::/64 accept
ip6 saddr fe80::/10 accept
log prefix " INPUT DROP " drop
}
chain forward {
type filter hook forward priority 0; log prefix "
FORWARD DROP "; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
Risque d'abus en tous genres, déni de service, empoisonnement de cache...
Salut, Pascal Hambourg a tapoté le 29/05/2022 18:34:
Les options allow-query* de BIND ne suffisent pas ? Elles supportent les préfixes IPv6. Il te faut vraiment un filtrage des paquets IPv6 en amont de BIND ?
Merci, je vais creuser cette piste.
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Il n'est pas interdit de la montrer.
Merci avec tes conseils, ça fonctionne : J'ai dans /etc/nftables.conf #!/usr/sbin/nft -f #Les lignes sont trop longues, j'espère que ce sera lisible.. flush ruleset table inet filter { chain input { type filter hook input priority 0; # allow from loopback iif lo accept ip6 saddr ::1 accept iifname lo accept ip saddr 192.168.0.0/24 accept # des tonnes de ip saddr **** drop # idem ip6 saddr ******** drop ct state invalid drop ct state related,established accept ct state new tcp dport {#serveurs usenet, apache} accept ct state new tcp dport {113, 137, 138} log prefix " REJECT " reject with icmpx type port-unreachable ct state new udp dport {113, 137, 138} log prefix " REJECT " reject with icmpx type port-unreachable ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, echo-request, nd-router-advert, nd-neighbor-advert } accept udp dport mdns ip6 daddr ff02::fb accept udp dport {bootpc, bootps} ip6 daddr ff02::fb accept ip daddr 255.255.255.255 accept ip daddr 224.0.0.251 log prefix " accept daddr 224.0.0.251 " accept ip6 saddr 2a01:e0a:21:ea80::/64 accept ip6 saddr fe80::/10 accept log prefix " INPUT DROP " drop } chain forward { type filter hook forward priority 0; log prefix " FORWARD DROP "; policy drop; } chain output { type filter hook output priority 0; policy accept; } }
Risque d'abus en tous genres, déni de service, empoisonnement de cache...
C'est ce qu'il me semblait! Merci! -- Stéphane
Pascal Hambourg
Le 02/06/2022 Í 11:02, yamo' a écrit :
Salut, Pascal Hambourg a tapoté le 29/05/2022 18:34:
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du moins essaie de le faire avec plus ou moins de succès) les règles iptables en règles nftables pour le noyau. C'est cette variante qui est active par défaut via les alternatives dans Debian Í la place de la variante originelle -legacy.
Le 02/06/2022 Í 11:02, yamo' a écrit :
Salut,
Pascal Hambourg a tapoté le 29/05/2022 18:34:
> J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Les commandes iptables et ip6tables ont une variante -nft qui traduit
(ou du moins essaie de le faire avec plus ou moins de succès) les règles
iptables en règles nftables pour le noyau. C'est cette variante qui est
active par défaut via les alternatives dans Debian Í la place de la
variante originelle -legacy.
Salut, Pascal Hambourg a tapoté le 29/05/2022 18:34:
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du moins essaie de le faire avec plus ou moins de succès) les règles iptables en règles nftables pour le noyau. C'est cette variante qui est active par défaut via les alternatives dans Debian Í la place de la variante originelle -legacy.
Erwan David
Pascal Hambourg écrivait :
Le 02/06/2022 Í 11:02, yamo' a écrit :
Salut, Pascal Hambourg a tapoté le 29/05/2022 18:34:
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du moins essaie de le faire avec plus ou moins de succès) les règles iptables en règles nftables pour le noyau. C'est cette variante qui est active par défaut via les alternatives dans Debian Í la place de la variante originelle -legacy.
Ce ne sont pas des règles nftables, mais un autre jeu de règles. Et ce n'est pas non plus la syntaxe iptables... Pour voir l"tat du firewalling, il faut iptables-legacy -L iptables-nft -L nft list ruleset Et mieux vaut éviter de mettre des régles avec plusieurs systèmes, c'est le bordel assuré. Perso c'est iptables-legacy ou nft, mais pas le machin hybride. -- Les simplifications c'est trop compliqué
Salut,
Pascal Hambourg a tapoté le 29/05/2022 18:34:
> J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du
moins essaie de le faire avec plus ou moins de succès) les règles iptables en
règles nftables pour le noyau. C'est cette variante qui est active par défaut
via les alternatives dans Debian Í la place de la variante originelle -legacy.
Ce ne sont pas des règles nftables, mais un autre jeu de règles.
Et ce n'est pas non plus la syntaxe iptables...
Pour voir l"tat du firewalling, il faut
iptables-legacy -L
iptables-nft -L
nft list ruleset
Et mieux vaut éviter de mettre des régles avec plusieurs systèmes, c'est
le bordel assuré.
Perso c'est iptables-legacy ou nft, mais pas le machin hybride.
Salut, Pascal Hambourg a tapoté le 29/05/2022 18:34:
J'utilise encore ip6tables. Le vrai, pas l'émulation par nftables.
Je croyais que nftables était un projet concurrent Í iptables.
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du moins essaie de le faire avec plus ou moins de succès) les règles iptables en règles nftables pour le noyau. C'est cette variante qui est active par défaut via les alternatives dans Debian Í la place de la variante originelle -legacy.
Ce ne sont pas des règles nftables, mais un autre jeu de règles. Et ce n'est pas non plus la syntaxe iptables... Pour voir l"tat du firewalling, il faut iptables-legacy -L iptables-nft -L nft list ruleset Et mieux vaut éviter de mettre des régles avec plusieurs systèmes, c'est le bordel assuré. Perso c'est iptables-legacy ou nft, mais pas le machin hybride. -- Les simplifications c'est trop compliqué
Pascal Hambourg
Le 02/06/2022 Í 21:01, Erwan David a écrit :
Pascal Hambourg écrivait :
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du moins essaie de le faire avec plus ou moins de succès) les règles iptables en règles nftables pour le noyau. C'est cette variante qui est active par défaut via les alternatives dans Debian Í la place de la variante originelle -legacy.
Ce ne sont pas des règles nftables, mais un autre jeu de règles. Et ce n'est pas non plus la syntaxe iptables...
Vraiment ? Alors comment se fait-il que si je crée des règles avec iptables-nft en utilisant la syntaxe d'iptables, nft list ruleset affiche les règles équivalentes dans la syntaxe de nftables ?
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du
moins essaie de le faire avec plus ou moins de succès) les règles iptables en
règles nftables pour le noyau. C'est cette variante qui est active par défaut
via les alternatives dans Debian Í la place de la variante originelle -legacy.
Ce ne sont pas des règles nftables, mais un autre jeu de règles.
Et ce n'est pas non plus la syntaxe iptables...
Vraiment ? Alors comment se fait-il que si je crée des règles avec
iptables-nft en utilisant la syntaxe d'iptables, nft list ruleset
affiche les règles équivalentes dans la syntaxe de nftables ?
Les commandes iptables et ip6tables ont une variante -nft qui traduit (ou du moins essaie de le faire avec plus ou moins de succès) les règles iptables en règles nftables pour le noyau. C'est cette variante qui est active par défaut via les alternatives dans Debian Í la place de la variante originelle -legacy.
Ce ne sont pas des règles nftables, mais un autre jeu de règles. Et ce n'est pas non plus la syntaxe iptables...
Vraiment ? Alors comment se fait-il que si je crée des règles avec iptables-nft en utilisant la syntaxe d'iptables, nft list ruleset affiche les règles équivalentes dans la syntaxe de nftables ?
yamo'
Salut, Erwan David a tapoté le 02/06/2022 21:01:
Pour voir l"tat du firewalling, il faut iptables-legacy -L
bash: iptables-legacy : commande introuvable
iptables-nft -L
Idem
nft list ruleset
LÍ ça réponds correctement. Je suis sur debian stable (plutÍ´t raspbian) iptables est toujours disponible mais n'est pas installé sur mon système. <https://wiki.debian.org/nftables> -- Stéphane
Salut,
Erwan David a tapoté le 02/06/2022 21:01:
Pour voir l"tat du firewalling, il faut
iptables-legacy -L
bash: iptables-legacy : commande introuvable
iptables-nft -L
Idem
nft list ruleset
LÍ ça réponds correctement.
Je suis sur debian stable (plutÍ´t raspbian)
iptables est toujours disponible mais n'est pas installé sur mon système.
Pour voir l"tat du firewalling, il faut iptables-legacy -L
bash: iptables-legacy : commande introuvable
iptables-nft -L
Idem
nft list ruleset
LÍ ça réponds correctement. Je suis sur debian stable (plutÍ´t raspbian) iptables est toujours disponible mais n'est pas installé sur mon système. <https://wiki.debian.org/nftables> -- Stéphane
