On Thu, Apr 05, 2007 at 10:28:43PM +0200, Pascal Hambourg wrote: > 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. Je pensais qu'il n'y avait que le echo-reply qui était qualifie de ESTABLISHED pour le protocol ICMP. Je ne me suis pas trop penche sur les types timestamp, information ... qui m'etaient jusque la inconnus =(! > >>## 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. Ok, je remets cela en ordre dans ma tete. De toute facon, je voulais savoir si j'avais bien compris ou non. Il me manquait un bout. > >>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. C'etait pas le mot approprie en effet. > 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. Donc on distingue en fait deux cas pour l'etat RELATED : - suite a une connexion existante mais non etablie (soit NEW), un message ICMP est envoye avec l'etat RELATED. - suite à une connexion etablie (ESTABLISHED), une nouvelle connexion est cree grace aux *helpers*. > >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... ;-) Cela ressemble a une tentative de traduction un peu loupee. Merci à vous deux pour avoir pose les choses de facon plus claires. -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
Attachment:
signature.asc
Description: Digital signature