Architecture Systeme Securisee Sonde IDS Reseau-Article
Architecture Systeme Securisee Sonde IDS Reseau-Article
Architecture Systeme Securisee Sonde IDS Reseau-Article
réseau
1 Introduction
En complément des mesures de protection appliquées sur un réseau, il est
classique de déployer un système de supervision. Ce système a pour but d’ob-
server en temps réel les communications afin de détecter des tentatives de com-
promission des équipements connectés au réseau supervisé, mais également les
compromissions réussies de ces équipements.
De part leur fonction et leur exposition, les sondes IDS réseau constituent une
cible potentielle pour les attaquants : elles embarquent une grande quantité de
décodeurs protocolaires, sont présentes sur la plupart des réseaux, et perçoivent
l’ensemble du trafic.
Les décodeurs protocolaires au cœur des logiciels IDS ont un rôle très sensible
en sécurité car leurs implémentations sont fréquemment sujettes à l’introduction
de vulnérabilités [2,3]. En effet, les protocoles à décoder sont d’une part de plus
en plus complexes, et d’autre part les spécifications qui les accompagnent sont
parfois incomplètes ou erronées, lorsqu’elles existent. Le plus souvent écrits dans
des langages bas niveaux tels que le C pour des raisons de performances, ces
décodeurs sont alors potentiellement vulnérables à de nombreuses classes de pro-
blèmes : débordements mémoire, injection de code, corruption mémoire, double
1. Network Intrusion Detection System
2. Intrusion Detection System
libération, etc. Bien que ces problèmes soient connus et récurrents, aucun chan-
gement notable n’est constaté sur le choix des langages [10] employés par les
logiciels IDS.
En ciblant directement les sondes, un attaquant peut rendre aveugle la su-
pervision de sécurité d’un réseau. Au sein d’un même système de supervision,
les sondes sont généralement identiques : une vulnérabilité exploitable sur l’une
d’entre elles est de facto reproductible sur toutes les autres, ce qui peut conduire
à l’indisponibilité (ou la compromission) de l’ensemble du système de supervision
de sécurité.
Lorsque le logiciel IDS d’une sonde s’exécute avec des privilèges importants,
un attaquant qui réussit à exploiter une vulnérabilité avec succès peut prendre
le contrôle de la sonde. Si les sondes sont inter-connectées et gérées de manière
centralisées, l’attaquant peut alors remonter de la sonde vers la machine d’ad-
ministration, puis rebondir vers d’autres machines. Le réseau de supervision de
sécurité se retrouve alors dans la situation singulière où il risque de devenir le
réseau permettant de compromettre l’ensemble des machines supervisées.
Enfin, les alertes correspondant aux événements détectés sont souvent remon-
tées sur le même réseau que le réseau surveillé. La confidentialité et l’intégrité
des événements ne sont donc pas toujours assurées.
Face à ces constatations, il nous est apparu essentiel d’assurer la sécurité des
éléments de détection réseau, condition indispensable pour avoir confiance dans
le système de supervision de sécurité. L’objectif de cet article est de proposer
une architecture de sonde IDS réseau, en s’appuyant sur un matériel muni de
fonctions de sécurité, permettant d’en améliorer la sécurité intrinsèque, indépen-
damment du logiciel IDS utilisé. En effet, la modification du logiciel IDS peut
s’avérer complexe à réaliser, en particulier sans introduire de vulnérabilité, mais
rend surtout difficile sa maintenance en conditions opérationnelle et de sécurité.
Cet article comporte trois parties. Nous détaillons tout d’abord dans la sec-
tion 2 les bases systèmes nécessaires à la conception d’une architecture système
sécurisée de sonde IDS réseau. Dans la section 3, nous expliquons ensuite com-
ment ces protections permettent de définir une architecture robuste, basée sur
l’isolation des rôles et sur des flux d’informations unidirectionnels. Enfin, nous
expliquons dans la section 4 comment nous avons conçu un prototype de sonde
légère mettant en œuvre cette architecture et quelques résultats expérimentaux
permettant de valider cette architecture.
2 Protections système
La fonction principale d’un IDS étant d’analyser du trafic réseau, on peut
considérer que tout le trafic qu’il perçoit est potentiellement malveillant. L’ob-
jectif des protections présentées dans cette section est de s’assurer que l’attaquant
ne puisse pas désactiver la fonction IDS, corrompre le journal d’alertes, prendre
le contrôle de la machine hébergeant la fonction IDS, voire remonter dans le
réseau de supervision. Il ne doit pas non plus pouvoir faire fuir de l’information
depuis l’IDS, par exemple les règles de l’IDS qui pourraient être sensibles.
L’idée générale est d’appliquer au maximum les principes de défense en pro-
fondeur et de moindre privilèges. Les protections apportées peuvent être classées
en deux catégories : celles qui renforcent la sécurité des logiciels s’exécutant sur
la sonde présentées dans la section 2.1, et celles qui renforcent l’isolation des com-
posants du système présentées dans la section 2.2. La section 2.3 présente les
éléments matériels nécessaires au bon fonctionnement de l’architecture proposée,
notamment au regard de l’impact sur les performances.
Afin de protéger n’importe quel logiciel IDS qui s’exécute sur la sonde, la sé-
curité de l’architecture proposée s’articule autour de deux axes : la configuration
du système, et le durcissement du noyau.
Le travail initial consiste à appliquer les principes essentiels de sécurisa-
tion [5] : réduire la surface d’attaque, supprimer les applications et services in-
utiles, réduire les permissions et les privilèges des processus importants, et recom-
piler les applications et services avec les options de durcissement de gcc. Pour
empêcher la persistance d’une attaque réussie, et assurer que chaque démarrage
se fait dans un état « propre », l’environnement d’exécution des processus est
figé : toute modification (configuration, fichiers exécutés ou installés, accès aux
périphériques) est interdite en montant toutes les partitions en lecture seule, à
l’exception de celle contenant des données variables (telles que les journaux) qui
doivent persister entre les redémarrages.
Bien qu’essentiels, ces éléments de configuration ne sont pas suffisants. Des
modifications plus profondes s’avère en effet nécessaires, comme l’application des
patches PaX et grsecurity [7] au noyau. Sans entrer dans le détail des bénéfices
apportés par ces modifications [4], il convient toutefois de citer les propriétés les
plus pertinentes dans le cadre de l’élaboration d’une sonde durcie :
– espace d’adressage aléatoire (ASLR 3 ) ;
– vérification de débordement lors de copies de données ;
– interdiction d’exécuter du code situé en espace utilisateur depuis l’espace
noyau ;
– restrictions sur les programmes utilisateurs : suppression de la visibilité des
programmes des autres utilisateurs, interdiction de créer des pages en écri-
ture et exécution, allocations de mémoire forcée à des adresses aléatoires,
interdiction du debugging d’un processus ;
– protections additionnelles des conteneurs : réduction systématique des ca-
pabilities, restrictions additionnelles appliquées aux environnements confi-
nés (chroots) ;
– montage définitif d’une partition en lecture seule (sans possibilité de refaire
un montage avec écriture) ;
– Trusted Path Execution, qui permet de s’assurer qu’un utilisateur ne peut
pas exécuter de programmes situés dans un répertoire qui n’appartient pas
à root.
3. Address Space Layout Randomization
L’application de ces patches est complétée par une configuration minimale du
noyau, qui supprime les éléments inutiles (USB, accélération graphique, etc.)
voire dangereux (chargement des modules, accès direct à la mémoire, etc.).
Il est important de noter que ces mesures ne modifient pas le comportement
de l’IDS, ou ses vulnérabilités intrinsèques. Si les techniques classiques telles
que l’exécution sur la pile seront détectées et bloquées, certaines autres restent
applicables, comme le ROP 4 [12] par exemple.
Afin de diminuer autant que possible les conséquences d’une compromission,
nous proposons d’utiliser, en plus des protections décrites ci-dessus, un méca-
nisme de cloisonnement.
2.2 Cloisonnement
Nous décrivons ici le cas où le socle doit héberger soit plusieurs logiciels IDS
tels que Suricata [11], Bro [8] ou encore Snort [13], soit des instances différentes
du même IDS, avec des paramétrages distincts.
L’architecture proposée est décrite dans la figure 1. Chaque instance d’IDS
est isolée dans un conteneur dédié. La sécurité de ces conteneurs repose sur les
mécanismes suivants :
1. tous les systèmes de fichiers des conteneurs sont montés en lecture seule. Si
le conteneur a besoin d’écrire des données temporaires, un point de montage
en mémoire uniquement (tmpfs) est utilisé (contenu non exécutable, effacé à
chaque démarrage du conteneur) ;
2. les conteneurs n’ont accès à aucun périphérique de l’hôte, en particulier les
cartes réseau ou l’affichage ;
3. les protections systèmes décrites dans la section 2 doivent également être
appliquées dans les conteneurs ;
4. les données de configuration et les règles des IDS sont exposées depuis le
socle par un mécanisme de type montage par recouvrement (bind-mount),
qui s’assure que le conteneur en charge d’exécuter un IDS ne peut en aucun
cas écrire dans ces données ;
5. les protections apportées sont complémentaires des mesures qui peuvent être
proposées dans un IDS, telles que la réduction de privilèges (ou de capabi-
lities), l’utilisation d’un utilisateur non privilégié, ou encore la limitation
d’utilisation de ressources système.
socle
eth0 eth1
(ipsec)
TAP
Nous avons choisi un matériel de type embarqué, pour lequel plusieurs so-
lutions à base de processeur ARM sont disponibles sous forme de set-top box.
Ces solutions conviennent en terme d’encombrement, et peuvent être facilement
déployées. De plus, elles ont l’avantage de pouvoir n’utiliser aucun élément méca-
nique (disque dur ou ventilateur), ce qui augmente considérablement leur durée
de vie et diminue leur consommation.
De nombreuses plates-formes de ce type existent sur le marché, telles que
RaspberryPi, GuruPlug, cartes FreeScale (SabreLite, Nitrogen, . . .) ou encore
MiraBox. Étant données les contraintes exposées dans la section 2.3, nous avons
retenu la MiraBox qui dispose d’un CPU ARMv7 cadencé à 1,2 GHz, d’un Go
de RAM et de deux interfaces réseau gigabit.
Pour le socle, une Debian unstable avec un noyau Linux 3.16.3 modifié pour
intégrer grsecurity a été installée. Pour cloisonner les conteneurs, nous avons
retenu la virtualisation légère LXC intégrée au noyau Linux. Chaque conteneur
est basé sur une Debian unstable réduite à son strict minimum.
Un seul conteneur IDS est instancié, exécutant la version 2.0.3 de Suricata [11],
modifié pour utiliser les règles et le préprocesseur Modbus spécifiques aux sys-
tèmes industriels [9].
Les flux de remontée d’alertes et d’administration de la sonde se font sur la
même interface physique, en les isolant dans des VPN IPsec séparés.
La seconde interface est dédiée à l’acquisition. Cette interface n’est pas di-
rectement exposée dans le conteneur IDS. Un TAP logiciel est mis en place à
l’aide d’un bridge et d’une paire d’interfaces virtuelles veth dont une extrémité
est présentée à l’IDS. Des règles ebtables sont ajoutées dans le socle pour garantir
l’unidirectionnalité des flux.
Le mécanisme de diode utilisé pour remonter les alertes est un tube nommé
de type FIFO 10 entre le conteneur IDS et le conteneur de collecte de journaux.
4.2 Performances
Les tests ont pour but de mesurer l’impact des mesures de durcissement sur
les performances. À cet effet, nous nous sommes basés sur les travaux de [9], pour
disposer d’une sonde témoin (non durcie) et d’une capture de 200 000 paquets de
trafic réel d’un système industriel. Cependant, les règles de l’IDS déclenchent une
alerte pour chaque transaction Modbus. En pratique, sur la capture utilisée, cela
équivaut à une alerte tous les deux paquets : l’objectif n’est pas de représenter
10. First In First Out
un volume d’alertes réaliste, mais de se placer dans le cas le plus défavorable
pour évaluer les performances.
Les figures 2 et 3 présentent les résultats obtenus en rejouant la capture à
différents débits avec la sonde témoin et la sonde durcie, respectivement.
250000
Paquets traités
Paquets perdus
Alertes
200000
150000
100000
50000
4.3 Discussion
Durant les tests de performances, la principale limitation constatée est la
saturation des ressources CPU, alors qu’une marge était encore disponible pour
les ressources mémoire, disque et réseau. En dehors de quelques réglages, aucune
optimisation particulière de l’IDS n’a été réalisée.
Le TAP logiciel a un impact important sur les performances. Il est cependant
facile et peu coûteux de remplacer ce TAP logiciel par un TAP matériel qui offre
250000
Paquets traités
Paquets perdus
Alertes
200000
150000
100000
50000
tout autant voire plus de garantie en terme de sécurité que le TAP logiciel, mais
dont l’impact sur les performances est nul.
Le matériel choisi (MiraBox) ne dispose que d’un seul CPU, qui de plus est
mono-cœur. Cette limitation est particulièrement importante ici, car l’IDS choisi
(Suricata) et la virtualisation légère (LXC) sont des composants qui bénéficie-
raient particulièrement d’une augmentation des ressources CPU.
Dans l’ensemble, la preuve de concept a permis de valider qu’un matériel
non spécialisé, peu coûteux (moins de 150€), supporte la mise en place d’une
architecture sécurisée pour une sonde IDS. Si le nombre d’alertes générées dans
notre expérience est artificiellement élevé, il permet toutefois de valider le fait
que cette preuve de concept de sonde IDS durcie peut effectivement traiter un
débit équivalent à plusieurs dizaines d’équipements [9] sans perdre aucune alerte.
5 Conclusion
Les sondes réseau, et plus généralement les logiciels IDS, sont les briques
essentielles des systèmes de supervision de sécurité. La qualité de ces composants
se résume traditionnellement à la sensibilité et à la précision de leur processus
de détection de comportements inhabituels ou malveillants. Cependant, de part
leur fonction et leur exposition, la sécurité intrinsèque de ces équipements s’avère
cruciale. En effet, la compromission d’un IDS par un attaquant lui donnerait
non seulement une position stratégique pour observer tout le trafic du réseau
surveillé, mais lui permettrait également de compromettre d’autres équipements
de ce réseau sans être détecté.
L’architecture logicielle de sonde IDS que nous proposons intègre les prin-
cipes de défense en profondeur à l’état de l’art en matière de sécurité logicielle :
durcissement du socle logiciel pour prévenir des exploitations « triviales », prin-
cipe de moindre privilèges pour les utilisateurs et processus, différenciation des
rôles d’administrateur système, d’administrateur IDS et d’auditeur, cloisonne-
ment par virtualisation légère des différents composants logiciels (IDS, collecte,
journalisation, mises à jour), flux unidirectionnels de collecte d’alertes, remontée
des alertes sur un réseau de supervision dédié protégé en confidentialité et en
intégrité.
Il faut cependant rappeler que l’architecture proposée ne modifie pas la qua-
lité de la détection, ni les causes premières des vulnérabilités, qui restent liées à
chacun des logiciels IDS utilisés. Sur ce point, le durcissement des logiciels IDS,
voire l’écriture de parties critiques (en particulier les décodeurs protocolaires)
dans des langages sécurisés restent des actions complémentaires indispensables.
Afin de montrer que l’architecture durcie que nous présentons dans ce papier
est réalisable et viable, nous avons choisi de monter une preuve de concept de
sonde IDS légère, particulièrement adaptée aux réseaux industriels. Nous avons
conduit différents tests sur cette sonde durcie en utilisant une capture de trafic
réel d’un système industriel dans le but de mesurer l’impact des mesures de dur-
cissement. Les résultats obtenus montre un impact significatif des mesures de
durcissement sur les performances. Néanmoins, nous nous sommes délibérement
placés dans des conditions défavorables tant sur le nombre d’alertes générées que
sur les choix d’architectures matérielle et logicielle. Nous pouvons donc raison-
nablement statuer sur le fait que cette mesure constitue une borne maximale du
coût engendré par les mesures de durcissement que nous préconisons dans notre
architecture.
Bien qu’appliquée à la conception d’une sonde IDS légère, l’architecture que
nous proposons reste entièrement valable pour la conception de sonde disposant
de plus de ressources et capables de traiter des volumes de données dépassant
le gigabit. De plus, sur du matériel de type serveur, la majorité des mécanismes
de durcissement que nous proposons d’utiliser tirent partie de propriétés du
matériel sous-jacent. L’impact sur les performances engendré par ces protections
s’en trouvera alors fortement réduit puisque qu’ils ne sont plus implantés de
manière logicielle, comme dans notre preuve de concept.
Références