Soit un serveur kvm configuré de la sorte
auto eth0
iface eth0 manual
auto br0
iface br0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 255.255.255.0
bridge_ports eth0
bridge_stp off
bridge_fd 2
bridge_maxwait 3
je souhaite restreindre l'accès, via iptable, à cette machine aussi bien
au niveau de l'hôte que des différentes machines virtuelles.
comment dois-je m'y prendre ?
j'envisageais de mettre des règles sur br0 pour l'hôte, et ensuite pour
chaques machines virtuelles sur leur ethx respectives.
La question que je me pose, est : en mettant des règles sur br0, ne
vais-je pas bloquer l'accès à mes vm par la même occasion ?
l'exemple proposé à eric, autorise l'accès à la machine hôte uniquement via ssh. Ce qui signifie que tout accès à cette machine via un autre protocole est exclu.
Oui, mais rien ne t'empêche d'ajouter des règles pour autoriser d'autres protocoles.
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
Ce n'est pas normal. Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
Pascal a écrit :
l'exemple proposé à eric, autorise l'accès à la machine hôte uniquement
via ssh.
Ce qui signifie que tout accès à cette machine via un autre protocole
est exclu.
Oui, mais rien ne t'empêche d'ajouter des règles pour autoriser d'autres
protocoles.
maintenant avec cette seule règle sur la machine hôte, si je souhaite
accéder à mon serveur postgresql, via un client postgresql, situé sur
une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça
m'est impossible,> alors que si
/proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
Ce n'est pas normal.
Où est situé ce serveur postgresql ? Sur une machine extérieure, la
machine hôte ou une autre machine virtuelle ?
Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es
sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu
n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
l'exemple proposé à eric, autorise l'accès à la machine hôte uniquement via ssh. Ce qui signifie que tout accès à cette machine via un autre protocole est exclu.
Oui, mais rien ne t'empêche d'ajouter des règles pour autoriser d'autres protocoles.
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
Ce n'est pas normal. Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
Pascal
-------- Message original --------
Pascal a écrit :
l'exemple proposé à eric, autorise l'accès à la machine hôte uniquement via ssh. Ce qui signifie que tout accès à cette machine via un autre protocole est exclu.
Oui, mais rien ne t'empêche d'ajouter des règles pour autoriser d'autres protocoles.
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
Ce n'est pas normal. Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
Je n'étatit peut petre pas très clair
il s'agit donc d'une machine hôte sur laquelle tourne kvm configurée de la sorte : auto eth0 iface eth0 manual auto br0 iface br0 inet static address 192.168.0.1 netmask 255.255.255.0 network 192.168.0.0 broadcast 255.255.255.0 bridge_ports eth0 bridge_stp off bridge_fd 2 bridge_maxwait 3
sur cette machine tourne entre autre un serveur postgresql en vm cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci http://pastebin.fr/11365
je n'autorise donc que le flux ssh à destination de la machine hôte
si je laisse comme ça, le flux postgresql à destination de la vm postgresql est bloqué. Si j'ai bien compris ton explication, parceque je drop tout le forward. Par contre si, selon tes conseils, je met /proc/sys/net/bridge/bridge-nf-call-iptables=0, le flux passe bien vers la vm postgresql.
du coup je gère les accès à la vm postgresql directement sur celle-ci.
j'ai bon ?
-------- Message original --------
Pascal a écrit :
l'exemple proposé à eric, autorise l'accès à la machine hôte uniquement
via ssh.
Ce qui signifie que tout accès à cette machine via un autre protocole
est exclu.
Oui, mais rien ne t'empêche d'ajouter des règles pour autoriser d'autres
protocoles.
maintenant avec cette seule règle sur la machine hôte, si je souhaite
accéder à mon serveur postgresql, via un client postgresql, situé sur
une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça
m'est impossible,> alors que si
/proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
Ce n'est pas normal.
Où est situé ce serveur postgresql ? Sur une machine extérieure, la
machine hôte ou une autre machine virtuelle ?
Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es
sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu
n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
Je n'étatit peut petre pas très clair
il s'agit donc d'une machine hôte sur laquelle tourne kvm configurée de la sorte :
auto eth0
iface eth0 manual
auto br0
iface br0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 255.255.255.0
bridge_ports eth0
bridge_stp off
bridge_fd 2
bridge_maxwait 3
sur cette machine tourne entre autre un serveur postgresql en vm
cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci
http://pastebin.fr/11365
je n'autorise donc que le flux ssh à destination de la machine hôte
si je laisse comme ça, le flux postgresql à destination de la vm postgresql est
bloqué. Si j'ai bien compris ton explication, parceque je drop tout le forward.
Par contre si, selon tes conseils, je met
/proc/sys/net/bridge/bridge-nf-call-iptables=0, le flux passe bien vers la vm
postgresql.
du coup je gère les accès à la vm postgresql directement sur celle-ci.
l'exemple proposé à eric, autorise l'accès à la machine hôte uniquement via ssh. Ce qui signifie que tout accès à cette machine via un autre protocole est exclu.
Oui, mais rien ne t'empêche d'ajouter des règles pour autoriser d'autres protocoles.
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
Ce n'est pas normal. Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
Je n'étatit peut petre pas très clair
il s'agit donc d'une machine hôte sur laquelle tourne kvm configurée de la sorte : auto eth0 iface eth0 manual auto br0 iface br0 inet static address 192.168.0.1 netmask 255.255.255.0 network 192.168.0.0 broadcast 255.255.255.0 bridge_ports eth0 bridge_stp off bridge_fd 2 bridge_maxwait 3
sur cette machine tourne entre autre un serveur postgresql en vm cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci http://pastebin.fr/11365
je n'autorise donc que le flux ssh à destination de la machine hôte
si je laisse comme ça, le flux postgresql à destination de la vm postgresql est bloqué. Si j'ai bien compris ton explication, parceque je drop tout le forward. Par contre si, selon tes conseils, je met /proc/sys/net/bridge/bridge-nf-call-iptables=0, le flux passe bien vers la vm postgresql.
du coup je gère les accès à la vm postgresql directement sur celle-ci.
j'ai bon ?
Pascal Hambourg
Pascal a écrit :
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
[...]
Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
[...]
sur cette machine tourne entre autre un serveur postgresql en vm cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci http://pastebin.fr/11365
D'accord, donc le serveur est sur une machine virtuelle pontée et tu mettais bien la politique par défaut de la chaîne FORWARD de l'hôte à DROP, ce qui explique le blocage quand bridge-nf-call-iptables=1.
Note que l'hôte n'est pas configuré en routeur (ip_forward=0) donc il ne peut pas y avoir de trafic routé dans la chaîne FORWARD et il n'était pas utile de la bloquer. Ceci dit bridge-nf-call-iptables=0 a quand même l'avantage d'éviter le suivi de connexion des paquets pontés, ce dont l'hôte n'a rien à faire puisque le but n'est pas de faire un pont filtrant.
Quelques observations sur ton script.
ligne 20 : $IPTABLES -t nat -F
Ton jeu de règles n'utilise pas de NAT donc c'est inutile de charger la table nat si elle ne l'est pas déjà, ce que fait cette commande. Tu peux ajouter un test conditionnel sur la présence de cette table :
Même chose pour les tables mangle et raw. Pourquoi on les oublie toujours ?
ligne 72 : # PING # On autorise l'ICMP, avec une limite en entree a dix 'pings' # par seconde, afin de prevenir toute attaque par flood. $IPTABLES -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
Cette règle ne limite pas seulement le ping (echo request) mais aussi tous les autres types ICMP. Il manque "--icmp-type echo-request". D'autre part elle devrait être plutôt en fin de chaîne car le ping n'est vraiment pas ce qu'il y a de plus prioritaire.
Pascal a écrit :
maintenant avec cette seule règle sur la machine hôte, si je souhaite
accéder à mon serveur postgresql, via un client postgresql, situé sur
une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça
m'est impossible,> alors que si
/proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
[...]
Où est situé ce serveur postgresql ? Sur une machine extérieure, la
machine hôte ou une autre machine virtuelle ?
Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es
sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu
n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
[...]
sur cette machine tourne entre autre un serveur postgresql en vm
cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci
http://pastebin.fr/11365
D'accord, donc le serveur est sur une machine virtuelle pontée et tu
mettais bien la politique par défaut de la chaîne FORWARD de l'hôte à
DROP, ce qui explique le blocage quand bridge-nf-call-iptables=1.
Note que l'hôte n'est pas configuré en routeur (ip_forward=0) donc il ne
peut pas y avoir de trafic routé dans la chaîne FORWARD et il n'était
pas utile de la bloquer. Ceci dit bridge-nf-call-iptables=0 a quand même
l'avantage d'éviter le suivi de connexion des paquets pontés, ce dont
l'hôte n'a rien à faire puisque le but n'est pas de faire un pont filtrant.
Quelques observations sur ton script.
ligne 20 :
$IPTABLES -t nat -F
Ton jeu de règles n'utilise pas de NAT donc c'est inutile de charger la
table nat si elle ne l'est pas déjà, ce que fait cette commande. Tu peux
ajouter un test conditionnel sur la présence de cette table :
Même chose pour les tables mangle et raw. Pourquoi on les oublie toujours ?
ligne 72 :
# PING
# On autorise l'ICMP, avec une limite en entree a dix 'pings'
# par seconde, afin de prevenir toute attaque par flood.
$IPTABLES -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
Cette règle ne limite pas seulement le ping (echo request) mais aussi
tous les autres types ICMP. Il manque "--icmp-type echo-request".
D'autre part elle devrait être plutôt en fin de chaîne car le ping n'est
vraiment pas ce qu'il y a de plus prioritaire.
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
[...]
Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
[...]
sur cette machine tourne entre autre un serveur postgresql en vm cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci http://pastebin.fr/11365
D'accord, donc le serveur est sur une machine virtuelle pontée et tu mettais bien la politique par défaut de la chaîne FORWARD de l'hôte à DROP, ce qui explique le blocage quand bridge-nf-call-iptables=1.
Note que l'hôte n'est pas configuré en routeur (ip_forward=0) donc il ne peut pas y avoir de trafic routé dans la chaîne FORWARD et il n'était pas utile de la bloquer. Ceci dit bridge-nf-call-iptables=0 a quand même l'avantage d'éviter le suivi de connexion des paquets pontés, ce dont l'hôte n'a rien à faire puisque le but n'est pas de faire un pont filtrant.
Quelques observations sur ton script.
ligne 20 : $IPTABLES -t nat -F
Ton jeu de règles n'utilise pas de NAT donc c'est inutile de charger la table nat si elle ne l'est pas déjà, ce que fait cette commande. Tu peux ajouter un test conditionnel sur la présence de cette table :
Même chose pour les tables mangle et raw. Pourquoi on les oublie toujours ?
ligne 72 : # PING # On autorise l'ICMP, avec une limite en entree a dix 'pings' # par seconde, afin de prevenir toute attaque par flood. $IPTABLES -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
Cette règle ne limite pas seulement le ping (echo request) mais aussi tous les autres types ICMP. Il manque "--icmp-type echo-request". D'autre part elle devrait être plutôt en fin de chaîne car le ping n'est vraiment pas ce qu'il y a de plus prioritaire.
Pascal
Le 16/05/2011 20:32, Pascal Hambourg a écrit :
Pascal a écrit :
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
[...]
Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
[...]
sur cette machine tourne entre autre un serveur postgresql en vm cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci http://pastebin.fr/11365
D'accord, donc le serveur est sur une machine virtuelle pontée et tu mettais bien la politique par défaut de la chaîne FORWARD de l'hôte à DROP, ce qui explique le blocage quand bridge-nf-call-iptables=1.
Note que l'hôte n'est pas configuré en routeur (ip_forward=0) donc il ne peut pas y avoir de trafic routé dans la chaîne FORWARD et il n'était pas utile de la bloquer. Ceci dit bridge-nf-call-iptables=0 a quand même l'avantage d'éviter le suivi de connexion des paquets pontés, ce dont l'hôte n'a rien à faire puisque le but n'est pas de faire un pont filtrant.
Quelques observations sur ton script.
ligne 20 : $IPTABLES -t nat -F
Ton jeu de règles n'utilise pas de NAT donc c'est inutile de charger la table nat si elle ne l'est pas déjà, ce que fait cette commande. Tu peux ajouter un test conditionnel sur la présence de cette table :
Même chose pour les tables mangle et raw. Pourquoi on les oublie toujours ?
ligne 72 : # PING # On autorise l'ICMP, avec une limite en entree a dix 'pings' # par seconde, afin de prevenir toute attaque par flood. $IPTABLES -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
Cette règle ne limite pas seulement le ping (echo request) mais aussi tous les autres types ICMP. Il manque "--icmp-type echo-request". D'autre part elle devrait être plutôt en fin de chaîne car le ping n'est vraiment pas ce qu'il y a de plus prioritaire.
en fait le script de départ n'est pas de moi , je l'ai arrangé à ma sauce et du coup peut être pas toujours comme il le faudrait.
Je te remercie pour ton aide et tes explications qui m'ont permis d'avancer .
Le 16/05/2011 20:32, Pascal Hambourg a écrit :
Pascal a écrit :
maintenant avec cette seule règle sur la machine hôte, si je souhaite
accéder à mon serveur postgresql, via un client postgresql, situé sur
une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça
m'est impossible,> alors que si
/proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
[...]
Où est situé ce serveur postgresql ? Sur une machine extérieure, la
machine hôte ou une autre machine virtuelle ?
Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es
sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu
n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
[...]
sur cette machine tourne entre autre un serveur postgresql en vm
cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci
http://pastebin.fr/11365
D'accord, donc le serveur est sur une machine virtuelle pontée et tu
mettais bien la politique par défaut de la chaîne FORWARD de l'hôte à
DROP, ce qui explique le blocage quand bridge-nf-call-iptables=1.
Note que l'hôte n'est pas configuré en routeur (ip_forward=0) donc il ne
peut pas y avoir de trafic routé dans la chaîne FORWARD et il n'était
pas utile de la bloquer. Ceci dit bridge-nf-call-iptables=0 a quand même
l'avantage d'éviter le suivi de connexion des paquets pontés, ce dont
l'hôte n'a rien à faire puisque le but n'est pas de faire un pont filtrant.
Quelques observations sur ton script.
ligne 20 :
$IPTABLES -t nat -F
Ton jeu de règles n'utilise pas de NAT donc c'est inutile de charger la
table nat si elle ne l'est pas déjà, ce que fait cette commande. Tu peux
ajouter un test conditionnel sur la présence de cette table :
Même chose pour les tables mangle et raw. Pourquoi on les oublie toujours ?
ligne 72 :
# PING
# On autorise l'ICMP, avec une limite en entree a dix 'pings'
# par seconde, afin de prevenir toute attaque par flood.
$IPTABLES -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
Cette règle ne limite pas seulement le ping (echo request) mais aussi
tous les autres types ICMP. Il manque "--icmp-type echo-request".
D'autre part elle devrait être plutôt en fin de chaîne car le ping n'est
vraiment pas ce qu'il y a de plus prioritaire.
en fait le script de départ n'est pas de moi , je l'ai arrangé à ma
sauce et du coup peut être pas toujours comme il le faudrait.
Je te remercie pour ton aide et tes explications qui m'ont permis
d'avancer .
maintenant avec cette seule règle sur la machine hôte, si je souhaite accéder à mon serveur postgresql, via un client postgresql, situé sur une de mes vm si /proc/sys/net/bridge/bridge-nf-call-iptables=1, ça m'est impossible,> alors que si /proc/sys/net/bridge/bridge-nf-call-iptables=0 c'est possible.
[...]
Où est situé ce serveur postgresql ? Sur une machine extérieure, la machine hôte ou une autre machine virtuelle ? Si c'est sur une machine extérieure ou une autre virtuelle, alors tu es sûr de n'avoir mis que les règles et politiques par défaut d'Eric ? Tu n'aurais pas mis la politique par défaut de la chaîne FORWARD à DROP ?
[...]
sur cette machine tourne entre autre un serveur postgresql en vm cette vm a donc une interface virtuelle mappée sur le bridge-0-1
le firewall de la machine hôte est configuré comme ceci http://pastebin.fr/11365
D'accord, donc le serveur est sur une machine virtuelle pontée et tu mettais bien la politique par défaut de la chaîne FORWARD de l'hôte à DROP, ce qui explique le blocage quand bridge-nf-call-iptables=1.
Note que l'hôte n'est pas configuré en routeur (ip_forward=0) donc il ne peut pas y avoir de trafic routé dans la chaîne FORWARD et il n'était pas utile de la bloquer. Ceci dit bridge-nf-call-iptables=0 a quand même l'avantage d'éviter le suivi de connexion des paquets pontés, ce dont l'hôte n'a rien à faire puisque le but n'est pas de faire un pont filtrant.
Quelques observations sur ton script.
ligne 20 : $IPTABLES -t nat -F
Ton jeu de règles n'utilise pas de NAT donc c'est inutile de charger la table nat si elle ne l'est pas déjà, ce que fait cette commande. Tu peux ajouter un test conditionnel sur la présence de cette table :
Même chose pour les tables mangle et raw. Pourquoi on les oublie toujours ?
ligne 72 : # PING # On autorise l'ICMP, avec une limite en entree a dix 'pings' # par seconde, afin de prevenir toute attaque par flood. $IPTABLES -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
Cette règle ne limite pas seulement le ping (echo request) mais aussi tous les autres types ICMP. Il manque "--icmp-type echo-request". D'autre part elle devrait être plutôt en fin de chaîne car le ping n'est vraiment pas ce qu'il y a de plus prioritaire.
en fait le script de départ n'est pas de moi , je l'ai arrangé à ma sauce et du coup peut être pas toujours comme il le faudrait.
Je te remercie pour ton aide et tes explications qui m'ont permis d'avancer .
