Broken-by-Design/posts/sondes.md

---
title: "Sondes de détection : performances, évaluations et biais"
author: "Florian Maury"
date: "2019-11-01"
slug: sondes
categories:
- network security
tags:
- network
- security
- probes 
---

En avril 2019, l’ANSSI a qualifié les premières sondes pour assurer la
supervision de sécurité de réseaux. 
Les {{< abbr OIV "opérateurs d’importance vitale" >}}, 
les {{< abbr OSE "opérateurs de services essentiels" >}} et, d’une
manière générale, les organismes opérant des fonctions sensibles disposent ainsi
de produits français de confiance : Cybels Sensor de Thales et Trackwatch Full
Edition de Gatewatcher. La méthodologie d’évaluation des sondes n’est, hélas,
pas publique. Les ingénieurs sécurité et réseau devant intégrer ces sondes ne
disposent donc pas de guides pour effectuer la recette de leur efficacité en
production.

<!--more-->

Cet article propose un retour d’expérience sur l’évaluation des sondes,
notamment sous l’angle de la performance. Cet aspect est, en effet,
particulièrement significatif puisque le taux de détection d’une sonde diminue
si elle est submergée, quand bien même elle serait équipée des meilleurs
signatures et moteurs d’analyse.

# De la notion de budget

Les différents moteurs d’analyse constituant une sonde consomment des ressources
machine. Celles-ci sont en quantité finie et dépendante du matériel sur lequel
sont installés les mécanismes de détection et d’analyse. Ces ressources
comprennent notamment la capacité de calcul (CPU, FPGA, ASIC) et la mémoire
(RAM, mémoire de travail des périphériques...).

Il est généralement possible d’effectuer certains compromis calcul/mémoire afin
d’optimiser le traitement. Néanmoins, ces ressources confinent, in fine, au
temps nécessaire pour traiter un paquet entrant. La variable non ajustable est,
en effet, le débit entrant dans une sonde. Ce débit est exprimé en deux unités :
le nombre de paquets par seconde, et le nombre d’octets par seconde.

Le nombre de paquets par seconde est significatif, car il définit le budget
temporel disponible pour le traitement des paquets. Un million de paquets par
seconde signifient que la sonde dispose d’un millionième de seconde pour le
traitement de chaque paquet en moyenne. En outre, le nombre de paquets par
seconde a une influence sur le nombre d’interruptions (matérielles ou
logicielles) qu’un CPU doit traiter. De la même manière qu’un ingénieur est
moins productif s’il est constamment interrompu, un CPU perd du temps à chaque
interruption. En conséquence, à l’instar de nombreux équipements, il est aisé de
noyer une sonde sous de nombreux paquets représentant un trafic extrêmement
modéré en octets par seconde.

Le nombre d’octets par seconde reste cependant significatif. Ce dernier a, en
effet, un impact sur les temps de transfert des paquets entre les différents
composants de la sonde. Cet impact se matérialise notamment pendant les recopies
des paquets, entre composants matériels ou logiciels.

Dès lors qu’une sonde épuise son budget pour le traitement d’un paquet, celui
des paquets suivants peut en pâtir. S’il ne s’agit que d’un pic de trafic, il
est généralement possible d’absorber celui-ci en lissant son coût sur les
millisecondes/secondes suivantes. En effet, certains paquets sont traités plus
rapidement que d’autres, comme ceux qui sont immédiatement écartés, car faisant
partie d’un flux chiffré dont la sonde n’a pas la clé de déchiffrement. Si le
pic d’activité se prolonge, la sonde n’a alors d’autre choix que de défausser du
trafic. L’endroit et la manière dont le trafic est défaussé sont déterminés en
fonction de la localisation du goulot d’étranglement.

# Les goulots d’étranglement

Les paquets reçus peuvent être défaussés par de nombreux composants matériels ou
logiciels, dès lors qu’une surconsommation budgétaire survient. Cela peut se
produire dès la carte réseau recevant les paquets et ne pouvant pas les diffuser
au noyau, ou bien plus tard, quelque part dans le noyau ou dans le logiciel de
détection en lui-même.

## Pertes par la carte réseau

Les cartes réseau disposent d’une mémoire interne relativement réduite ; il
s’agit d’une file d’attente. Chaque paquet entrant dans la carte est inséré dans
cette file. Celle-ci est ensuite consommée par un procédé qui transfère les
paquets dans la mémoire centrale du serveur. Cela s’effectue par des écritures
{{< abbr DMA "Direct Memory Access" >}} ou des variantes, telles 
qu’{{< abbr "IOAT/DMA" "I/O Acceleration Technology DMA" >}}).

Une carte réseau peut saturer sa file d’attente, si elle n’arrive pas à
effectuer les écritures DMA aussi rapidement que les paquets arrivent depuis le
réseau. Outre de possibles lenteurs matérielles sur les bus de communication en
eux-mêmes, la cause principale de lenteur est le filtrage des accès mémoire par
l’{{< abbr IOMMU "I/O Memory Management Unit" >}} [^PCIe]. 
Il s’agit d’un gestionnaire des écritures DMA, capable de limiter les plages
mémoires sur lesquelles les périphériques d’un serveur sont en mesure d’écrire,
à l’instar d’un pare-feu limitant les accès à un réseau. Sa fonction est
cruciale pour la sécurité des serveurs, mais totalement contre-productive si
elle résulte en l’incapacité de la sonde à remplir son rôle.

## Pertes dans le noyau

Lors de son démarrage, le logiciel de détection fait appel au noyau pour
configurer une méthode d’acquisition des paquets. Plusieurs existent, parmi
lesquels les plus populaires sont certainement AF_Packet (natif dans Linux),
PF_Ring, DPDK, ou encore Netmap.

Généralement, le logiciel de détection configure le noyau afin qu’une plage
mémoire soit réservée pour la réception des paquets écrits par DMA.

Plus cette plage mémoire est grande, plus la quantité de paquets qui pourront
être stockés en attendant leur traitement est importante. Si toutefois cette
plage se remplit plus vite qu’elle n’est consommée par le logiciel de détection,
alors des paquets sont défaussés.

La lenteur de la consommation des paquets entrants n’est pas systématiquement à
imputer aux lenteurs du logiciel de détection. En effet, le noyau effectue des
transformations ou ajoute des métadonnées, qui peuvent être plus ou moins
coûteuses. Des pertes peuvent donc se produire avant même que le logiciel de
détection ne soit prévenu de la réception de paquets ! Ce cas peut être
notamment observé si l’on utilise des programmes {{< abbr XDP "eXpress Data Path" >}}
très gourmands, ou des algorithmes peu performants de répartition des paquets
(load-balancing) entre les différents processeurs.

Une autre cause de pertes de paquets impliquant le noyau est l’extraction de
fichiers. Les logiciels de détection peuvent, en effet, stocker les paquets
reçus (fichiers PCAP) ou les fichiers suspects transitant sur le réseau (HTTP,
SMB, SMTP...). Si les périphériques de stockage ne sont pas suffisamment
rapides, les appels système d’opération sur les fichiers (`write(2)`,
`sync(2)`...) pourraient être plus lents à rendre la main au logiciel de
détection, et donc dépasser le budget. En conséquence, une perte de paquets est
possible dès lors qu’une grande quantité de fichiers doivent être extraits pour
mise en quarantaine et analyses ultérieures.

## Pertes dues au logiciel de détection

L’organisation des composants constituant le logiciel de détection et la
complexité des règles d’analyse peuvent avoir un impact significatif sur les
performances, et entraîner la perte de paquets.

Les moteurs d’analyse sont découpés, en interne, en plusieurs sous-tâches :

* acquérir de nouveaux paquets à traiter ;
* replacer les paquets dans leur contexte (e.g. « fait-il partie d’une session
  TCP ? », « est-ce un fragment d’un paquet déjà vu ? ») ;
* effectuer des analyses de sécurité des paquets ou des flux, afin d’inférer des
  événements de sécurité ou d’extraire des fichiers suspects ;
* produire des journaux enregistrant les événements générés.

Ces sous-tâches peuvent être gérées par un ou plusieurs processus. Utiliser
plusieurs processus peut être avantageux pour paralléliser les traitements, et
ne pas se retrouver avec une surcharge de travail qui pourrait saturer les
capacités de traitement d’un unique processus. Hélas, utiliser plusieurs
processus n’est pas non plus une panacée, car ces sous-tâches peuvent nécessiter
des états partagés. Il est alors nécessaire d’organiser l’accès à ces états, par
l’intermédiaire de serveurs mandataires (comme le fait Zeek/Bro) ou de verrous
(futex/mutex, comme le fait Suricata).

Une analyse de performance assez poussée du logiciel de détection Suricata a été
conduite [^SuriLock] ; elle montre que les verrous constituent un des freins
principaux, pouvant causer la perte de paquets. Dans cette analyse, il est
notamment stipulé que Suricata effectue beaucoup d’accès concurrents aux états
des sessions TCP.

Ainsi, un trafic réseau comportant une grande quantité de sessions TCP
simultanées ou de nombreuses nouvelles connexions par seconde peut avoir pour
conséquence le ralentissement de Suricata. En effet, tous les processus ayant
pour objectif de remplacer un paquet dans son contexte seront alors figés en
l’attente de la libération des verrous pour accéder aux états partagés.

En outre, et sans même parler de verrous, une grande quantité de sessions TCP
peut saturer les tables de hachage dans lesquelles sont stockés les états. Or,
la complexité algorithmique d’accès aux éléments des tables de hachage passe
d’O(1) (temps constant) à O(n) (temps linéaire, fonction de la quantité de
collisions dans la table de hachage) lorsque celles-ci saturent. Il en résulte
alors une surconsommation CPU, et donc une surconsommation du budget temporel
pour le traitement d’un paquet.

L’architecture logicielle des moteurs d’analyse peut également influencer les
performances en cas de mauvaise répartition des paquets reçus entre les
différents processus en charge de leur traitement. La perte de paquets survient
lorsqu’un CPU est saturé/noyé sous les traitements qu’un processus d’analyse
doit entreprendre. Ce cas de figure se manifeste très facilement lorsque la
répartition des paquets reçus n’est pas aléatoire, mais tend à concentrer sur le
même processus d’analyse tous les paquets relatifs à un même flux (ex. :
sessions TCP). Cette répartition par flux est la plus commune et privilégiée,
car elle permet de limiter les accès aux ressources partagées et d’augmenter la
localité des accès mémoire [^SEPTUN]. Le problème est que cette méthodologie ne
répartit pas correctement le trafic incluant des tunnels (IPsec, GRE, L2TP,
TLS...). En effet, à moins que le programme en charge de la répartition ne fasse
de l’inspection profonde (DPI) du trafic (qui n’est même pas toujours possible,
par exemple en cas de paquets fragmentés), l’intégralité des paquets d’un tunnel
sera analysée par un même processus d’analyse ! Si ce tunnel est très actif, le
processus d’analyse sera facilement débordé, et des paquets commenceront à être
perdus.

Finalement, les moteurs d’analyse (ex. : dissecteurs, analyseurs de contenu,
greffons d’analyse) peuvent être des sources de problèmes de performance,
résultant en la perte de paquets. Le pare-feu applicatif de Cloudflare a causé
une indisponibilité de l’ensemble de leurs services en juillet 2019
[^CloudflareWAF], à cause d’une expression rationnelle gourmande en CPU. De même,
une règle de détection mal conçue pourra freiner significativement l’analyse des
paquets, et surconsommer le budget.

De l’expérience de l’auteur de cet article, le problème est encore pire avec des
greffons écrits en Lua. Ce langage utilise, en effet, exclusivement des
co-routines pour simuler le parallélisme. En conséquence, si une instruction Lua
met en attente l’interpréteur Lua, sans rendre la main pour que ce dernier
exécute une autre co-routine en attendant, l’ensemble des processus d’analyse de
paquets ayant recours à un greffon Lua se retrouvent figés [^LuaLock].

# Biais introduits par les méthodologies d’évaluation

Les conditions évoquées dans la précédente section de cet article peuvent se
manifester lors de la capture de trafic sur des réseaux de production.
Néanmoins, étant donné que les sondes sont des composants généralement connectés
à des réseaux sensibles, nombre d’opérateurs préfèrent évaluer ces équipements
en émulant de tels réseaux, avant d’en sélectionner un et de le raccorder à leur
production. De même, les constructeurs de sondes doivent évaluer leur produit
afin de s’assurer de leur performance.

L’émulation d’un réseau n’est cependant pas chose aisée, et de nombreux biais
peuvent être introduits, faussant positivement ou négativement la perception des
performances réelles des sondes ! Cette section détaille quelques erreurs
communes que l’auteur de cet article a pu observer ou commettre dans le cadre de
son activité professionnelle.

## Les outils pour l’émulation de réseaux

Outre les plateformes commerciales, dont l’efficacité et la pertinence des tests
pourraient certainement faire l’objet d’études formelles, plusieurs outils
libres existent. Parmi ces derniers, il est notamment judicieux de citer :

* tcpdump, qui permet la capture de trafic, le filtrage et le stockage dans des
  fichiers PCAP [^tcpdump] ;
* tcpreplay, qui permet de rejouer des PCAP à plus ou moins grande vitesse, et
  même d’éditer les PCAP [^tcpreplay] ;
* TRex, de Cisco, qui constitue une plateforme de rejeu de trafic complète
  [^TRex] ;
* scapy, une bibliothèque Python dédiée à la manipulation de paquets réseau.
  Elle permet de capturer du trafic, de l’analyser, de le filtrer et de
  l’éditer, avant de l’enregistrer sous la forme de fichiers PCAP, ou de
  renvoyer les paquets sur le réseau [^Scapy] ;
* tc qdisc, un ensemble d’outils sous Linux permettant notamment l’émulation de
  certaines conditions sur un réseau, comme la limitation de débit avec le
  module tbf, ou la création de latence ou d’instabilités (pertes de paquets,
  rejeux...) avec le module netem [^tc].

### Tcpdump

tcpdump permet de capturer et d’enregistrer du trafic sur des réseaux modérément
actifs. Lorsque les réseaux sont trop rapides, ce dernier ne parvient pas
toujours à collecter tous les paquets reçus. Les flux réseau ainsi enregistrés
s’en retrouvent alors corrompus. Quelle que soit la technologie employée pour le
rejeu du trafic, il est crucial que les captures réseau employées soient
représentatives de la situation que l’on cherche à émuler. En outre, il est
normal de souhaiter que le trafic envoyé à la sonde contienne des pertes, des
rejeux et des réordonnancements de paquets. Il convient cependant que ceux-ci
soient désirés et émulés à dessein, plutôt que le résultat du hasard et d’une
méthodologie de capture inadéquate.

Il convient également de noter que la capture de trafic d’un réseau réel peut
générer des fichiers PCAP non représentatifs, malgré une source de données bien
légitime. En effet, il est absolument capital de nettoyer ces captures, car
celles-ci contiennent des demi-flux [^CleanPCAP]. Ces demi-flux sont des flux qui
ont commencé avant le début de la capture ou qui se termineront après la fin de
la capture.

Les demi-flux commencés avant le début de la capture sont problématiques si la
sonde est configurée pour ignorer de tels flux. En rejouant ces demi-flux,
l’évaluateur néophyte pourrait alors avoir l’impression d’envoyer une quantité
importante de trafic à la sonde et que cette dernière se comporte parfaitement,
sans perdre le moindre paquet. En réalité, la sonde n’effectuera aucune analyse
des paquets reçus et les défaussera, sans lever la moindre alerte, même en
présence d’un trafic malveillant.

Les demi-flux ne se terminant pas pendant la capture sont également
problématiques si la capture est relativement courte, et rejouée en boucle, par
exemple avec tcpreplay. En effet, ces flux ne se terminant jamais, ils vont
créer à chaque itération de nouveaux états à maintenir dans la sonde, pouvant
ainsi causer une explosion en coût mémoire, et une saturation de différentes
tables de hachage internes. Or, si les logiciels de détection sont optimisés
pour ne pas s’écrouler face à des DDoS de type SYN Flood, une explosion du
nombre de flux tombe dans le spectre des attaques logiques. Les sondes n’ont
alors d’autres choix, pour ne pas s’écrouler, que de défausser arbitrairement
des flux, parmi lesquels des flux potentiellement malveillants. Pour ce faire,
des délais de grâce (*timeout*) agressifs sont employés.

### Tcpreplay

tcpreplay permet de rejouer des PCAP contenant des flux de toute nature et peut
être un outil efficace pour évaluer une sonde. Des biais peuvent cependant être
introduits dès lors que le PCAP est rejoué en boucle à l’aide de l’option
`--loop`.

Le premier biais constaté par l’auteur de cet article survient si la périodicité
des rejeux en boucle est inférieure à la valeur du délai de grâce (*timeout*)
`CLOSE_WAIT` configuré dans la sonde. Dans l’absolu, `CLOSE_WAIT` est un état de la
machine à états du protocole TCP, qui est indépendant des paquets reçus, et qui
évolue seulement après un certain délai. Son objectif est d’empêcher qu’un
serveur croie à l’établissement d’une nouvelle connexion TCP à cause de paquets
réseau dupliqués trouvant leurs chemins après la fermeture de la session
originale. Les sondes devant émuler les piles TCP des serveurs qu’elles
protègent, elles doivent avoir un délai de grâce pour l’état `CLOSE_WAIT`
représentatif de ces serveurs. Or, si tcpreplay rejoue en boucle « trop
rapidement » (relativement au délai de grâce) le même PCAP, alors le trafic sera
partiellement ignoré par la sonde, comme il l’aurait été par le serveur auquel
s’adressait le trafic original, en vertu des spécifications du protocole TCP !
Il en résulte une sonde donnant l’impression de traiter énormément de paquets,
alors qu’en pratique, elle les ignore.

Pour éviter le biais précédent, il est possible d’utiliser l’option
`--unique-ip` de tcpreplay qui fait varier les adresses IP à chaque nouvelle
itération d’un PCAP. Hélas, cette option conduit au second biais !

Ce second biais est une amusante et improbable coïncidence. Il existe, en effet,
une interaction entre l’algorithme utilisé par `--unique-ip` et certaines
méthodes de hachage des paquets en vue d’effectuer la répartition des paquets
entre les processus d’analyse !

Les méthodes de hachage des paquets pour répartir les flux nécessitent une
propriété assez inhabituelle. En effet, il est nécessaire de hacher vers le même
processus d’analyse, tant les requêtes que les réponses d’un même flux. Il faut
donc utiliser un algorithme dit symétrique, qui hachera les adresses IP de
manière identique même si les adresses IP source et destination sont inversées.
Or, certains mécanismes de répartition, comme celui de la méthode de capture des
paquets PF_Ring, utilisent une simple addition modulaire des octets des adresses
IP. Ainsi, un paquet allant de 192.168.0.1 à 192.168.0.2 donnera un haché égal à
$192+168+1+192+168+2 = 723 modulo N$.

De son côté, l’implémentation de `--unique-ip` dans tcpreplay se contente de
soustraire le nombre d’itérations du PCAP à une adresse IP, et d’ajouter le
nombre d’itérations du PCAP à l’autre adresse IP. Or il s‘agit d’une opération
mathématique à somme nulle qui conduira donc l’algorithme de répartition des
paquets de la sonde à toujours envoyer les paquets vers les mêmes processus
d’analyse. Si le PCAP est suffisamment court, alors la sonde se trouvera
submergée artificiellement au niveau de certains processus, tandis que tous les
autres ne recevront pratiquement aucun flux !

### TRex

TRex est une plateforme développée par Cisco permettant le rejeu d’une gamme de
PCAP. Chaque PCAP ne doit contenir qu’un seul flux. La configuration de cette
plateforme permet ensuite de spécifier la fréquence relative de chaque PCAP par
rapport aux autres. Il est alors possible d’envoyer plus ou moins de flux, en
sachant que la quantité et la nature des flux envoyés sont maîtrisées.

TRex évite les biais introduits par tcpreplay, en faisant varier les adresses IP
de manière aléatoire à chaque nouvel envoi d’un flux. En outre, pour
l’expédition des flux, il envoie les paquets d’une adresse A vers une adresse B
sur une interface réseau, et les paquets retour, de B vers A sur une autre
interface réseau. Cela résulte en une méthode d’acquisition des flux par la
sonde qui est plus réaliste, car plus proche de la méthode d’acquisition des
flux sur une fibre optique.

La seule ombre au tableau de TRex est sa complexité ; il est, en effet, aisé
d’envoyer à une sonde du trafic dépassant l’une de ses spécifications, soit en
nombre de paquets par seconde, de nouveaux flux par seconde, de nombre de flux
totaux, de fichiers à extraire, ou autre.

### Scapy

Scapy est un outil probablement indispensable pour les évaluateurs de sonde. Il
leur permet, en effet, de retravailler un fichier PCAP, notamment pour y
nettoyer les demi-flux, altérer les flux pour dupliquer des paquets ou en
supprimer, corrompre sciemment des sommes de contrôle. Son seul véritable défaut
est sa relative lenteur, due principalement à son modèle d’abstraction des
paquets, et au langage Python. Il est donc peu pratique d’opérer sur des PCAP de
plusieurs gigaoctets.

### Tc qdisc

tc qdisc (traffic control -- queue discipline) est un cadriciel reposant sur le
noyau Linux et des outils de l’espace utilisateur (*userland*) pour altérer
l’écoulement des paquets sur des interfaces réseau spécifiques. Cet outil est
notamment utile lorsqu’un évaluateur cherche à créer des PCAP pour TRex. En
effet, il est possible de créer un environnement contrôlé, par exemple avec une
paire d’interfaces virtuelles (*veth*). L’une des interfaces fait alors tourner
le serveur et l’autre accueille le client. tc permet d’altérer cet environnement
de tests pour y introduire des perturbations volontaires (ex. : délais, pertes,
réduction de débit...).

## Biais introduits par l’injection de flux non représentatifs

Le comportement d’une sonde peut varier significativement en fonction du trafic
reçu. Leurs logiciels de détection doivent, en effet, être en mesure de
s’adapter à tout type de trafic susceptible d’être reçu par les équipements
qu’elles protègent. Or le traitement d’un grand nombre de petits paquets, ou à
l’inverse le traitement de *jumbo frames* (des trames dont la taille excède les
classiques 1514 octets) demande des allocations mémoire contradictoires, ne
serait-ce que pour stocker les paquets en attendant leur traitement. De même, de
nombreux flux distincts ne se gèrent pas de la même manière que quelques flux
bien connus, mais massifs.

Or, une sonde, par défaut, doit savoir gérer toutes ces situations. Leur
configuration doit donc être suffisamment générique pour accorder au logiciel la
flexibilité nécessaire pour les encaisser. Il en résulte une allocation des
ressources potentiellement inadéquates pour des cas extrêmes, comme le
traitement d’un trafic réseau à très haut débit. Pire, ces configurations
génériques ont tendance à « surbooker » les ressources à disposition.
L’hypothèse optimiste est, en effet, que plusieurs situations extrêmes ne se
présenteront pas simultanément. Les ressources de la machine étant en quantité
finie, il peut alors en résulter des dénis de service du logiciel de détection
(ex. : déclenchement de l’OOM Killer de Linux, qui tue les processus consommant
beaucoup de mémoire).

Finalement, la nature des flux injectés peut également influencer le
comportement de la sonde. Une grande quantité de flux chiffrés est, en général,
facile à gérer pour une sonde. Cette dernière n’a, en effet, pas accès aux clés
de déchiffrement ; le flux peut donc généralement être ignoré, pour privilégier
l’analyse de paquets en clair. À l’inverse, une grande quantité de flux
distincts (ex. : sessions TCP ou questions/réponses sur UDP...) peuvent faire
exploser les états dans la sonde, comme cela a été détaillé plus haut dans cet
article.

# Conclusion

Au fil de cet article ont été présentés différents :

* goulots d’étranglement d’une sonde ;
* ressources critiques ;
* sources de lenteur ;
* biais pouvant être introduits involontairement lors de l’évaluation.

À moins d’avoir développé une expertise notable dans l’intégration de ce genre
d’équipements, il est donc nécessaire de se référer à des guides de déploiement,
et des méthodologies de tests éprouvées et génériques. Hélas, de tels documents
n’existent pas encore, et les ingénieurs doivent réinventer la roue
systématiquement, quitte à en produire des carrées, de temps à autre.

Dans le monde des systèmes industriels, souvent considéré par la communauté de
la sécurité des systèmes d’information IT comme le vilain petit canard, ce
problème a pourtant déjà été résolu ! La certification ANSI/ISA 62443 et le
programme ISA-Secure [^ISASec] spécifient une méthodologie d’évaluation très
précise des systèmes industriels, et des équipements pouvant automatiser ces
tests. Les exigences sont donc clairement établies, les méthodologies de tests
documentées, et les produits d’évaluation certifiés. Ces tests incluent la
conformité, la robustesse au trafic anormal, et la robustesse contre la montée
en charge.

Ces éléments manquent cruellement dans le monde des sondes de détection, dont la
réaction peut varier significativement, comme décrit dans cet article, en
fonction du trafic reçu, de la nature de ses flux et de son intensité.

# Remerciements

Je tiens à remercier mes relecteurs : Erwan Abgrall, Baptiste Bone, Piotr
Chmielnicky, Sebastien Larinier, ainsi que ceux qui ont souhaité rester
anonymes, et les employés de Gatewatcher. Les avis exprimés dans cet article ne
sauraient les engager.

# Références

[^CleanPCAP]: Script permettant de nettoyer les demi-flux : https://frama.link/RfNczV0d
[^CloudflareWAF]: Rapport d’incident de Cloudflare impliquant leur pare-feu applicatif web : https://blog.cloudflare.com/cloudflare-outage/
[^ISASec]: Site de la certification ISA Secure : https://www.isasecure.org/en-US/
[^LuaLock]: Exemples cassant le modèle de threads collaboratifs de Lua : https://stackoverflow.com/a/18964444
[^PCIe]: Neugebauer et alii., « Understanding PCIe performance for end host networking », août 2018
[^Scapy]: Dépôt de l’outil Scapy : https://github.com/secdev/scapy
[^SEPTUN]: Document sur l’amélioration des performances d’acquisition de Suricata : https://github.com/pevma/SEPTun
[^SuriLock]: Étude sur l’incidence des verrous dans Suricata : https://xbu.me/article/performance-characterization-of-suricata-thread-models/
[^tc]: Documentation sur l’émulation d’incidents réseau avec Traffic Control : https://wiki.linuxfoundation.org/networking/netem#packet_duplication
[^tcpdump]: Site de l’outil Tcpdump : https://www.tcpdump.org/
[^tcpreplay]: Site de l’outil Tcpreplay : https://tcpreplay.appneta.com/
[^Trex]: Site de l’outil TRex : https://trex-tgn.cisco.com/

Publié par les [Editions Diamond](https://connect.ed-diamond.com/MISC/misc-106/sondes-de-detection-performances-evaluations-et-biais) sous licence [CC-BY-NC-ND](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.fr).