Chasse réseau avec Zeek et Suricata : déploiement, optimisation des règles, analyse TLS et processus Alert-to-Case

La chasse réseau avec Zeek et Suricata est particulièrement efficace lorsqu’elle n’est pas perçue comme « encore un capteur », mais comme une discipline d’exploitation : architecture de capture propre, réglage contrôlé des règles, métadonnées TLS robustes et un processus qui transforme les alertes en cas traçables. Zeek (Network Security Monitor, génère des métadonnées de protocole et de flux structurées) et Suricata (moteur IDS/IPS, compare le trafic à des signatures et à des règles de protocole) se complètent très bien — mais seulement si le déploiement et le chemin des données sont corrects.

Ce billet s’adresse aux administrateurs et aux opérateurs qui veulent démarrer de façon pragmatique : quelle topologie de capteurs fonctionne en pratique ? Comment éviter que 10 000 alertes par jour paralysent les équipes ? Que permet encore l’analyse TLS alors que les contenus sont chiffrés ? Et comment concevoir un processus qui transforme les alertes en cas et qui tient face à l’audit, à la réponse aux incidents et au quotidien ?

Chasse réseau avec Zeek et Suricata en pratique

Zeek est efficace si vous souhaitez extraire rapidement des métadonnées exploitables à partir de paquets bruts : données de connexion (5-tuple, durée, octets), événements de protocole (p. ex. requêtes DNS, en-têtes HTTP, données du handshake TLS) et métadonnées de fichiers. Suricata est efficace si vous voulez détecter des motifs connus : signatures (classiques « Rules »), décodeurs de protocole, détection d’anomalies et — selon le mode d’exploitation — blocage inline en tant qu’IPS.

Dans les déploiements de chasse, Suricata est généralement utile en tant qu’IDS (passif), car un IPS inline peut rapidement conduire à des risques de disponibilité : suppressions faussement positives, routage asymétrique, problèmes de réassemblage de sessions. Zeek reste passif et fournit souvent des données « plus honnêtes » en termes de qualité — à condition que la capture et les horodatages soient propres.

Il est important d’ajuster les attentes : avec TLS, vous ne verrez généralement pas le contenu, mais de nombreux signaux issus du handshake et du comportement de connexion. Cela suffit pour de nombreuses questions (indicateurs C2, chaînes de destination inhabituelles, SNI suspect, anomalies de certificats), mais ne remplace pas la télémétrie hôte.

Architecture de déploiement : TAP vs. SPAN, placement des capteurs et stratégie de repli

La principale source d’erreurs dans le déploiement des capteurs n’est pas le logiciel mais l’accès au réseau. Pour Zeek/Suricata, vous avez besoin de Packet Capture (PCAP) ou d’une capture basée sur AF_PACKET/DPDK. Les éléments cruciaux sont : visibilité complète, absence de perte de paquets et synchronisation temporelle correcte.

TAP ou SPAN ?

Un TAP (Test Access Point) est une dérivation physique, typiquement plus stable : il reflète les bits sans « interprétation » du switch. Un port SPAN/mirror sur un switch est souvent plus rapidement disponible, mais apporte des pièges typiques : Oversubscription (plus de trafic que le port miroir peut supporter), visibilité VLAN incomplète, rafales de paquets et — selon la plateforme — des effets de filtrage subtils.

• TAP : meilleur pour une analyse forensique fiable, coûts matériels plus élevés, mais fonctionnement reproductible.
• SPAN : rapide, économique, mais vous devez vérifier activement le risque de pertes et l’exhaustivité.

Où placer ?

Pour commencer, trois emplacements pratiques :

• Internet Edge / Perimeter: une bonne vue d’ensemble des entrées et sorties (Egress est souvent plus important que Ingress pour la chasse aux menaces).
• Agrégation du centre de données: trafic East-West entre réseaux de serveurs – pertinent pour le mouvement latéral.
• Segment avec « joyaux de la couronne »: bases de données, backends ERP/CRM, services de fichiers centraux – idéal pour la chasse ciblée.

Compromis typique : commencez par un capteur en périmètre (couverture maximale) et ajoutez ensuite des capteurs segmentaires ciblés, lorsque vous savez où se situent les hypothèses principales.

Stratégie de repli (Rollback) dès la conception

Même avec des capteurs passifs, vous pouvez perturber la production : des configurations Mirror peuvent être mal définies, des NIC de capteurs peuvent inonder des ports de switch (p. ex. en cas de boucles), le storage peut se remplir et les systèmes de supervision peuvent basculer sous des tempêtes de logs. Prévoyez donc :

• Mirror/TAP rapidement désactivable (plan de changement, ports clairement étiquetés).
• Opérer les capteurs en « Fail-open » (passifs) ; IPS uniquement avec autorisation spécifique.
• Rate-limits et backpressure dans la pipeline de logs (Queue, Batch, Drop-Policy).
• Limites de capacité : PCAP-Ringbuffer, rotation des logs, seuils d’alerte du storage.

Base matérielle et performance : éviter les Drops avant d’affiner les règles

L’affinement des règles est inutile si vos capteurs perdent des paquets. La perte de paquets crée des artefacts : handshakes TLS fragmentés, transactions HTTP manquantes, réassemblage de flux incorrect – ce qui entraîne des alertes fantômes et des angles morts.

Liste de contrôle minimale pour les hôtes de capteurs

• NIC: NIC serveur avec pilote stable ; RSS (Receive Side Scaling) activé, taille du ringbuffer adaptée.
• CPU: cœurs suffisants, pinning/modèle de workers adapté ; éviter « alles auf Core 0 ».
• Storage: volumes séparés pour Logs/PCAP ; réserve d’IOPS pour les pics ; Logrotate testé.
• Temps: NTP/Chrony stable ; la dérive temporelle détruit la corrélation et la timeline des incidents.

Étapes de vérification : Dropped Packets, débordement de queue, Capture-Health

Ne vous contentez pas de vérifier « läuft der Dienst », mais « verarbeiten wir Traffic vollständig ». Selon le backend de capture, les métriques diffèrent. Deux tests de base pratiques sont : les statistiques d’interface (Kernel) et les statistiques du capteur (Application).

# Interface-Statistiken (Drops, Errors) – Ausgangspunkt
ip -s link show dev eth1

# Kernel- und Treiberzähler (je nach Treiber aussagekräftig)
ethtool -S eth1 | egrep -i 'drop|dropped|miss|error|fifo'

# Ringbuffer/RX-Tuning prüfen
ethtool -g eth1

# CPU/Softirq-Last im Blick: wenn ksoftirqd hoch geht, drohen Drops
top -H

Si vous observez déjà des drops ici, les contre-mesures typiques sont : réduire la charge du mirroring (SPAN sélectif), changer le backend de capture (AF_PACKET vs. DPDK), augmenter le RX-Ring, régler proprement l’IRQ-Balancing ou utiliser du matériel de capteur dédié.

Déploiement Suricata : EVE JSON, jeux de règles et discipline de mise à jour sécurisée

Suricata fournit typiquement ses résultats au format EVE JSON (événements structurés au format JSON). Pour l’exploitation et les intégrations, c’est idéal : SIEM, gestion des logs, bus de messages ou systèmes de ticketing peuvent parser les événements de manière robuste.

Principes de configuration utiles au quotidien

• Séparez le chemin d’exploitation et le chemin d’analyse : Suricata écrit localement, un forwarder (p. ex. Filebeat/Fluent Bit/Vector) transmet ensuite.
• Versionnez les règles : dépôt Git ou registre d’artefacts ; ne faites pas les mises à jour « sur le capteur » via l’UI.
• Fenêtre de mise à jour : les mises à jour de règles sont en fait des changements de code — avec enregistrement des changements et possibilité de rollback.

Effectuer un update de règles de façon contrôlée (exemple de procédure)

# Beispiel: Regeln aktualisieren (Distribution/Tooling variiert je nach Setup)
# 1) Vorher: aktuelle Regeln sichern
sudo tar -C /etc/suricata -czf /var/backups/suricata-rules_$(date +%F).tar.gz rules

# 2) Update aus kontrollierter Quelle (z. B. internes Repo / signiertes Paket)
# (Hier als Platzhalter – in der Praxis per Paketmanager oder suricata-update)
# sudo suricata-update --no-test --reload-command 'systemctl reload suricata'

# 3) Syntax-/Ladeprüfung und anschließend Reload
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl reload suricata

# 4) Rückfall: falls Alarmflut oder Fehler
# sudo tar -C /etc/suricata -xzf /var/backups/suricata-rules_YYYY-MM-DD.tar.gz
# sudo systemctl reload suricata

Pourquoi cette procédure fonctionne : vous séparez le test (vérification de configuration / des règles) de l’activation. Et vous disposez d’une option de retour rapide avant que la pipeline ne soit submergée par des signatures erronées.

Déploiement Zeek : métadonnées comme base pour le threat hunting et découpe pertinente des logs

Zeek génère de nombreux types de logs (p. ex. conn, dns, http, ssl/tls). Pour l’exploitation, moins est souvent mieux : si vous activez « tout », la charge de stockage et de parsing augmente, et les équipes perdent le fil. Commencez par un jeu de base couvrant les hypothèses typiques :

• conn : connexions de base (qui parle à qui, quand et quel volume).
• dns : résolution de noms (domaines C2, suspicion de DGA, exfiltration via DNS).
• tls/ssl : métadonnées du handshake (SNI, certificat, versions, ALPN).
• files (optionnel) : métadonnées de fichiers (hashs) — uniquement si vous supportez la charge I/O.

Un piège fréquent est la corrélation entre capteurs : si vous exploitez plusieurs capteurs, vous avez besoin d’IDs de capteurs uniques et de sources temporelles cohérentes. Sinon, deux événements peuvent devenir « deux vérités ».

Étapes de vérification : santé de Zeek et rotation des logs

# Läuft Zeek und schreibt Logs?
sudo systemctl status zeek
ls -lh /opt/zeek/logs/current/

# Rotation/Archive prüfen (Pfad je nach Installation)
find /opt/zeek/logs -maxdepth 2 -type d -name "20*" | tail

# Grober Plausibilitätscheck: wächst conn.log, dns.log, tls/ssl.log?
for f in conn.log dns.log ssl.log tls.log; do
  test -f "/opt/zeek/logs/current/$f" && echo "OK: $f" || echo "MISS: $f";
done

Si les logs ne tournent pas ou que les archives ne sont pas purgées, ce n’est pas un défaut esthétique : des systèmes de fichiers pleins entraînent une perte de données et, au pire, des capteurs instables.

Ajustement des règles dans Suricata : de l’avalanche d’alarmes à des signaux fiables

Ajustement des règles ne signifie pas « tout désactiver jusqu’à ce qu’il y ait le calme », mais : définir les attentes, établir des baselines, ajouter du contexte puis affiner de manière itérative. L’objectif est un rapport signal/bruit que l’équipe peut effectivement traiter.

Causes typiques de faux positifs

• Réseaux incompatibles : les règles se déclenchent sur le monitoring interne, les sauvegardes, les scanners de vulnérabilités ou le trafic proxy.
• TLS partout : de nombreuses signatures ciblant des protocoles en clair sont « à moitié » déclenchées par TLS (SNI/handshake), sans preuve véritable.
• Normalisation des protocoles : reverse proxies, NAT, load balancers modifient la visibilité et entraînent des flux « étranges ».
• Réassemblage incomplet : perte de paquets ou routage asymétrique génèrent des événements de décodage trompeurs.

Flux de travail pratique d’ajustement (3 étapes)

1. Étape 1 : couper le bruit – exceptions claires pour les scanners connus, les serveurs de mise à jour internes et les réseaux de gestion. Il ne s’agit pas de « filtrer les attaques », mais d’éliminer le feu continu que personne ne traite.
2. Étape 2 : imposer le contexte – n’alerter que lorsque plusieurs conditions sont réunies (p. ex. zone cible + protocole + cible rare + port inhabituel).
3. Étape 3 : intégrer le processus – chaque règle restante obtient une responsabilité (qui la maintient ?) et un rythme de revue.

Important : l’ajustement doit toujours être fondé sur des données. Si vous désactivez des règles, documentez la raison et fixez une date de réexamen. Sinon, des dettes techniques s’accumulent et génèrent ultérieurement des angles morts.

Analyse TLS : ce que vous pouvez exploiter de manière fiable sans déchiffrement

L’analyse TLS consiste à analyser la partie non chiffrée du handshake TLS. Cela inclut notamment le SNI (Server Name Indication – le nom d’hôte demandé), la chaîne de certificats, la version/le choix de cipher et les extensions. Zeek et Suricata peuvent fournir ici des métadonnées utiles, même si la charge utile est chiffrée.

Quels signaux TLS sont utiles en pratique ?

• SNI : souvent le meilleur indicateur de relations cibles. Échoue pour IP-only, ESNI/ECH (SNI masquée) ou tunnels TLS.
• Certificat : émetteur, subject, validité, auto-signé, motifs SAN inhabituels. Attention : Let’s Encrypt n’est pas « malveillant », mais une bonne baseline est nécessaire.
• JA3/JA3S : empreintes à partir des paramètres du handshake client/serveur. Utile pour le clustering, mais pas comme unique « preuve de malware », car les empreintes peuvent se chevaucher et évoluer.
• ALPN : négociation de HTTP/2, HTTP/1.1, etc. Aide à établir des profils de protocole.

Quand le parsing TLS échoue : avec ECH (Encrypted ClientHello), la valeur ajoutée classique du SNI est réduite. De plus, des middleboxes (proxies) peuvent « uniformiser » le comportement TLS visible, de sorte que vous fingerprinterez davantage le proxy que le client.

Pièges : mondes de proxy et interception de certificats

Dans de nombreuses entreprises, un proxy termine le TLS et réétablit la connexion vers la cible. Vous ne voyez alors pas l’empreinte réelle du client au niveau du périmètre, mais celle du proxy. Ce n’est pas « mauvais », mais vous devez adapter vos hypothèses : la chasse « l’appareil/ le poste parle directement avec X » ne fonctionne alors pas ; en revanche, la chasse « le proxy établit des connexions inhabituelles » peut très bien fonctionner.

Alert-to-Case : des événements à des cas exploitables

Une alerte est un événement technique. Un cas est un processus avec contexte, responsabilité, chronologie et décision. Sans cette transition, la chasse réseau se transforme souvent en décharge d’alarmes ou en projet ponctuel.

Jeu de données minimal pour un cas, éprouvé

• Identité : ID du cas, capteur, fenêtre temporelle, assets concernés (IP, nom d’hôte, utilisateur le cas échéant).
• Justification : quelle règle/heuristique a déclenché, quelles preuves sont attachées (lignes de log Zeek, alerte Suricata, référence PCAP).
• Contexte : criticité de l’asset, tickets de changement connus, fenêtres de maintenance, liste d’IP de scanners.
• Décision : True/False Positive, gravité, action suivante (contain, observe, close).
• Travail de suivi : tâche de tuning oui/non, propriétaire de la règle, rappel.

Conception pragmatique de corrélation

En pratique, vous ne corrélez pas « tout avec tout », mais construisez quelques ponts robustes :

• Suricata Alert → Zeek Kontext : même 5-Tuple (source/destination/ports/proto) + fenêtre temporelle.
• Zeek TLS/DNS → Asset-DB : IP/nom d’hôte vers CMDB/inventaire (quel serveur est-ce ?).
• PCAP à la demande : uniquement pour les cas escaladés ; sinon les métadonnées suffisent.

Cela réduit les coûts : le PCAP continu est coûteux (stockage, protection des données, exploitation). Un « PCAP-Ringbuffer pour 2–6 heures » est souvent un bon compromis pour pouvoir revenir en arrière en cas d’incident sans tout conserver en permanence.

Pipeline de logs et conservation des données : robustesse avant « beau tableau de bord »

La plupart des pannes se produisent entre le capteur et l’analyse : forwarder de logs bloqué, file d’attente saturée, indexeur surchargé, horodatages erronés, champs qui changent après des mises à jour. Traitez la pipeline comme un système productif.

Bonnes pratiques pour le forwarding et le backpressure

• Mise en spool locale : le forwarder doit pouvoir bufferiser (Disk-Queue), sinon vous perdez des événements lors de courtes perturbations.
• Contrôle de schéma : versionner EVE JSON/Zeek-Logs ; tester les changements de parseur avant leur mise en production.
• Séparation du « hot » et du « cold » : recherche active dans l’index rapide, conservation longue durée en archives compressées.

Étapes de vérification : corrélation temporelle et stabilité des champs

Si vous pratiquez la chasse, le « temps » est une fonction clé. Vérifiez régulièrement :

• Dérive entre capteur, collecteur de logs, indexeur SIEM (statut NTP).
• Zones temporelles (UTC vs heure locale) à tous les niveaux.
• Noms/types de champs après des mises à jour (p. ex. champs EVE de Suricata, formats de logs Zeek).

Dépannage : quand les résultats ne correspondent pas à votre réalité

Il est normal que les premières semaines paraissent « étranges ». L’important est de vérifier systématiquement si le problème se situe dans le réseau, la capture, le parsing ou le processus.

Symptôme : Beaucoup d’alertes TLS, mais pas de traces DNS correspondantes

• Cause : le DNS est mis en cache/résolu en interne (résolveur), les clients utilisent DoH/DoT (DNS over HTTPS/TLS) ou un proxy effectue la résolution.
• Vérification : voyez-vous le port 53/853 ? Y a-t-il des connexions DoH vers des résolveurs connus ? Tout passe-t-il par un proxy ?
• Contremesure : placer le capteur plus près des clients/résolveurs ou formuler des hypothèses au niveau du proxy.

Symptôme : des règles se déclenchent sur « tout », particulièrement lors de backups/scans

• Cause : les scanners et outils de sauvegarde génèrent des schémas similaires à des scans d’exploits (nombreux objectifs/ports/requêtes).
• Vérification : identifier l’IP source, comparer avec les fenêtres de maintenance et la liste d’outils.
• Contremesure : exceptions clairement documentées ; politique distincte de gestion du bruit pour les réseaux de management.

Symptôme : journaux de protocoles manquants ou instables

• Cause : pertes de paquets, routage asymétrique, mauvaise miroir de VLAN, MTU/fragmentation.
• Vérification : vérifier drops/errors comme ci‑dessus, config SPAN, comparer avec NetFlow/logs de firewall.
• Contremesure : utiliser un TAP, sélectionner le SPAN, adapter la NIC/CPU/backend du capteur.

Proposition de mise en œuvre : en 14 jours vers une capacité de hunting utile

Un plan praticable vaut mieux que « on installe et on voit ». Le déroulé suivant s’est avéré réaliste sans surcharger les équipes :

Phase 1 (Jour 1–3) : visibilité et stabilité

• Déployer le capteur au périmètre ou sur une agrégation (passif).
• NTP/Chrony configurés correctement, définir les politiques de stockage et de rotation.
• Vérifier un traitement sans pertes (tester aux heures de pointe).

Phase 2 (Jour 4–7) : rendre les données exploitables

• Suricata EVE JSON et les logs noyau de Zeek vers la journalisation centrale.
• Premiers tableaux de bord/requêtes : destinations principales, nouveaux domaines, SNI rares, ports inhabituels.
• Mesurer le flot d’alertes : Top-10 règles, Top-10 sources, Top-10 destinations.

Phase 3 (Jour 8–14) : tuning et processus de cas

• Réduction du bruit avec des exceptions documentées.
• Définir un modèle de cas (champs, responsabilités, SLA à petite échelle).
• Revue hebdomadaire : quelles règles apportent de la valeur, lesquelles non, quelles hypothèses manquent.

Conclusion : le hunting est de l’exploitation – et Zeek/Suricata sont votre sensorique

Zeek et Suricata fournissent ensemble une base très robuste pour le Network-Hunting, si vous assurez d’abord la qualité de capture, puis que vous ajustez les règles de manière itérative et classez correctement les métadonnées TLS. Le levier le plus important n’est pas « plus de règles », mais le processus Alert-to-Case : responsabilités claires, preuves reproductibles et une boucle de retour qui améliore en continu le tuning et la qualité des données.

Si vous souhaitez approfondir le sujet dans le cadre de la sécurité des API, de la gestion centralisée des secrets ou du logging des accès distants, la prochaine étape doit toujours être la même : augmenter la visibilité de façon ciblée, mais uniquement là où vous pouvez aussi opérationnaliser les constats.

Pour ce sujet, l’architecture Ids/Nsm et l’ajustement des règles Suricata sont également importants. Le billet remet ces aspects en perspective de façon compréhensible et montre ce qui compte au quotidien.