Oui, l'effet de bord de filtrage du NAT peut être obtenu avec un simple filtrage à état avec suivi de connexion, disponible dans le noyau Linux depuis la série 2.4 pour IPv4 et la version 2.6.15 (mais pas forcément activé dans les noyaux précompilés des distributions avant la version 2.6.20) pour IPv6, sans l'inconvénient de la réécriture d'adresse et/ou de port. Le NAT source (masquerading) peut être remplacé par l'autorisation des connexions sortantes et le NAT destination (redirection) par l'autorisation sélective des connexions entrantes.
En pratique : Actuellement, en IPV4, mes PC sont derrière le NAT (une box en fait), avec des partages de fichiers sans mot de passe (inutile, y'a que moi et ma famille qui s'en servent). Les mots de passe de login sont triviaux (à quoi bon ?).
En IPV6, comment je fais pour que mes partages soient inaccessibles de l'extérieur ?
Première possibilité, triviale : configurer les services de partage pour qu'il n'écoute qu'en IPv4, ou ne serve que les adresses de ton réseau. Ça me semble quand même être la base d'ouvrir les services juste comme nécessaire plutôt que d'ouvrir à tous les vents puis de filtrer par dessus avec un pare-feu.
Seconde possibilité : bloquer les ports des services de partage en IPv6 en entrée avec un pare-feu sur chaque machine.
Troisième possibilité : faire du filtrage à état et bloquer les connexions IPv6 entrantes avec un pare-feu sur chaque machine. On peut raffiner pour autoriser les connexions en provenance des adresses du réseau local.
Quatrième possibilité : installer un pont filtrant entre la box et le réseau local bloquant les ports indésirables ou les connexions provenant de l'extérieur.
Sergio a écrit :
Le 22/07/2010 09:55, Pascal Hambourg a écrit :
Oui, l'effet de bord de filtrage du NAT peut être obtenu avec un simple
filtrage à état avec suivi de connexion, disponible dans le noyau Linux
depuis la série 2.4 pour IPv4 et la version 2.6.15 (mais pas forcément
activé dans les noyaux précompilés des distributions avant la version
2.6.20) pour IPv6, sans l'inconvénient de la réécriture d'adresse et/ou
de port. Le NAT source (masquerading) peut être remplacé par
l'autorisation des connexions sortantes et le NAT destination
(redirection) par l'autorisation sélective des connexions entrantes.
En pratique :
Actuellement, en IPV4, mes PC sont derrière le NAT (une box en fait),
avec des partages de fichiers sans mot de passe (inutile, y'a que moi et
ma famille qui s'en servent). Les mots de passe de login sont triviaux
(à quoi bon ?).
En IPV6, comment je fais pour que mes partages soient inaccessibles de
l'extérieur ?
Première possibilité, triviale : configurer les services de partage pour
qu'il n'écoute qu'en IPv4, ou ne serve que les adresses de ton réseau.
Ça me semble quand même être la base d'ouvrir les services juste comme
nécessaire plutôt que d'ouvrir à tous les vents puis de filtrer par
dessus avec un pare-feu.
Seconde possibilité : bloquer les ports des services de partage en IPv6
en entrée avec un pare-feu sur chaque machine.
Troisième possibilité : faire du filtrage à état et bloquer les
connexions IPv6 entrantes avec un pare-feu sur chaque machine. On peut
raffiner pour autoriser les connexions en provenance des adresses du
réseau local.
Quatrième possibilité : installer un pont filtrant entre la box et le
réseau local bloquant les ports indésirables ou les connexions provenant
de l'extérieur.
Oui, l'effet de bord de filtrage du NAT peut être obtenu avec un simple filtrage à état avec suivi de connexion, disponible dans le noyau Linux depuis la série 2.4 pour IPv4 et la version 2.6.15 (mais pas forcément activé dans les noyaux précompilés des distributions avant la version 2.6.20) pour IPv6, sans l'inconvénient de la réécriture d'adresse et/ou de port. Le NAT source (masquerading) peut être remplacé par l'autorisation des connexions sortantes et le NAT destination (redirection) par l'autorisation sélective des connexions entrantes.
En pratique : Actuellement, en IPV4, mes PC sont derrière le NAT (une box en fait), avec des partages de fichiers sans mot de passe (inutile, y'a que moi et ma famille qui s'en servent). Les mots de passe de login sont triviaux (à quoi bon ?).
En IPV6, comment je fais pour que mes partages soient inaccessibles de l'extérieur ?
Première possibilité, triviale : configurer les services de partage pour qu'il n'écoute qu'en IPv4, ou ne serve que les adresses de ton réseau. Ça me semble quand même être la base d'ouvrir les services juste comme nécessaire plutôt que d'ouvrir à tous les vents puis de filtrer par dessus avec un pare-feu.
Seconde possibilité : bloquer les ports des services de partage en IPv6 en entrée avec un pare-feu sur chaque machine.
Troisième possibilité : faire du filtrage à état et bloquer les connexions IPv6 entrantes avec un pare-feu sur chaque machine. On peut raffiner pour autoriser les connexions en provenance des adresses du réseau local.
Quatrième possibilité : installer un pont filtrant entre la box et le réseau local bloquant les ports indésirables ou les connexions provenant de l'extérieur.
Erwan David
Pascal Hambourg écrivait :
Erwan David a écrit :
Pascal Hambourg écrivait :
Néanmoins je n'ai pas été, disons, convaincu par la gestion du filtrage IPv6 par le pare-feu intégré d'une distribution les dernières fois que j'ai essayé (c'était avec Mandriva 2008 et 2009).
Je gère ça avec shorewall6, ça marche bien.
Sous Mandriva ? Il me semble que c'est shorewall qui est derrière l'interface de configuration du pare-feu de Mandriva, et je pensais qu'il gérait aussi IPv6. Il faudrait en fait installer ce paquet supplémentaire pour un filtrage IPv6 digne de ce nom ?
Non sous debian. Il ya effectivement 2 jeux de règles, un pour IPv4 avec shorewall et un pour IPv6 avec shorewall6.
Il est vrai que au moins les policy pourraient être partagés, sauf à vouloir découper ses zones différemment en v4 et en v6...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Néanmoins je n'ai pas été, disons, convaincu par la gestion
du filtrage IPv6 par le pare-feu intégré d'une distribution les
dernières fois que j'ai essayé (c'était avec Mandriva 2008 et 2009).
Je gère ça avec shorewall6, ça marche bien.
Sous Mandriva ? Il me semble que c'est shorewall qui est derrière
l'interface de configuration du pare-feu de Mandriva, et je pensais
qu'il gérait aussi IPv6. Il faudrait en fait installer ce paquet
supplémentaire pour un filtrage IPv6 digne de ce nom ?
Non sous debian. Il ya effectivement 2 jeux de règles, un pour IPv4 avec
shorewall et un pour IPv6 avec shorewall6.
Il est vrai que au moins les policy pourraient être partagés, sauf à
vouloir découper ses zones différemment en v4 et en v6...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Néanmoins je n'ai pas été, disons, convaincu par la gestion du filtrage IPv6 par le pare-feu intégré d'une distribution les dernières fois que j'ai essayé (c'était avec Mandriva 2008 et 2009).
Je gère ça avec shorewall6, ça marche bien.
Sous Mandriva ? Il me semble que c'est shorewall qui est derrière l'interface de configuration du pare-feu de Mandriva, et je pensais qu'il gérait aussi IPv6. Il faudrait en fait installer ce paquet supplémentaire pour un filtrage IPv6 digne de ce nom ?
Non sous debian. Il ya effectivement 2 jeux de règles, un pour IPv4 avec shorewall et un pour IPv6 avec shorewall6.
Il est vrai que au moins les policy pourraient être partagés, sauf à vouloir découper ses zones différemment en v4 et en v6...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
xavier
HD wrote:
mais depuis cette "protection" est effectivement très largement dépassée.
D'autant plus que c'est un concept qui n'existe tout simplement plus en IPv6
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
HD <hd@anti.spam.fr> wrote:
mais depuis cette "protection" est effectivement très largement dépassée.
D'autant plus que c'est un concept qui n'existe tout simplement plus en
IPv6
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
mais depuis cette "protection" est effectivement très largement dépassée.
D'autant plus que c'est un concept qui n'existe tout simplement plus en IPv6
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Pascal Hambourg
Xavier a écrit :
D'autant plus que c'est un concept qui n'existe tout simplement plus en IPv6
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6. Il ne fait pas partie de leur spécification (même s'il existe des RFC pour IPv4 qui essaient plus ou moins de le standardiser), et rien n'empêche qui que ce soit de faire du NAT en IPv6 si ça lui chante.
Xavier a écrit :
D'autant plus que c'est un concept qui n'existe tout simplement plus en
IPv6
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6. Il ne
fait pas partie de leur spécification (même s'il existe des RFC pour
IPv4 qui essaient plus ou moins de le standardiser), et rien n'empêche
qui que ce soit de faire du NAT en IPv6 si ça lui chante.
D'autant plus que c'est un concept qui n'existe tout simplement plus en IPv6
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6. Il ne fait pas partie de leur spécification (même s'il existe des RFC pour IPv4 qui essaient plus ou moins de le standardiser), et rien n'empêche qui que ce soit de faire du NAT en IPv6 si ça lui chante.
xavier
Pascal Hambourg wrote:
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6.
Tu as tout à fait raison, je ferais mieux de réfléchir avant d'écrire des honneries :-)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6.
Tu as tout à fait raison, je ferais mieux de réfléchir avant d'écrire des honneries :-)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Pascal Hambourg
Xavier a écrit :
Pascal Hambourg wrote:
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6.
Tu as tout à fait raison,
Ah, oui, encore !
je ferais mieux de réfléchir avant d'écrire des honneries :-)
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui est intimement lié alors que ce n'est et ne restera qu'une verrue. Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6.
Tu as tout à fait raison,
Ah, oui, encore !
je ferais mieux de réfléchir avant d'écrire des honneries :-)
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait
tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui
est intimement lié alors que ce n'est et ne restera qu'une verrue.
Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser
du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
Le NAT en tant que concept n'existe pas plus en IPv4 qu'en IPv6.
Tu as tout à fait raison,
Ah, oui, encore !
je ferais mieux de réfléchir avant d'écrire des honneries :-)
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui est intimement lié alors que ce n'est et ne restera qu'une verrue. Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
xavier
Pascal Hambourg wrote:
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui est intimement lié alors que ce n'est et ne restera qu'une verrue.
A tel point, que dans la config d'un FW, si tu veux déclarer un IP publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux que je connais, IPFilter, PF, et IOS pour PIX.
Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
C'est vrai que PF sait faire, sjmsb. Mais faut dire que j'ai du mal à imaginer une utilité dans ce cas...
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait
tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui
est intimement lié alors que ce n'est et ne restera qu'une verrue.
A tel point, que dans la config d'un FW, si tu veux déclarer un IP
publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux
que je connais, IPFilter, PF, et IOS pour PIX.
Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser
du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
C'est vrai que PF sait faire, sjmsb. Mais faut dire que j'ai du mal à
imaginer une utilité dans ce cas...
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui est intimement lié alors que ce n'est et ne restera qu'une verrue.
A tel point, que dans la config d'un FW, si tu veux déclarer un IP publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux que je connais, IPFilter, PF, et IOS pour PIX.
Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
C'est vrai que PF sait faire, sjmsb. Mais faut dire que j'ai du mal à imaginer une utilité dans ce cas...
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Pascal Hambourg
Xavier a écrit :
Pascal Hambourg wrote:
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui est intimement lié alors que ce n'est et ne restera qu'une verrue.
A tel point, que dans la config d'un FW, si tu veux déclarer un IP publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux que je connais, IPFilter, PF, et IOS pour PIX.
Ah ? C'est bizarre comme façon de faire. Avec netfilter/iptables, il suffit de lui dire de ne pas NATer.
Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
C'est vrai que PF sait faire, sjmsb.
Concernant netfilter/iptables, les développeurs ont dit et répété qu'ils ne le feraient pas.
Mais faut dire que j'ai du mal à imaginer une utilité dans ce cas...
Avec un peu d'imagination, on peut en trouver.
Pour le NAT source ou "masquerading" : - si on n'a pas de préfixe IPv6 global fixe et qu'on ne veut pas s'embêter à renuméroter son réseau local à chaque changement ou si on n'a qu'une seule adresse IPv6 globale (rigolez pas, ça existe) : on configure un préfixe local ULA sur le réseau et on fait du masquerading sur le routeur, exactement comme avec les adresses privées en IPv4. - en cas de multihoming avec routage avancé si au moins un des FAI fait de la vérification d'adresse source, pour s'assurer qu'on utilise le bon préfixe source sur chaque lien.
Pour le NAT destination : - redirection de port - changement de port ou d'adresse d'écoute d'un service - serveurs virtuels, - équilibrage de charge,
Certes, on notera qu'à chaque fois le NAT sert de rustine pour résoudre de façon "quick and dirty" des problèmes qui devraient être résolus proprement autrement.
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait
tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui
est intimement lié alors que ce n'est et ne restera qu'une verrue.
A tel point, que dans la config d'un FW, si tu veux déclarer un IP
publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux
que je connais, IPFilter, PF, et IOS pour PIX.
Ah ? C'est bizarre comme façon de faire. Avec netfilter/iptables, il
suffit de lui dire de ne pas NATer.
Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser
du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
C'est vrai que PF sait faire, sjmsb.
Concernant netfilter/iptables, les développeurs ont dit et répété qu'ils
ne le feraient pas.
Mais faut dire que j'ai du mal à imaginer une utilité dans ce cas...
Avec un peu d'imagination, on peut en trouver.
Pour le NAT source ou "masquerading" :
- si on n'a pas de préfixe IPv6 global fixe et qu'on ne veut pas
s'embêter à renuméroter son réseau local à chaque changement ou si on
n'a qu'une seule adresse IPv6 globale (rigolez pas, ça existe) : on
configure un préfixe local ULA sur le réseau et on fait du masquerading
sur le routeur, exactement comme avec les adresses privées en IPv4.
- en cas de multihoming avec routage avancé si au moins un des FAI fait
de la vérification d'adresse source, pour s'assurer qu'on utilise le bon
préfixe source sur chaque lien.
Pour le NAT destination :
- redirection de port
- changement de port ou d'adresse d'écoute d'un service
- serveurs virtuels,
- équilibrage de charge,
Certes, on notera qu'à chaque fois le NAT sert de rustine pour résoudre
de façon "quick and dirty" des problèmes qui devraient être résolus
proprement autrement.
Mais c'est symptomatique de ce que je soulignais plus haut. Le NAT fait tellement partie du paysage IPv4 qu'on finit par se persuader qu'il lui est intimement lié alors que ce n'est et ne restera qu'une verrue.
A tel point, que dans la config d'un FW, si tu veux déclarer un IP publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux que je connais, IPFilter, PF, et IOS pour PIX.
Ah ? C'est bizarre comme façon de faire. Avec netfilter/iptables, il suffit de lui dire de ne pas NATer.
Inversement IPv6 a été conçu entre autres avec l'idée de se débarrasser du NAT, donc on a tendance à penser que le NAT ne peut pas exister en IPv6.
C'est vrai que PF sait faire, sjmsb.
Concernant netfilter/iptables, les développeurs ont dit et répété qu'ils ne le feraient pas.
Mais faut dire que j'ai du mal à imaginer une utilité dans ce cas...
Avec un peu d'imagination, on peut en trouver.
Pour le NAT source ou "masquerading" : - si on n'a pas de préfixe IPv6 global fixe et qu'on ne veut pas s'embêter à renuméroter son réseau local à chaque changement ou si on n'a qu'une seule adresse IPv6 globale (rigolez pas, ça existe) : on configure un préfixe local ULA sur le réseau et on fait du masquerading sur le routeur, exactement comme avec les adresses privées en IPv4. - en cas de multihoming avec routage avancé si au moins un des FAI fait de la vérification d'adresse source, pour s'assurer qu'on utilise le bon préfixe source sur chaque lien.
Pour le NAT destination : - redirection de port - changement de port ou d'adresse d'écoute d'un service - serveurs virtuels, - équilibrage de charge,
Certes, on notera qu'à chaque fois le NAT sert de rustine pour résoudre de façon "quick and dirty" des problèmes qui devraient être résolus proprement autrement.
Eric Belhomme
Le Thu, 29 Jul 2010 16:01:48 +0200, Xavier a écrit :
A tel point, que dans la config d'un FW, si tu veux déclarer un IP publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux que je connais, IPFilter, PF, et IOS pour PIX.
??? Tu as vu ça où ??? J'ai eu utilisé ipfilter sous netbsd et la NAT se configure explicitement via une règle dans /etc/ipnat.conf J'ai jamais utilisé PF, mais tous les dictaciels que j'ai pu lire dessus font état du même type de règle ?
-- Rico
Le Thu, 29 Jul 2010 16:01:48 +0200, Xavier a écrit :
A tel point, que dans la config d'un FW, si tu veux déclarer un IP
publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux
que je connais, IPFilter, PF, et IOS pour PIX.
??? Tu as vu ça où ???
J'ai eu utilisé ipfilter sous netbsd et la NAT se configure explicitement
via une règle dans /etc/ipnat.conf
J'ai jamais utilisé PF, mais tous les dictaciels que j'ai pu lire dessus
font état du même type de règle ?
Le Thu, 29 Jul 2010 16:01:48 +0200, Xavier a écrit :
A tel point, que dans la config d'un FW, si tu veux déclarer un IP publique, tu est obligé de la bi-natter sur elle même. Au moins sur ceux que je connais, IPFilter, PF, et IOS pour PIX.
??? Tu as vu ça où ??? J'ai eu utilisé ipfilter sous netbsd et la NAT se configure explicitement via une règle dans /etc/ipnat.conf J'ai jamais utilisé PF, mais tous les dictaciels que j'ai pu lire dessus font état du même type de règle ?
-- Rico
Eric Belhomme
Le Thu, 29 Jul 2010 17:02:41 +0200, Pascal Hambourg a écrit :
Ah ? C'est bizarre comme façon de faire. Avec netfilter/iptables, il suffit de lui dire de ne pas NATer.
ou plus exactement, il suffit de ne PAS lui dire de NATter ;)
-- Rico
Le Thu, 29 Jul 2010 17:02:41 +0200, Pascal Hambourg a écrit :
Ah ? C'est bizarre comme façon de faire. Avec netfilter/iptables, il
suffit de lui dire de ne pas NATer.
ou plus exactement, il suffit de ne PAS lui dire de NATter ;)
