Je suis passé récemment du noyau 2.6.11 au 2.6.12. Ce sont en fait des
noyaus patchés par Gentoo, mais le problème ne vient pas de là puisqu'il
reste présent avec un 2.6.12 vanilla.
Il s'agit en fait d'un problème avec netfilter qui est survenu avec le
changement de noyau.
En gros, on peut supposer que les règles iptables acceptent tous les
paquets entrants sur les différentes interfaces, dont l'interface
loopoback lo. Tous ? Un petit nombre d'irréductibles paquets ne sont pas
ACCEPTées. Il s'agit des paquets qui matchent la règle suivante :
--state INVALID
Cette règle est la première à être parcourue poru les paquets parcourant
INPUT.
Je fais maintenant un "telnet 127.0.0.1" pour tester. Après
vérification, il s'avère que le paquet TCP SYN envoyé par le programme
telnet est reconnu par la règle "--state INVALID" au lieu de l'être plus
tard par la règle "-i lo".
C'est plus que bizarre, il me semble. J'ai eu l'occasion de rencontrer
quelqu'un qui avait exactement le même problème que moi, donc cela
semble reproductible.
J'ai entamé des recherches, pour voir si d'autres avaient le même
problème, pour voir s'il s'agissait d'un bug, ou encore si c'est la
signification des règles iptables qui a changé. Je n'ai malheureusement
rien trouvé d'extra.
Auriez-vous une piste, un lien ou quelque explication qui pourrait
m'éclairer ?
En gros, on peut supposer que les règles iptables acceptent tous les paquets entrants sur les différentes interfaces, dont l'interface loopoback lo. Tous ? Un petit nombre d'irréductibles paquets ne sont pas ACCEPTées. Il s'agit des paquets qui matchent la règle suivante : --state INVALID
Ce n'est pas une règle, ça, c'est un critère de correspondance.
Cette règle est la première à être parcourue poru les paquets parcourant INPUT.
Je fais maintenant un "telnet 127.0.0.1" pour tester. Après vérification, il s'avère que le paquet TCP SYN envoyé par le programme telnet est reconnu par la règle "--state INVALID" au lieu de l'être plus tard par la règle "-i lo".
Ça se produit uniquement sur l'interface lo et dans la chaîne INPUT ?
Salut,
En gros, on peut supposer que les règles iptables acceptent tous les
paquets entrants sur les différentes interfaces, dont l'interface
loopoback lo. Tous ? Un petit nombre d'irréductibles paquets ne sont pas
ACCEPTées. Il s'agit des paquets qui matchent la règle suivante :
--state INVALID
Ce n'est pas une règle, ça, c'est un critère de correspondance.
Cette règle est la première à être parcourue poru les paquets parcourant
INPUT.
Je fais maintenant un "telnet 127.0.0.1" pour tester. Après
vérification, il s'avère que le paquet TCP SYN envoyé par le programme
telnet est reconnu par la règle "--state INVALID" au lieu de l'être plus
tard par la règle "-i lo".
Ça se produit uniquement sur l'interface lo et dans la chaîne INPUT ?
En gros, on peut supposer que les règles iptables acceptent tous les paquets entrants sur les différentes interfaces, dont l'interface loopoback lo. Tous ? Un petit nombre d'irréductibles paquets ne sont pas ACCEPTées. Il s'agit des paquets qui matchent la règle suivante : --state INVALID
Ce n'est pas une règle, ça, c'est un critère de correspondance.
Cette règle est la première à être parcourue poru les paquets parcourant INPUT.
Je fais maintenant un "telnet 127.0.0.1" pour tester. Après vérification, il s'avère que le paquet TCP SYN envoyé par le programme telnet est reconnu par la règle "--state INVALID" au lieu de l'être plus tard par la règle "-i lo".
Ça se produit uniquement sur l'interface lo et dans la chaîne INPUT ?
TiChou
Dans le message <news:42ce3831$0$3128$, *Khanh-Dang* tapota sur f.c.o.l.configuration :
Bonjour à tous,
Bonjour,
[problème Netfilter]
Auriez-vous une piste, un lien ou quelque explication qui pourrait m'éclairer ?
Sans les règles, non. :)
La sortie de iptables-save serait la bienvenue.
-- TiChou
Dans le message <news:42ce3831$0$3128$8fcfb975@news.wanadoo.fr>,
*Khanh-Dang* tapota sur f.c.o.l.configuration :
Bonjour à tous,
Bonjour,
[problème Netfilter]
Auriez-vous une piste, un lien ou quelque explication qui pourrait
m'éclairer ?
Dans le message <news:42ce3831$0$3128$, *Khanh-Dang* tapota sur f.c.o.l.configuration :
Bonjour à tous,
Bonjour,
[problème Netfilter]
Auriez-vous une piste, un lien ou quelque explication qui pourrait m'éclairer ?
Sans les règles, non. :)
La sortie de iptables-save serait la bienvenue.
-- TiChou
Khanh-Dang
La sortie de iptables-save serait la bienvenue.
Désolé. Vu la simplicité des règles, je n'avais pas jugé nécessaire de les montrer :-) Les voici donc, quand ça ne marche pas :
*nat :PREROUTING ACCEPT [356611:28656085] :POSTROUTING ACCEPT [67951:6616695] :OUTPUT ACCEPT [454673:29240106] -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [217:10836] :OUTPUT DROP [1016:38608] -A INPUT -m state --state INVALID -j DROP -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -j ACCEPT -A INPUT -i ppp0 -j ACCEPT -A INPUT -i ppp1 -j ACCEPT -A FORWARD -m state --state INVALID -j DROP -A FORWARD -i ppp0 -o eth0 -j ACCEPT -A FORWARD -i eth0 -o ppp0 -j ACCEPT -A FORWARD -i ppp0 -o ppp1 -j ACCEPT -A FORWARD -i ppp1 -o ppp0 -j ACCEPT -A FORWARD -i eth0 -o ppp1 -j REJECT -A FORWARD -i ppp1 -o eth0 -j REJECT -A OUTPUT -m state --state INVALID -j DROP -A OUTPUT -o lo -j ACCEPT -A OUTPUT -o eth0 -j ACCEPT -A OUTPUT -o ppp0 -j ACCEPT -A OUTPUT -o ppp1 -j ACCEPT COMMIT
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A INPUT -m state --state INVALID -j DROP", alors qu'il ne devrait pas, en toute logique.
La sortie de iptables-save serait la bienvenue.
Désolé. Vu la simplicité des règles, je n'avais pas jugé nécessaire de
les montrer :-)
Les voici donc, quand ça ne marche pas :
*nat
:PREROUTING ACCEPT [356611:28656085]
:POSTROUTING ACCEPT [67951:6616695]
:OUTPUT ACCEPT [454673:29240106]
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [217:10836]
:OUTPUT DROP [1016:38608]
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i ppp0 -j ACCEPT
-A INPUT -i ppp1 -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i ppp0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o ppp0 -j ACCEPT
-A FORWARD -i ppp0 -o ppp1 -j ACCEPT
-A FORWARD -i ppp1 -o ppp0 -j ACCEPT
-A FORWARD -i eth0 -o ppp1 -j REJECT
-A FORWARD -i ppp1 -o eth0 -j REJECT
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -o ppp0 -j ACCEPT
-A OUTPUT -o ppp1 -j ACCEPT
COMMIT
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé
avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A
INPUT -m state --state INVALID -j DROP", alors qu'il ne devrait pas, en
toute logique.
Désolé. Vu la simplicité des règles, je n'avais pas jugé nécessaire de les montrer :-) Les voici donc, quand ça ne marche pas :
*nat :PREROUTING ACCEPT [356611:28656085] :POSTROUTING ACCEPT [67951:6616695] :OUTPUT ACCEPT [454673:29240106] -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [217:10836] :OUTPUT DROP [1016:38608] -A INPUT -m state --state INVALID -j DROP -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -j ACCEPT -A INPUT -i ppp0 -j ACCEPT -A INPUT -i ppp1 -j ACCEPT -A FORWARD -m state --state INVALID -j DROP -A FORWARD -i ppp0 -o eth0 -j ACCEPT -A FORWARD -i eth0 -o ppp0 -j ACCEPT -A FORWARD -i ppp0 -o ppp1 -j ACCEPT -A FORWARD -i ppp1 -o ppp0 -j ACCEPT -A FORWARD -i eth0 -o ppp1 -j REJECT -A FORWARD -i ppp1 -o eth0 -j REJECT -A OUTPUT -m state --state INVALID -j DROP -A OUTPUT -o lo -j ACCEPT -A OUTPUT -o eth0 -j ACCEPT -A OUTPUT -o ppp0 -j ACCEPT -A OUTPUT -o ppp1 -j ACCEPT COMMIT
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A INPUT -m state --state INVALID -j DROP", alors qu'il ne devrait pas, en toute logique.
TiChou
Dans le message <news:42ce815b$0$25036$, *Khanh-Dang* tapota sur f.c.o.l.configuration :
La sortie de iptables-save serait la bienvenue.
J'aurais du préciser avec l'option --counters, ça aurait été peut être plus parlant.
Les voici donc, quand ça ne marche pas :
*filter :INPUT DROP [0:0] :FORWARD DROP [217:10836] :OUTPUT DROP [1016:38608]
Ça « drope » beaucoup en sortie, c'est assez curieux à la vue des autres règles. Il y a d'autres interfaces réseaux que lo, eth0, ppp0 et ppp1 ?
[...]
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A INPUT -m state --state INVALID -j DROP",
À quoi le voyez-vous ? Qu'est-ce qui vous permet de dire que c'est cette règle qui est matchée et bloquante ? Il serait intéressant de rajouter, avant vos règles DROP, des règles de log en utilisant la cible LOG. tcpdump en mode verbeux devrait aussi être fort utile.
-- TiChou
Dans le message <news:42ce815b$0$25036$8fcfb975@news.wanadoo.fr>,
*Khanh-Dang* tapota sur f.c.o.l.configuration :
La sortie de iptables-save serait la bienvenue.
J'aurais du préciser avec l'option --counters, ça aurait été peut être plus
parlant.
Les voici donc, quand ça ne marche pas :
*filter
:INPUT DROP [0:0]
:FORWARD DROP [217:10836]
:OUTPUT DROP [1016:38608]
Ça « drope » beaucoup en sortie, c'est assez curieux à la vue des autres
règles. Il y a d'autres interfaces réseaux que lo, eth0, ppp0 et ppp1 ?
[...]
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé
avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A
INPUT -m state --state INVALID -j DROP",
À quoi le voyez-vous ? Qu'est-ce qui vous permet de dire que c'est cette
règle qui est matchée et bloquante ?
Il serait intéressant de rajouter, avant vos règles DROP, des règles de log
en utilisant la cible LOG.
tcpdump en mode verbeux devrait aussi être fort utile.
Dans le message <news:42ce815b$0$25036$, *Khanh-Dang* tapota sur f.c.o.l.configuration :
La sortie de iptables-save serait la bienvenue.
J'aurais du préciser avec l'option --counters, ça aurait été peut être plus parlant.
Les voici donc, quand ça ne marche pas :
*filter :INPUT DROP [0:0] :FORWARD DROP [217:10836] :OUTPUT DROP [1016:38608]
Ça « drope » beaucoup en sortie, c'est assez curieux à la vue des autres règles. Il y a d'autres interfaces réseaux que lo, eth0, ppp0 et ppp1 ?
[...]
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A INPUT -m state --state INVALID -j DROP",
À quoi le voyez-vous ? Qu'est-ce qui vous permet de dire que c'est cette règle qui est matchée et bloquante ? Il serait intéressant de rajouter, avant vos règles DROP, des règles de log en utilisant la cible LOG. tcpdump en mode verbeux devrait aussi être fort utile.
-- TiChou
Samuel
Bonjour,
La sortie de iptables-save serait la bienvenue.
Désolé. Vu la simplicité des règles, je n'avais pas jugé nécessaire de les montrer :-) Les voici donc, quand ça ne marche pas :
[...]
-A INPUT -m state --state INVALID -j DROP -A INPUT -i lo -j ACCEPT
Ce n'est pas la solution etc'est pas propre, mais inverser ces deux règles permettrait de voir rapidement si c'est la règle INVALID qui droppe.
Samuel.
Bonjour,
La sortie de iptables-save serait la bienvenue.
Désolé. Vu la simplicité des règles, je n'avais pas jugé nécessaire de
les montrer :-)
Les voici donc, quand ça ne marche pas :
[...]
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i lo -j ACCEPT
Ce n'est pas la solution etc'est pas propre, mais inverser ces deux
règles permettrait de voir rapidement si c'est la règle INVALID qui droppe.
Ce n'est propre et ce n'est pas la solution non plus mais,
-A INPUT -m state --state INVALID -j DROP -A INPUT -i lo -j ACCEPT
Je voualis dire d'inverser ces deux règles :
-A INPUT -m state --state INVALID -j DROP -A INPUT -i lo -j ACCEPT
Samuel.
Khanh-Dang
Dans le message <news:42ce815b$0$25036$, *Khanh-Dang* tapota sur f.c.o.l.configuration :
La sortie de iptables-save serait la bienvenue.
J'aurais du préciser avec l'option --counters, ça aurait été peut être plus parlant.
Oui, dès que j'aurai la main sur la machine, je ferai voir ça.
*filter :INPUT DROP [0:0] :FORWARD DROP [217:10836] :OUTPUT DROP [1016:38608]
Ça « drope » beaucoup en sortie, c'est assez curieux à la vue des autres règles. Il y a d'autres interfaces réseaux que lo, eth0, ppp0 et ppp1 ?
En fait, il y avait aussi un eth0 (une carte wifi), que j'ai enlevée. J'ai aussi enlevé les règles correspondantes. Celà n'avait en rien changé le problème recontré.
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A INPUT -m state --state INVALID -j DROP",
À quoi le voyez-vous ? Qu'est-ce qui vous permet de dire que c'est cette règle qui est matchée et bloquante ?
D'une part, quand j'inverse les deux première règles - comme proposé par Samul C. - celà fonctionne. D'autre part, j'ai observé le phénomène grâce au compteur de la règle qui s'incrémentait.
Il serait intéressant de rajouter, avant vos règles DROP, des règles de log en utilisant la cible LOG. tcpdump en mode verbeux devrait aussi être fort utile.
Oui, dès que j'aurai la main sur la machine, je vous montrerai tout ça.
En tout cas, merci beaucoup à tous pour vos réponses.
Dans le message <news:42ce815b$0$25036$8fcfb975@news.wanadoo.fr>,
*Khanh-Dang* tapota sur f.c.o.l.configuration :
La sortie de iptables-save serait la bienvenue.
J'aurais du préciser avec l'option --counters, ça aurait été peut être plus
parlant.
Oui, dès que j'aurai la main sur la machine, je ferai voir ça.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [217:10836]
:OUTPUT DROP [1016:38608]
Ça « drope » beaucoup en sortie, c'est assez curieux à la vue des autres
règles. Il y a d'autres interfaces réseaux que lo, eth0, ppp0 et ppp1 ?
En fait, il y avait aussi un eth0 (une carte wifi), que j'ai enlevée.
J'ai aussi enlevé les règles correspondantes. Celà n'avait en rien
changé le problème recontré.
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé
avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A
INPUT -m state --state INVALID -j DROP",
À quoi le voyez-vous ? Qu'est-ce qui vous permet de dire que c'est cette
règle qui est matchée et bloquante ?
D'une part, quand j'inverse les deux première règles - comme proposé par
Samul C. - celà fonctionne. D'autre part, j'ai observé le phénomène
grâce au compteur de la règle qui s'incrémentait.
Il serait intéressant de rajouter, avant vos règles DROP, des règles de log
en utilisant la cible LOG.
tcpdump en mode verbeux devrait aussi être fort utile.
Oui, dès que j'aurai la main sur la machine, je vous montrerai tout ça.
En tout cas, merci beaucoup à tous pour vos réponses.
Dans le message <news:42ce815b$0$25036$, *Khanh-Dang* tapota sur f.c.o.l.configuration :
La sortie de iptables-save serait la bienvenue.
J'aurais du préciser avec l'option --counters, ça aurait été peut être plus parlant.
Oui, dès que j'aurai la main sur la machine, je ferai voir ça.
*filter :INPUT DROP [0:0] :FORWARD DROP [217:10836] :OUTPUT DROP [1016:38608]
Ça « drope » beaucoup en sortie, c'est assez curieux à la vue des autres règles. Il y a d'autres interfaces réseaux que lo, eth0, ppp0 et ppp1 ?
En fait, il y avait aussi un eth0 (une carte wifi), que j'ai enlevée. J'ai aussi enlevé les règles correspondantes. Celà n'avait en rien changé le problème recontré.
Ainsi, disais-je dans le message initial, un simple paquet SYN envoyé avec "telnet 127.0.0.1" sur la même machine est matché par la règle "-A INPUT -m state --state INVALID -j DROP",
À quoi le voyez-vous ? Qu'est-ce qui vous permet de dire que c'est cette règle qui est matchée et bloquante ?
D'une part, quand j'inverse les deux première règles - comme proposé par Samul C. - celà fonctionne. D'autre part, j'ai observé le phénomène grâce au compteur de la règle qui s'incrémentait.
Il serait intéressant de rajouter, avant vos règles DROP, des règles de log en utilisant la cible LOG. tcpdump en mode verbeux devrait aussi être fort utile.
Oui, dès que j'aurai la main sur la machine, je vous montrerai tout ça.
En tout cas, merci beaucoup à tous pour vos réponses.
Khanh-Dang
[netfilter et noyau 2.6.12: certains paquets TCP sur interface loopback semblent être marqués comme INVALID]
J'avais trouvé une ligne dans le changelog de la version 2.6.12 qui était susceptible de pointer du doigt le changement posant problème chez moi. Je n'ai pas pu aller chercher plus loin, n'étant pas lecteur régulier du code source de linux.
En recherchant à nouveau dans Google (mots clé: "2.6.12" netfilter invalid), j'ai maintenant trouvé des résultats probants (Google n'a dû les archiver qu'après ma première recherche) : <https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020366.html> <https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020355.html>
C'est donc un problème connu et qui concerne d'autres personnes que moi.
Encore une fois, merci à tous ceux qui ont eu la gentillesse et les compétences pour m'avoir répondu :-)
[netfilter et noyau 2.6.12: certains paquets TCP sur interface loopback
semblent être marqués comme INVALID]
J'avais trouvé une ligne dans le changelog de la version 2.6.12 qui
était susceptible de pointer du doigt le changement posant problème chez
moi. Je n'ai pas pu aller chercher plus loin, n'étant pas lecteur
régulier du code source de linux.
En recherchant à nouveau dans Google (mots clé: "2.6.12" netfilter
invalid), j'ai maintenant trouvé des résultats probants (Google n'a dû
les archiver qu'après ma première recherche) :
<https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020366.html>
<https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020355.html>
C'est donc un problème connu et qui concerne d'autres personnes que moi.
Encore une fois, merci à tous ceux qui ont eu la gentillesse et les
compétences pour m'avoir répondu :-)
[netfilter et noyau 2.6.12: certains paquets TCP sur interface loopback semblent être marqués comme INVALID]
J'avais trouvé une ligne dans le changelog de la version 2.6.12 qui était susceptible de pointer du doigt le changement posant problème chez moi. Je n'ai pas pu aller chercher plus loin, n'étant pas lecteur régulier du code source de linux.
En recherchant à nouveau dans Google (mots clé: "2.6.12" netfilter invalid), j'ai maintenant trouvé des résultats probants (Google n'a dû les archiver qu'après ma première recherche) : <https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020366.html> <https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020355.html>
C'est donc un problème connu et qui concerne d'autres personnes que moi.
Encore une fois, merci à tous ceux qui ont eu la gentillesse et les compétences pour m'avoir répondu :-)
