Schéma de notre plateforme d’expérimentation

volontairement vulnérable à une ou plusieurs failles connues visant à attirer les pirates afin d’étudier leurs stratégies d’attaque pour mieux les comprendre et les anticiper. En simulant un ordinateur ou un réseau entier vulnérable à une ou plusieurs failles, les honeypots attirent les pirates qui tenteront alors d’exploiter ces dernières dans le but d’arrêter ou corrompre le dit système..

Dans cette section, nous présentons cette plateforme d’expérimentation dans la partie 6.3.1. Dans la partie 6.3.2, nous présenterons les politiques de protection et de détection utilisées sur chaque hôte de cette plateforme ainsi que les bases de signatures obtenues. Nous commenterons ensuite les attaques détectées durant un an dans la partie 6.3.3. Finalement, nous discuterons des résultats de cette détection dans la partie 6.3.4.

6.3.1 Plateforme d’expérimentation

La figure 6.5 représente la plateforme d’expérimentation définie pour tester notre outil de détection d’intrusion. Cette plateforme est constituée de quatre systèmes :

– Une passerelle connectée à Internet (4IPpublics) et à un sous réseau (172.30.3.0/24) ; – Une machine contenant des applications utilisateurs sous Gentoo (Util-1) ;

– Une deuxième machine utilisateur sous Debian (Util-2) ;

– Un serveur sur lequel est installé l’outil de virtualisation VMWare. Cette machine héberge ainsi les deux machines utilisateurs (Util-1 et Util-2).

Ces systèmes ont accès à Internet, directement ou via la passerelle, et chaque machine possède un ser-vicesshdmodifié. Ce service a été modifié pour accepter aléatoirement des demandes de connexions

ssh(en moyenne 1% des demandes). De ce fait, ce service autorise aléatoirement la connexion d’un attaquant qui tente d’ouvrir une sessionsshsur un hôte. Les attaquants peuvent ensuite se connecter par rebond sur les trois autres systèmes. NotreIDSest installé sur le serveurVMWare/Gentooet il ana-lyse alors les traces des quatre systèmes de cette plateforme. Ces quatre systèmes sont donc configurés pour envoyer les traces du mécanisme de contrôle d’accès vers notreIDSvia le mode syslog distant.

✞ ☎ 1 integrity(SCexec) 2 int_domain(SC_{.∗:.∗:user.∗}) 3

confidentiality(SCS, sc_{.∗:.∗:user.∗}, Gtrans)

4 duties_sep(SC_S, Gtrans) 5 bad_transition(.∗ : .∗ : user.∗, SCS) 6 conformity() ✡^{✝ ✆}

Listing 6.13 – Exemple de politique de détection.

Cette plateforme a été utilisée durant un an, de juillet 2006 à juin 2007, et a reçu de nombreuses attaques suite à la découverte de ces systèmes ouverts lors de scan ssh. Ce type de scan est utilisé par les attaquants afin de découvrir les systèmes ayant des comptes sshouverts. Notre pot-de-miel, avec son serveursshdmodifié, offre alors une cible de choix pour les attaquants et a subi de nombreuses connections illicites.

Dans cette section, nous détaillons tout d’abord les politiques de contrôle d’accès et la politique de détection utilisées sur ces systèmes. Nous détaillerons ensuite les caractéristiques des bases de signatures obtenues pour notre IDS. Finalement, nous présenterons les statistiques d’attaques sur la durée de l’expérimentation, puis nous étudierons un cas particulier d’attaque.

6.3.2 Politiques utilisées

Nous commençons par détailler la politique de détection et les politiques de contrôle d’accès installées sur nos systèmes. Notre définition de la politique de détection permet de générer une base de signatures adaptée au cas des pots-de-miel.

6.3.2.1 Politique de détection

Notre plateforme d’expérimentations étant considérée comme un pot-de-miel, nous avons défini une politique de détection dont l’objectif est de garantir :

1. L’intégrité du système ;

2. L’isolation du domaine utilisateur ; 3. La confidentialité du système ; 4. La séparation de privilèges ;

5. L’absence de transitions pour l’utilisateur ; 6. Le respect de la politique de protection.

Ces règles permettent ainsi de détecter l’ensemble des activités réalisées par les utilisateurs, c’est-à-dire les attaquants s’étant connectés sur un système. En effet, dans le cadre d’une utilisation normale, nul n’est sensé se connecter sur un de ces systèmes (définition même d’un pot-de-miel). Les activités des utilisateurs sont donc considérées comme illicites.

Le listing 6.13 contient la politique de détection définie afin d’appliquer ces propriétés de sécurité. Ces règles ont été définies dans la section 4.4 (page. 110), la table A.1 (page. 188) en contient une synthèse. La première règle concerne l’intégrité du système. Ainsi, toute modification directe, ou par séquence, d’un objet exécutable du système donnera lieu à une alerte. La seconde règle correspond à la propriété d’intégrité des domaines qui permet d’isoler tous les contextes dont le type commence par user. Ainsi, nous détectons toutes les actions réalisées par les utilisateurs. La troisième règle permet de garantir la confidentialité du système. Ainsi, nous détectons tous les accès à l’information

6.3. EXPÉRIMENTATION 165

Nom Passerelle Util-1 VMware Util-2

Distribution Gentoo Debian Gentoo/vmware Gentoo

Description Version 2004 2004 2005

Type Serveur Serveur Serveur

Utilisateur Etch Utilisateur

Utilisateur 3 3 5 3 Rôle 5 6 5 5 Politique Type 637 2086 637 656 Cible Règle 17 639 235 691 17 650 19 497 SCO 438 1940 459 452 Politique SCS 139 1077 165 143 Neutre SC 577 3017 624 595 IV 17 684 314 582 21 359 18 215 Graphe de 139 1077 165 143 Graphes de transitions 256 2269 300 263

dépendance causale Graphe de 411 1893 428 423

flux d’informations 451 8795 448 451

(Mapping > 36)

TAB. 6.7 – Systèmes installés sur notre réseau.

du système réalisés par les utilisateurs. La quatrième règle correspond à la propriété de séparation de privilèges simple. Ainsi, nous détectons les modifications d’objets suivies de leurs exécutions. Avec la règle bad_transition, nous détectons toutes les transitions ou séquences de transitions réalisées par l’utilisateur. Finalement, la règleconformitygarantit le respect de la politique cible. Ainsi, nous détectons les activités qui violent la politique de protection.

6.3.2.2 Synthèse des politiques de contrôle d’accès

Les systèmes installés sur cette plateforme correspondent aux systèmes SELinux étudiés dans la section précédente (cf. section 6.1.2.2). La table 6.7 contient une synthèse des caractéristiques de leur politique de contrôle d’accès. Ainsi, nous avons pris en considération trois systèmes standards (Passerelle, VMWare, Util-2) et un système complet Util-1.

6.3.2.3 Base de signatures

Les politiques de contrôle d’accès (de la table 6.7) et la politique de détection (du listing 6.13) ont ainsi servi de source à la phase de génération de la base de signatures. La table 6.8 synthétise les caractéristiques des différentes bases obtenues. La règle générant le plus de signatures est ainsi la règle concernant la confidentialité du système, la règle qui en génère le moins est la règle d’intégrité. En effet, dans la définition de notre politique de détection, cette seconde règle est restreinte à l’intégrité des objets exécutables.

Nous obtenons ainsi quatre bases de signatures. Pour chaque base, nous donnons la taille de la base stockée sous forme d’un fichier compressé et l’espace réel utilisé en mémoire. Ainsi, nous pouvons remarquer que la base occupe environ 5Mo pour un système standard contre 30Mo pour un système complet.

Nous précisons ensuite le nombre de règles d’audit qui doivent être ajoutées dans la politique de contrôle d’accès. Sur la première ligne nous indiquons le nombre d’audits nécessaires et sur la

Nom Passerelle Util-1 VMware Util-2 Graphe SC 577 3017 624 595 IV 17 684 314 582 21 359 18 215 integrity 137 9 461 186 140 Règles int_domain 16 283 510 215 18 130 16 546 de confidentiality 29510 726 842 29510 29510 détection duties_sep 243 16 405 320 270 bad_transition 3555 126 228 4250 3941

Taille de 1,1Mo 3,6Mo 1,2Mo 1,1Mo

Résultat la base 4,7Mo 28Mo 4,9Mo 4,8Mo

Nb d’audit 13 664 44 503 14 417 14051

3 624 51 616 3 491 3 764

Durée de l’analyse 47s 10min31s 1min2s 52s

TAB. 6.8 – Base de signatures obtenues.

seconde, le nombre de vecteurs d’audits correspondant. Ainsi, avec notre approche, moins d’un quart des opérations système sont auditées contrairement aux autres approches de détection qui nécessitent l’audit complet du système (cf. section 3.4, page 85). C’est pourquoi notre approche est appliquée sur l’ensemble du système. De plus, comme nous le verrons dans la section suivante, notre approche permet de détecter des activités complexes telles que des séquences d’interactions.

Finalement, la dernière ligne indique le temps nécessaire pour la création de la base de signatures. Ainsi, sur un système standard, cette construction nécessite moins de 1 minute. Dans le pire cas étudié, cette construction nécessite 10 minutes. Étant donné que cette phase n’est réalisée que lorsque la politique de contrôle d’accès est modifiée, ces performances sont tout à fait adaptées à une utilisation réelle de notre outil. Dans le cas de cette plateforme, la base de signatures n’a été régénérée que lors de mises-à-jour nécessaires à la phase d’installation (au mois de juillet). Une fois les politiques correctement définies, cette phase n’a plus été ré-effectuée.

6.3.3 Analyse des résultats

Dans cette section, nous présentons les résultats obtenus lors de la phase de détection sur cette plateforme d’expérimentation. Nous proposerons ainsi une analyse des attaques subies. Dans certains graphiques, nous ignorons volontairement les alertes qui correspondent à la règleint_domain. Cette règle génère une alerte par interaction réalisée par un utilisateur, SELinux étant un système de contrôle d’accès fin, les autres alertes sont noyées dans le flux généré par cette règle. En effet, la présence de cette règle est plus liée à des perspectives de corrélation.

6.3.3.1 Analyse sur un an

Tout d’abord, la figure 6.6 représente la répartition des alertes obtenues sur un an d’expérimenta-tion. La majorité des alertes correspondent à des violations de l’intégrité des contextes exécutables. Cette proportion peut s’expliquer par le fait que, dans la majorité des attaques, lorsque l’attaquant ac-cède à notre pot-de-miel, il l’utilise ensuite pour installer un outil de scan ou un robot irc. De ce fait, il télécharge une archive dans le répertoire temporaire ou dans son répertoire utilisateur, puis l’extrait. Or, lors de cette extraction, il crée (donc modifie), pour chaque fichier extrait, un nouvel objet qui est du type exécutable. Ainsi, pour chaque fichier extrait, une alerte de typeintegrityest générée puisque cela correspond à une modification d’un fichier exécutable.

6.3. EXPÉRIMENTATION 167 2% 0% 6% 1% 92%

conformity duties_sep confidentiality bad_transition integrity