🔬 Séance 2 : Wireshark — TLS, artefacts et rapport d'incident

B2 3h30 C2.3.3 SISR

Formation	BTS SIO option SISR — IRIS Mediaschool
Bloc	B2 — Réseaux et sécurité
Module	M2.3 — Sécurité des infrastructures
Compétences	B2.4 / Lien B3.4
Durée	3h30
Prérequis	Avoir complété la Séance 1

Introduction (10 min)

🏢 Contexte InnovatTech

Une exfiltration de données RH chez InnovatTech a été détectée rétrospectivement dans des pcaps archivés : un poste interne a transféré des fichiers via FTP vers une IP externe et les identifiants apparaissaient en clair dans les captures. Ce scénario illustre l'importance d'analyser TLS et flux applicatifs pour différencier une fuite accidentelle d'une exfiltration malveillante.

🎯 Objectifs de la séance

À l'issue de cette séance, vous serez capable de :

Analyser une négociation TLS depuis le ClientHello jusqu'au ChangeCipherSpec et repérer des ciphers faibles ou des anomalies SNI.
Reconstruire des flux TCP applicatifs (Follow TCP Stream), extraire des objets transférés et retrouver des credentials en clair (FTP/Telnet/HTTP).
Détecter des patterns d'attaque (scans Nmap, SYN flood, brute-force SSH) et produire un rapport d'incident synthétique au format InnovatTech (2 pages).

1. Analyse TLS (80 min)

Le protocole TLS démarre par une phase de négociation (handshake) visible sur le réseau (sauf si perfect forward secrecy empêche de déchiffrer le contenu). Les étapes observables sont :

ClientHello — liste des ciphers proposés et extensions (notamment SNI)
ServerHello — choix du cipher et annonce de la version
Certificate — envoi du certificat serveur
ServerKeyExchange — selon le mode choisi
ChangeCipherSpec — basculement vers le chiffrement
Application Data — données chiffrées

Examiner ces champs permet de détecter une négociation faible (ex : RC4, DES, MD5) ou des incompatibilités.

Extraction avec tshark

# Lister les ClientHello avec ciphers et SNI
tshark -r capture.pcap -Y "tls.handshake.type == 1" \
  -T fields \
  -e frame.number \
  -e ip.src \
  -e ip.dst \
  -e tls.handshake.version \
  -e tls.handshake.ciphersuite \
  -e tls.handshake.extensions_server_name

# Voir le détail complet d'un échange TLS (verbose)
tshark -r capture.pcap -Y "tls.handshake" -V | less

Ce que vous cherchez

Indicateur	Filtre / champ	Signification
Ciphers faibles	`tls.handshake.ciphersuite`	Présence de `RC4`, `DES` ou suites basées sur `MD5` → mise à jour nécessaire
SNI	`tls.handshake.extensions_server_name`	Nom de domaine demandé par le client ; utile pour corréler avec les certificats d'un reverse-proxy
Certificats	Paquet Certificate	Vérifier Subject, Issuer, dates de validité, chaîne de confiance — repérer certificats expirés ou auto-signés

💡 Astuce déchiffrement

Si vous disposez de la clé privée du serveur (cas pédagogique), Wireshark/tshark peut déchiffrer TLS pour inspection complète. En milieu réel, on s'appuie sur les métadonnées (ciphers, SNI, tailles, timings) pour enquêter sans jamais avoir accès à la clé.

2. Reconstruction de flux TCP et extraction d'artefacts (60 min)

Follow TCP Stream (GUI Wireshark)

Dans Wireshark, faire un clic droit sur un paquet TCP pertinent → Follow → TCP Stream. La vue fournie assemble les échanges dans les deux sens, propose un encodage (ASCII / HEX / Base64) et permet d'extraire le contenu HTTP/FTP/Telnet lisible.

Reconstruction en ligne de commande

# Reconstruire tous les flux en fichiers lisibles
sudo tcpflow -r capture.pcap -o ./flows

# Lister les fichiers extraits
ls flows/

# Isoler un flux spécifique par numéro de stream
tshark -r capture.pcap -Y "tcp.stream eq 12" -w stream12.pcap

Extraction d'identifiants en clair

Protocole	Filtre Wireshark	Ce qu'on cherche
FTP	`ftp.request.command`	Commandes `USER` et `PASS` en clair dans le flux reconstruit
Telnet	`tcp.port == 23`	Suivre le flux TCP du port 23 et lire l'ASCII reconstruit
HTTP	`http.authorization`	`Authorization: Basic` ou données POST en clair dans le corps d'une requête

Étapes pratiques (Follow TCP Stream)

Filtrer la connexion suspecte : tcp.stream eq 12
Clic droit sur un paquet → Follow → TCP Stream
Sélectionner Show and save as raw pour enregistrer le contenu brut
Analyser le contenu ASCII pour repérer credentials, requêtes et réponses

Export d'objets HTTP (GUI)

Wireshark GUI → File → Export Objects → HTTP → sélectionner et sauvegarder les fichiers transférés. On peut également utiliser NetworkMiner ou foremost sur les fichiers extraits par tcpflow.

3. Détection d'anomalies et patterns d'attaque (30 min)

Scans Nmap

Un scan se repère par une rafale de SYNs vers une gamme de ports depuis la même IP sur une courte fenêtre temporelle. Filtre pour isoler les SYNs initiaux :

tcp.flags.syn==1 && tcp.flags.ack==0

SYN Flood

Grand nombre de SYNs sans handshake achevé (peu de SYN/ACKs ou d'ACKs correspondants). Corréler avec :

tcp.analysis.retransmission — retransmissions excessives côté serveur
tcp.analysis.lost_segment — segments manquants signalés

Brute-force SSH

Forte fréquence de tentatives vers le port 22 : SYNs rapprochés suivis de courtes sessions immédiatement refusées (RST ou échange rapide). Filtre d'analyse :

tcp.port == 22 && tcp.flags.syn==1

⚠️ Pour chaque pattern, documenter systématiquement :

IP source et destination
Rythme (paquets/sec)
Plage de ports ciblés
Réponse de la cible (RST / ICMP unreachable / SYN-ACK)

4. Rapport d'analyse incident réseau (30 min)

Un bon rapport InnovatTech (2 pages) contient les sections suivantes :

Section	Contenu attendu
1. Résumé exécutif	1–2 paragraphes décrivant l'incident, son impact potentiel et les actions immédiates prises
2. Chronologie	Horodatages précis et numéros de trames importantes (t=0 scan, t=+2min transfert FTP…)
3. Artefacts identifiés	Pcap, fichiers extraits, captures d'écran Follow TCP Stream — avec hash MD5/SHA256
4. Sources et destinations	IPs, noms d'hôtes (ex : 192.168.30.5 debian-srv02) et rôles dans l'incident
5. Analyse technique	Cause racine, preuves, capture filtrée, protocoles impliqués
6. Recommandations	Opérationnelles et priorisées : bloquer, patcher, activer TLS, forcer MFA
Annexes	Commandes utilisées, filtres Wireshark/tshark, trames clés numérotées

Exemple de chronologie condensée

t=0      : Scan Nmap SYN depuis 10.0.0.42 → plage 192.168.30.0/24
t=+1m12s : Connexion FTP depuis 10.0.0.42 → 192.168.30.5:21
t=+1m14s : Commandes USER ftpuser / PASS s3cr3t en clair (trames #1482, #1483)
t=+1m20s : Transfert fichier rh_export_2024.csv (512 kB, trames #1490–#1620)
t=+3m05s : Multiples retransmissions TCP détectées (tcp.analysis.retransmission)

💡 Règle des 3P

Preuves (numéros de trames), Priorisation (criticité de chaque recommandation) et Précision (horodatages à la seconde) sont les trois piliers d'un rapport d'incident professionnel.

💻 Travaux Pratiques — TP S2 (90 min)

🏢 Contexte

Vous êtes technicien chez InnovatTech. Sur la DMZ, debian-srv02 (192.168.30.5) héberge des services web. Vous devez capturer 5 minutes de trafic pendant que le formateur simule des connexions (curl, navigation, tests TLS) et produire un rapport de 2 pages.

Objectif

Capturer le trafic de debian-srv02 pendant 5 minutes, analyser la négociation TLS des connexions observées, reconstruire un flux HTTP choisi, extraire un objet transféré et produire un rapport d'incident synthétique (format InnovatTech, 2 pages).

Étape 1 — Capture (5 minutes)

# Capturer 5 minutes de trafic pour debian-srv02
sudo timeout 300 tcpdump -i eth0 host 192.168.30.5 -w debian-srv02-5min.pcap

Étape 2 — Analyse TLS

# Lister les handshakes TLS : SNI et ciphers
tshark -r debian-srv02-5min.pcap -Y "tls.handshake" \
  -T fields \
  -e frame.number \
  -e ip.src \
  -e ip.dst \
  -e tls.handshake.ciphersuite \
  -e tls.handshake.extensions_server_name

Relever : ClientHello proposés, cipher retenu par le serveur, présence d'un certificat auto-signé ou expiré.

Étape 3 — Reconstruction d'un flux HTTP

Ouvrir le pcap dans Wireshark, repérer une connexion HTTP et faire Right-click → Follow → TCP Stream. Sauvegarder le contenu ASCII et repérer les en-têtes Content-Type et le corps du message.

Étape 4 — Extraction d'un objet

Si l'objet est transféré via HTTP :

GUI : Wireshark → File → Export Objects → HTTP → sauvegarder le fichier
CLI : tcpflow -r debian-srv02-5min.pcap -o ./flows puis identifier le fichier correspondant

tcpflow -r debian-srv02-5min.pcap -o ./flows
ls flows/
# Calculer le hash pour l'annexer au rapport
sha256sum flows/192.168.030.005.00080-*.raw

Étape 5 — Rédiger le rapport InnovatTech (2 pages)

Le rapport doit contenir :

Résumé exécutif (max 5 lignes)
Chronologie des événements avec horodatages précis
Artefacts extraits (nom de fichier + hash MD5/SHA256)
Analyse technique (cause, impact)
Recommandations immédiates (bloquer IP, désactiver FTP, forcer HTTPS)

📋 Livrable attendu

Le fichier debian-srv02-5min.pcap (ou un lien vers)
L'objet extrait (nom + hash SHA-256)
Un rapport de 2 pages (PDF ou Markdown) respectant la structure InnovatTech

✅ Critères de réussite

Le rapport contient une chronologie précise avec les numéros de trames supportant l'analyse
L'objet demandé est correctement extrait et son intégrité vérifiée (hash)
Les recommandations sont actionnables et priorisées (court / moyen / long terme)

🔖 Synthèse (10 min)

Cette séance a montré que :

La négociation TLS, même chiffrée, laisse des métadonnées exploitables (ciphers, SNI, certificats) permettant d'orienter une enquête.
La reconstruction de flux (Follow TCP Stream, tcpflow) permet de récupérer artefacts et identifiants en clair sur les protocoles non chiffrés.
Ces éléments se synthétisent dans un rapport d'incident opérationnel structuré, traçable et actionnable.

🧠 Question de vérification

En une phrase, que vous indique la présence d'un SNI dans un ClientHello TLS ?

📅 Cours suivant

C2.3.4 — Scan et audit de vulnérabilités : Nmap avancé, méthodologie CVSS et OpenVAS pour compléter l'approche d'analyse de sécurité.

🎮 Quiz — Testez vos connaissances

📝 Afficher les corrections

B) La liste des suites cryptographiques proposées et les extensions (dont le SNI) — Le ClientHello est le premier message TLS ; il contient la liste des ciphers que le client supporte, les extensions (notamment le SNI qui indique le nom de domaine ciblé) et un nombre aléatoire pour la dérivation des clés. Il ne contient pas encore de certificat ni de clé de session.
Vrai — tcpflow réassemble les flux TCP et écrit chaque flux dans un fichier séparé nommé d'après les IPs et ports source/destination, permettant une lecture directe du contenu applicatif.
C) tcp.flags.syn==1 && tcp.flags.ack==0 — Un SYN sans ACK correspond à l'initiation d'une connexion TCP. Une rafale de tels paquets depuis la même IP vers de nombreux ports distincts est la signature caractéristique d'un scan SYN (half-open scan) tel que celui réalisé par Nmap avec l'option -sS.
A) FTP — FTP (RFC 959) transmet les identifiants en clair sur le port 21 dans la session de contrôle. SFTP les chiffre via SSH, FTPS les protège avec TLS, et HTTPS encode en Base64 mais sur un canal chiffré. Trouver USER / PASS en ASCII dans un flux pcap indique donc du FTP non sécurisé.
D) Le nom du fichier et son hash cryptographique (MD5 ou SHA-256) — Le hash garantit que le fichier n'a pas été modifié depuis son extraction. C'est une exigence de la chaîne de custody numérique : sans hash, la valeur probante de l'artefact peut être contestée lors d'une procédure ou d'un audit.

← C2.3.3 Séance 1 — Capture et filtres TCP C2.3.4 Séance 1 — Nmap et méthodologie CVSS →