NAT + iptables

Mickybadia

25/01/2004 à 23:57

Hi all!

Ce fil de discussion a décidément perdu toute son organistation, entre les
Xposts FU2-és contestés puis ratés et le sujet qui avait un pied dans
chaque forum... :-)
Donc, que je réponde ici comme ça ou ailleurs autrement, ça ne l'arrangera
pas. ATTENTION en revanche [je le fais exprès :-) ] : celui-ci restera
cette fois chez FCOLC, puisque j'ai l'impression que, même si c'est un
sujet purement réseaux, fcri traite moins des configurations propres aux
systèmes Linux.

TiChou wrote:

Toutes mes recherches WWW préconisent cette règle :
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
qui me fait "iptables: invalid argument"

Je n'arrive pas à me débarraser de cette erreur.

La syntaxe étant correct, il semblerait alors que votre iptables ne soit
pas compatible avec la version de votre kernel ou que celui-ci ait besoin
d'être recompilé pour qu'il prenne en compte les spécificités de votre
kernel.

Oui, bien sûr, il fallait recompiler iptables après avoir recompilé le
kernel. En fait, j'avais fait un "update", donc Emerge avait comparé les
versions et a vu qu'il n'y avait rien à faire, puisque j'avais la dernière.
Donc il a rien fait, et je n'avais pas remarqué. C'est bon maintenant, je
n'ai plus l'erreur "invalid argument". Par contre, je reste un peu
désemparé quant à la suite : le NAT.

Apparemment, ça dit que les IPs fixes (C'est bien le cas de l'ADSL ?)

Non, une connexion ADSL n'implique pas l'IP fixe.

OK, je l'avais toujours cru. D'ailleurs, mon "IP du jour" n'est pas la même
que celle que je retrouve dans mon post de début de fil.

Si votre IP est dynamique (ce qui est le cas à priori), la syntaxe
correcte serait :

iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -d 192.168.0.0/24 -i ppp0 -o eth0
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0
-j MASQUERADE

D'accord, j'ai fait ces règles et je n'ai pas de message d'erreur ; les
règles NAT sont donc toutes acceptées. En revanche, je n'arrive toujours
pas à avoir de réponse sur l'autre ordi.

Au boot, il n'a que 2 entrées de routage :
192.168.0.0/24 sur eth0
loopback sur lo
Je rajoute :
default sur eth0

Quand je fais route, la table s'affiche correctement, mais lentement (20 s
pour la dernière ligne). C'est sûrment un indice, même si je ne sais pas
quoi en tirer, que les pings fonctionnent, et que ce qui est affiché est
(selon moi) correct. Je n'ai rien dans le navigateur de l'autre ordi quand
j'essaie d'afficher une page web. Est-ce un problème de DNS ? "Unknown
host: www.google.com".

Que me manque-t-il ? Qu'est-ce qui est crucial et que je ne fais pas ?

Merci pour vos réponses précédentes, je sais que je n'ai pas une IP fixe,
que c'est ppp0 que je dois utiliser, etc.

--
Mickybadia [http://mickybadia.free.fr/]

To reply, please remove "SAY_HELLO_TO_" from address.
Veuillez supprimer "SAY_HELLO_TO_" de l'adresse pour me répondre.

Hi all!

Ce fil de discussion a décidément perdu toute son organistation, entre les
Xposts FU2-és contestés puis ratés et le sujet qui avait un pied dans
chaque forum... :-)
Donc, que je réponde ici comme ça ou ailleurs autrement, ça ne l'arrangera
pas. ATTENTION en revanche [je le fais exprès :-) ] : celui-ci restera
cette fois chez FCOLC, puisque j'ai l'impression que, même si c'est un
sujet purement réseaux, fcri traite moins des configurations propres aux
systèmes Linux.

TiChou wrote:

Toutes mes recherches WWW préconisent cette règle :
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
qui me fait "iptables: invalid argument"

Je n'arrive pas à me débarraser de cette erreur.

La syntaxe étant correct, il semblerait alors que votre iptables ne soit
pas compatible avec la version de votre kernel ou que celui-ci ait besoin
d'être recompilé pour qu'il prenne en compte les spécificités de votre
kernel.

Oui, bien sûr, il fallait recompiler iptables après avoir recompilé le
kernel. En fait, j'avais fait un "update", donc Emerge avait comparé les
versions et a vu qu'il n'y avait rien à faire, puisque j'avais la dernière.
Donc il a rien fait, et je n'avais pas remarqué. C'est bon maintenant, je
n'ai plus l'erreur "invalid argument". Par contre, je reste un peu
désemparé quant à la suite : le NAT.

Apparemment, ça dit que les IPs fixes (C'est bien le cas de l'ADSL ?)

Non, une connexion ADSL n'implique pas l'IP fixe.

OK, je l'avais toujours cru. D'ailleurs, mon "IP du jour" n'est pas la même
que celle que je retrouve dans mon post de début de fil.

Si votre IP est dynamique (ce qui est le cas à priori), la syntaxe
correcte serait :

iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -d 192.168.0.0/24 -i ppp0 -o eth0
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0
-j MASQUERADE

D'accord, j'ai fait ces règles et je n'ai pas de message d'erreur ; les
règles NAT sont donc toutes acceptées. En revanche, je n'arrive toujours
pas à avoir de réponse sur l'autre ordi.

Au boot, il n'a que 2 entrées de routage :
192.168.0.0/24 sur eth0
loopback sur lo
Je rajoute :
default sur eth0

Quand je fais route, la table s'affiche correctement, mais lentement (20 s
pour la dernière ligne). C'est sûrment un indice, même si je ne sais pas
quoi en tirer, que les pings fonctionnent, et que ce qui est affiché est
(selon moi) correct. Je n'ai rien dans le navigateur de l'autre ordi quand
j'essaie d'afficher une page web. Est-ce un problème de DNS ? "Unknown
host: www.google.com".

Que me manque-t-il ? Qu'est-ce qui est crucial et que je ne fais pas ?

Merci pour vos réponses précédentes, je sais que je n'ai pas une IP fixe,
que c'est ppp0 que je dois utiliser, etc.

--
Mickybadia [http://mickybadia.free.fr/]

To reply, please remove "SAY_HELLO_TO_" from address.
Veuillez supprimer "SAY_HELLO_TO_" de l'adresse pour me répondre.

Vous avez filtré cet utilisateur ! Consultez son message

Hi all!

Ce fil de discussion a décidément perdu toute son organistation, entre les
Xposts FU2-és contestés puis ratés et le sujet qui avait un pied dans
chaque forum... :-)
Donc, que je réponde ici comme ça ou ailleurs autrement, ça ne l'arrangera
pas. ATTENTION en revanche [je le fais exprès :-) ] : celui-ci restera
cette fois chez FCOLC, puisque j'ai l'impression que, même si c'est un
sujet purement réseaux, fcri traite moins des configurations propres aux
systèmes Linux.

TiChou wrote:

Toutes mes recherches WWW préconisent cette règle :
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
qui me fait "iptables: invalid argument"

Je n'arrive pas à me débarraser de cette erreur.

La syntaxe étant correct, il semblerait alors que votre iptables ne soit
pas compatible avec la version de votre kernel ou que celui-ci ait besoin
d'être recompilé pour qu'il prenne en compte les spécificités de votre
kernel.

Oui, bien sûr, il fallait recompiler iptables après avoir recompilé le
kernel. En fait, j'avais fait un "update", donc Emerge avait comparé les
versions et a vu qu'il n'y avait rien à faire, puisque j'avais la dernière.
Donc il a rien fait, et je n'avais pas remarqué. C'est bon maintenant, je
n'ai plus l'erreur "invalid argument". Par contre, je reste un peu
désemparé quant à la suite : le NAT.

Apparemment, ça dit que les IPs fixes (C'est bien le cas de l'ADSL ?)

Non, une connexion ADSL n'implique pas l'IP fixe.

OK, je l'avais toujours cru. D'ailleurs, mon "IP du jour" n'est pas la même
que celle que je retrouve dans mon post de début de fil.

Si votre IP est dynamique (ce qui est le cas à priori), la syntaxe
correcte serait :

iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -d 192.168.0.0/24 -i ppp0 -o eth0
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0
-j MASQUERADE

D'accord, j'ai fait ces règles et je n'ai pas de message d'erreur ; les
règles NAT sont donc toutes acceptées. En revanche, je n'arrive toujours
pas à avoir de réponse sur l'autre ordi.

Au boot, il n'a que 2 entrées de routage :
192.168.0.0/24 sur eth0
loopback sur lo
Je rajoute :
default sur eth0

Quand je fais route, la table s'affiche correctement, mais lentement (20 s
pour la dernière ligne). C'est sûrment un indice, même si je ne sais pas
quoi en tirer, que les pings fonctionnent, et que ce qui est affiché est
(selon moi) correct. Je n'ai rien dans le navigateur de l'autre ordi quand
j'essaie d'afficher une page web. Est-ce un problème de DNS ? "Unknown
host: www.google.com".

Que me manque-t-il ? Qu'est-ce qui est crucial et que je ne fais pas ?

Merci pour vos réponses précédentes, je sais que je n'ai pas une IP fixe,
que c'est ppp0 que je dois utiliser, etc.

--
Mickybadia [http://mickybadia.free.fr/]

To reply, please remove "SAY_HELLO_TO_" from address.
Veuillez supprimer "SAY_HELLO_TO_" de l'adresse pour me répondre.

TiChou

26/01/2004 à 00:33

Dans l'article news:40144951$0$17109$,
Mickybadia écrivait :

iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -d 192.168.0.0/24 -i ppp0 -o eth0
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0
-j MASQUERADE

D'accord, j'ai fait ces règles et je n'ai pas de message d'erreur ;
les règles NAT sont donc toutes acceptées. En revanche, je n'arrive
toujours pas à avoir de réponse sur l'autre ordi.

Au boot, il n'a que 2 entrées de routage :
192.168.0.0/24 sur eth0
loopback sur lo
Je rajoute :
default sur eth0

Avec quelle adresse IP pour la passerelle ? 192.168.0.2 ?

Quand je fais route, la table s'affiche correctement, mais lentement
(20 s pour la dernière ligne). C'est sûrment un indice, même si je ne
sais pas quoi en tirer,

La commande route essaye de résoudre les adresses IP et réseaux qu'elle
affiche et il y a un délai de timeout si le système n'arrive pas à résoudre
ces adresses IP.

que les pings fonctionnent,

Les pings vers quelles destinations ? Locale ou bien aussi vers des adresses
IP externes ?

Je n'ai rien dans le navigateur de
l'autre ordi quand j'essaie d'afficher une page web. Est-ce un
problème de DNS ? "Unknown host: www.google.com".

Oui.

Que me manque-t-il ? Qu'est-ce qui est crucial et que je ne fais pas ?

Vu les symptômes, il semblerait qu'il y ait déjà un problème de résolution
DNS.

Avez vous renseigné correctement le fichier /etc/resolv.conf avec les
adresses IP des serveurs DNS de votre FAI ?

Et sinon, sur la passerelle Linux, avez-vous activé l'IP forwarding en
faisant :

echo 1 >/proc/sys/net/ipv4/ip_forward

Merci pour vos réponses précédentes, je sais que je n'ai pas une IP
fixe, que c'est ppp0 que je dois utiliser, etc.

De rien. Et c'est sympa de vous voir progresser. :)

--
TiChou

Annie D.

26/01/2004 à 01:52

"Jean-Claude(06)" wrote:

Excusez moi si je pose ces questions.

Et puis quoi encore ? Maintenant il faudrait s'excuser de poser des
questions, d'être curieux et d'avoir envie d'apprendre ?

C'est juste pour comprendre (et apprendre) que je me suis
permis d'intervenir dans votre conversation.

Comme moi concernant un détail secondaire apparu dans la discussion.

Je voulais juste savoir en quoi ce n'est pas secure ?
Ces regles sont sur ma passerelle (2 cartes reseau)
entre mon reseau local et internet.

Je considere mon reseau local comme de confiance :
Je laisse donc par defaut tout sortir

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne pas
trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si vous
avez des machines sous Windows).

et je ne filtre qu'en entree.

Même pas. Vous ne filtrez (sommairement) que le trafic destiné à votre
passerelle, mais pas le trafic entrant à destination du réseau local.

Mes regles perso sont simples.
Les voici :
----------------------------------------
iptables -P INPUT DROP

RAS.

iptables -P OUTPUT ACCEPT

Cf. ma remarque précédente sur ce qu'on autorise en sortie.

iptables -P FORWARD ACCEPT

Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.

iptables -A INPUT -i lo -j ACCEPT

RAS.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pas suffisant. D'une part vous empêchez toute connexion vers la
passerelle, même depuis le réseau local. Aussi, vous bloquez le ping en
entrée, ce qui n'est pas génial (de mon point de vue, mais le sujet est
controversé).
D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est valable
aussi pour la chaîne FORWARD.

iptables -A INPUT -j DROP

Pas nécessaire compte tenu de la politique par défaut DROP de la chaîne.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

RAS.
Mais il y a sûrement d'autres problèmes que je n'ai pas vus.

"Jean-Claude(06)" wrote:

Excusez moi si je pose ces questions.

Et puis quoi encore ? Maintenant il faudrait s'excuser de poser des
questions, d'être curieux et d'avoir envie d'apprendre ?

C'est juste pour comprendre (et apprendre) que je me suis
permis d'intervenir dans votre conversation.

Comme moi concernant un détail secondaire apparu dans la discussion.

Je voulais juste savoir en quoi ce n'est pas secure ?
Ces regles sont sur ma passerelle (2 cartes reseau)
entre mon reseau local et internet.

Je considere mon reseau local comme de confiance :
Je laisse donc par defaut tout sortir

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne pas
trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si vous
avez des machines sous Windows).

et je ne filtre qu'en entree.

Même pas. Vous ne filtrez (sommairement) que le trafic destiné à votre
passerelle, mais pas le trafic entrant à destination du réseau local.

Mes regles perso sont simples.
Les voici :
----------------------------------------
iptables -P INPUT DROP

RAS.

iptables -P OUTPUT ACCEPT

Cf. ma remarque précédente sur ce qu'on autorise en sortie.

iptables -P FORWARD ACCEPT

Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.

iptables -A INPUT -i lo -j ACCEPT

RAS.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pas suffisant. D'une part vous empêchez toute connexion vers la
passerelle, même depuis le réseau local. Aussi, vous bloquez le ping en
entrée, ce qui n'est pas génial (de mon point de vue, mais le sujet est
controversé).
D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est valable
aussi pour la chaîne FORWARD.

iptables -A INPUT -j DROP

Pas nécessaire compte tenu de la politique par défaut DROP de la chaîne.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

RAS.
Mais il y a sûrement d'autres problèmes que je n'ai pas vus.

Vous avez filtré cet utilisateur ! Consultez son message

"Jean-Claude(06)" wrote:

Excusez moi si je pose ces questions.

Et puis quoi encore ? Maintenant il faudrait s'excuser de poser des
questions, d'être curieux et d'avoir envie d'apprendre ?

C'est juste pour comprendre (et apprendre) que je me suis
permis d'intervenir dans votre conversation.

Comme moi concernant un détail secondaire apparu dans la discussion.

Je voulais juste savoir en quoi ce n'est pas secure ?
Ces regles sont sur ma passerelle (2 cartes reseau)
entre mon reseau local et internet.

Je considere mon reseau local comme de confiance :
Je laisse donc par defaut tout sortir

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne pas
trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si vous
avez des machines sous Windows).

et je ne filtre qu'en entree.

Même pas. Vous ne filtrez (sommairement) que le trafic destiné à votre
passerelle, mais pas le trafic entrant à destination du réseau local.

Mes regles perso sont simples.
Les voici :
----------------------------------------
iptables -P INPUT DROP

RAS.

iptables -P OUTPUT ACCEPT

Cf. ma remarque précédente sur ce qu'on autorise en sortie.

iptables -P FORWARD ACCEPT

Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.

iptables -A INPUT -i lo -j ACCEPT

RAS.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pas suffisant. D'une part vous empêchez toute connexion vers la
passerelle, même depuis le réseau local. Aussi, vous bloquez le ping en
entrée, ce qui n'est pas génial (de mon point de vue, mais le sujet est
controversé).
D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est valable
aussi pour la chaîne FORWARD.

iptables -A INPUT -j DROP

Pas nécessaire compte tenu de la politique par défaut DROP de la chaîne.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

RAS.
Mais il y a sûrement d'autres problèmes que je n'ai pas vus.

Jean-Claude(06)

26/01/2004 à 19:15

Bonjour,

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne > pas trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si > v ous avez des machines sous Windows).
Vous avez raison mais mon petit reseau prive est de confiance:

il rien ne tourne rien de malsain qui pourrait prevenir quelqu'un ou quelqu e chose sur internet.
Et aucun service ne tourne sans que je sois au courant.
- blocs privés RFC 1918 : je ne sais pas ce que c'est
mais je me renseigne.
- APIPA et services Microsofts : je n'en ai pas puisque pas de machines win dows.

et je ne filtre qu'en entree.
Même pas. Vous ne filtrez (sommairement) que le trafic destiné à vo tre

passerelle, mais pas le trafic entrant à destination du réseau local.

Quel traffic internet a destination de mon reseau local ??
Expliquez moi please.
Mon reseau local est injoignable puisque je n'ai qu'une adresse IP publique fournie par mon provider.
Il n'y a que ma passerelle qui est joignable.
Vu de l'exterieur je n'ai apparemment qu'une machine :
ma passerelle, non ?
Qui pourrait adresser a partir d'internet un paquet
a destination de 192.168.0.x !!
Cette adresse n'existe pas sur le reseau public, non ?
Contredisez moi si je me trompe: comprends pas.

iptables -P FORWARD ACCEPT
Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant

par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.
Meme reponse que precedemment.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Pas suffisant. D'une part vous empêchez toute connexion vers la

passerelle, même depuis le réseau local. Aussi, vous bloquez le ping > en entrée, ce qui n'est pas génial (de mon point de vue, mais le > s ujet est controversé).
Negatif, cette regle indique seulement que j'accepte les paquets

entrants relatifs à des connexions déjà établies, c'est a dire cell e
que j'ai initie depuis mon LAN vers l'exterieur.
Et donc l'exterieur me repond, non ?
De plus, je n'ai pas mis toutes mes regles puisque
la suivante est par exemple :
iptables -A INPUT -p tcp --dport 22 -i eth1 -j LOG_ACCEPT
qui me permet de joindre depuis mon reseau local mon serveur ssh
situe sur ma passerelle (eth1).

D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est > valab le aussi pour la chaîne FORWARD.
ICMP c'est le ping ca non ?

Si un ping arrive sur ma passerelle: il attaque ma chaine INPUT, non ?
Pas sur la chaine FORWARD ? Je me trompe ?
Si c'est le cas, il sera donc refuse.
De plus j'ai verifie et on ne peut pas me pinguer depuis internet !!

Malgre tout je comprends votre argumentation en cas de reseau interne
qui n'est pas de confiance :
- machine windows qui font tourner un tas de service non desires.
- utilisateur mal intentionne.
De toute facon il parait que 9/10 le probleme viendrait de l'interieur.

Mais dans mon cas je ne vois pas ce qui cloche.
Notamment au niveau d'un eventuel forwardind depuis le net vers le reseau l ocal.

Merci de m'expliquer.
J.C

Bonjour,

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne > pas trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si > v ous avez des machines sous Windows).
Vous avez raison mais mon petit reseau prive est de confiance:

il rien ne tourne rien de malsain qui pourrait prevenir quelqu'un ou quelqu e chose sur internet.
Et aucun service ne tourne sans que je sois au courant.
- blocs privés RFC 1918 : je ne sais pas ce que c'est
mais je me renseigne.
- APIPA et services Microsofts : je n'en ai pas puisque pas de machines win dows.

et je ne filtre qu'en entree.
Même pas. Vous ne filtrez (sommairement) que le trafic destiné à vo tre

passerelle, mais pas le trafic entrant à destination du réseau local.

Quel traffic internet a destination de mon reseau local ??
Expliquez moi please.
Mon reseau local est injoignable puisque je n'ai qu'une adresse IP publique fournie par mon provider.
Il n'y a que ma passerelle qui est joignable.
Vu de l'exterieur je n'ai apparemment qu'une machine :
ma passerelle, non ?
Qui pourrait adresser a partir d'internet un paquet
a destination de 192.168.0.x !!
Cette adresse n'existe pas sur le reseau public, non ?
Contredisez moi si je me trompe: comprends pas.

iptables -P FORWARD ACCEPT
Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant

par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.
Meme reponse que precedemment.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Pas suffisant. D'une part vous empêchez toute connexion vers la

passerelle, même depuis le réseau local. Aussi, vous bloquez le ping > en entrée, ce qui n'est pas génial (de mon point de vue, mais le > s ujet est controversé).
Negatif, cette regle indique seulement que j'accepte les paquets

entrants relatifs à des connexions déjà établies, c'est a dire cell e
que j'ai initie depuis mon LAN vers l'exterieur.
Et donc l'exterieur me repond, non ?
De plus, je n'ai pas mis toutes mes regles puisque
la suivante est par exemple :
iptables -A INPUT -p tcp --dport 22 -i eth1 -j LOG_ACCEPT
qui me permet de joindre depuis mon reseau local mon serveur ssh
situe sur ma passerelle (eth1).

D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est > valab le aussi pour la chaîne FORWARD.
ICMP c'est le ping ca non ?

Si un ping arrive sur ma passerelle: il attaque ma chaine INPUT, non ?
Pas sur la chaine FORWARD ? Je me trompe ?
Si c'est le cas, il sera donc refuse.
De plus j'ai verifie et on ne peut pas me pinguer depuis internet !!

Malgre tout je comprends votre argumentation en cas de reseau interne
qui n'est pas de confiance :
- machine windows qui font tourner un tas de service non desires.
- utilisateur mal intentionne.
De toute facon il parait que 9/10 le probleme viendrait de l'interieur.

Mais dans mon cas je ne vois pas ce qui cloche.
Notamment au niveau d'un eventuel forwardind depuis le net vers le reseau l ocal.

Merci de m'expliquer.
J.C

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne > pas trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si > v ous avez des machines sous Windows).
Vous avez raison mais mon petit reseau prive est de confiance:

il rien ne tourne rien de malsain qui pourrait prevenir quelqu'un ou quelqu e chose sur internet.
Et aucun service ne tourne sans que je sois au courant.
- blocs privés RFC 1918 : je ne sais pas ce que c'est
mais je me renseigne.
- APIPA et services Microsofts : je n'en ai pas puisque pas de machines win dows.

et je ne filtre qu'en entree.
Même pas. Vous ne filtrez (sommairement) que le trafic destiné à vo tre

passerelle, mais pas le trafic entrant à destination du réseau local.

Quel traffic internet a destination de mon reseau local ??
Expliquez moi please.
Mon reseau local est injoignable puisque je n'ai qu'une adresse IP publique fournie par mon provider.
Il n'y a que ma passerelle qui est joignable.
Vu de l'exterieur je n'ai apparemment qu'une machine :
ma passerelle, non ?
Qui pourrait adresser a partir d'internet un paquet
a destination de 192.168.0.x !!
Cette adresse n'existe pas sur le reseau public, non ?
Contredisez moi si je me trompe: comprends pas.

iptables -P FORWARD ACCEPT
Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant

par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.
Meme reponse que precedemment.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Pas suffisant. D'une part vous empêchez toute connexion vers la

passerelle, même depuis le réseau local. Aussi, vous bloquez le ping > en entrée, ce qui n'est pas génial (de mon point de vue, mais le > s ujet est controversé).
Negatif, cette regle indique seulement que j'accepte les paquets

entrants relatifs à des connexions déjà établies, c'est a dire cell e
que j'ai initie depuis mon LAN vers l'exterieur.
Et donc l'exterieur me repond, non ?
De plus, je n'ai pas mis toutes mes regles puisque
la suivante est par exemple :
iptables -A INPUT -p tcp --dport 22 -i eth1 -j LOG_ACCEPT
qui me permet de joindre depuis mon reseau local mon serveur ssh
situe sur ma passerelle (eth1).

D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est > valab le aussi pour la chaîne FORWARD.
ICMP c'est le ping ca non ?

Si un ping arrive sur ma passerelle: il attaque ma chaine INPUT, non ?
Pas sur la chaine FORWARD ? Je me trompe ?
Si c'est le cas, il sera donc refuse.
De plus j'ai verifie et on ne peut pas me pinguer depuis internet !!

Malgre tout je comprends votre argumentation en cas de reseau interne
qui n'est pas de confiance :
- machine windows qui font tourner un tas de service non desires.
- utilisateur mal intentionne.
De toute facon il parait que 9/10 le probleme viendrait de l'interieur.

Mais dans mon cas je ne vois pas ce qui cloche.
Notamment au niveau d'un eventuel forwardind depuis le net vers le reseau l ocal.

Merci de m'expliquer.
J.C

Mickybadia

26/01/2004 à 23:23

Hi all! TiChou wrote:

Au boot, il n'a que 2 entrées de routage :
192.168.0.0/24 sur eth0
loopback sur lo
Je rajoute :
default sur eth0

Avec quelle adresse IP pour la passerelle ? 192.168.0.2 ?

Oui. Et .1 pour l'autre.

Avez vous renseigné correctement le fichier /etc/resolv.conf avec les
adresses IP des serveurs DNS de votre FAI ?

Ça y est, on y arrive. Je pensais que tout partirait sur la route par
défaut, même les requêtes DNS, et je n'avais pas recopié les "nameserver"
sur l'autre ordi.

Oh !

[SUPPR de tout le nouvel état des lieux que je commençais à taper ici, qui
disait que ça avait avancé, mais ça bloquait encore un peu plus loin,
car.....]

Ça s'est mis à marcher ! Magiiiiique !

Merci pour vos réponses précédentes, je sais que je n'ai pas une IP
fixe, que c'est ppp0 que je dois utiliser, etc.

De rien.

Merci aussi pour votre patience.

Et c'est sympa de vous voir progresser. :)
:-)

Ha! Je saurais même le refaire !

Merci à ceux qui ont lu et répondu.

--
Mickybadia [http://mickybadia.free.fr/]

To reply, please remove "SAY_HELLO_TO_" from address.
Veuillez supprimer "SAY_HELLO_TO_" de l'adresse pour me répondre.

Annie D.

27/01/2004 à 02:54

"Jean-Claude(06)" wrote:

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne
pas trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si
vous avez des machines sous Windows).

Vous avez raison mais mon petit reseau prive est de confiance:
il rien ne tourne rien de malsain qui pourrait prevenir quelqu'un ou quelque chose sur internet.

Il ne s'agit pas de cela. Vous ne préviendriez rien ni personne en
laissant sortir ces adresses puisqu'elles ne sont pas censées être
routées sur l'internet public. Mais justement, comme elles ne sont pas
censées y être routées, vous n'êtes pas censé y en envoyer. Et pourtant,
ça peut arriver malgré vous, par exemple à cause d'un défaut de
configuration de votre passerelle (tout le monde peut se tromper), en
répondant à un paquet ayant une telle adresse en source, en suivant un
lien sur un site web pointant sur ce genre d'adresse, en resolvant un
domaine mal configuré qui pointe vers ce genre d'adresse... les
occasions ne manquent pas. Ce n'est pas risqué, c'est juste sale. Le
plus souvent ça n'ira pas plus loin que le premier routeur de votre FAI.

- blocs privés RFC 1918 : je ne sais pas ce que c'est

Cf. http://www.faqs.org/rfcs/rfc1918.html
Les blocs 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 sont réservés à
l'adressage des réseaux privés et ne doivent pas être routés sur
l'internet public.

- APIPA et services Microsofts : je n'en ai pas puisque pas de machines windows.

Tant mieux. Ça fait tout drôle de voir une machine Windows tenter de sa
propre initiative d'ouvrir des connexions Netbios avec les machines
distantes avec lesquelles elle communique.

et je ne filtre qu'en entree.
Même pas. Vous ne filtrez (sommairement) que le trafic destiné à votre

passerelle, mais pas le trafic entrant à destination du réseau local.

Quel traffic internet a destination de mon reseau local ??
Expliquez moi please.
Mon reseau local est injoignable puisque je n'ai qu'une adresse IP publique fournie par mon provider.
Il n'y a que ma passerelle qui est joignable.
Vu de l'exterieur je n'ai apparemment qu'une machine :
ma passerelle, non ?

Ça, c'est la théorie, quand tout est beau et propre, à l'image de votre
réseau local sur lequel vous avez un contrôle total. Mais internet,
INTERNET, ça n'a rien à voir. C'est une jungle peuplée de bêtes féroces
qui n'attende qu'un signe de faiblesse de votre part pour vous sauter
dessus. Internet, c'est tout le contraire d'un réseau "de confiance",
c'est le CHAOS. Vous n'avez aucune maîtrise sur ce qui s'y passe. Votre
passerelle est le seul et unique rempart entre le chaos d'internet et
votre douillet réseau local, et croyez-moi, si vous vous préoccupez un
minimum de sécurité, vous ne devriez écarter aucune possibilité
concernant ce qui peut frapper à la porte. Et ne comptez pas sur votre
fournisseur d'accès pour vous protéger de quoi que ce soit. Il fait
partie d'internet, et en tant que tel ne peut pas être considéré comme
étant "de confiance". Non, vous ne pouvez comptez que sur vous.

Bon, j'ai un peu exagéré dans le paragraphe qui précède, mais l'idée est
là. Ne faites AUCUNE supposition a priori sur les caractéristiques des
paquets qui peuvent arriver, au contraire considérez que TOUT est
possible, même si une grande partie est très improbable.

Qui pourrait adresser a partir d'internet un paquet
a destination de 192.168.0.x !!
Cette adresse n'existe pas sur le reseau public, non ?

Elle n'est pas _censée_ exister, nuance. Il n'empêche que ma connexion
reçoit des tombereaux de paquets ayant comme adresse source une de ces
adresses qui ne devraient pas exister. Toutefois je reconnais ne pas
encore avoir vu arriver de paquet portant en adresse de destination
autre chose que l'adresse de ma connexion.

Contredisez moi si je me trompe: comprends pas.

En gros, vous dites : les paquets que je reçois ne peuvent porter en
adresse de destination que ma propre adresse, sinon mon FAI ne me les
enverrait pas. Je réponds : avez-vous si confiance en votre FAI ? Est-il
absolument inenvisageable que le routeur qui vous relie à lui souffre
d'un bug, d'un défaut de configuration, voire d'une compromission qui le
ferait vous envoyer autre chose que ce qu'il est censé vous envoyer ?
D'autre part, que savez-vous de l'architecture de votre FAI ? Qui vous
dit, par exemple, que vous n'êtes pas sur un lien partagé par d'autres
utilisateurs, façon câble, qui peuvent par ce biais vous envoyer un peu
n'importe quoi pourvu qu'ils connaissent l'adresse MAC de votre
équipement de raccordement ?

iptables -P FORWARD ACCEPT

Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.

Meme reponse que precedemment.

Un paquet arrive avec en adresse de destination une adresse de votre
réseau local. Ne dites pas que c'est impossible, c'est seulement très
improbable sauf dans des conditions particulières. Ce paquet traverse
tranquillement la passerelle et atteint le réseau local. Mieux : un
paquet arrive avec en adresse de destination l'adresse d'une station sur
internet. Aucun contrôle, la chaîne FORWARD le redirige vers l'interface
internet, et la chaîne POSTROUTING masquerade son adresse source avant
qu'il ressorte. Résultat, c'est votre adresse que la station cible verra
comme source.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pas suffisant. D'une part vous empêchez toute connexion vers la
passerelle, même depuis le réseau local. Aussi, vous bloquez le ping
en entrée, ce qui n'est pas génial (de mon point de vue, mais le
sujet est controversé).

Negatif, cette regle indique seulement que j'accepte les paquets
entrants relatifs à des connexions déjà établies, c'est a dire celle
que j'ai initie depuis mon LAN vers l'exterieur.

Non. La chaîne INPUT ne concerne que les paquets à destination de la
passerelle. Les paquets qui ne font que transiter dépendent de la chaîne
FORWARD.

Et donc l'exterieur me repond, non ?

Oui, mais ça n'a rien à voir avec cette règle ni cette chaîne mais avec
la chaîne FORWARD, sur laquelle vous ne gérez pas les états, comme je
l'ai déjà dit. Et la passerelle elle-même est injoignable aussi bien
depuis internet que depuis le réseau local en l'absence d'une règle
ACCEPT prenant en compte l'état NEW.

De plus, je n'ai pas mis toutes mes regles puisque
la suivante est par exemple :
iptables -A INPUT -p tcp --dport 22 -i eth1 -j LOG_ACCEPT
qui me permet de joindre depuis mon reseau local mon serveur ssh
situe sur ma passerelle (eth1).

Je me disais aussi.

D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est
valable aussi pour la chaîne FORWARD.

ICMP c'est le ping ca non ?

ICMP, c'est toute une famille de messages de contrôle pour le protocole
IP. Le "ping" n'est qu'un des différents types ICMP, de son vrai nom
"echo-request". La réponse au ping en est un autre, appelé "echo-reply".

Si un ping arrive sur ma passerelle: il attaque ma chaine INPUT, non ?
Pas sur la chaine FORWARD ? Je me trompe ?

Non, vous avez bon.

Si c'est le cas, il sera donc refuse.
De plus j'ai verifie et on ne peut pas me pinguer depuis internet !!

C'est bien ce que je reproche. Quel intérêt de bloquer le ping qui est
un outil de diagnostic utile, et probablement le plus bénin des ICMP ?
Alors que dans le même temps, vous acceptez sans sourciller des types
ICMP comme les "redirect" qui ont l'état RELATED et qui sont susceptible
de modifier les tables de routage de vos machines.

PS: la façon de citer de votre logiciel de news est très perfectible.

"Jean-Claude(06)" wrote:

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne
pas trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si
vous avez des machines sous Windows).

Vous avez raison mais mon petit reseau prive est de confiance:
il rien ne tourne rien de malsain qui pourrait prevenir quelqu'un ou quelque chose sur internet.

Il ne s'agit pas de cela. Vous ne préviendriez rien ni personne en
laissant sortir ces adresses puisqu'elles ne sont pas censées être
routées sur l'internet public. Mais justement, comme elles ne sont pas
censées y être routées, vous n'êtes pas censé y en envoyer. Et pourtant,
ça peut arriver malgré vous, par exemple à cause d'un défaut de
configuration de votre passerelle (tout le monde peut se tromper), en
répondant à un paquet ayant une telle adresse en source, en suivant un
lien sur un site web pointant sur ce genre d'adresse, en resolvant un
domaine mal configuré qui pointe vers ce genre d'adresse... les
occasions ne manquent pas. Ce n'est pas risqué, c'est juste sale. Le
plus souvent ça n'ira pas plus loin que le premier routeur de votre FAI.

- blocs privés RFC 1918 : je ne sais pas ce que c'est

Cf. http://www.faqs.org/rfcs/rfc1918.html
Les blocs 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 sont réservés à
l'adressage des réseaux privés et ne doivent pas être routés sur
l'internet public.

- APIPA et services Microsofts : je n'en ai pas puisque pas de machines windows.

Tant mieux. Ça fait tout drôle de voir une machine Windows tenter de sa
propre initiative d'ouvrir des connexions Netbios avec les machines
distantes avec lesquelles elle communique.

et je ne filtre qu'en entree.
Même pas. Vous ne filtrez (sommairement) que le trafic destiné à votre

passerelle, mais pas le trafic entrant à destination du réseau local.

Quel traffic internet a destination de mon reseau local ??
Expliquez moi please.
Mon reseau local est injoignable puisque je n'ai qu'une adresse IP publique fournie par mon provider.
Il n'y a que ma passerelle qui est joignable.
Vu de l'exterieur je n'ai apparemment qu'une machine :
ma passerelle, non ?

Ça, c'est la théorie, quand tout est beau et propre, à l'image de votre
réseau local sur lequel vous avez un contrôle total. Mais internet,
INTERNET, ça n'a rien à voir. C'est une jungle peuplée de bêtes féroces
qui n'attende qu'un signe de faiblesse de votre part pour vous sauter
dessus. Internet, c'est tout le contraire d'un réseau "de confiance",
c'est le CHAOS. Vous n'avez aucune maîtrise sur ce qui s'y passe. Votre
passerelle est le seul et unique rempart entre le chaos d'internet et
votre douillet réseau local, et croyez-moi, si vous vous préoccupez un
minimum de sécurité, vous ne devriez écarter aucune possibilité
concernant ce qui peut frapper à la porte. Et ne comptez pas sur votre
fournisseur d'accès pour vous protéger de quoi que ce soit. Il fait
partie d'internet, et en tant que tel ne peut pas être considéré comme
étant "de confiance". Non, vous ne pouvez comptez que sur vous.

Bon, j'ai un peu exagéré dans le paragraphe qui précède, mais l'idée est
là. Ne faites AUCUNE supposition a priori sur les caractéristiques des
paquets qui peuvent arriver, au contraire considérez que TOUT est
possible, même si une grande partie est très improbable.

Qui pourrait adresser a partir d'internet un paquet
a destination de 192.168.0.x !!
Cette adresse n'existe pas sur le reseau public, non ?

Elle n'est pas _censée_ exister, nuance. Il n'empêche que ma connexion
reçoit des tombereaux de paquets ayant comme adresse source une de ces
adresses qui ne devraient pas exister. Toutefois je reconnais ne pas
encore avoir vu arriver de paquet portant en adresse de destination
autre chose que l'adresse de ma connexion.

Contredisez moi si je me trompe: comprends pas.

En gros, vous dites : les paquets que je reçois ne peuvent porter en
adresse de destination que ma propre adresse, sinon mon FAI ne me les
enverrait pas. Je réponds : avez-vous si confiance en votre FAI ? Est-il
absolument inenvisageable que le routeur qui vous relie à lui souffre
d'un bug, d'un défaut de configuration, voire d'une compromission qui le
ferait vous envoyer autre chose que ce qu'il est censé vous envoyer ?
D'autre part, que savez-vous de l'architecture de votre FAI ? Qui vous
dit, par exemple, que vous n'êtes pas sur un lien partagé par d'autres
utilisateurs, façon câble, qui peuvent par ce biais vous envoyer un peu
n'importe quoi pourvu qu'ils connaissent l'adresse MAC de votre
équipement de raccordement ?

iptables -P FORWARD ACCEPT

Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.

Meme reponse que precedemment.

Un paquet arrive avec en adresse de destination une adresse de votre
réseau local. Ne dites pas que c'est impossible, c'est seulement très
improbable sauf dans des conditions particulières. Ce paquet traverse
tranquillement la passerelle et atteint le réseau local. Mieux : un
paquet arrive avec en adresse de destination l'adresse d'une station sur
internet. Aucun contrôle, la chaîne FORWARD le redirige vers l'interface
internet, et la chaîne POSTROUTING masquerade son adresse source avant
qu'il ressorte. Résultat, c'est votre adresse que la station cible verra
comme source.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pas suffisant. D'une part vous empêchez toute connexion vers la
passerelle, même depuis le réseau local. Aussi, vous bloquez le ping
en entrée, ce qui n'est pas génial (de mon point de vue, mais le
sujet est controversé).

Negatif, cette regle indique seulement que j'accepte les paquets
entrants relatifs à des connexions déjà établies, c'est a dire celle
que j'ai initie depuis mon LAN vers l'exterieur.

Non. La chaîne INPUT ne concerne que les paquets à destination de la
passerelle. Les paquets qui ne font que transiter dépendent de la chaîne
FORWARD.

Et donc l'exterieur me repond, non ?

Oui, mais ça n'a rien à voir avec cette règle ni cette chaîne mais avec
la chaîne FORWARD, sur laquelle vous ne gérez pas les états, comme je
l'ai déjà dit. Et la passerelle elle-même est injoignable aussi bien
depuis internet que depuis le réseau local en l'absence d'une règle
ACCEPT prenant en compte l'état NEW.

De plus, je n'ai pas mis toutes mes regles puisque
la suivante est par exemple :
iptables -A INPUT -p tcp --dport 22 -i eth1 -j LOG_ACCEPT
qui me permet de joindre depuis mon reseau local mon serveur ssh
situe sur ma passerelle (eth1).

Je me disais aussi.

D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est
valable aussi pour la chaîne FORWARD.

ICMP c'est le ping ca non ?

ICMP, c'est toute une famille de messages de contrôle pour le protocole
IP. Le "ping" n'est qu'un des différents types ICMP, de son vrai nom
"echo-request". La réponse au ping en est un autre, appelé "echo-reply".

Si un ping arrive sur ma passerelle: il attaque ma chaine INPUT, non ?
Pas sur la chaine FORWARD ? Je me trompe ?

Non, vous avez bon.

Si c'est le cas, il sera donc refuse.
De plus j'ai verifie et on ne peut pas me pinguer depuis internet !!

C'est bien ce que je reproche. Quel intérêt de bloquer le ping qui est
un outil de diagnostic utile, et probablement le plus bénin des ICMP ?
Alors que dans le même temps, vous acceptez sans sourciller des types
ICMP comme les "redirect" qui ont l'état RELATED et qui sont susceptible
de modifier les tables de routage de vos machines.

PS: la façon de citer de votre logiciel de news est très perfectible.

Vous avez filtré cet utilisateur ! Consultez son message

"Jean-Claude(06)" wrote:

Je filtrerais au moins les adresses de destination et les ports des
services qui n'ont rien à faire sur l'internet public histoire de ne
pas trop polluer (blocs privés RFC 1918, APIPA, services Microsoft si
vous avez des machines sous Windows).

Vous avez raison mais mon petit reseau prive est de confiance:
il rien ne tourne rien de malsain qui pourrait prevenir quelqu'un ou quelque chose sur internet.

Il ne s'agit pas de cela. Vous ne préviendriez rien ni personne en
laissant sortir ces adresses puisqu'elles ne sont pas censées être
routées sur l'internet public. Mais justement, comme elles ne sont pas
censées y être routées, vous n'êtes pas censé y en envoyer. Et pourtant,
ça peut arriver malgré vous, par exemple à cause d'un défaut de
configuration de votre passerelle (tout le monde peut se tromper), en
répondant à un paquet ayant une telle adresse en source, en suivant un
lien sur un site web pointant sur ce genre d'adresse, en resolvant un
domaine mal configuré qui pointe vers ce genre d'adresse... les
occasions ne manquent pas. Ce n'est pas risqué, c'est juste sale. Le
plus souvent ça n'ira pas plus loin que le premier routeur de votre FAI.

- blocs privés RFC 1918 : je ne sais pas ce que c'est

Cf. http://www.faqs.org/rfcs/rfc1918.html
Les blocs 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 sont réservés à
l'adressage des réseaux privés et ne doivent pas être routés sur
l'internet public.

- APIPA et services Microsofts : je n'en ai pas puisque pas de machines windows.

Tant mieux. Ça fait tout drôle de voir une machine Windows tenter de sa
propre initiative d'ouvrir des connexions Netbios avec les machines
distantes avec lesquelles elle communique.

et je ne filtre qu'en entree.
Même pas. Vous ne filtrez (sommairement) que le trafic destiné à votre

passerelle, mais pas le trafic entrant à destination du réseau local.

Quel traffic internet a destination de mon reseau local ??
Expliquez moi please.
Mon reseau local est injoignable puisque je n'ai qu'une adresse IP publique fournie par mon provider.
Il n'y a que ma passerelle qui est joignable.
Vu de l'exterieur je n'ai apparemment qu'une machine :
ma passerelle, non ?

Ça, c'est la théorie, quand tout est beau et propre, à l'image de votre
réseau local sur lequel vous avez un contrôle total. Mais internet,
INTERNET, ça n'a rien à voir. C'est une jungle peuplée de bêtes féroces
qui n'attende qu'un signe de faiblesse de votre part pour vous sauter
dessus. Internet, c'est tout le contraire d'un réseau "de confiance",
c'est le CHAOS. Vous n'avez aucune maîtrise sur ce qui s'y passe. Votre
passerelle est le seul et unique rempart entre le chaos d'internet et
votre douillet réseau local, et croyez-moi, si vous vous préoccupez un
minimum de sécurité, vous ne devriez écarter aucune possibilité
concernant ce qui peut frapper à la porte. Et ne comptez pas sur votre
fournisseur d'accès pour vous protéger de quoi que ce soit. Il fait
partie d'internet, et en tant que tel ne peut pas être considéré comme
étant "de confiance". Non, vous ne pouvez comptez que sur vous.

Bon, j'ai un peu exagéré dans le paragraphe qui précède, mais l'idée est
là. Ne faites AUCUNE supposition a priori sur les caractéristiques des
paquets qui peuvent arriver, au contraire considérez que TOUT est
possible, même si une grande partie est très improbable.

Qui pourrait adresser a partir d'internet un paquet
a destination de 192.168.0.x !!
Cette adresse n'existe pas sur le reseau public, non ?

Elle n'est pas _censée_ exister, nuance. Il n'empêche que ma connexion
reçoit des tombereaux de paquets ayant comme adresse source une de ces
adresses qui ne devraient pas exister. Toutefois je reconnais ne pas
encore avoir vu arriver de paquet portant en adresse de destination
autre chose que l'adresse de ma connexion.

Contredisez moi si je me trompe: comprends pas.

En gros, vous dites : les paquets que je reçois ne peuvent porter en
adresse de destination que ma propre adresse, sinon mon FAI ne me les
enverrait pas. Je réponds : avez-vous si confiance en votre FAI ? Est-il
absolument inenvisageable que le routeur qui vous relie à lui souffre
d'un bug, d'un défaut de configuration, voire d'une compromission qui le
ferait vous envoyer autre chose que ce qu'il est censé vous envoyer ?
D'autre part, que savez-vous de l'architecture de votre FAI ? Qui vous
dit, par exemple, que vous n'êtes pas sur un lien partagé par d'autres
utilisateurs, façon câble, qui peuvent par ce biais vous envoyer un peu
n'importe quoi pourvu qu'ils connaissent l'adresse MAC de votre
équipement de raccordement ?

iptables -P FORWARD ACCEPT

Ça c'est mal. Vous ne filtrez rien du tout sur le trafic transitant par
votre passerelle, qu'il soit entrant ou sortant entre internet et le
réseau local, ou même entre deux points sur internet. Ainsi avec votre
règle POSTROUTING plus bas, votre passerelle constitue un relais qui
"masquerade" n'importe qui du LAN ou d'internet vers n'importe où sur
internet. Vous devez au minimum utiliser les états et les interfaces
d'entrée et de sortie pour n'autoriser un flux qu'à l'initiative du
réseau local.

Meme reponse que precedemment.

Un paquet arrive avec en adresse de destination une adresse de votre
réseau local. Ne dites pas que c'est impossible, c'est seulement très
improbable sauf dans des conditions particulières. Ce paquet traverse
tranquillement la passerelle et atteint le réseau local. Mieux : un
paquet arrive avec en adresse de destination l'adresse d'une station sur
internet. Aucun contrôle, la chaîne FORWARD le redirige vers l'interface
internet, et la chaîne POSTROUTING masquerade son adresse source avant
qu'il ressorte. Résultat, c'est votre adresse que la station cible verra
comme source.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pas suffisant. D'une part vous empêchez toute connexion vers la
passerelle, même depuis le réseau local. Aussi, vous bloquez le ping
en entrée, ce qui n'est pas génial (de mon point de vue, mais le
sujet est controversé).

Negatif, cette regle indique seulement que j'accepte les paquets
entrants relatifs à des connexions déjà établies, c'est a dire celle
que j'ai initie depuis mon LAN vers l'exterieur.

Non. La chaîne INPUT ne concerne que les paquets à destination de la
passerelle. Les paquets qui ne font que transiter dépendent de la chaîne
FORWARD.

Et donc l'exterieur me repond, non ?

Oui, mais ça n'a rien à voir avec cette règle ni cette chaîne mais avec
la chaîne FORWARD, sur laquelle vous ne gérez pas les états, comme je
l'ai déjà dit. Et la passerelle elle-même est injoignable aussi bien
depuis internet que depuis le réseau local en l'absence d'une règle
ACCEPT prenant en compte l'état NEW.

De plus, je n'ai pas mis toutes mes regles puisque
la suivante est par exemple :
iptables -A INPUT -p tcp --dport 22 -i eth1 -j LOG_ACCEPT
qui me permet de joindre depuis mon reseau local mon serveur ssh
situe sur ma passerelle (eth1).

Je me disais aussi.

D'autre part vous laissez tout passer dans les deux sens à partir du
moment c'est lié à un flux existant, y compris certains messages ICMP
qui peuvent être nocifs (type "redirect"). Ce dernier point est
valable aussi pour la chaîne FORWARD.

ICMP c'est le ping ca non ?

ICMP, c'est toute une famille de messages de contrôle pour le protocole
IP. Le "ping" n'est qu'un des différents types ICMP, de son vrai nom
"echo-request". La réponse au ping en est un autre, appelé "echo-reply".

Si un ping arrive sur ma passerelle: il attaque ma chaine INPUT, non ?
Pas sur la chaine FORWARD ? Je me trompe ?

Non, vous avez bon.

Si c'est le cas, il sera donc refuse.
De plus j'ai verifie et on ne peut pas me pinguer depuis internet !!

C'est bien ce que je reproche. Quel intérêt de bloquer le ping qui est
un outil de diagnostic utile, et probablement le plus bénin des ICMP ?
Alors que dans le même temps, vous acceptez sans sourciller des types
ICMP comme les "redirect" qui ont l'état RELATED et qui sont susceptible
de modifier les tables de routage de vos machines.

PS: la façon de citer de votre logiciel de news est très perfectible.

Jean-Claude(06)

27/01/2004 à 18:00

Bonjour,

Je crois avoir compris ce que vous dites.
Non pas que je sois parfaitement convaincu
mais vos arguments tiennent la route.

En effet :
- Je pourrais polluer inutilement internet en propageant
a l'exterieur des paquets inutiles.
- Certains paquets pourraient etre forwardes vers mon reseau local
en faisant la supposition (tres peu probable, mais bon possible)
que des paquets a destination d'une de mes machines
de mon reseau local arrive depuis internet vers ma passerelle.

PS: la façon de citer de votre logiciel de news est très perfectible.
Pardon pour ma mauvaise mise en forme.

Cordialement.
J.C

NAT + iptables

7 réponses

Veuillez sélectionner un problème