Network Traffic Monitoring
Apprends a capturer, analyser et interpreter le trafic reseau pour detecter les menaces et les comportements suspects en tant qu'analyste SOC.
- Comprendre les methodes de capture de paquets (TAP, SPAN, inline)
- Maitriser les bases de Wireshark et tcpdump
- Analyser les flux avec NetFlow/IPFIX
- Detecter les anomalies et patterns suspects dans le trafic
- Identifier les protocoles utilises pour l'exfiltration de donnees
🔍 15.1 — Capture de paquets (Packet Capture)
La capture de paquets est la premiere etape de l'analyse du trafic reseau. Elle consiste a intercepter et enregistrer les paquets qui transitent sur un reseau pour les examiner ulterieurement.
Imagine un poste de peage sur une autoroute. Chaque voiture (paquet) qui passe est photographiee et enregistree : plaque d'immatriculation (IP source), destination, contenu du coffre (payload). La capture de paquets, c'est ce systeme de surveillance applique au trafic reseau.
Pourquoi capturer le trafic ?
- Detection d'intrusions : identifier les tentatives d'attaque en temps reel
- Forensics : analyser un incident apres coup pour comprendre ce qui s'est passe
- Troubleshooting : diagnostiquer des problemes de performance ou de connectivite
- Compliance : prouver la conformite aux politiques de securite
- Threat hunting : rechercher proactivement des menaces cachees
Ou capturer ? Les methodes de capture
Network TAP (Test Access Point)
Un dispositif physique place entre deux points du reseau qui copie tout le trafic sans l'alterer.
- Avantages : capture 100% du trafic, pas de perte de paquets, invisible pour le reseau
- Inconvenients : cout materiel, necessite un acces physique, point unique de capture
- Usage : environnements critiques ou la fiabilite de capture est essentielle
SPAN / Mirror Port (Port Mirroring)
Fonctionnalite du switch qui copie le trafic d'un ou plusieurs ports vers un port de destination dedie a l'analyse.
- Avantages : pas de materiel supplementaire, configuration flexible, peut surveiller plusieurs ports
- Inconvenients : peut perdre des paquets sous forte charge, consomme des ressources du switch
- Usage : monitoring courant en entreprise, alimentation d'un IDS/IPS
Inline Capture
L'outil de capture est place directement dans le chemin du trafic (entre deux segments reseau).
- Avantages : peut bloquer le trafic malveillant en temps reel (IPS), voit 100% du trafic
- Inconvenients : point de defaillance unique (SPOF), ajoute de la latence
- Usage : IPS (Intrusion Prevention System), firewalls, WAF
Full Packet Capture vs NetFlow
| Critere | Full Packet Capture (PCAP) | NetFlow / IPFIX |
|---|---|---|
| Donnees capturees | Tout le paquet (headers + payload) | Metadonnees des flux uniquement |
| Volume de stockage | Tres eleve (Go/To par jour) | Faible (resumé des flux) |
| Analyse du contenu | Oui (on peut lire le payload) | Non (pas de contenu) |
| Performance | Impact eleve sur le reseau/stockage | Impact minimal |
| Cas d'usage | Forensics, analyse detaillee | Vue d'ensemble, detection d'anomalies |
| Analogie | Filmer chaque voiture en HD | Compter les voitures par type et direction |
🦈 15.2 — Wireshark : l'analyseur de paquets
Wireshark est l'outil d'analyse de paquets le plus utilise au monde. C'est un analyseur de protocoles graphique, open source, qui permet de capturer et d'examiner le trafic reseau en temps reel ou a partir de fichiers PCAP.
Wireshark, c'est comme un microscope pour le reseau. La ou l'oeil nu ne voit que "Internet marche" ou "Internet ne marche pas", Wireshark te montre chaque paquet, chaque octet, chaque echange entre les machines.
Interface de Wireshark
Zone en haut ou tu tapes les filtres pour isoler le trafic qui t'interesse. Ex : ip.addr == 192.168.1.1
Chaque ligne = un paquet capture, avec le numero, le temps, les IP source/destination, le protocole et un resume.
Arborescence detaillant chaque couche du paquet selectionne : Ethernet, IP, TCP/UDP, Application (HTTP, DNS...).
Representation hexadecimale et ASCII du paquet. Utile pour l'analyse forensique approfondie.
Filtres d'affichage essentiels (Display Filters)
| Filtre | Description | Exemple |
|---|---|---|
ip.addr == x.x.x.x | Trafic depuis ou vers une IP | ip.addr == 10.0.0.5 |
ip.src == x.x.x.x | Trafic depuis une IP source | ip.src == 192.168.1.100 |
ip.dst == x.x.x.x | Trafic vers une IP destination | ip.dst == 8.8.8.8 |
tcp.port == n | Trafic TCP sur un port specifique | tcp.port == 443 |
udp.port == n | Trafic UDP sur un port specifique | udp.port == 53 |
http | Tout le trafic HTTP | http.request.method == "GET" |
dns | Tout le trafic DNS | dns.qry.name contains "evil" |
tcp.flags.syn == 1 | Paquets SYN (debut de connexion) | tcp.flags.syn == 1 && tcp.flags.ack == 0 |
frame.len > n | Paquets de taille superieure a n octets | frame.len > 1500 |
!(arp || dns) | Exclure certains protocoles | !broadcast |
&& (ET), || (OU) et ! (NON) pour combiner les filtres.
Exemple : ip.addr == 10.0.0.5 && tcp.port == 80 montre le trafic HTTP vers/depuis 10.0.0.5.
Filtres de capture (Capture Filters)
Les filtres de capture utilisent la syntaxe BPF (Berkeley Packet Filter) et sont appliques avant la capture. Ils limitent ce qui est enregistre pour economiser les ressources.
| Filtre BPF | Description |
|---|---|
host 192.168.1.1 | Capture le trafic depuis/vers cette IP |
net 10.0.0.0/24 | Capture le trafic d'un sous-reseau |
port 80 | Capture le trafic sur le port 80 |
tcp | Capture uniquement le trafic TCP |
not port 22 | Exclut le trafic SSH |
Follow TCP Stream
Fonctionnalite puissante de Wireshark : clic droit sur un paquet TCP puis Follow > TCP Stream. Cela reconstitue l'integralite de la conversation entre deux machines, comme si tu lisais un chat en direct.
💻 15.3 — tcpdump : capture en ligne de commande
tcpdump est l'outil de capture de paquets en ligne de commande le plus utilise sur Linux/Unix. Leger, rapide et puissant, il est present sur la majorite des systemes et est essentiel pour tout analyste SOC.
Si Wireshark est un microscope avec ecran HD, tcpdump est une loupe de terrain. Moins joli, mais toujours disponible, rapide a deployer et parfait pour capturer sur des serveurs distants ou on n'a pas d'interface graphique.
Commandes essentielles
| Commande | Description |
|---|---|
tcpdump -i eth0 | Capturer sur l'interface eth0 |
tcpdump -i any | Capturer sur toutes les interfaces |
tcpdump -c 100 | Capturer 100 paquets puis s'arreter |
tcpdump -w capture.pcap | Ecrire la capture dans un fichier PCAP |
tcpdump -r capture.pcap | Lire un fichier PCAP existant |
tcpdump -n | Ne pas resoudre les noms (plus rapide) |
tcpdump -v / -vv / -vvv | Niveaux de verbosity croissants |
tcpdump -X | Afficher le contenu en hex et ASCII |
tcpdump -A | Afficher le contenu en ASCII uniquement |
Syntaxe BPF (Berkeley Packet Filter)
tcpdump utilise la meme syntaxe BPF que les filtres de capture de Wireshark :
tcpdump host 192.168.1.1 — trafic depuis/vers cette IP
tcpdump src host 10.0.0.5 — trafic depuis cette IP source
tcpdump dst host 8.8.8.8 — trafic vers cette IP destination
tcpdump port 80 — trafic sur le port 80 (HTTP)
tcpdump tcp port 443 — trafic TCP sur le port 443 (HTTPS)
tcpdump udp port 53 — trafic DNS (UDP 53)
tcpdump portrange 1-1024 — trafic sur les ports 1 a 1024
tcpdump host 10.0.0.5 and port 80 — trafic HTTP d'un hote specifique
tcpdump src net 192.168.1.0/24 and dst port 443 — HTTPS sortant du LAN
tcpdump not port 22 and not port 53 — exclure SSH et DNS
Operateurs : and, or, not (ou &&, ||, !)
Detecter des SYN scans :
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'
Capturer le trafic DNS pour analyse :
tcpdump -i eth0 -w dns_capture.pcap udp port 53
Surveiller les connexions vers un C2 suspect :
tcpdump -i eth0 -nn host 203.0.113.66 -w suspect.pcap
Capturer les paquets ICMP (ping, tunneling) :
tcpdump -i eth0 icmp -vv
📊 15.4 — NetFlow / IPFIX : l'analyse des flux
NetFlow (developpe par Cisco) et IPFIX (Internet Protocol Flow Information Export, la version standardisee) sont des protocoles qui collectent des metadonnees sur le trafic reseau sous forme de flux (flows).
Si la capture de paquets (PCAP) est une camera de surveillance qui filme tout en detail, NetFlow est le registre du gardien qui note : "a 14h32, une voiture rouge (IP source) est allee de la porte A (port source) a la porte B (port destination), elle est restee 5 minutes et a transporte 2 tonnes de marchandises (bytes)." On ne voit pas le contenu, mais on sait qui, quand, ou et combien.
Donnees collectees par un flux NetFlow
| Champ | Description | Interet pour le SOC |
|---|---|---|
| Source IP | Adresse IP de l'emetteur | Identifier l'origine du trafic |
| Destination IP | Adresse IP du destinataire | Identifier la cible ou le serveur C2 |
| Source Port | Port source | Identifier le type de service client |
| Destination Port | Port destination | Identifier le service accede (80, 443, 53...) |
| Protocol | TCP, UDP, ICMP... | Detecter des protocoles inattendus |
| Bytes | Volume de donnees echangees | Detecter l'exfiltration (volumes anormaux) |
| Packets | Nombre de paquets dans le flux | Identifier les scans (beaucoup de paquets, peu de donnees) |
| Timestamps | Debut et fin du flux | Correlations temporelles, detection de beaconing |
| TCP Flags | Drapeaux TCP observes | Identifier SYN floods, RST attacks |
| ToS / DSCP | Type of Service | Detecter la manipulation de priorite |
Outils d'analyse NetFlow
nfdump / nfsen
nfdump est un outil en ligne de commande pour lire et filtrer les donnees NetFlow. nfsen est son interface web.
nfdump -r nfcapd.202601 -s srcip/bytes: Top des IP sources par volumenfdump -r nfcapd.202601 'dst port 53 and bytes > 10M': Flux DNS anormalement grosnfdump -r nfcapd.202601 -s dstport/flows: Top des ports destination par nombre de flux
ntopng
Interface web d'analyse de trafic en temps reel. Permet de visualiser les flux, detecter les anomalies et generer des alertes.
- Dashboard temps reel avec graphiques
- Detection automatique d'anomalies
- Analyse par hote, protocole, application
- Alertes configurables (seuils, comportements)
Integration SIEM
Les donnees NetFlow sont souvent injectees dans un SIEM (Security Information and Event Management) comme Splunk, Elastic SIEM ou QRadar pour :
- Correlations avec d'autres sources de logs (firewall, IDS, endpoints)
- Dashboards personnalises pour le SOC
- Regles de detection automatisees
- Investigation sur de longues periodes (retention)
🎯 15.5 — Analyse de trafic reseau : detecter les anomalies
L'analyse de trafic reseau (Network Traffic Analysis, NTA) consiste a surveiller le trafic pour etablir un comportement normal (baseline) et detecter les ecarts qui pourraient indiquer une attaque.
Etablir une baseline
La baseline, c'est comme connaitre le rythme cardiaque normal d'un patient. Si le coeur bat normalement a 70 bpm et qu'il monte soudainement a 180 bpm sans raison, le medecin sait qu'il y a un probleme. Pareil pour le reseau : si le trafic DNS est habituellement de 500 Mo/jour et qu'il passe a 50 Go, c'est une alerte.
Elements a mesurer pour la baseline :
- Volume de trafic par protocole et par heure/jour
- Top des destinations (internes et externes)
- Distribution des ports utilises
- Duree moyenne des sessions
- Ratio upload/download par segment
Patterns suspects a detecter
Un malware contacte regulierement un serveur de commande et controle (C2) a intervalles fixes ou quasi-fixes.
| Indicateur | Detail |
|---|---|
| Pattern temporel | Connexions a intervalles reguliers (ex : toutes les 60 secondes, toutes les 5 minutes) |
| Taille constante | Paquets de taille similaire a chaque beacon |
| Destination inhabituelle | IP ou domaine non reconnu dans la baseline |
| Jitter | Un C2 sophistique ajoute un leger aleas pour eviter la detection |
Detection : analyser la regularite des connexions sortantes avec des outils statistiques ou RITA (Real Intelligence Threat Analytics).
Un attaquant extrait des donnees sensibles du reseau vers l'exterieur.
| Indicateur | Detail |
|---|---|
| Volume anormal | Upload inhabituel depuis un poste de travail |
| Horaires suspects | Transferts volumineux la nuit ou le week-end |
| Destinations inconnues | Uploads vers des services cloud non autorises, des IP etrangeres |
| Protocoles detournes | DNS, ICMP ou HTTP utilises pour exfiltrer (tunneling) |
Apres avoir compromis une machine, l'attaquant se deplace vers d'autres systemes internes.
| Indicateur | Detail |
|---|---|
| Connexions inhabituelles | Un poste de travail se connecte soudainement a de nombreux serveurs internes |
| Protocoles d'admin | Utilisation de RDP, SMB, WinRM, SSH depuis des machines qui ne le font jamais |
| Authentifications anormales | Tentatives de login sur de multiples machines (pass-the-hash, brute force) |
| Scans internes | Port scanning depuis une machine interne |
Un attaquant explore le reseau pour identifier les cibles potentielles.
- Port scanning : une IP contacte de nombreux ports sur une ou plusieurs machines
- Network sweeps : une IP contacte de nombreuses machines sur un meme port
- DNS zone transfers : tentative de recuperer toute la zone DNS
- SNMP enumeration : requetes SNMP pour cartographier le reseau
🚨 15.6 — Protocoles a surveiller : tunneling et exfiltration
Les attaquants utilisent des protocoles legitimes pour camoufler leur trafic malveillant. Les analystes SOC doivent connaitre ces techniques pour les detecter.
DNS Tunneling
Les donnees sont encodees dans les requetes et reponses DNS. Le DNS est rarement bloque par les firewalls, ce qui en fait un vecteur ideal pour les attaquants.
Mecanisme : les donnees a exfiltrer sont encodees en base64 et placees comme sous-domaine : aGVsbG8gd29ybGQ=.evil.com
Indicateurs de DNS tunneling :
- Requetes DNS avec des sous-domaines tres longs (> 50 caracteres)
- Volume DNS anormalement eleve depuis une machine
- Types d'enregistrements inhabituels (TXT, NULL, CNAME longs)
- Requetes vers des domaines recemment enregistres
- Entropie elevee dans les noms de domaine (caracteres aleatoires)
Outils : iodine, dnscat2, dns2tcp
ICMP Tunneling
Les donnees sont cachees dans les champs de donnees des paquets ICMP (ping). Normalement, un ping contient une petite charge utile de test, mais un tunnel ICMP remplit le payload avec des donnees utiles.
Indicateurs de ICMP tunneling :
- Paquets ICMP avec un payload anormalement gros (> 64 octets)
- Flux ICMP continu vers une destination unique
- Contenu du payload non-standard (donnees au lieu de patterns de test)
- Volume ICMP inhabituel depuis un poste de travail
Outils : icmpsh, ptunnel, ICMP-Shell
HTTP/HTTPS Exfiltration
Les donnees sont exfiltrees via des requetes HTTP normales (POST, GET avec des parametres longs) ou via HTTPS chiffre, rendant l'inspection difficile.
Indicateurs :
- Requetes POST volumineuses vers des domaines suspects
- Upload vers des services cloud non autorises (Pastebin, file sharing)
- Parametres GET anormalement longs (donnees encodees dans l'URL)
- Connexions HTTPS longue duree vers des IP non categorisees
- User-Agent inhabituels ou absents
Protocoles non standard sur ports standard
Un attaquant peut utiliser un protocole non standard sur un port standard pour contourner les firewalls. Par exemple :
- SSH sur le port 443 : le firewall pense que c'est du HTTPS
- VPN sur le port 80 : le trafic VPN se fait passer pour du HTTP
- Reverse shell sur le port 53 : un shell se cache dans du trafic DNS
- C2 sur le port 8080 : commandes C2 sur un port web alternatif
Detection :
- Deep Packet Inspection (DPI) : analyser le contenu, pas juste le port
- Verification protocol/port mismatch : le port 443 devrait avoir du TLS
- Detection de protocoles par signature (IDS/IPS)
🔬 15.7 — Lab : Analyse d'une capture reseau
Tu es analyste SOC. Le SIEM a genere une alerte pour une activite suspecte sur le poste 10.0.1.45 (poste de Sarah, comptabilite). Voici un extrait de la capture reseau. Analyse les paquets et reponds aux questions.
| # | Temps | Source | Destination | Protocole | Port Dst | Taille | Info |
|---|---|---|---|---|---|---|---|
| 1 | 09:01:00 | 10.0.1.45 | 10.0.1.1 | DNS | 53 | 74 B | Query: mail.company.com |
| 2 | 09:01:01 | 10.0.1.45 | 10.0.1.20 | TCP | 25 | 62 B | SYN |
| 3 | 09:15:00 | 10.0.1.45 | 185.234.72.19 | DNS | 53 | 247 B | Query: a3RhbGxpbnN0YWxs.data.suspect-domain.xyz |
| 4 | 09:15:02 | 10.0.1.45 | 185.234.72.19 | DNS | 53 | 312 B | Query: dXNlcnM9YWRtaW4. |
| 5 | 09:15:05 | 10.0.1.45 | 185.234.72.19 | DNS | 53 | 289 B | Query: cGFzc3dvcmQ9MTIzNA.data.suspect-domain.xyz |
| 6 | 09:20:00 | 10.0.1.45 | 185.234.72.19 | DNS | 53 | 256 B | Query: ZmluYW5jZV9yZXBvcnQ.data.suspect-domain.xyz |
| 7 | 09:25:00 | 10.0.1.45 | 185.234.72.19 | DNS | 53 | 278 B | Query: Y29tcGxldGVkX2V4Zml.data.suspect-domain.xyz |
| 8 | 09:30:00 | 10.0.1.45 | 10.0.1.1 | DNS | 53 | 68 B | Query: www.google.com |
| 9 | 09:30:01 | 10.0.1.45 | 142.250.74.36 | TCP | 443 | 66 B | SYN (HTTPS) |
| 10 | 09:35:00 | 10.0.1.45 | 185.234.72.19 | ICMP | - | 1024 B | Echo Request (payload: 984 bytes) |
Paquets 1-2, 8-9 sont normaux :
- Paquet 1 : requete DNS vers le serveur DNS interne pour le serveur mail de l'entreprise
- Paquet 2 : connexion SMTP vers le serveur mail interne (port 25)
- Paquet 8 : requete DNS normale vers Google
- Paquet 9 : connexion HTTPS vers Google
DNS Tunneling / Data Exfiltration via DNS
- Les requetes sont envoyees a une IP externe (185.234.72.19) au lieu du DNS interne
- Les sous-domaines contiennent des chaines encodees en base64
- La taille des requetes DNS est anormalement grande (247-312 octets vs 68-74 pour le DNS normal)
- Le domaine
suspect-domain.xyzest suspect (TLD .xyz, nom evocateur) - Pattern temporel regulier : toutes les 5 minutes
En decodant le base64 des sous-domaines :
a3RhbGxpbnN0YWxs= "ktallinstall" (probable commande d'installation)dXNlcnM9YWRtaW4= "users=admin" (enumeration d'utilisateurs)cGFzc3dvcmQ9MTIzNA= "password=1234" (exfiltration de credentials)ZmluYW5jZV9yZXBvcnQ= "finance_report" (exfiltration de documents)Y29tcGxldGVkX2V4Zml= "completed_exfi" (confirmation d'exfiltration)
Conclusion : un malware exfiltre des identifiants et des documents financiers via DNS tunneling.
ICMP Tunneling suspect :
- Le paquet ICMP fait 1024 octets avec un payload de 984 octets
- Un ping normal a un payload de 32-64 octets
- La destination est la meme IP suspecte (185.234.72.19)
- L'attaquant utilise probablement aussi un tunnel ICMP comme canal de communication secondaire
- Isoler le poste 10.0.1.45 du reseau
- Bloquer l'IP 185.234.72.19 et le domaine suspect-domain.xyz sur le firewall/DNS
- Capturer le trafic complet pour l'investigation forensique
- Analyser le poste pour identifier le malware
- Verifier si d'autres machines communiquent avec la meme IP/domaine
- Changer les mots de passe compromis (admin)
- Documenter l'incident et escalader selon la procedure
ip.addr == 10.0.1.45 && (ip.addr == 185.234.72.19 || dns.qry.name contains "suspect-domain")
🔐 15.7 — Analyse de trafic chiffré
Avec la généralisation de HTTPS et TLS, plus de 80% du trafic réseau est chiffré. Les analystes SOC doivent pouvoir détecter des activités malveillantes sans déchiffrer le contenu, en utilisant les métadonnées.
Techniques d'analyse du trafic chiffré
| Technique | Description | Indicateur suspect |
|---|---|---|
| JA3 / JA3S Fingerprinting | Hash MD5 des paramètres du ClientHello/ServerHello TLS | JA3 connu associé à un malware (ex : Cobalt Strike, Emotet) |
| Analyse des certificats | Examiner le certificat TLS du serveur | Certificat auto-signé, CN (Common Name) suspect, durée de validité anormale, émetteur inconnu |
| SNI (Server Name Indication) | Le nom de domaine est visible en clair dans le ClientHello | Domaine DGA (Domain Generation Algorithm), domaine récemment enregistré |
| Analyse comportementale | Taille des paquets, timing, fréquence des connexions | Beaconing régulier (C&C), transferts de données volumineux à des heures inhabituelles |
| Destination inhabituelle | IP de destination, géolocalisation, réputation | Connexions vers des pays à risque, IP sur liste noire, hébergeurs bulletproof |
Indicateurs de TLS malveillant
- Port non standard pour TLS — TLS sur un port autre que 443 (ex : 4443, 8443, 1337)
- Version TLS obsolète — TLS 1.0 ou SSL 3.0 indique un malware mal mis à jour ou un outil offensif ancien
- Certificat auto-signé — Légitime dans un lab, suspect en production
- Durée de certificat anormale — Let's Encrypt = 90 jours normal; certificat valide 10 ans = suspect
- Beaconing pattern — Connexions TLS à intervalles réguliers vers la même destination = probable C&C
📝 15.9 — Quiz de revision
🔬 15.7 — Lab : Analyse de trafic avec tcpdump et Wireshark
Mets en pratique tes connaissances en utilisant les commandes tcpdump et les filtres Wireshark. Tape les commandes dans le terminal ci-dessous pour voir les resultats.
Exercice : associe chaque anomalie a son type d'attaque
Glisse chaque indicateur reseau dans la zone d'attaque correspondante.
Points cles du Module 15
- La capture de paquets peut se faire via TAP (physique), SPAN/mirror port (switch) ou en inline (IPS)
- Full Packet Capture (PCAP) capture tout le paquet ; NetFlow ne capture que les metadonnees des flux
- Wireshark utilise des display filters (syntaxe propre) et des capture filters (syntaxe BPF)
- tcpdump est l'outil CLI essentiel pour la capture sur les serveurs Linux
- NetFlow/IPFIX collecte les metadonnees des flux : IP, ports, volumes, timestamps
- La baseline du trafic normal est indispensable pour detecter les anomalies
- Les patterns suspects incluent le beaconing, l'exfiltration, le lateral movement et le scanning
- Les attaquants utilisent le DNS tunneling, l'ICMP tunneling et le HTTP/S pour exfiltrer des donnees
- La detection repose sur les anomalies de volume, de frequence, de destination et de contenu
- Le JA3 fingerprinting identifie les applications dans le trafic chiffré via le ClientHello TLS
- Le SNI révèle le domaine en clair, le certificat peut être analysé sans déchiffrement
- Le beaconing (connexions régulières) est un indicateur C&C dans le trafic chiffré
- La TLS inspection par proxy permet le déchiffrement mais pose des questions de confidentialité