Broken-by-Design/posts/sondes.md
2022-05-29 09:28:38 +02:00

28 KiB
Raw Permalink Blame History

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

En avril 2019, lANSSI a qualifié les premières sondes pour assurer la supervision de sécurité de réseaux. Les {{< abbr OIV "opérateurs dimportance vitale" >}}, les {{< abbr OSE "opérateurs de services essentiels" >}} et, dune 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 nest, 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.

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

De la notion de budget

Les différents moteurs danalyse 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 danalyse. 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 deffectuer certains compromis calcul/mémoire afin doptimiser 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 doctets 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 dun 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 dinterruptions (matérielles ou logicielles) quun CPU doit traiter. De la même manière quun ingénieur est moins productif sil est constamment interrompu, un CPU perd du temps à chaque interruption. En conséquence, à linstar 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 doctets 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 quune sonde épuise son budget pour le traitement dun paquet, celui des paquets suivants peut en pâtir. Sil ne sagit que dun pic de trafic, il est généralement possible dabsorber celui-ci en lissant son coût sur les millisecondes/secondes suivantes. En effet, certains paquets sont traités plus rapidement que dautres, comme ceux qui sont immédiatement écartés, car faisant partie dun flux chiffré dont la sonde na pas la clé de déchiffrement. Si le pic dactivité se prolonge, la sonde na alors dautre choix que de défausser du trafic. Lendroit 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 quune 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 dune mémoire interne relativement réduite ; il sagit dune file dattente. 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 seffectue 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 dattente, si elle narrive 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" >}} 1. Il sagit dun gestionnaire des écritures DMA, capable de limiter les plages mémoires sur lesquelles les périphériques dun serveur sont en mesure décrire, à linstar dun 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 lincapacité 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 dacquisition 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 quune 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 quelle nest consommée par le logiciel de détection, alors des paquets sont défaussés.

La lenteur de la consommation des paquets entrants nest 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 lon 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 lextraction 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 dopé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 quune grande quantité de fichiers doivent être extraits pour mise en quarantaine et analyses ultérieures.

Pertes dues au logiciel de détection

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

Les moteurs danalyse 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 dune session TCP ? », « est-ce un fragment dun paquet déjà vu ? ») ;
  • effectuer des analyses de sécurité des paquets ou des flux, afin dinférer des événements de sécurité ou dextraire 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 dun unique processus. Hélas, utiliser plusieurs processus nest pas non plus une panacée, car ces sous-tâches peuvent nécessiter des états partagés. Il est alors nécessaire dorganiser laccès à ces états, par lintermé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 2 ; 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 daccè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 lattente 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 daccès aux éléments des tables de hachage passe dO(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 dun paquet.

Larchitecture logicielle des moteurs danalyse 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 lorsquun CPU est saturé/noyé sous les traitements quun processus danalyse doit entreprendre. Ce cas de figure se manifeste très facilement lorsque la répartition des paquets reçus nest pas aléatoire, mais tend à concentrer sur le même processus danalyse 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 daugmenter la localité des accès mémoire 3. 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 linspection profonde (DPI) du trafic (qui nest même pas toujours possible, par exemple en cas de paquets fragmentés), lintégralité des paquets dun tunnel sera analysée par un même processus danalyse ! Si ce tunnel est très actif, le processus danalyse sera facilement débordé, et des paquets commenceront à être perdus.

Finalement, les moteurs danalyse (ex. : dissecteurs, analyseurs de contenu, greffons danalyse) 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 lensemble de leurs services en juillet 2019 4, à cause dune expression rationnelle gourmande en CPU. De même, une règle de détection mal conçue pourra freiner significativement lanalyse des paquets, et surconsommer le budget.

De lexpérience de lauteur 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 linterpréteur Lua, sans rendre la main pour que ce dernier exécute une autre co-routine en attendant, lensemble des processus danalyse de paquets ayant recours à un greffon Lua se retrouvent figés 5.

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 dopérateurs préfèrent évaluer ces équipements en émulant de tels réseaux, avant den sélectionner un et de le raccorder à leur production. De même, les constructeurs de sondes doivent évaluer leur produit afin de sassurer de leur performance.

Lémulation dun réseau nest 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 lauteur 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 lefficacité et la pertinence des tests pourraient certainement faire lobjet 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 6 ;
  • tcpreplay, qui permet de rejouer des PCAP à plus ou moins grande vitesse, et même déditer les PCAP 7 ;
  • 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 lanalyser, de le filtrer et de léditer, avant de lenregistrer sous la forme de fichiers PCAP, ou de renvoyer les paquets sur le réseau 8 ;
  • tc qdisc, un ensemble doutils 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 dinstabilités (pertes de paquets, rejeux...) avec le module netem 9.

Tcpdump

tcpdump permet de capturer et denregistrer 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 sen 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 lon 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 dune méthodologie de capture inadéquate.

Il convient également de noter que la capture de trafic dun 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 10. 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 limpression denvoyer 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 neffectuera aucune analyse des paquets reçus et les défaussera, sans lever la moindre alerte, même en présence dun 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 nont alors dautres 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 à laide de loption --loop.

Le premier biais constaté par lauteur 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 labsolu, 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 dempêcher quun serveur croie à létablissement dune 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 quelles 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 laurait été par le serveur auquel sadressait le trafic original, en vertu des spécifications du protocole TCP ! Il en résulte une sonde donnant limpression de traiter énormément de paquets, alors quen pratique, elle les ignore.

Pour éviter le biais précédent, il est possible dutiliser loption --unique-ip de tcpreplay qui fait varier les adresses IP à chaque nouvelle itération dun 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 lalgorithme utilisé par --unique-ip et certaines méthodes de hachage des paquets en vue deffectuer la répartition des paquets entre les processus danalyse !

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 danalyse, tant les requêtes que les réponses dun 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é, limplémentation de --unique-ip dans tcpreplay se contente de soustraire le nombre ditérations du PCAP à une adresse IP, et dajouter le nombre ditérations du PCAP à lautre adresse IP. Or il sagit dune opération mathématique à somme nulle qui conduira donc lalgorithme de répartition des paquets de la sonde à toujours envoyer les paquets vers les mêmes processus danalyse. 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 dune gamme de PCAP. Chaque PCAP ne doit contenir quun 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 denvoyer 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 dun flux. En outre, pour lexpédition des flux, il envoie les paquets dune 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 dacquisition des flux par la sonde qui est plus réaliste, car plus proche de la méthode dacquisition des flux sur une fibre optique.

La seule ombre au tableau de TRex est sa complexité ; il est, en effet, aisé denvoyer à une sonde du trafic dépassant lune 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 dabstraction des paquets, et au langage Python. Il est donc peu pratique dopé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 lespace utilisateur (userland) pour altérer lécoulement des paquets sur des interfaces réseau spécifiques. Cet outil est notamment utile lorsquun é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 dinterfaces virtuelles (veth). Lune des interfaces fait alors tourner le serveur et lautre accueille le client. tc permet daltérer cet environnement de tests pour y introduire des perturbations volontaires (ex. : délais, pertes, réduction de débit...).

Biais introduits par linjection de flux non représentatifs

Le comportement dune sonde peut varier significativement en fonction du trafic reçu. Leurs logiciels de détection doivent, en effet, être en mesure de sadapter à tout type de trafic susceptible dêtre reçu par les équipements quelles protègent. Or le traitement dun grand nombre de petits paquets, ou à linverse 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 dun trafic réseau à très haut débit. Pire, ces configurations génériques ont tendance à « surbooker » les ressources à disposition. Lhypothè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 lOOM 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 na, en effet, pas accès aux clés de déchiffrement ; le flux peut donc généralement être ignoré, pour privilégier lanalyse de paquets en clair. À linverse, 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 dune sonde ;
  • ressources critiques ;
  • sources de lenteur ;
  • biais pouvant être introduits involontairement lors de lévaluation.

À moins davoir développé une expertise notable dans linté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 nexistent 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 dinformation 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 11 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

Publié par les Editions Diamond sous licence CC-BY-NC-ND.


  1. Neugebauer et alii., « Understanding PCIe performance for end host networking », août 2018 ↩︎

  2. Étude sur lincidence des verrous dans Suricata : https://xbu.me/article/performance-characterization-of-suricata-thread-models/ ↩︎

  3. Document sur lamélioration des performances dacquisition de Suricata : https://github.com/pevma/SEPTun ↩︎

  4. Rapport dincident de Cloudflare impliquant leur pare-feu applicatif web : https://blog.cloudflare.com/cloudflare-outage/ ↩︎

  5. Exemples cassant le modèle de threads collaboratifs de Lua : https://stackoverflow.com/a/18964444 ↩︎

  6. Site de loutil Tcpdump : https://www.tcpdump.org/ ↩︎

  7. Site de loutil Tcpreplay : https://tcpreplay.appneta.com/ ↩︎

  8. Dépôt de loutil Scapy : https://github.com/secdev/scapy ↩︎

  9. Documentation sur lémulation dincidents réseau avec Traffic Control : https://wiki.linuxfoundation.org/networking/netem#packet_duplication ↩︎

  10. Script permettant de nettoyer les demi-flux : https://frama.link/RfNczV0d ↩︎

  11. Site de la certification ISA Secure : https://www.isasecure.org/en-US/ ↩︎