Résumé

  • conn.log est une synthèse produite par un capteur Zeek configuré ; ni ses compteurs ni son champ history ne reconstituent une chronologie exhaustive des paquets.
  • Une conclusion durable doit conserver la version de Zeek, le schéma, les scripts, le point d’observation, l’horloge, les signaux de perte et les journaux reliés par uid.

Un témoin technique a toujours une place

Le premier article de Paxson sur Bro, publié en 1998, ne décrivait pas une boîte noire omnisciente. Le système observait passivement un lien réseau, appliquait un filtre, transformait les paquets retenus en événements de niveau supérieur, puis laissait des scripts de politique interpréter ces événements. Cette séparation entre mécanisme et politique permettait de modifier une règle locale sans reconstruire le moteur qui suivait le trafic.

Le gain était considérable : réduire le volume assez tôt pour analyser un lien chargé en temps réel. Mais cette efficacité définit aussi ce que la donnée peut prouver. Avant la ligne lisible, il existe une interface, un sens de circulation, un filtre, une longueur de capture, des contrôles d’intégrité, une machine d’état et une politique. Le journal est le produit de cette chaîne.

Le texte de 1998 insiste sur les paquets perdus. Un moniteur saturé peut manquer précisément l’élément qui signale l’intrusion. Il suppose également que l’adversaire connaîtra les méthodes de détection et tentera de les contourner ou de les submerger. La prudence moderne ne consiste donc pas à ajouter une réserve abstraite au bas d’un rapport. Elle consiste à documenter la chaîne d’observation au moment où la donnée est encore vérifiable.

Lire les verbes cachés dans les colonnes

La documentation actuelle de Zeek présente conn.log comme un journal fondamental des éléments de couches 3 et 4 : qui a communiqué avec qui, quand, pendant combien de temps et au moyen de quel protocole. Il couvre TCP et UDP. Pour UDP et ICMP, le terme « connexion » prend le sens d’un flux de paquets, et non celui d’une session TCP. Le nom de la table ne suffit donc pas à définir l’objet.

ts indique l’heure du premier paquet vu par Zeek. Il ne certifie pas qu’aucun paquet antérieur n’a existé ailleurs sur le trajet. uid identifie la connexion dans l’univers des journaux Zeek et sert à retrouver les traces DNS, HTTP, TLS ou autres qui s’y rapportent. Il rend la corrélation possible ; il n’est pas un identifiant négocié par les deux machines.

conn_state condense l’état déduit. S0 signifie qu’une tentative a été vue sans réponse ; SF correspond à un établissement et une fin considérés comme normaux ; d’autres codes décrivent rejet, réinitialisation ou fermeture partielle. Ces valeurs ne sont pas fausses parce qu’elles sont calculées. Elles deviennent trompeuses seulement lorsqu’on omet le sujet du verbe : le capteur a vu.

Le champ history mérite la même discipline. Une majuscule représente un événement provenant de l’initiateur, une minuscule un événement du répondant. SYN, acquittement, données, FIN, RST, lacune ou retransmission deviennent des lettres. Certaines ne sont conservées qu’une fois par direction ; d’autres se répètent selon une échelle logarithmique. La chaîne permet de reconnaître une forme d’échange. Elle ne peut pas être décompressée en une liste ordonnée de tous les paquets.

Les chiffres ne sont pas exempts de choix. Pour TCP, orig_bytes et resp_bytes sont calculés à partir des numéros de séquence et la référence avertit qu’ils peuvent être inexacts, notamment sur de longues connexions. La durée omet certains paquets tardifs qui n’apportent plus de nouvelles données, même si history peut en garder la marque. Les compteurs de paquets sont optionnels et dépendent d’un analyseur activé. Les indicateurs local/distant dépendent de Site::local_nets. Une cellule vide peut signaler une configuration absente, pas un phénomène absent.

Examiner la qualité de l’observation

missed_bytes mesure les octets manqués dans des lacunes de contenu. Une valeur non nulle provoque normalement l’échec de l’analyse de protocole, bien qu’une partie du traitement ait pu aboutir auparavant. capture_loss.log offre un autre angle : Zeek repère des trous dans les numéros de séquence TCP et suppose qu’ils correspondent à du trafic perdu. C’est un indicateur précieux, mais limité au raisonnement qu’il expose.

reporter.log enregistre les avertissements et erreurs internes liés au traitement du trafic ou aux ressources de calcul. Pour apprécier une ligne de connexion, il faut donc regarder autour d’elle : le capteur a-t-il redémarré ? Le filtre a-t-il changé ? Des pertes ou erreurs couvrent-elles la même fenêtre ? Les deux directions empruntaient-elles le point observé ?

Un missed_bytes à zéro ne prouve pas qu’aucun équipement situé avant l’interface n’a perdu le paquet, qu’aucune route asymétrique n’a dérobé un sens ou qu’aucun filtre n’a exclu une classe de trafic. À l’inverse, une alerte de perte ne rend pas tous les champs inutilisables. La bonne pratique localise l’incertitude dans le temps, la direction et l’étape de traitement.

Constituer un dossier réexaminable

Une ligne isolée vieillit mal. Pour qu’un tiers puisse la réexaminer, il faut conserver le journal brut et son schéma exact, la version de Zeek, les scripts chargés, les paramètres pertinents, l’interface et l’emplacement du capteur, le filtre de capture, la source de temps et l’écart mesuré, puis les extraits de capture_loss.log et reporter.log correspondant à la période. Les journaux portant le même uid doivent rester liés au dossier.

Si les règles de confidentialité et de conservation l’autorisent, une tranche PCAP immuable ou son empreinte renforce l’ensemble. Cette capture n’est pas pour autant une vérité sans point de vue : elle possède sa propre interface, sa longueur de capture, ses pertes et sa chaîne de garde. Elle permet toutefois de retester l’inférence compacte à partir d’observations plus proches des paquets.

S’il n’existe pas de PCAP, il ne faut ni inventer son équivalent ni dévaloriser le journal. La formulation exacte est simple : « ce capteur Zeek, dans cette configuration, a observé et résumé… ». La portée se resserre, la conclusion devient plus solide.

Enfin, conserver le schéma n’est pas bureaucratique. La documentation note que ip_proto est apparu avec Zeek 7.1 ; des scripts peuvent ajouter des colonnes ou modifier ce qui est consigné. Sans version ni en-tête, un outil futur risque d’appliquer la définition actuelle à une donnée plus ancienne.

Sources