Outils Linux réseau

Diagnostic du réseau et outils d’audit : tcpdump, ping, traceroute, netstat, nslookup, dig.

1. Tcpdump

Tcpdump permet de capturer des paquets en console.

On conseillera la lecture de la page Manuel de Tcpdump : man tcpdump.

Par exemple :

tcpdump -ennqti eth0 \( arp or icmp \)

Pour écrire dans un fichier pcap :

tcpdump -ennqti eth0 \( arp or icmp \) -w arp-icmp.pcap

2. Commande ping

  • Commande système qui vérifie la connectivité d’une destination avec ICMP.
  • Commande active.
  • Génère des paquets ICMP Echo Request (type 8, code 0) en vue de vérifier la connectivité.
  • Attend des paquets ICMP de retour :
    • Au mieux des ICMP Echo Reply (type 0, code 0).
    • D’autres messages pourraient être reçus (Destination Unreachable, TTL exceeded, …). Des réponses d’erreurs pourraient revenir et indiquer la nature de l’erreur.
  • Par défaut, l’adresse IP source utilisée est celle de l’interface la plus proche de la destination.
  • Si son usage est abordé ici de manière succincte, la commande entre dans une démarche de diagnostic visant à notamment interpréter les informations qui reviennent (ou ne reviennent pas).

2.1. ping : vérification

Ping Détermine trois éléments :

  • Si une interface IP est active ou pas par ICMP, pour dire simplement.
  • Le délais des paquets
  • Le taux de perte des paquets

Ici la réception de quatre “echo reply” :

$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=9.31 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=9.41 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=9.34 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=51 time=9.41 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 9.317/9.371/9.417/0.080 ms

2.2. ping : interprétation

  • Le diagnostic s’arrête à ICMP et monte à la couche L7 en tentant de joindre des noms.
  • L’hôte de destination peut être configuré pour ne pas répondre à ces requêtes (pare-feu configuré traditionnellement)
  • Peut signifier un problème de routage dans le chemin (un routeur n’arrive pas à placer le paquet).
  • Un élément (pare-feu, proxy) peut filtrer ce trafic dans le chemin.
  • Les résultats de délais et de perte permettent de qualifier la qualité de la transmission. C’est utile pour diagnostiquer du trafic d’applications en temps réel (VoIP, streaming, jeux en ligne, …).

2.3. Connectivité IP globale

  • Vérification de la connectivité locale : vers la passerelle
  • Vérification de la connectivité globale vers une adresse IP globale bien connue :
    • En Belgique, les serveurs DNS de Belgacom : 195.238.2.21, 195.238.2.22
    • Les serveurs DNS IPv4 de Google : 8.8.8.8, 8.8.4.4

2.4. ping 8.8.8.8

Quel est le trafic généré par un ping 8.8.8.8 ?

aa:bb:cc:dd:ee:ff > ff:ff:ff:ff:ff:ff, ARP, length 42: Request who-has 10.185.220.95 tell 10.185.220.133, length 28
c8:d7:19:23:b6:bf > aa:bb:cc:dd:ee:ff, ARP, length 60: Reply 10.185.220.95 is-at c8:d7:19:23:b6:bf, length 46
aa:bb:cc:dd:ee:ff > c8:d7:19:23:b6:bf, IPv4, length 98: 10.185.220.133 > 8.8.8.8: ICMP echo request, id 14174, seq 1, length 64
c8:d7:19:23:b6:bf > aa:bb:cc:dd:ee:ff, IPv4, length 98: 8.8.8.8 > 10.185.220.133: ICMP echo reply, id 14174, seq 1, length 64

3. traceroute/tracert

Les commandes traceroute et tracert (Windows) permettent de détecter les routeurs entre la station d’origine et une destination.

3.1. tracert (Windows)

  • Le logiciel envoie trois messages ICMP echo request (type 8, code 0) avec un TTL de 1, puis de 2, et ainsi de suite.
  • Trois réponses sont attendues de la passerelle qui filtre le TTL à 1 : des messages ICMP “TTL Exceeded in Transit” avec des identifiers et Sequence Numbers correspondants.

3.2. traceroute (Linux)

  • Le logiciel envoie trois messages UDP avec un TTL de 1, puis de 2, et ainsi de suite. Chaque message est à destination d’un port UDP différent.
  • Trois réponses sont attendues de la passerelle intermédiaire qui filtre le TTL à 1 : des messages ICMP “TTL Exceeded in Transit” embarquant le message UDP original avec son port de destination. Les trois réponses sont représentées dans les trois délais de la sortie.

3.3. traceroute interprétation

  • Délais : Round Trip (RTT)
  • Délais : détermine la qualité des liaisons (congestion)
  • Délais : mais aussi la distance (propagation)
  • Adresses des interfaces d’entrées
  • Localisation
  • Fournisseur
  • A lier avec un whois
  • RAS Traceroute

3.4. traceroute : exemple

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  WDR3600-D3.lan (192.168.100.1)  3.299 ms  3.518 ms  3.434 ms
 2  88.147.32.1 (88.147.32.1)  27.768 ms  27.690 ms  36.957 ms
 3  88.147.95.13 (88.147.95.13)  36.936 ms  37.300 ms  37.230 ms
 4  ge-2-2-2-193.bru20.ip4.tinet.net (77.67.76.121)  37.154 ms  37.076 ms  37.059 ms
 5  xe-0-0-2.ams60.ip4.tinet.net (89.149.180.121)  42.757 ms  42.678 ms  43.997 ms
 6  as15169.ams60.ip4.tinet.net (141.136.102.246)  64.105 ms  60.201 ms  78.499 ms
 7  209.85.248.92 (209.85.248.92)  59.925 ms 209.85.248.112 (209.85.248.112)  34.158 ms  33.950 ms
 8  72.14.238.69 (72.14.238.69)  40.288 ms 209.85.253.249 (209.85.253.249)  64.905 ms  52.239 ms
 9  209.85.254.231 (209.85.254.231)  58.553 ms  59.042 ms  58.659 ms
10  209.85.255.51 (209.85.255.51)  64.564 ms 209.85.254.189 (209.85.254.189)  58.307 ms 216.239.49.30 (216.239.49.30)  58.246 ms
11  * * *
12  google-public-dns-a.google.com (8.8.8.8)  58.556 ms  58.716 ms  43.237 ms

4. Vérification des ports TCP/UDP

4.1. Commande netstat

  • netstat, pour « network statistics », est une ligne de commande affichant des informations sur les connexions réseau, les tables de routage et un certain nombre de statistiques dont ceux des interfaces, sans oublier les connexions masquées, les membres Multicast, et enfin, les messages netlink.
  • La commande est disponible sous Unix (et ses dérivés dont Linux) et sous Windows NT compatibles.

4.2. Commande ss

Les ports TCP IPv4/IPv6 à l’écoute :

ss -antp
State      Recv-Q Send-Q Local Address:Port               Peer Address:Port
LISTEN     0      128          *:22                       *:*                   users:(("sshd",pid=17454,fd=3))
LISTEN     0      128    127.0.0.1:631                      *:*                   users:(("cupsd",pid=834,fd=13))
LISTEN     0      100    127.0.0.1:25                       *:*                   users:(("master",pid=1359,fd=13))
LISTEN     0      128         :::80                      :::*                   users:(("httpd",pid=9932,fd=4),("httpd",pid=9931,fd=4),("httpd",pid=9930,fd=4),("httpd",pid=9929,fd=4),("httpd",pid=9928,fd=4),("httpd",pid=9925,fd=4))
LISTEN     0      128         :::22                      :::*                   users:(("sshd",pid=17454,fd=4))
LISTEN     0      128        ::1:631                     :::*                   users:(("cupsd",pid=834,fd=12))

Toutes les sessions :

ss -a

5. La résolution de noms

  • Dans le domaine des réseaux, la résolution de nom fait généralement référence au Domain Name System (DNS), service Internet qui associe des noms d’hôtes à leurs adresses IP;
  • la résolution de noms sur les réseaux peut aussi se faire grâce aux technologies suivantes :
  • WINS (Windows Internet Naming Service) pour les clients utilisant les noms NetBIOS. Samba peut aussi agir comme serveur WINS,
  • NIS Protocole permettant la centralisation d’information sur un réseau Unix. Notamment les noms d’hôtes (/etc/hosts) et les comptes utilisateurs (/etc/passwd).

5.1. Résolution locale

  • Le fichier hosts est un fichier utilisé par le système d’exploitation d’un ordinateur lors de l’accès à Internet. Son rôle est d’associer des noms d’hôtes à des adresses IP.
  • Lors de l’accès à une ressource réseau par nom de domaine, ce fichier est consulté avant l’accès au serveur DNS et permet au système de connaître l’adresse IP associée au nom de domaine sans avoir recours à une requête DNS.
  • Le fichier host est en texte brut et est usuellement nommé hosts. Les modifications sont prises en compte directement. Il est présent dans la plupart des systèmes d’exploitation.
  • Unix, Unix-like,POSIX dans /etc/hosts
  • Microsoft Windows %SystemRoot%\system32\drivers\etc\hosts

5.2. Domain Name System (DNS)

  • Le Domain Name System (ou DNS, système de noms de domaine) est un service permettant de traduire un nom de domaine en informations de plusieurs types qui y sont associées, notamment en adresses IP de la machine portant ce nom. À la demande de la DARPA, Jon Postel et Paul Mockapetris ont conçu le « Domain Name System » en 1983 et en écrivirent la première réalisation.
  • Ce fichier enregistre l’adresse des serveurs de résolution de nom :
cat /etc/resolv.conf

5.3. Domain Name System (DNS)

On ira lire utilement : https://fr.wikipedia.org/wiki/Domain_Name_System

  1. Rôle du DNS
  2. Histoire
  3. Un système hiérarchique et distribué
  4. Serveurs DNS racine
  5. Fully Qualified Domain Name
  6. Nom de domaine internationalisé
  7. Les techniques du DNS Round-Robin pour la distribution de la charge
  8. Principaux enregistrements DNS
  9. Time to live
  10. Glue records
  11. Mise à jour dynamique
  12. Considérations opérationnelles

5.4. nslookup

Commande Linux/Windows permettant de vérifier la résolution de noms.

6. dig

apt-get install dnsutils || yum install bind-utils

6.1. Usage de dig

dig www.google.com aaaa
; <<>> DiG 9.8.3-P1 <<>> www.google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54128
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.com.			IN	AAAA
;; ANSWER SECTION:
www.google.com.		63	IN	AAAA	2a00:1450:4001:801::1014
;; Query time: 123 msec
;; SERVER: 10.185.220.95#53(10.185.220.95)
;; WHEN: Wed May 21 15:04:24 2014
;; MSG SIZE  rcvd: 60

La valeur de la ligne Query time: des sorties de dig permet de se faire une idée des délais de résolution de nom. Ce délai est un indicateur de la qualité de la connexion Internet.

6.2. dig auprès d’un serveur spécifique

dig @8.8.8.8 www.google.com aaaa
; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.google.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62597
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.com.			IN	AAAA
;; ANSWER SECTION:
www.google.com.		296	IN	AAAA	2a00:1450:400c:c06::93
;; Query time: 45 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed May 21 15:05:33 2014
;; MSG SIZE  rcvd: 60

6.3. dig succint

dig google.com +nocomments +noquestion +noauthority +noadditional +nostats
dig +short

6.4. dig sur les champs MX

dig gmail.com  MX +noall +answer
; <<>> DiG 9.8.3-P1 <<>> gmail.com MX +noall +answer
;; global options: +cmd
gmail.com.		2909	IN	MX	5 gmail-smtp-in.l.google.com.
gmail.com.		2909	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
gmail.com.		2909	IN	MX	20 alt2.gmail-smtp-in.l.google.com.
gmail.com.		2909	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
gmail.com.		2909	IN	MX	40 alt4.gmail-smtp-in.l.google.com.

6.5. dig NS record

dig goffinet.org NS +noall +answer
; <<>> DiG 9.8.3-P1 <<>> goffinet.org NS +noall +answer
;; global options: +cmd
goffinet.org.		7200	IN	NS	ns4.zoneedit.com.
goffinet.org.		7200	IN	NS	ns19.zoneedit.com.

6.6. dig reverse lookup

dig -x 72.163.4.161
; <<>> DiG 9.8.3-P1 <<>> -x 72.163.4.161
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63459
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;161.4.163.72.in-addr.arpa.	IN	PTR
;; ANSWER SECTION:
161.4.163.72.in-addr.arpa. 300	IN	PTR	www1.cisco.com.
;; Query time: 192 msec
;; SERVER: 10.185.220.95#53(10.185.220.95)
;; WHEN: Wed May 21 15:15:20 2014
;; MSG SIZE  rcvd: 71

6.7. dig trace

dig +trace www.test.tf

6.8. Transfert de zone AXFR

Ne réaliser l’opération que sur des ressources autorisées !

dig zonetransfer.me
; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> zonetransfer.me
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39317
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;zonetransfer.me.        IN    A

;; ANSWER SECTION:
zonetransfer.me.    7200    IN    A    217.147.180.162

;; AUTHORITY SECTION:
zonetransfer.me.    86398    IN    NS    nsztm1.digi.ninja.
zonetransfer.me.    86398    IN    NS    nsztm2.digi.ninja.

;; Query time: 2923 msec
;; SERVER: 192.168.122.1#53(192.168.122.1)
;; WHEN: Sun Jan 17 17:44:30 CET 2016
;; MSG SIZE  rcvd: 112

dig axfr zonetransfer.me
; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> axfr zonetransfer.me
;; global options: +cmd
; Transfer failed.

dig axfr zonetransfer.me @nsztm1.digi.ninja

Ou encore via l’API de hackertarget.com : curl https://api.hackertarget.com/zonetransfer/?q=zonetransfer.me

7. Diagnostic fondamental

    1. Collecte d’information :
      • Connexion de l’interface (oui/non)
      • Adresse IP, masque, passerelle, serveur DNS, serveur DHCP (paramètres)
    1. Vérification :
      • Résolution de noms
      • Connectivité globale
      • Connectivité locale
      • Routage

7.1. Collecte d’information

Collecte d’information (Sorties type Windows)

Commandes :

ip link show
ip addr show
  • Le câble est-il branché ? problème physique/infrastructure
  • Y voit-on des paramètres TCP/IP ?
  • Comment sont-ils attribués ? Problème de configuration d’interface.

7.2. Vérifications

Vérifications (Sorties type Windows)
  • Résolution de nom : ping www.google.com
  • nslookup / dig
  • Connectivité globale : ping 8.8.8.8
  • réponse négative distante
  • réponse négative locale
  • pas de réponse
  • Connectivité locale : ping [passerelle]
  • Vérification du routage : ip route show / traceroute

8. Protocoles DHCP

8.1. Client DHCP

dhclient -4 -x
dhclient -6 -x
dhclient -4 -v
dhclient -6 -v