Add probe article

2022-05-29 09:28:38 +02:00 · 2022-05-29 09:28:38 +02:00 · 142812d036
commit 142812d036
parent c91bc9298f
1 changed files with 467 additions and 0 deletions
--- a/posts/sondes.md
+++ b/posts/sondes.md
@ -0,0 +1,467 @@
 ---
 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).