Depuis plus de deux ans, le projet Honeynet propose régulièrement
d'étudier des outils, des tactiques utilisés par des pirates lors
d'intrusion pour démontrer la réalité de ces attaques, pour apprendre
comment un pirate agit pour s'en protéger et plus généralement pour
améliorer les technologies et méthodes de collecte d'information.
Chaque mois, le Scan of the Month
challenge propose
l'analyse de trames réseaux suspectes. Cet article est inspiré du
Scan of the Month du mois de septembre
Scan23.
Il s'agit du premier challenge destiné aux débutants. Son but
est d'analyser les captures réseaux produits par un scan de port
afin de répondre aux questions suivantes
Pour collecter les paquets circulant sur un réseau, un sniffer est utilisé. La programmation de ces utilitaires de capture a été présentée dans un article de LinuxMag de septembre. Parmi les différentes méthodes, l'une d'entre elles est multiplateforme, il s'agit d'utiliser les fonctions de la librairie libpcap. Pcap est utilisé par des sniffers comme tcpdump, ethereal mais aussi des sondes de détection d'intrusion comme snort ou prelude. Ils ont tous la possibilité d'enregistré les événements réseaux dans un fichier de capture binaire.
Le fichier de capture de septembre est disponible à l'adresse
http://old.honeynet.org/scans/scan23/. Afin de garantir l'intégrité de ce fichier,
une signature éléctronique de ce fichier est aussi disponible sur le site.
Cette signature a été effectuée avec l'algorithme MD5, Message Digest
de la société RSA Data Security. Il ne reste plus qu'à comparer cette
signature de référence à la signature que l'on calcule à partir du fichier
récupéré avec la commande md5sum
.
[kmaster@christophe sotm23]$ md5sum sotm23.tar.gz 9d28c5ee9ce7b77e3099a07ad303811f sotm23.tar.gz
Attention, la somme MD5 garantie uniquement contre les corruptions accidentelles (par exemple, fichier tronqué). Si le serveur est piraté, l'archive peut être modifiée et le pirate n'a plus qu'à remplacer l'empreinte MD5 par la nouvelle valeur.
Un scan de port permet d'identifier les ports TCP ou UDP sur lesquelles une application réseau est à l'écoute. Un pirate utilise généralement un scanner de port dans la phase d'approche lorsqu'il prépare son attaque. C'est pourquoi les NIDS, sondes de détections d'intrusion réseau (cf dossier IDS: Détection d'intrusion de MISC 3), sont capables de les détecter. Soumettons la capture réseau au logiciel Snort http://www.snort.org, sans doute le NIDS le plus populaire, de plus sous licence GNU.
Snort est configuré via son fichier /etc/snort.conf de la façon suivante:
var HOME_NET any var EXTERNAL_NET any var SMTP $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var DNS_SERVERS $HOME_NET var RULE_PATH /etc/snort var SHELLCODE_PORTS !80 var HTTP_PORTS 80 var ORACLE_PORTS 1521 preprocessor frag2 preprocessor stream4: detect_scans, detect_state_problems preprocessor stream4_reassemble: both, ports all preprocessor http_decode: 80 -unicode -cginull preprocessor rpc_decode: 111 32771 preprocessor bo preprocessor telnet_decode preprocessor portscan: $HOME_NET 4 3 portscan.log output alert_syslog: LOG_AUTH LOG_ALERT output alert_unified: filename snort.alert, limit 128 include classification.config
et la totalité des règles est active
include $RULE_PATH/bad-traffic.rules ... include $RULE_PATH/info.rules include $RULE_PATH/icmp-info.rules include $RULE_PATH/virus.rules include $RULE_PATH/local.rules
Dans cette configuration, le préprocesseur portscan va être
utile pour détecter les scans TCP SYN et les scans UDP,
l'option detect_scans
du préprocesseur
stream4 active l'identification des scans furtifs.
Demandons à Snort d'analyser le fichier de log et d'afficher sur la console
les alertes.
snort -A console -llog -r 0826\@19-snort.log -c /etc/snort.conf
-*> Snort! <*- Version 1.8.7 (Build 128) By Martin Roesch (roesch@sourcefire.com, www.snort.org) 1603 Snort rules read... 1603 Option Chains linked into 176 Chain Headers 0 Dynamic rules +++++++++++++++++++++++++++++++++++++++++++++++++++ Rule application order: ->activation->dynamic->alert->pass->log 08/27-01:59:50.250759 [**] [1:469:1] ICMP PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] {ICMP} 192.168.0.9 -> 192.168.0.99 08/27-01:59:50.250837 [**] [1:408:4] ICMP Echo Reply [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.0.99 -> 192.168.0.9 09/14-15:40:03.499462 [**] [100:1:1] spp_portscan: PORTSCAN DETECTED from 192.168.0.9 (THRESHOLD 4 connections exceeded in 0 seconds) [**] 09/14-15:40:03.506090 [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 170 connections across 1 hosts: TCP(170), UDP(0) [**] ... 09/14-16:39:52.690139 [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 162 connections across 1 hosts: TCP(162), UDP(0) [**]
Demblé, les alertes nous apprennent que
Attention, les alertes de spp_portscan utilisent la date actuelle!
Observons avec la commande tcpdump
, les premiers paquets de la capture réseau.
tcpdump, http://www.tcpdump.org, est le sniffer
le plus répandu sous Unix. Il fonctionne en mode texte et est extrêmement rapide.
[kmaster@christophe sotm23]$ tcpdump -r 0826\@19-snort.log -n 01:59:50.250759 192.168.0.9 > 192.168.0.99: icmp: echo request 01:59:50.250837 192.168.0.99 > 192.168.0.9: icmp: echo reply 01:59:50.250803 192.168.0.9.52218 > 192.168.0.99.http: . ack 4094787819 win 2048 01:59:50.250878 192.168.0.99.http > 192.168.0.9.52218: R 4094787819:4094787819(0) win 0 (DF)
On peut réaliser la même chose avec tethereal
, le sniffer en mode texte de ethereal:
tethereal -r 0826\@19-snort.log -n
ethereal, http://www.ethereal.com, est un sniffer
disponible aussi bien sous Unix que sous Windows,
comme tcpdump d'ailleurs, qui a l'avantage de proposer une interface graphique
permettant d'analyser les paquets sur plusieurs niveaux et connaissant de
nombreux protocoles.
Remarque, tcpdump est bien plus rapide que ethereal car il applique un filtre de capture avec pcap. Tandis que ethereal "capture" la totalité des données puis applique un filtre de lecture ou d'affichage.
Nmap utilise deux méthodes pour vérifier que le serveur 192.168.0.99 est disponible: un ping ICMP et un ping TCP ACK sur le port 80 (http) par défaut. Recherchons les paquets ICMP echo-request, c'est à dire les paquets ICMP de type 8 et les paquets TCP avec le flag ACK, autrement dit flags=0x10.
[kmaster@christophe sotm23]$ tcpdump -r 0826\@19-snort.log -n "src ! 192.168.0.99 and (icmp[0]=8 or tcp[13]=0x10)" 01:59:50.250759 192.168.0.9 > 192.168.0.99: icmp: echo request 01:59:50.250803 192.168.0.9.52218 > 192.168.0.99.http: . ack 4094787819 win 2048 02:21:04.853059 192.168.0.9 > 192.168.0.99: icmp: echo request 02:21:04.853103 192.168.0.9.42314 > 192.168.0.99.http: . ack 2866936176 win 4096 02:21:38.723091 192.168.0.9.42304 > 192.168.0.99.ssh: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:21:38.723304 192.168.0.9.42306 > 192.168.0.99.tcpmux: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:23:17.506855 192.168.0.9 > 192.168.0.99: icmp: echo request 02:23:17.506900 192.168.0.9.58183 > 192.168.0.99.http: . ack 3623169759 win 1024 02:23:51.679297 192.168.0.9.58173 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:23:51.679512 192.168.0.9.58175 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:24:39.805309 192.168.0.9.40551 > 192.168.0.99.http: . ack 1401847552 win 1024 02:24:50.337389 192.168.0.9.34203 > 192.168.0.99.sunrpc: . ack 1288214714 win 5840 <nop,nop,timestamp 16917393 14921528> (DF) 02:24:51.037263 192.168.0.9.34398 > 192.168.0.99.http: . ack 1296081605 win 5840 <nop,nop,timestamp 16917463 14921598> (DF) 02:24:51.117254 192.168.0.9.34399 > 192.168.0.99.https: . ack 1296564949 win 5840 <nop,nop,timestamp 16917471 14921606> (DF) 02:24:52.417675 192.168.0.9.34800 > 192.168.0.99.ssh: . ack 1296230717 win 5840 <nop,nop,timestamp 16917601 14921736> (DF) 02:24:53.597612 192.168.0.9.35169 > 192.168.0.99.domain: . ack 1298205505 win 5840 <nop,nop,timestamp 16917719 14921854> (DF) 02:24:54.378018 192.168.0.9.40541 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:24:54.378205 192.168.0.9.40543 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:26:32.335638 192.168.0.1 > 192.168.0.99: icmp: echo request 02:26:32.335671 192.168.0.254 > 192.168.0.99: icmp: echo request 02:26:32.335700 192.168.0.199 > 192.168.0.99: icmp: echo request 02:26:32.335735 192.168.0.199 > 192.168.0.99: icmp: echo request 02:26:32.335785 192.168.0.1.35984 > 192.168.0.99.http: . ack 3438589941 win 3072 02:26:32.335790 192.168.0.254.35984 > 192.168.0.99.http: . ack 3438589941 win 3072 02:26:32.335840 192.168.0.9.35984 > 192.168.0.99.http: . ack 3438589941 win 3072 02:26:32.335870 192.168.0.199.35984 > 192.168.0.99.http: . ack 3438589941 win 3072
Syntaxe ethreal:
tethereal -r 0826\@19-snort.log -n "! ip.src eq 192.168.0.99 and (icmp.type eq 8 or tcp.flags eq 0x10)"
A 01:59:50, 02:21:04 et 02:23:17, on observe des pings ICMP et TCP ACK, à 02:24:39, un ping TCP ACK et à 02:26:32, des pings ICMP et TCP ACK provenant de plusieurs sources.
tcpslice -w s1.log "0" "02h21m04s853059u" 0826\@19-snort.log tcpslice -w s2.log "02h21m04s853059u" "02h23m17s506855u" 0826\@19-snort.log tcpslice -w s3.log "02h23m17s506855u" "02h24m39s805309u" 0826\@19-snort.log tcpslice -w s4.log "02h24m39s805309u" "02h26m32s335638u" 0826\@19-snort.log tcpslice -w s5.log "02h26m32s335638u" "23h" 0826\@19-snort.log
Nmap peut utiliser des leurres (option -g), ainsi la cible a l'impression de se faire scanner par plusieurs machines différentes.
08/27-02:26:42.655912 [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.1:35964 -> 192.168.0.99:1542 08/27-02:26:42.655918 [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.254:35964 -> 192.168.0.99:1542 08/27-02:26:42.655980 [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.9:35964 -> 192.168.0.99:1542 08/27-02:26:42.655995 [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.199:35964 -> 192.168.0.99:1542
Le TCP SYN scan consiste en l'envoi de paquets SYN comme pour initialiser des connexions TCP. Si le port destination du serveur est ouvert, il renvoie un Syn/Ack et dans le cas contraire, un paquet avec l'indicateur RST (reset).
09/14-16:44:48.031067 [**] [100:1:1] spp_portscan: PORTSCAN DETECTED from 192.168.0.9 (THRESHOLD 4 connections exceeded in 0 seconds) [**] 09/14-16:44:48.037698 [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 170 connections across 1 hosts: TCP(170), UDP(0) [**] 09/14-16:44:48.047311 [**] [100:2:1] spp_portscan: portscan status from 192.168.0.9: 205 connections across 1 hosts: TCP(205), UDP(0) [**]
Comment distinguer un TCP SYN scan d'un TCP connect scan ? Le TCP SYN scan se limite à l'envoi d'un paquet SYN forgé par le scanner tandis que le TCP connect scan utilise les fonctions de connections standard du système d'exploitation. De manière pratique, si on observe un paquet SYN suivi d'un paquet SYN/ACK, le scanner en mode SYN scan vient de détecter un port ouvert. Si un paquet ACK suit, il s'agit alors d'un scan TCP connect.
Pour repérer les TCP connect scan, sélectionnons les paquets TCP avec le flag ACK.
tcpdump -r ../sotm23/0826\@19-snort.log "tcp[13]=0x10" -n 01:59:50.250803 192.168.0.9.52218 > 192.168.0.99.http: . ack 4094787819 win 2048 TCP SYN Scan 02:21:04.853103 192.168.0.9.42314 > 192.168.0.99.http: . ack 2866936176 win 4096 NULL Scan 02:21:38.723091 192.168.0.9.42304 > 192.168.0.99.ssh: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> OSfingerprinting 02:21:38.723304 192.168.0.9.42306 > 192.168.0.99.tcpmux: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:23:17.506900 192.168.0.9.58183 > 192.168.0.99.http: . ack 3623169759 win 1024 XMAS Scan 02:23:51.679297 192.168.0.9.58173 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> OSfingerprinting 02:23:51.679512 192.168.0.9.58175 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:24:39.805309 192.168.0.9.40551 > 192.168.0.99.http: . ack 1401847552 win 1024 TCP connect Scan 02:24:50.337389 192.168.0.9.34203 > 192.168.0.99.sunrpc: . ack 1288214714 win 5840 <nop,nop,timestamp 16917393 14921528> (DF) 02:24:51.037263 192.168.0.9.34398 > 192.168.0.99.http: . ack 1296081605 win 5840 <nop,nop,timestamp 16917463 14921598> (DF) 02:24:51.117254 192.168.0.9.34399 > 192.168.0.99.https: . ack 1296564949 win 5840 <nop,nop,timestamp 16917471 14921606> (DF) 02:24:52.417675 192.168.0.9.34800 > 192.168.0.99.ssh: . ack 1296230717 win 5840 <nop,nop,timestamp 16917601 14921736> (DF) 02:24:53.597612 192.168.0.9.35169 > 192.168.0.99.domain: . ack 1298205505 win 5840 <nop,nop,timestamp 16917719 14921854> (DF) 02:24:54.378018 192.168.0.9.40541 > 192.168.0.99.ssh: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> OSfingerprinting 02:24:54.378205 192.168.0.9.40543 > 192.168.0.99.tcpmux: . ack 0 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> 02:26:32.335785 192.168.0.1.35984 > 192.168.0.99.http: . ack 3438589941 win 3072 XMAS Scan 02:26:32.335790 192.168.0.254.35984 > 192.168.0.99.http: . ack 3438589941 win 3072 02:26:32.335840 192.168.0.9.35984 > 192.168.0.99.http: . ack 3438589941 win 3072 02:26:32.335870 192.168.0.199.35984 > 192.168.0.99.http: . ack 3438589941 win 3072
On distingue 5 paquets avec des options TCP et un numéro d'acknowledge non nul. Entre 02:24:50 et 02:24:53, un scan TCP connect a eu lieu.
08/27-02:21:15.175153 [**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] {TCP} 192.168.0.9:42294 -> 192.168.0.99:1393
Le scanner envoie un paquet qui ne comporte aucun indicateur. Le système distant ignore le paquet si le port est ouvert et renvoie un paquet Reset dans le cas contraire.
Le scanner envoie un paquet qui ne comporte aucun indicateur. Le système distant ignore le paquet si le port est ouvert et renvoie un paquet Reset dans le cas contraire.
08/27-02:23:27.821221 [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.9:58163 -> 192.168.0.99:963
Lorsqu'un TCP SYN scan ou TCP connect scan a eu lieu, il suffit de sélectionner les paquets avec les indicateurs SYN/ACK
pour obtenir les ports ouverts. Pour cela, utilisons plaçons un filtre sur tcpdump ou ethereal
tethereal -r 0826\@19-snort.log -n "tcp.flags eq 0x12"
tcpdump -r 0826\@19-snort.log -n "tcp[13]=0x12"
[kmaster@christophe sotm23]$ tcpdump -r 0826\@19-snort.log "tcp[13]=0x12" -n|cut -d' ' -f 2|sort -u 192.168.0.99.domain 192.168.0.99.http 192.168.0.99.https 192.168.0.99.ssh 192.168.0.99.sunrpc 192.168.0.99.32768
Il est à priori plus difficile de remarquer quels sont les ports ouverts lors d'un scan furtif (XMAS, NULL), car il
faut rechercher les ports qui ne répondent pas! En réalité, ce n'est pas une difficulté car à la fin de son scan, Nmap
vérifie les résultats en recommençant un scan sur les ports qui n'ont pas répondu.
Même si les protocoles IP/TCP/UDP/ICMP sont normalisés, leurs implémentations sont différentes selon les systèmes d'exploitation. Dès lors, ils peuvent réagir différemment à certains paquets. Nmap va envoyer plusieurs paquets avec plusieurs combinaisons d'indicateurs (SYN,ACK,FIN,URG,PSH...) et de paramètres IP pour identifier le système d'exploitation distant.
Pour identifier le système d'exploitation distant, Nmap envoie différents paquets sur un port TCP ouvert et sur un port TCP fermé.
08/27-02:21:38.723091 [**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] {TCP} 192.168.0.9:42304 -> 192.168.0.99:22 08/27-02:21:38.723384 [**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] {TCP} 192.168.0.9:42307 -> 192.168.0.99:1 08/27-02:21:38.723549 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.0.99 -> 192.168.0.9 08/27-02:21:40.522698 [**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] {TCP} 192.168.0.9:42302 -> 192.168.0.99:22
Il constate s'il reçoit une réponse et si c'est le cas, il vérifie au niveau IP
T1(DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T4(DF=Y%W=0%ACK=O%Flags=R%Ops=) T5(DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(DF=Y%W=0%ACK=O%Flags=R%Ops=) T7(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
En recherchant dans le fichier nmap-os-fingerprints, la base de connaissance de Nmap, on trouve la signature suivante
Fingerprint Linux Kernel 2.4.0 - 2.5.20 TSeq(Class=RI%gcd=<8%SI=<2D870AA&>10000%IPID=Z|C|I|RD%TS=100HZ|U) T1(DF=Y%W=5B4|F98|1140|11AC|12CC|16A0|1680|2D244000|7E18|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=5B4|F98|1140|11AC|12CC|16A0|1680|2D24|4000|7E18|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW) T4(DF=Y%W=0%ACK=O%Flags=R%Ops=) T5(DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(DF=Y%W=0%ACK=O%Flags=R%Ops=) T7(DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(DF=Y|N%TOS=14|C0|0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E|F%UCK=E|F%ULEN=134%DAT=E)
Elle correspond parfaitement. Le système scanné est un Linux Kernel 2.4.0 - 2.5.20. Remarque, Nmap effectue d'autres tests (TSeq et PU) dont je n'ai pas traduis les résultats.
p0f, http://www.stearns.org/p0f/, a pour but d'identifier un système d'exploitation en observant les ouvertures de connexion réseaux. Il est passif, c'est à dire qu'il n'envoie aucun paquet, il se contente d'observer.
Le scan TCP connect utilise la fonction connect()
du système d'exploitation,
les paquets ne sont donc pas forgés ce qui laisse une chance d'identifier le système
d'exploitation à l'origine du scan.
[kmaster@christophe sotm23]$ p0f -s 0826\@19-snort.log|sort -u p0f: passive os fingerprinting utility, version 1.8.2 (C) Michal Zalewski <lcamtuf@gis.net>, William Stearns <wstearns@pobox.com> p0f: file: '/etc/p0f.fp', 150 fprints, iface: 'eth0', rule: 'all'. 192.168.0.9 [12 hops]: NMAP scan (distance inaccurate) (7) 192.168.0.9 [17 hops]: NMAP scan (distance inaccurate) (2) 192.168.0.9 [1 hops]: Linux 2.4.2 - 2.4.14 (1) 192.168.0.9 [21 hops]: NMAP scan (distance inaccurate) (2) 192.168.0.9 [26 hops]: NMAP scan (distance inaccurate) (11)
Bingo, la signature permet d'identifier un Linux avec un noyau 2.4, probablement 2.4.2 ou supérieur.
01:59:50 | Ping ICMP et TCP ACK |
02:00:00-02:20:35 | SYN scan |
02:21:04 | Ping ICMP et TCP ACK |
02:21:15-02:21:38 | TCP NULL scan |
02:21:38 | Nmap Fingerprint |
02:23:17 | Ping ICMP et TCP ACK |
02:23:27-02:23:51 | TCP XMAS scan |
02:23:51 | Nmap Fingerprint |
02:24:39 | Ping TCP ACK |
02:24:50-02:24:54 | TCP connect scan |
02:24:54 | Nmap Fingerprint |
02:26:32 | Ping ICMP et TCP ACK, sources multiples |
02:26:42-02:27:32 | TCP XMAS scan, sources multiples |
Les dix secondes entre le ping sweep et le début du scan sont dues à une tentative de résolution de nom infructueuse. Le premier scan est plus long que les autres car les 65000 ports ont été scannés. Aucun FIN scan, c'est dommage. Il s'agit d'une autre technique de scan à base de paquets avec l'indicateur FIN, indicateur servant à clore une connexion.