Add probe article
This commit is contained in:
parent
c91bc9298f
commit
142812d036
1 changed files with 467 additions and 0 deletions
467
posts/sondes.md
Normal file
467
posts/sondes.md
Normal file
|
@ -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).
|
Loading…
Reference in a new issue