Je sais que mon poste n'est pas relatif a debian, mais en desespoir de
cause....
J'ai aquit un WRT54GL et l'ai flash=E9 en dd'wrt, donc en linux.
Iptables tourne dessus.
Plan reseau:
WWW ----- WRT54GL ---- LAN
Sur mon reseau LAN, j'ai install=E9 un serveur DNS pour mon reseau local, c=
a
fonctionne bien. Ce dns gerre aussi mon domaine sur internet.
Il me faut donc rediriger toutes les requette qui viennent d'internet sur l=
e
port 53 vers mon serveur DNS interne, et que ce dns interne renvois la
reponse =E0 son expediteur sur le net.
J'ai donc plac=E9 une regle PREROUTING qui DNAT mon port:
Ca ne marche pas. J'ai fait pareil avec le port 80 tcp pour ecarter une
erreur de mon dns.
J'ai donc essay=E9 ca (53 et 80):
$IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -p udp -i $IP_WAN --dport 53 -j DNAT
--to-destination $MOE:53
Idem, aucun resultat.
Je precise que par defaut, j'ai INPUT OUTPUT FORWARD a ACCEPT
Du coup, je vois pas trop comment faire pour que mon serveur MOE soit
accessible depuis internet sur ses port 53 et 80.
J'ai essay=E9 d'autres solutions trouv=E9es sur le net, et aucuns resultats=
. En
bref, je suis en train de m'arracher les cheuveux depuis 3 jours...
Bonjour,<br><br>Je sais que mon poste n'est pas relatif a debian, mais =
en desespoir de cause....<br><br>J'ai aquit un WRT54GL et l'ai flas=
h=E9 en dd'wrt, donc en linux.<br>Iptables tourne dessus.<br><br>Plan r=
eseau:
<br>WWW ----- WRT54GL ---- LAN<br><br>Sur mon reseau LAN, j'ai install=
=E9 un serveur DNS pour mon reseau local, ca fonctionne bien. Ce dns gerre =
aussi mon domaine sur internet.<br>Il me faut donc rediriger toutes les req=
uette qui viennent d'internet sur le port 53 vers mon serveur DNS inter=
ne, et que ce dns interne renvois la reponse =E0 son expediteur sur le net.
<br><br>J'ai donc plac=E9 une regle PREROUTING qui DNAT mon port:<br><b=
r>$IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT<br>$IP=
TABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT<br>$IPTABL=
ES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT --to-destinati=
on $MOE:53
<br><br>Ca ne marche pas. J'ai fait pareil avec le port 80 tcp pour eca=
rter une erreur de mon dns.<br>J'ai donc essay=E9 ca (53 et 80):<br>$IP=
TABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT<br>
$IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT<br>
$IPTABLES -t nat -A PREROUTING -p udp -i $IP_WAN --dport 53 -j DNAT --to-de=
stination $MOE:53<br><br>Idem, aucun resultat.<br>Je precise que par defaut=
, j'ai INPUT OUTPUT FORWARD a ACCEPT<br><br>Du coup, je vois pas trop c=
omment faire pour que mon serveur MOE soit accessible depuis internet sur s=
es port 53 et 80.
<br>J'ai essay=E9 d'autres solutions trouv=E9es sur le net, et aucu=
ns resultats. En bref, je suis en train de m'arracher les cheuveux depu=
is 3 jours...<br><br>merci d'avance pour toute piste ou solution.<br>
<br>
------=_Part_119032_15621868.1175523472860--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Lundi 02 Avril 2007 19:16, Pascal Hambourg a écrit :
Salut,
Bonjour,
Serge Cavailles a écrit :
Au vu du script, il me semble que la réponse de votre dns est dét ournée par la règle de masquerading $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les chaînes de la table 'nat'. Ils sont traités implicitement en fonct ion des opérations de NAT appliquées au premier paquet de la connexion .
Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
Mais je peux me tromper, je l'ai déjà prouvé :D
Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, l a réponse sera systématiquement en TCP et pas en UDP:
http://www.secuobs.com/plugs/18356.shtml
-- You can see that there are 25 unread articles in `news.announce.newusers' . There are no unread articles, but some ticked articles, in `alt.fan.andrea-dworkin' (see that little asterisk at the beginning of th e line?) You can fuck that up to your heart's delight by fiddling with the `gnus-group-line-format' variable. -- From the (ding) Gnus 5 documentation, by Lars Magne Ingebrigtsen
Serge Cavailles a écrit :
Le Lundi 02 Avril 2007 19:16, Pascal Hambourg a écrit :
Salut,
Bonjour,
Serge Cavailles a écrit :
Au vu du script, il me semble que la réponse de votre dns est dét ournée
par la règle de masquerading
$IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
chaînes de la table 'nat'. Ils sont traités implicitement en fonct ion
des opérations de NAT appliquées au premier paquet de la connexion .
Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
pense pas qu'il puisse y avoir de paquets ESTABLISHED.
Mais je peux me tromper, je l'ai déjà prouvé :D
Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, l a
réponse sera systématiquement en TCP et pas en UDP:
http://www.secuobs.com/plugs/18356.shtml
--
You can see that there are 25 unread articles in `news.announce.newusers' .
There are no unread articles, but some ticked articles, in
`alt.fan.andrea-dworkin' (see that little asterisk at the beginning of th e
line?)
You can fuck that up to your heart's delight by fiddling with the
`gnus-group-line-format' variable.
-- From the (ding) Gnus 5 documentation, by Lars Magne Ingebrigtsen
Le Lundi 02 Avril 2007 19:16, Pascal Hambourg a écrit :
Salut,
Bonjour,
Serge Cavailles a écrit :
Au vu du script, il me semble que la réponse de votre dns est dét ournée par la règle de masquerading $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les chaînes de la table 'nat'. Ils sont traités implicitement en fonct ion des opérations de NAT appliquées au premier paquet de la connexion .
Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
Mais je peux me tromper, je l'ai déjà prouvé :D
Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, l a réponse sera systématiquement en TCP et pas en UDP:
http://www.secuobs.com/plugs/18356.shtml
-- You can see that there are 25 unread articles in `news.announce.newusers' . There are no unread articles, but some ticked articles, in `alt.fan.andrea-dworkin' (see that little asterisk at the beginning of th e line?) You can fuck that up to your heart's delight by fiddling with the `gnus-group-line-format' variable. -- From the (ding) Gnus 5 documentation, by Lars Magne Ingebrigtsen
Pascal Hambourg
Serge Cavailles a écrit :
Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les chaînes de la table 'nat'. Ils sont traités implicitement en fonction des opérations de NAT appliquées au premier paquet de la connexion.
Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
C'est pareil en UDP et n'importe quel autre protocole IP du moment que le suivi de connexion peut identifier un paquet comme une réponse à un autre paquet qu'il a déjà vu passer. La notion de "connexion" de Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par ses adresses source et destination, protocole, ports source et destination (si applicables)... Exemples en dehors de TCP : - ICMP echo request et l'echo reply correspondant - requête DNS en UDP et la réponse correspondante - tunnel GRE, IPIP ou autre
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles a écrit :
Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
chaînes de la table 'nat'. Ils sont traités implicitement en fonction
des opérations de NAT appliquées au premier paquet de la connexion.
Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
pense pas qu'il puisse y avoir de paquets ESTABLISHED.
C'est pareil en UDP et n'importe quel autre protocole IP du moment que
le suivi de connexion peut identifier un paquet comme une réponse à un
autre paquet qu'il a déjà vu passer. La notion de "connexion" de
Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par
ses adresses source et destination, protocole, ports source et
destination (si applicables)... Exemples en dehors de TCP :
- ICMP echo request et l'echo reply correspondant
- requête DNS en UDP et la réponse correspondante
- tunnel GRE, IPIP ou autre
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les chaînes de la table 'nat'. Ils sont traités implicitement en fonction des opérations de NAT appliquées au premier paquet de la connexion.
Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
C'est pareil en UDP et n'importe quel autre protocole IP du moment que le suivi de connexion peut identifier un paquet comme une réponse à un autre paquet qu'il a déjà vu passer. La notion de "connexion" de Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par ses adresses source et destination, protocole, ports source et destination (si applicables)... Exemples en dehors de TCP : - ICMP echo request et l'echo reply correspondant - requête DNS en UDP et la réponse correspondante - tunnel GRE, IPIP ou autre
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles
Bonjour,
Le Mardi 03 Avril 2007 00:59, Jean-Yves F. Barbier a écrit :
Serge Cavailles a écrit : > Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je > ne pense pas qu'il puisse y avoir de paquets ESTABLISHED. > > Mais je peux me tromper, je l'ai déjà prouvé :D
Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, la réponse sera systématiquement en TCP et pas en UDP:
Ça ne répond pas réellement à ma question (qui correspondrait au ca s d'une réponse de taille inférieure à 512 octets donc), mais l'info est intéressante à connaître.
http://www.secuobs.com/plugs/18356.shtml
Et Hop! dans le marque pages.
Merci pour ces infos et bonne journée. -- Serge
Bonjour,
Le Mardi 03 Avril 2007 00:59, Jean-Yves F. Barbier a écrit :
Serge Cavailles a écrit :
> Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je
> ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
>
> Mais je peux me tromper, je l'ai déjà prouvé :D
Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, la
réponse sera systématiquement en TCP et pas en UDP:
Ça ne répond pas réellement à ma question (qui correspondrait au ca s d'une
réponse de taille inférieure à 512 octets donc), mais l'info est
intéressante à connaître.
Le Mardi 03 Avril 2007 00:59, Jean-Yves F. Barbier a écrit :
Serge Cavailles a écrit : > Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je > ne pense pas qu'il puisse y avoir de paquets ESTABLISHED. > > Mais je peux me tromper, je l'ai déjà prouvé :D
Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, la réponse sera systématiquement en TCP et pas en UDP:
Ça ne répond pas réellement à ma question (qui correspondrait au ca s d'une réponse de taille inférieure à 512 octets donc), mais l'info est intéressante à connaître.
http://www.secuobs.com/plugs/18356.shtml
Et Hop! dans le marque pages.
Merci pour ces infos et bonne journée. -- Serge
Serge Cavailles
Bonjour,
Le Mardi 03 Avril 2007 01:38, Pascal Hambourg a écrit :
Serge Cavailles a écrit : > Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je > ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
C'est pareil en UDP et n'importe quel autre protocole IP du moment que le suivi de connexion peut identifier un paquet comme une réponse à un autre paquet qu'il a déjà vu passer. La notion de "connexion" de Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par ses adresses source et destination, protocole, ports source et destination (si applicables)... Exemples en dehors de TCP : - ICMP echo request et l'echo reply correspondant - requête DNS en UDP et la réponse correspondante - tunnel GRE, IPIP ou autre
Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des connections au sens TCP. Je vais donc pouvoir simplifier mes règles.
Merci pour cette explication et bonne journée.
-- Serge
Bonjour,
Le Mardi 03 Avril 2007 01:38, Pascal Hambourg a écrit :
Serge Cavailles a écrit :
> Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je
> ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
C'est pareil en UDP et n'importe quel autre protocole IP du moment que
le suivi de connexion peut identifier un paquet comme une réponse à un
autre paquet qu'il a déjà vu passer. La notion de "connexion" de
Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par
ses adresses source et destination, protocole, ports source et
destination (si applicables)... Exemples en dehors de TCP :
- ICMP echo request et l'echo reply correspondant
- requête DNS en UDP et la réponse correspondante
- tunnel GRE, IPIP ou autre
Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des
connections au sens TCP.
Je vais donc pouvoir simplifier mes règles.
Le Mardi 03 Avril 2007 01:38, Pascal Hambourg a écrit :
Serge Cavailles a écrit : > Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je > ne pense pas qu'il puisse y avoir de paquets ESTABLISHED.
C'est pareil en UDP et n'importe quel autre protocole IP du moment que le suivi de connexion peut identifier un paquet comme une réponse à un autre paquet qu'il a déjà vu passer. La notion de "connexion" de Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par ses adresses source et destination, protocole, ports source et destination (si applicables)... Exemples en dehors de TCP : - ICMP echo request et l'echo reply correspondant - requête DNS en UDP et la réponse correspondante - tunnel GRE, IPIP ou autre
Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des connections au sens TCP. Je vais donc pouvoir simplifier mes règles.
Merci pour cette explication et bonne journée.
-- Serge
Pascal Hambourg
Serge Cavailles a écrit :
La notion de "connexion" de Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par ses adresses source et destination, protocole, ports source et destination (si applicables)... Exemples en dehors de TCP : - ICMP echo request et l'echo reply correspondant - requête DNS en UDP et la réponse correspondante - tunnel GRE, IPIP ou autre
Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des connections au sens TCP.
Et non, pas seulement. Note toutefois que le suivi de connexion de Netfilter a ses limites, sauf aide d'un module "helper" pour certains protocoles particuliers. Par exemple il ne sait pas reconnaître les réponses à un paquet émis en broadcast (ICMP ping broadcast, annonce Netbios UDP) car l'adresse source unicast des paquets de réponse est différente de l'adresse broadcast du paquet initial : comme le suivi de connexion ne sait rien de l'organisation des sous-réseaux, il ne fait pas le lien entre les deux. Autre exemple, il ne sait pas reconnaître tout seul la réponse à une requête TFTP (en UDP) car le port source dans le paquet de réponse du serveur est différent du port destination dans le paquet de requête du client. Pour des protocoles aussi courants que Netbios et TFTP, il existe des modules "helpers" ([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien n'est prévu pour le cas général.
Je vais donc pouvoir simplifier mes règles.
Probablement. En première approximation, dans une chaîne on peut se contenter de :
# accepte tout ce qui appartient ou est lié à une "connexion" existante -A -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte au cas par cas les nouvelles "connexions" -A -m state --state NEW <critères : interface, proto, adresse, port...> -j ACCEPT [...]
Et on jette le reste plus ou moins élégamment avec DROP ou REJECT.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles a écrit :
La notion de "connexion" de
Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par
ses adresses source et destination, protocole, ports source et
destination (si applicables)... Exemples en dehors de TCP :
- ICMP echo request et l'echo reply correspondant
- requête DNS en UDP et la réponse correspondante
- tunnel GRE, IPIP ou autre
Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des
connections au sens TCP.
Et non, pas seulement. Note toutefois que le suivi de connexion de
Netfilter a ses limites, sauf aide d'un module "helper" pour certains
protocoles particuliers. Par exemple il ne sait pas reconnaître les
réponses à un paquet émis en broadcast (ICMP ping broadcast, annonce
Netbios UDP) car l'adresse source unicast des paquets de réponse est
différente de l'adresse broadcast du paquet initial : comme le suivi de
connexion ne sait rien de l'organisation des sous-réseaux, il ne fait
pas le lien entre les deux. Autre exemple, il ne sait pas reconnaître
tout seul la réponse à une requête TFTP (en UDP) car le port source dans
le paquet de réponse du serveur est différent du port destination dans
le paquet de requête du client. Pour des protocoles aussi courants que
Netbios et TFTP, il existe des modules "helpers"
([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre
de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien
n'est prévu pour le cas général.
Je vais donc pouvoir simplifier mes règles.
Probablement. En première approximation, dans une chaîne on peut se
contenter de :
# accepte tout ce qui appartient ou est lié à une "connexion" existante
-A -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte au cas par cas les nouvelles "connexions"
-A -m state --state NEW <critères : interface, proto, adresse, port...>
-j ACCEPT
[...]
Et on jette le reste plus ou moins élégamment avec DROP ou REJECT.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
La notion de "connexion" de Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par ses adresses source et destination, protocole, ports source et destination (si applicables)... Exemples en dehors de TCP : - ICMP echo request et l'echo reply correspondant - requête DNS en UDP et la réponse correspondante - tunnel GRE, IPIP ou autre
Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des connections au sens TCP.
Et non, pas seulement. Note toutefois que le suivi de connexion de Netfilter a ses limites, sauf aide d'un module "helper" pour certains protocoles particuliers. Par exemple il ne sait pas reconnaître les réponses à un paquet émis en broadcast (ICMP ping broadcast, annonce Netbios UDP) car l'adresse source unicast des paquets de réponse est différente de l'adresse broadcast du paquet initial : comme le suivi de connexion ne sait rien de l'organisation des sous-réseaux, il ne fait pas le lien entre les deux. Autre exemple, il ne sait pas reconnaître tout seul la réponse à une requête TFTP (en UDP) car le port source dans le paquet de réponse du serveur est différent du port destination dans le paquet de requête du client. Pour des protocoles aussi courants que Netbios et TFTP, il existe des modules "helpers" ([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien n'est prévu pour le cas général.
Je vais donc pouvoir simplifier mes règles.
Probablement. En première approximation, dans une chaîne on peut se contenter de :
# accepte tout ce qui appartient ou est lié à une "connexion" existante -A -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte au cas par cas les nouvelles "connexions" -A -m state --state NEW <critères : interface, proto, adresse, port...> -j ACCEPT [...]
Et on jette le reste plus ou moins élégamment avec DROP ou REJECT.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles
Le Mercredi 04 Avril 2007 19:35, Pascal Hambourg a écrit :
Serge Cavailles a écrit : > Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des > connections au sens TCP.
Et non, pas seulement.
Eh oui, présupposé sans fondement. :/
Note toutefois que le suivi de connexion de Netfilter a ses limites, sauf aide d'un module "helper" pour certains protocoles particuliers. Par exemple il ne sait pas reconnaître les réponses à un paquet émis en broadcast (ICMP ping broadcast, annonce Netbios UDP) car l'adresse source unicast des paquets de réponse est différente de l'adresse broadcast du paquet initial : comme le suivi de connexion ne sait rien de l'organisation des sous-réseaux, il ne fait pas le lien entre les deux.
Ça se comprend, suffit (quand même) d'y penser.
Autre exemple, il ne sait pas reconnaître tout seul la réponse à une requête TFTP (en UDP) car le port source dans le paquet de réponse du serveur est différent du port destination dans le paquet de requête du client. Pour des protocoles aussi courants que Netbios et TFTP, il existe des modules "helpers"
De manière similaire à ce qui existe pour FTP (en TCP) pour les mêmes raisons. Ok.
([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien n'est prévu pour le cas général.
Pour NetBios, je n'ai rien vu dans mon noyau 2.6.8. Je suppose que tu parle s du Netbios_ns apparu au 2.6.14 selon http://www.plouf.fr.eu.org/bazar/netfilter/changements- netfilter-2.6.html#linux-2.6.8
> Je vais donc pouvoir simplifier mes règles.
Probablement.
Oui, j'ai une gestion 'explicite' de l'ICMP actuellement qui n'a donc pas lieu d'exister.
[snip]
Merci pour ces précisions.
-- Serge
Le Mercredi 04 Avril 2007 19:35, Pascal Hambourg a écrit :
Serge Cavailles a écrit :
> Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des
> connections au sens TCP.
Et non, pas seulement.
Eh oui, présupposé sans fondement. :/
Note toutefois que le suivi de connexion de
Netfilter a ses limites, sauf aide d'un module "helper" pour certains
protocoles particuliers. Par exemple il ne sait pas reconnaître les
réponses à un paquet émis en broadcast (ICMP ping broadcast, annonce
Netbios UDP) car l'adresse source unicast des paquets de réponse est
différente de l'adresse broadcast du paquet initial : comme le suivi de
connexion ne sait rien de l'organisation des sous-réseaux, il ne fait
pas le lien entre les deux.
Ça se comprend, suffit (quand même) d'y penser.
Autre exemple, il ne sait pas reconnaître
tout seul la réponse à une requête TFTP (en UDP) car le port source dans
le paquet de réponse du serveur est différent du port destination dans
le paquet de requête du client. Pour des protocoles aussi courants que
Netbios et TFTP, il existe des modules "helpers"
De manière similaire à ce qui existe pour FTP (en TCP) pour les mêmes
raisons. Ok.
([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre
de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien
n'est prévu pour le cas général.
Pour NetBios, je n'ai rien vu dans mon noyau 2.6.8. Je suppose que tu parle s
du Netbios_ns apparu au 2.6.14 selon
http://www.plouf.fr.eu.org/bazar/netfilter/changements-
netfilter-2.6.html#linux-2.6.8
> Je vais donc pouvoir simplifier mes règles.
Probablement.
Oui, j'ai une gestion 'explicite' de l'ICMP actuellement qui n'a donc pas
lieu d'exister.
Le Mercredi 04 Avril 2007 19:35, Pascal Hambourg a écrit :
Serge Cavailles a écrit : > Ah! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des > connections au sens TCP.
Et non, pas seulement.
Eh oui, présupposé sans fondement. :/
Note toutefois que le suivi de connexion de Netfilter a ses limites, sauf aide d'un module "helper" pour certains protocoles particuliers. Par exemple il ne sait pas reconnaître les réponses à un paquet émis en broadcast (ICMP ping broadcast, annonce Netbios UDP) car l'adresse source unicast des paquets de réponse est différente de l'adresse broadcast du paquet initial : comme le suivi de connexion ne sait rien de l'organisation des sous-réseaux, il ne fait pas le lien entre les deux.
Ça se comprend, suffit (quand même) d'y penser.
Autre exemple, il ne sait pas reconnaître tout seul la réponse à une requête TFTP (en UDP) car le port source dans le paquet de réponse du serveur est différent du port destination dans le paquet de requête du client. Pour des protocoles aussi courants que Netbios et TFTP, il existe des modules "helpers"
De manière similaire à ce qui existe pour FTP (en TCP) pour les mêmes raisons. Ok.
([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien n'est prévu pour le cas général.
Pour NetBios, je n'ai rien vu dans mon noyau 2.6.8. Je suppose que tu parle s du Netbios_ns apparu au 2.6.14 selon http://www.plouf.fr.eu.org/bazar/netfilter/changements- netfilter-2.6.html#linux-2.6.8
> Je vais donc pouvoir simplifier mes règles.
Probablement.
Oui, j'ai une gestion 'explicite' de l'ICMP actuellement qui n'a donc pas lieu d'exister.
[snip]
Merci pour ces précisions.
-- Serge
Pascal Hambourg
Serge Cavailles a écrit :
Note toutefois que le suivi de connexion de Netfilter a ses limites, sauf aide d'un module "helper" pour certains protocoles particuliers.
[...]
Autre exemple, il ne sait pas reconnaître tout seul la réponse à une requête TFTP (en UDP) car le port source dans le paquet de réponse du serveur est différent du port destination dans le paquet de requête du client. Pour des protocoles aussi courants que Netbios et TFTP, il existe des modules "helpers"
De manière similaire à ce qui existe pour FTP (en TCP) pour les mêmes raisons. Ok.
Plus ou moins, car TFTP est vraiment spécial. En FTP, du point de vue réseau la connexion TCP de données est totalement indépendante de la connexion TCP de contrôle. En TFTP c'est un peu bâtard : la réponse est envoyée par le serveur depuis un port UDP source différent du port TFTP ayant reçu la requête mais vers le même port UDP destination que le port source utilisé par la requête du client. C'est d'ailleurs grâce à cette particularité que le helper reconnaît la réponse.
([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien n'est prévu pour le cas général.
Pour NetBios, je n'ai rien vu dans mon noyau 2.6.8. Je suppose que tu parles du Netbios_ns apparu au 2.6.14 selon http://www.plouf.fr.eu.org/bazar/netfilter/changements-netfilter-2.6.html
Oui, en effet. Finalement cette page aura au moins servi à quelqu'un d'autre que moi. :-)
[...]
Oui, j'ai une gestion 'explicite' de l'ICMP actuellement
Moi aussi en fait : comme je suis un peu parano, je n'accepte pas tous les types ICMP qui sont classés dans l'état RELATED mais seulement ceux que je considère comme indispensables (destination unreachable, time exceeded, parameter problem). Idem pour les ICMP classés NEW : seul echo request (ping) est accepté. En revanche tous les ICMP classés ESTABLISHED sont acceptés : s'ils sont dans cet état, c'est qu'ils ont été sollicités, donc il n'y a pas de raison de les bloquer.
qui n'a donc pas lieu d'exister.
Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED. Pour les autres états, c'est selon ses goûts.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles a écrit :
Note toutefois que le suivi de connexion de
Netfilter a ses limites, sauf aide d'un module "helper" pour certains
protocoles particuliers.
[...]
Autre exemple, il ne sait pas reconnaître
tout seul la réponse à une requête TFTP (en UDP) car le port source dans
le paquet de réponse du serveur est différent du port destination dans
le paquet de requête du client. Pour des protocoles aussi courants que
Netbios et TFTP, il existe des modules "helpers"
De manière similaire à ce qui existe pour FTP (en TCP) pour les mêmes
raisons. Ok.
Plus ou moins, car TFTP est vraiment spécial. En FTP, du point de vue
réseau la connexion TCP de données est totalement indépendante de la
connexion TCP de contrôle. En TFTP c'est un peu bâtard : la réponse est
envoyée par le serveur depuis un port UDP source différent du port TFTP
ayant reçu la requête mais vers le même port UDP destination que le port
source utilisé par la requête du client. C'est d'ailleurs grâce à cette
particularité que le helper reconnaît la réponse.
([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre
de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien
n'est prévu pour le cas général.
Pour NetBios, je n'ai rien vu dans mon noyau 2.6.8. Je suppose que tu parles
du Netbios_ns apparu au 2.6.14 selon
http://www.plouf.fr.eu.org/bazar/netfilter/changements-netfilter-2.6.html
Oui, en effet. Finalement cette page aura au moins servi à quelqu'un
d'autre que moi. :-)
[...]
Oui, j'ai une gestion 'explicite' de l'ICMP actuellement
Moi aussi en fait : comme je suis un peu parano, je n'accepte pas tous
les types ICMP qui sont classés dans l'état RELATED mais seulement ceux
que je considère comme indispensables (destination unreachable, time
exceeded, parameter problem). Idem pour les ICMP classés NEW : seul echo
request (ping) est accepté. En revanche tous les ICMP classés
ESTABLISHED sont acceptés : s'ils sont dans cet état, c'est qu'ils ont
été sollicités, donc il n'y a pas de raison de les bloquer.
qui n'a donc pas lieu d'exister.
Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED.
Pour les autres états, c'est selon ses goûts.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Note toutefois que le suivi de connexion de Netfilter a ses limites, sauf aide d'un module "helper" pour certains protocoles particuliers.
[...]
Autre exemple, il ne sait pas reconnaître tout seul la réponse à une requête TFTP (en UDP) car le port source dans le paquet de réponse du serveur est différent du port destination dans le paquet de requête du client. Pour des protocoles aussi courants que Netbios et TFTP, il existe des modules "helpers"
De manière similaire à ce qui existe pour FTP (en TCP) pour les mêmes raisons. Ok.
Plus ou moins, car TFTP est vraiment spécial. En FTP, du point de vue réseau la connexion TCP de données est totalement indépendante de la connexion TCP de contrôle. En TFTP c'est un peu bâtard : la réponse est envoyée par le serveur depuis un port UDP source différent du port TFTP ayant reçu la requête mais vers le même port UDP destination que le port source utilisé par la requête du client. C'est d'ailleurs grâce à cette particularité que le helper reconnaît la réponse.
([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien n'est prévu pour le cas général.
Pour NetBios, je n'ai rien vu dans mon noyau 2.6.8. Je suppose que tu parles du Netbios_ns apparu au 2.6.14 selon http://www.plouf.fr.eu.org/bazar/netfilter/changements-netfilter-2.6.html
Oui, en effet. Finalement cette page aura au moins servi à quelqu'un d'autre que moi. :-)
[...]
Oui, j'ai une gestion 'explicite' de l'ICMP actuellement
Moi aussi en fait : comme je suis un peu parano, je n'accepte pas tous les types ICMP qui sont classés dans l'état RELATED mais seulement ceux que je considère comme indispensables (destination unreachable, time exceeded, parameter problem). Idem pour les ICMP classés NEW : seul echo request (ping) est accepté. En revanche tous les ICMP classés ESTABLISHED sont acceptés : s'ils sont dans cet état, c'est qu'ils ont été sollicités, donc il n'y a pas de raison de les bloquer.
qui n'a donc pas lieu d'exister.
Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED. Pour les autres états, c'est selon ses goûts.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
mouss
Le poulpe qui bloppe ! wrote:
Généralement, l'emploi de la cible LOG avec des --log-prefix avec un préfixe différent pour chaque chaine/table est pratique (à mon avis) pour définir ou ça coince.
Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc mais un routeur avec micronoyau linux. Et la seule memoire est une microflash et il ne me reste que tres tres peu de place.
Mais j'ai trouvé le probleme. Mon script commence par #!/bin/bash, et apparemment, le linux embarqué ne le supporte pas.
c'est malheureusement un mauvais reflexe linuxien assez courant...
Leçon: ne jamais utiliser #!/bin/bash. si on n'a pas besoin de sépcificités de bash, ça n'a aucun sens. et dans le cas contraire, y a de meilleurs langages (perl, python, ...).
En mettant #!/bin/sh à la place, le script est bien pris en compte, et il marche bien, donc je vous remercie beaucoup de votre aide.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le poulpe qui bloppe ! wrote:
Généralement, l'emploi de la cible LOG avec des --log-prefix avec un
préfixe
différent pour chaque chaine/table est pratique (à mon avis) pour
définir
ou ça coince.
Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc
mais
un routeur avec micronoyau linux. Et la seule memoire est une
microflash et
il ne me reste que tres tres peu de place.
Mais j'ai trouvé le probleme.
Mon script commence par #!/bin/bash, et apparemment, le linux embarqué
ne le
supporte pas.
c'est malheureusement un mauvais reflexe linuxien assez courant...
Leçon: ne jamais utiliser #!/bin/bash. si on n'a pas besoin de
sépcificités de bash, ça n'a aucun sens. et dans le cas contraire, y a
de meilleurs langages (perl, python, ...).
En mettant #!/bin/sh à la place, le script est bien pris en compte, et il
marche bien, donc je vous remercie beaucoup de votre aide.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Généralement, l'emploi de la cible LOG avec des --log-prefix avec un préfixe différent pour chaque chaine/table est pratique (à mon avis) pour définir ou ça coince.
Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc mais un routeur avec micronoyau linux. Et la seule memoire est une microflash et il ne me reste que tres tres peu de place.
Mais j'ai trouvé le probleme. Mon script commence par #!/bin/bash, et apparemment, le linux embarqué ne le supporte pas.
c'est malheureusement un mauvais reflexe linuxien assez courant...
Leçon: ne jamais utiliser #!/bin/bash. si on n'a pas besoin de sépcificités de bash, ça n'a aucun sens. et dans le cas contraire, y a de meilleurs langages (perl, python, ...).
En mettant #!/bin/sh à la place, le script est bien pris en compte, et il marche bien, donc je vous remercie beaucoup de votre aide.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles
Le Mercredi 04 Avril 2007 23:54, Franck Joncourt a écrit :
On Wed, Apr 04, 2007 at 11:24:49PM +0200, Pascal Hambourg wrote: > Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED. > Pour les autres états, c'est selon ses goûts.
De maniere generale, pour le suivi de connexion, cela se presente de la facon suivante :
## ICMP : echo-request/echo-reply : NEW > ESTABLISHED autres : NEW > RELATED
## TCP : NEW, RELATED, ESTABLISHED
## UDP : NEW, ESTABLISHED
Aurais-je faux ?
L'etat RELATED associé aux connexions TCP n'existe que grace aux modules de suivi de connexion conntrack specifiques.
Oui. Ce qui m'amène à me demander si on ne peut pas en dire autant à propos de l'UDP , et considérer donc que, dans le cas par exemple du TFTP cité par Pascal, RELATED puisse aussi s'appliquer en UDP aux paquets de la connexion 'retour' initiée par le serveur.
Je vois ce dernier comme la *dérivation* d'une connexion qualifiée comme ESTABLISHED. Vous voyez cela comment ?
Pas sans mes lunettes :D Le terme 'dérivation' me semble prêter à confusion; on peut penser à un dédoublement (1->1 devient 1->2) ou à un ManInTheMiddle (déviation).
Celà ne traduit pas pleinement à mon sens qu'il s'agit de "connexions" _distinctes_ qui sont *induites*(1) par la "connexion" initiale. Le terme connexion désigne ici plutôt un canal de communication s'il doit aussi être applicable pour l'udp.
La définition donnée sur le site de netfilter: [cite] RELATED
Un paquet qui est relaté a, mais pas partie de, une connection existante, comme une erreur ICMP, ou ( avec le module ftp chargé), un paquet qui etablit une connection de données ftp. [/cite]
(1) dépendantes, liées, subordonnées, apparentées (on retrouve 'rel ated' en anglais pour ce dernier)
-- Serge
Le Mercredi 04 Avril 2007 23:54, Franck Joncourt a écrit :
On Wed, Apr 04, 2007 at 11:24:49PM +0200, Pascal Hambourg wrote:
> Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED.
> Pour les autres états, c'est selon ses goûts.
De maniere generale, pour le suivi de connexion, cela se presente de la
facon suivante :
## ICMP :
echo-request/echo-reply : NEW > ESTABLISHED
autres : NEW > RELATED
## TCP :
NEW, RELATED, ESTABLISHED
## UDP :
NEW, ESTABLISHED
Aurais-je faux ?
L'etat RELATED associé aux connexions TCP n'existe que grace aux modules
de suivi de connexion conntrack specifiques.
Oui. Ce qui m'amène à me demander si on ne peut pas en dire autant à propos
de l'UDP , et considérer donc que, dans le cas par exemple du TFTP cité par
Pascal, RELATED puisse aussi s'appliquer en UDP aux paquets de la connexion
'retour' initiée par le serveur.
Je vois ce dernier comme la
*dérivation* d'une connexion qualifiée comme ESTABLISHED. Vous voyez
cela comment ?
Pas sans mes lunettes :D
Le terme 'dérivation' me semble prêter à confusion; on peut penser à un
dédoublement (1->1 devient 1->2) ou à un ManInTheMiddle (déviation).
Celà ne traduit pas pleinement à mon sens qu'il s'agit de "connexions"
_distinctes_ qui sont *induites*(1) par la "connexion" initiale. Le terme
connexion désigne ici plutôt un canal de communication s'il doit aussi être
applicable pour l'udp.
La définition donnée sur le site de netfilter:
[cite]
RELATED
Un paquet qui est relaté a, mais pas partie de, une connection
existante, comme une erreur ICMP, ou ( avec le module ftp chargé),
un paquet qui etablit une connection de données ftp.
[/cite]
(1) dépendantes, liées, subordonnées, apparentées (on retrouve 'rel ated' en
anglais pour ce dernier)
Le Mercredi 04 Avril 2007 23:54, Franck Joncourt a écrit :
On Wed, Apr 04, 2007 at 11:24:49PM +0200, Pascal Hambourg wrote: > Disons qu'il y a moyen de simplifier la gestion des ICMP ESTABLISHED. > Pour les autres états, c'est selon ses goûts.
De maniere generale, pour le suivi de connexion, cela se presente de la facon suivante :
## ICMP : echo-request/echo-reply : NEW > ESTABLISHED autres : NEW > RELATED
## TCP : NEW, RELATED, ESTABLISHED
## UDP : NEW, ESTABLISHED
Aurais-je faux ?
L'etat RELATED associé aux connexions TCP n'existe que grace aux modules de suivi de connexion conntrack specifiques.
Oui. Ce qui m'amène à me demander si on ne peut pas en dire autant à propos de l'UDP , et considérer donc que, dans le cas par exemple du TFTP cité par Pascal, RELATED puisse aussi s'appliquer en UDP aux paquets de la connexion 'retour' initiée par le serveur.
Je vois ce dernier comme la *dérivation* d'une connexion qualifiée comme ESTABLISHED. Vous voyez cela comment ?
Pas sans mes lunettes :D Le terme 'dérivation' me semble prêter à confusion; on peut penser à un dédoublement (1->1 devient 1->2) ou à un ManInTheMiddle (déviation).
Celà ne traduit pas pleinement à mon sens qu'il s'agit de "connexions" _distinctes_ qui sont *induites*(1) par la "connexion" initiale. Le terme connexion désigne ici plutôt un canal de communication s'il doit aussi être applicable pour l'udp.
La définition donnée sur le site de netfilter: [cite] RELATED
Un paquet qui est relaté a, mais pas partie de, une connection existante, comme une erreur ICMP, ou ( avec le module ftp chargé), un paquet qui etablit une connection de données ftp. [/cite]
(1) dépendantes, liées, subordonnées, apparentées (on retrouve 'rel ated' en anglais pour ce dernier)
