Product SiteDocumentation Site

10.9. Outils de diagnostic réseau

Lorsqu'une application réseau ne fonctionne pas comme on l'attend, il est important de pouvoir regarder de plus près ce qui se passe. Même lorsque tout semble fonctionner, il est utile de lancer des diagnostics sur le réseau, pour vérifier qu'il n'y a rien d'anormal. On dispose pour cela de plusieurs outils de diagnostic, qui opèrent à divers niveaux.

10.9.1. Diagnostic local : netstat

Citons tout d'abord la commande netstat (du paquet net-tools), qui affiche sur une machine un résumé instantané de son activité réseau. Invoquée sans arguments, cette commande se contente de lister toutes les connexions ouvertes. Or, cette liste est très vite verbeuse et indigeste. En effet, elle inclut aussi les connexions en domaine Unix, qui ne passent pas par le réseau mais sont très nombreuses sur un système standard, car utilisées par un grand nombre de démons.
On utilise donc généralement des options, qui permettent de modifier le comportement de netstat. Parmi les options les plus courantes, on trouve :
  • -t, qui filtre les résultats renvoyés pour que seules les connexions TCP soient listées ;
  • -u, qui fonctionne de la même manière mais pour les connexions UDP ; ces deux options ne s'excluent pas mutuellement et la présence des deux aura pour seul effet visible de masquer les connexions du domaine Unix ;
  • -a, qui liste également les sockets en écoute (en attente de connexions entrantes) ;
  • -n, qui affiche sous forme numérique les adresses IP (sans résolution DNS), les numéros de ports (et non leur alias tel que défini dans /etc/services) et les numéros d'utilisateurs (et non leur nom de connexion) ;
  • -p, qui affiche les processus mis en jeu ; cette option n'est réellement utile que lorsque netstat est invoqué par l'utilisateur root, faute de quoi seuls les processus appartenant au même utilisateur seront listés ;
  • -c, qui rafraîchit la liste des connexions en continu.
D'autres options (documentées dans la page de manuel netstat(8)) permettent de contrôler encore plus finement les résultats obtenus ; en pratique, on utilise si souvent la conjonction des cinq premières options que la commande netstat -tupan est quasiment devenue un réflexe chez les administrateurs systèmes et réseaux. Un résultat typique sur une machine peu active ressemble à ceci :
# netstat -tupan
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      397/rpcbind     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      431/sshd        
tcp        0      0 0.0.0.0:36568           0.0.0.0:*               LISTEN      407/rpc.statd   
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      762/exim4       
tcp        0    272 192.168.1.242:22        192.168.1.129:44452     ESTABLISHED 1172/sshd: roland [
tcp6       0      0 :::111                  :::*                    LISTEN      397/rpcbind     
tcp6       0      0 :::22                   :::*                    LISTEN      431/sshd        
tcp6       0      0 ::1:25                  :::*                    LISTEN      762/exim4       
tcp6       0      0 :::35210                :::*                    LISTEN      407/rpc.statd   
udp        0      0 0.0.0.0:39376           0.0.0.0:*                           916/dhclient    
udp        0      0 0.0.0.0:996             0.0.0.0:*                           397/rpcbind     
udp        0      0 127.0.0.1:1007          0.0.0.0:*                           407/rpc.statd   
udp        0      0 0.0.0.0:68              0.0.0.0:*                           916/dhclient    
udp        0      0 0.0.0.0:48720           0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:111             0.0.0.0:*                           397/rpcbind     
udp        0      0 192.168.1.242:123       0.0.0.0:*                           539/ntpd        
udp        0      0 127.0.0.1:123           0.0.0.0:*                           539/ntpd        
udp        0      0 0.0.0.0:123             0.0.0.0:*                           539/ntpd        
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:39172           0.0.0.0:*                           407/rpc.statd   
udp6       0      0 :::996                  :::*                                397/rpcbind     
udp6       0      0 :::34277                :::*                                407/rpc.statd   
udp6       0      0 :::54852                :::*                                916/dhclient    
udp6       0      0 :::111                  :::*                                397/rpcbind     
udp6       0      0 :::38007                :::*                                451/avahi-daemon: r
udp6       0      0 fe80::5054:ff:fe99::123 :::*                                539/ntpd        
udp6       0      0 2001:bc8:3a7e:210:a:123 :::*                                539/ntpd        
udp6       0      0 2001:bc8:3a7e:210:5:123 :::*                                539/ntpd        
udp6       0      0 ::1:123                 :::*                                539/ntpd        
udp6       0      0 :::123                  :::*                                539/ntpd        
udp6       0      0 :::5353                 :::*                                451/avahi-daemon: r
On y retrouve bien les connexions établies (ESTABLISHED), ici deux connexions SSH, et les applications en attente de connexion (LISTEN), notamment le serveur de messagerie Exim4 sur le port 25.

10.9.2. Diagnostic distant : nmap

nmap (du paquet éponyme) est en quelque sorte l'équivalent de netstat, mais s'utilise à distance. Il permet en effet de balayer un ensemble de ports classiques d'un ou plusieurs serveurs distants et de lister parmi ces ports ceux sur lesquels une application répond aux connexions entrantes. nmap est en outre capable d'identifier certaines de ces applications, parfois avec la version correspondante. La contrepartie de cet outil est que, comme il fonctionne à distance, il ne peut pas lister les connexions établies ni obtenir d'information sur les processus ou les utilisateurs ; en revanche, on peut le lancer sur plusieurs cibles en même temps.
Une utilisation typique de nmap utilise simplement l'option -A, qui déclenche les tentatives d'identification des versions des logiciels serveurs, suivie d'une ou plusieurs adresses ou noms DNS de machines à tester. Ici encore, de nombreuses options existent et permettent de contrôler finement le comportement de nmap ; on se référera à la documentation, dans la page de manuel nmap(1).
# nmap mirtuel

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:05 CET
Nmap scan report for mirtuel (192.168.1.242)
Host is up (0.000013s latency).
rDNS record for 192.168.1.242: mirtuel.internal.placard.fr.eu.org
Not shown: 998 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
111/tcp open  rpcbind

Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds
# nmap -A localhost

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:17 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000039s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 997 closed ports
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 7.9p1 Debian 10 (protocol 2.0)
| ssh-hostkey: 
|   2048 33:a1:d8:b1:e5:5b:b2:0d:15:1b:8e:76:7f:e4:d7:3d (RSA)
|   256 8f:83:cf:fa:b3:58:54:9a:1d:1b:4c:db:b1:e2:58:76 (ECDSA)
|_  256 fa:3d:58:62:49:92:93:90:52:fe:f4:26:ca:dc:4c:40 (ED25519)
25/tcp  open  smtp    Exim smtpd 4.92
| smtp-commands: mirtuel Hello localhost [127.0.0.1], SIZE 52428800, 8BITMIME, PIPELINING, CHUNKING, PRDR, HELP, 
|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA BDAT NOOP QUIT RSET HELP 
631/tcp open  ipp     CUPS 2.2
| http-methods: 
|_  Potentially risky methods: PUT
| http-robots.txt: 1 disallowed entry 
|_/
|_http-server-header: CUPS/2.2 IPP/2.1
|_http-title: Home - CUPS 2.2.10
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.10
Network Distance: 0 hops
Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.33 seconds
On retrouve bien les applications SSH et Exim4. Notez que toutes les applications n'écoutent pas sur toutes les adresses IP ; ainsi, comme Exim4 n'est accessible que sur l'interface de boucle locale lo, il n'apparaît que lors d'une analyse de localhost et non de mirtuel (l'interface réseau eth0 de la même machine).

10.9.3. Les sniffers : tcpdump et wireshark

Il arrive parfois que l'on ait besoin de voir ce qui passe réellement sur le réseau, paquet par paquet. On utilise dans ce cas un « analyseur de trame », plus connu sous le nom de sniffer (renifleur). Cet outil scrute tous les paquets qui atteignent une interface réseau et les affiche de manière plus lisible à l'utilisateur.
L'ancêtre dans ce domaine est sans conteste tcpdump (dans le paquet du même nom). Il est disponible en standard sur un très grand nombre de plates-formes et permet toutes sortes de captures de trafic réseau, mais la représentation de ce trafic reste assez obscure. Par conséquent, nous ne nous étendrons pas dessus.
Plus récent et plus moderne, l'outil wireshark (paquet wireshark) est devenu la référence dans l'analyse de trafic réseau, notamment grâce à ses nombreux modules de décodage qui permettent une analyse simplifiée des paquets capturés. La représentation graphique des paquets est en effet organisée par couches successives, ce qui permet de visualiser chacun des protocoles impliqués dans un paquet. Par exemple, pour un paquet correspondant à une requête HTTP, on verra de manière séparée les informations correspondant à la couche physique, la couche Ethernet, les informations du paquet IP, puis celles de la connexion TCP, puis enfin la requête HTTP en tant que telle. On pourra ainsi se focaliser sur une couche particulière.
Analyseur de trafic réseau wireshark

Figure 10.1. Analyseur de trafic réseau wireshark

In our example, the packets traveling over SSH are filtered out (with the !tcp.port == 22 filter). The packet currently displayed was developed at the transport layer of the SSHv2 protocol.