Introduction
Bienvenue dans ce laboratoire sur l'analyse du trafic réseau et l'accès à distance sécurisé sous Linux. Comprendre comment surveiller l'activité réseau et sécuriser les communications est une compétence essentielle pour tout administrateur système, développeur ou passionné de sécurité.
Dans ce laboratoire, vous acquerrez une expérience pratique avec une suite d'outils puissants en ligne de commande. Vous apprendrez à :
- Inspecter les connexions réseau actives et les services en écoute à l'aide de
netstatet de son successeur moderne,ss. - Capturer et analyser les paquets réseau en direct avec
tcpdump. - Établir une connexion à distance sécurisée à votre propre machine en utilisant
ssh. - Vérifier l'intégrité des réponses DNS à l'aide de
diget DNSSEC.
À la fin de ce laboratoire, vous aurez une compréhension pratique de ces utilitaires réseau essentiels et de leur rôle dans la gestion et la sécurisation d'un système Linux.
Inspecter les connexions réseau actives avec Netstat/SS
Dans cette étape, vous apprendrez à visualiser les connexions réseau actives et les ports en écoute sur votre système. Ceci est fondamental pour comprendre quels services sont en cours d'exécution et accessibles sur le réseau. Nous utiliserons deux outils courants : netstat et ss.
Tout d'abord, utilisons netstat, un utilitaire classique et bien connu. Le paquet net-tools, qui contient netstat, a été installé pour vous lors de la configuration du laboratoire.
Exécutez la commande suivante pour lister tous les ports TCP (-t) et UDP (-u) en écoute dans un format numérique (-n) sans résoudre les noms, en se concentrant uniquement sur les sockets en écoute (-l) :
netstat -tuln
Vous devriez voir une sortie similaire à celle-ci. Notez les entrées pour le serveur SSH (port 22) et le serveur web Python (port 8000) qui ont été démarrés pour vous, ainsi que des services supplémentaires sur les ports 3001 et 3002 :
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3002 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.11:37199 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
udp 0 0 127.0.0.11:60120 0.0.0.0:*
udp 0 0 0.0.0.0:3001 0.0.0.0:*
Maintenant, utilisons ss, qui est le remplacement moderne de netstat. Il est généralement plus rapide et fournit des informations plus détaillées. La commande et les options sont très similaires.
ss -tuln
La sortie sera légèrement différente en format, mais affichera les mêmes informations essentielles : les services en écoute sur les ports 22, 3001, 3002 et 8000, ainsi que certains services Docker internes :
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.11:60120 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:3002 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:8000 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.11:37199 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*
En utilisant ces commandes, vous pouvez rapidement obtenir un aperçu des services exposés par votre système sur le réseau.
Capturer le trafic réseau local avec Tcpdump
Dans cette étape, vous utiliserez tcpdump, un puissant analyseur de paquets en ligne de commande, pour capturer et inspecter le trafic réseau en temps réel. Ceci est inestimable pour le débogage des problèmes réseau ou pour comprendre le fonctionnement des protocoles.
Tout d'abord, voyons quelles interfaces réseau sont disponibles pour la capture de trafic.
sudo tcpdump -D
La sortie listera les interfaces disponibles. lo est l'interface "loopback" (boucle locale), utilisée pour la communication réseau au sein de la même machine (par exemple, la connexion à localhost). Vous verrez diverses interfaces, y compris l'interface réseau principale eth1 :
1.eth1 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]
Nous allons capturer le trafic sur l'interface de boucle locale (lo) pour voir les requêtes vers notre serveur web local. Pour ce faire, vous aurez besoin de deux terminaux.
Dans votre terminal actuel, exécutez la commande tcpdump suivante. Elle écoutera sur l'interface lo (-i lo) et s'arrêtera après avoir capturé 5 paquets (-c 5).
sudo tcpdump -i lo -c 5
Maintenant, cliquez sur l'icône + dans la barre d'onglets du terminal pour ouvrir un nouveau terminal. Dans ce nouveau terminal, générez du trafic réseau en effectuant une requête vers le serveur web local à l'aide de curl.
curl http://localhost:8000
Revenez à votre premier terminal. Vous verrez que tcpdump a capturé les paquets liés à votre requête curl. La sortie ressemblera à ceci, montrant la négociation TCP (handshake) et le transfert de données :
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:57:14.158058 IP localhost.57272 > localhost.8000: Flags [S], seq 2025143228, win 65495, options [mss 65495,sackOK,TS val 1006286113 ecr 0,nop,wscale 7], length 0
14:57:14.158072 IP localhost.8000 > localhost.57272: Flags [S.], seq 403368374, ack 2025143229, win 65483, options [mss 65495,sackOK,TS val 1006286113 ecr 1006286113,nop,wscale 7], length 0
14:57:14.158083 IP localhost.57272 > localhost.8000: Flags [.], ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
14:57:14.158129 IP localhost.57272 > localhost.8000: Flags [P.], seq 1:79, ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 78
14:57:14.158133 IP localhost.8000 > localhost.57272: Flags [.], ack 79, win 511, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
5 packets captured
24 packets received by filter
0 packets dropped by kernel
Notez que si vous exécutez tcpdump sans générer de trafic spécifique, vous pourriez voir des requêtes DNS en arrière-plan et d'autres communications système, comme indiqué dans vos journaux. C'est un comportement normal du système et cela démontre que même lorsque vous ne naviguez pas activement, votre système maintient diverses communications réseau.
Vous avez réussi à capturer et à visualiser le trafic réseau en direct.
Démontrer l'accès à distance sécurisé avec SSH
Dans cette étape, vous apprendrez à utiliser SSH (Secure Shell) pour un accès à distance sécurisé. Nous allons configurer l'authentification par clé, qui est plus sécurisée que l'utilisation de mots de passe, pour nous connecter à notre propre machine (localhost). Le openssh-server a déjà été démarré pour vous.
Tout d'abord, vous devez générer une paire de clés SSH (une clé privée et une clé publique). Nous allons créer une clé RSA avec une longueur de 2048 bits. L'option -f spécifie le fichier dans lequel enregistrer la clé, et -N "" définit une phrase secrète vide pour plus de commodité dans ce laboratoire.
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""
Cette commande crée id_rsa (votre clé privée) et id_rsa.pub (votre clé publique) dans le répertoire ~/.ssh.
Ensuite, pour permettre à votre propre utilisateur de se connecter en utilisant cette clé, vous devez ajouter la clé publique au fichier authorized_keys. Ce fichier liste toutes les clés publiques autorisées à se connecter.
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
Pour des raisons de sécurité, SSH exige des permissions strictes sur le répertoire .ssh et ses fichiers. Assurons-nous qu'elles sont correctement définies. Le script de configuration a déjà créé ces fichiers avec les bonnes permissions, mais il est bon de connaître ces commandes.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Tout est maintenant configuré. Vous pouvez tester la connexion sécurisée à localhost. La commande exécutera echo "Hello from SSH" à distance (sur votre propre machine) et affichera le résultat.
ssh labex@localhost 'echo "Hello from SSH"'
La première fois que vous vous connecterez, il vous sera peut-être demandé de vérifier l'empreinte digitale de l'hôte. Tapez yes et appuyez sur Entrée. Vous devriez ensuite voir la sortie de la commande echo.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Hello from SSH
Vous avez configuré et utilisé avec succès SSH pour une authentification sécurisée basée sur des clés.
Vérifier la résolution DNSSEC avec Dig
Dans cette étape, vous utiliserez dig (Domain Information Groper) pour effectuer des requêtes DNS et en apprendre davantage sur DNSSEC (DNS Security Extensions). DNSSEC aide à se protéger contre l'usurpation de DNS en ajoutant des signatures cryptographiques aux données DNS.
Tout d'abord, effectuons une requête DNS standard pour labex.io afin de voir son adresse IP.
dig labex.io
La sortie vous montrera les détails de la requête et, surtout, la ANSWER SECTION avec les enregistrements A (adresses IP). Notez que labex.io possède plusieurs adresses IP pour l'équilibrage de charge :
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9789
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 10 IN A 104.26.10.219
labex.io. 10 IN A 104.26.11.219
labex.io. 10 IN A 172.67.72.162
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:16 CST 2025
;; MSG SIZE rcvd: 85
Maintenant, effectuons la même requête mais demandons au résolveur DNS de fournir des données relatives à DNSSEC en ajoutant l'option +dnssec.
dig labex.io +dnssec
La sortie inclut des informations supplémentaires relatives à DNSSEC dans la OPT PSEUDOSECTION, indiquant que DNSSEC a été demandé (le drapeau do signifie "DNSSEC OK"). Cependant, notez que la section flags ne contient pas de drapeau ad (Authenticated Data) :
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1042
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 5 IN A 172.67.72.162
labex.io. 5 IN A 104.26.11.219
labex.io. 5 IN A 104.26.10.219
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:21 CST 2025
;; MSG SIZE rcvd: 108
L'absence du drapeau ad indique que, bien que des informations DNSSEC aient été demandées, le résolveur n'a pas pu valider les signatures ou que le domaine n'a pas DNSSEC activé.
Essayons un autre domaine bien connu qui utilise DNSSEC, icann.org, pour le voir à nouveau.
dig icann.org +dnssec
Là encore, inspectez l'en-tête dans la sortie :
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> icann.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;icann.org. IN A
;; ANSWER SECTION:
icann.org. 10 IN A 192.0.43.7
;; Query time: 72 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:26 CST 2025
;; MSG SIZE rcvd: 77
Comme pour la requête précédente, il n'y a pas de drapeau ad dans la réponse. Cela indique que le résolveur DNS dans cet environnement n'effectue pas la validation DNSSEC, ce qui est courant dans les environnements conteneurisés ou virtualisés où le résolveur DNS peut être configuré différemment d'un résolveur système standard.
Résumé
Félicitations pour avoir terminé le laboratoire ! Vous avez acquis une expérience pratique avec plusieurs outils essentiels de réseau et de sécurité sous Linux.
Dans ce laboratoire, vous avez appris à :
- Utiliser
netstatetsspour inspecter quels services réseau sont en cours d'exécution et écoutent les connexions. - Capturer des paquets réseau en direct sur une interface spécifique à l'aide de
tcpdumppour analyser le trafic. - Configurer et utiliser
sshavec authentification par clé pour un accès à distance sécurisé. - Utiliser
digpour interroger le système de noms de domaine (DNS) et comprendre les concepts de DNSSEC, y compris comment demander des informations DNSSEC et interpréter les résultats.
Ce sont des compétences fondamentales qui sont cruciales pour gérer, dépanner et sécuriser tout environnement Linux. Nous vous encourageons à continuer d'explorer les nombreuses options que ces outils puissants offrent.
