Re: [HS] iptables, DNS sur une machne du LAN
Serge Cavailles a écrit :
Le Mercredi 04 Avril 2007 23:54, Franck Joncourt a écrit :
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
Je ne suis pas certain de comprendre ce que signifie ce NEW > RELATED.
Il y a d'autres types ICMP avec un schéma requête/réponse que l'echo qui
doivent prendre les états NEW et ESTABLISHED : timestamp, information,
address mask...
Les types ICMP correspondant à des messages d'erreurs sont bien sûr dans
l'état RELATED quand ils sont liés à une "connexion" existante, mais ne
sont pas forcément émis en réponse à un paquet dans l'état NEW. Par
exemple : fragmentation needed pour un paquet ESTABLISHED trop gros
appartenant à une connexion déjà établie.
## TCP :
NEW, RELATED, ESTABLISHED
## UDP :
NEW, ESTABLISHED
On peut trouver des paquets RELATED en UDP aussi, ainsi que dans
d'autres protocoles de niveau 4 (couche transport). Je pense notamment
au tunnel GRE (protocole n° 41) des VPN PPTP.
L'etat RELATED associé aux connexions TCP n'existe que grace aux modules
de suivi de connexion conntrack specifiques.
Idem pour UDP et les autres protocoles de couche transport.
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 n'ai pas vérifié le cas de TFTP (ou bien c'était il y a longtemps et
j'ai oublié) mais ce serait logique. Même chose pour SIP, RTSP...
Je vois ce dernier comme la
*dérivation* d'une connexion qualifiée comme ESTABLISHED. Vous voyez
cela comment ?
Je ne suis pas certain de bien "voir" ce que tu veux dire.
Il faut que le paquet soit lié à une "connexion" *existante* (connue par
le suivi de connexion), pas forcément à une connexion établie (qui a
engendré du trafic dans les deux sens). Par exemple un ICMP port
unreachable en réponse à un TCP SYN ou une requête UDP (par exemple DNS)
qui sont dans l'état NEW sans qu'il y ait eu de connexion établie. Quand
l'état RELATED concerne une vraie connexion liée (connexion de données
en FTP, tunnel GRE en PPTP...) il remplace l'état NEW du premier paquet
de cette connexion.
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.
Les guillements sont de rigueur, particulièrement quand la "connexion"
est en fait un simple message d'erreur ICMP. C'est d'ailleurs le seul
type de paquet qui peut être classé dans l'état RELATED par le suivi de
connexion de base sans helper spécifique, car ICMP fait partie
intégrante de la suite TCP/IP.
La définition donnée sur le site de netfilter:
[cite]
RELATED
Un paquet qui est relaté
Quelle horreur ! A défaut de paquet "relaté", c'est au moins la
traduction qui est frelatée... ;-)
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]
La définition est bonne.
(1) dépendantes, liées, subordonnées, apparentées (on retrouve 'related' en
anglais pour ce dernier)
Moi j'aime bien "lié".
Reply to: