Créer votre piège à  pirates

de contamination externe. De plus, je recommande fortement de prendre des notes soignées et abondantes pendant la préparation de chaque session virtuelle. Cette pratique vous donnera une bonne description des pièges à pirates et vous aidera dans l’autopsie ultérieure des systèmes virtuels compromis.

Le profil d’un système virtuel est la configuration spécifique, y compris la mise en place de l’OS et du logiciel tierce partie et l’exposition de certains services. Ainsi, pour tester les vulnérabilités d’une ferme de serveurs Web, vous pourriez établir un profil qui reflète vos serveurs en utilisant un serveur Web Microsoft IIS 5.0 sur Win2K Server, sécurise IIS avec l’outil IIS Lockdown, et utilise un filtre de paquets qui bloque tous les ports sauf TCP 80 et 443. Vous pouvez ensuite sauvegarder cette session virtuelle comme un profil de base puis créer des variantes de ce profil pour ajouter ou enlever des vulnérabilités connues, afin d’affiner davantage les tests du piège à pirates.

Installer l’OS de base est simple mais long dans Virtual PC. Une session virtuelle étant configurée, vous pouvez insérer un CD-ROM initialisable ou une image ISO avec l’OS désiré et effectuer une installation standard. Malheureusement, l’installation des OS dans Virtual PC est plus lente qu’on ne l’imagine. Il m’a fallu environ 20 minutes pour installer Windows 2003 sur l’OS hôte, mais plus de 4 heures pour l’installer dans une machine virtuelle. J’ai essayé de changer l’option par défaut qui régit la manière dont Virtual PC partage la CPU entre l’hôte et les sessions virtuelles, mais aucune modification n’a semblé changer notablement le temps d’installation. Cela dit, il faut reconnaître que, une fois installés, les OS invités fonctionnent très bien.

 Ensuite, il faut configurer chaque session virtuelle avec le profil désiré. C’est-à-dire : configurer l’OS, installer les composants voulus, configurer la sécurité du système, appliquer les packs et les correctifs de service souhaités et installer tout logiciel tierce partie envisagé. Si vous envisagez d’exposer les services publiquement disponibles, comme un serveur Web, assurez-vous que les services sont configurés de façon à masquer le fait qu’ils sont en réalité un piège à pirates. Ainsi, un serveur Web dont le contenu est sans rapport avec l’organisation qui le gère, ou dont le contenu est obsolète, pourrait fort bien éveiller les soupçons d’attaquants potentiels.

Lors du masquage des systèmes, faites bien attention à la signification et à l’implication de deux notions : l’appât ou leurre, légal mais qui soulève quelques réticences sur le plan éthiques, et l’incitation à commettre un délit, carrément illégale. L’exploitation d’un serveur Web piège à pirates anonyme sur votre périmètre peut appâter un attaquant interne et l’inciter à venir. Mais le fait d’envoyer un e-mail à des attaquants potentiels sur l’existence du serveur Web et du contenu potentiel pourrait être considéré comme une incitation abusive. Même si des experts juridiques ne pensent pas qu’un procès basé sur l’incitation avec des pièges à pirates soit gagnable, vous devriez faire votre éducation à ce sujet. (Vous trouverez quelques pistes pour cela dans l’encadré Autres ressources.) La plupart des experts recommandent que les pièges à pirates internes affichent un avertissement indiquant que les utilisateurs doivent être autorisés et s’exposent à être surveillés.

En configurant chaque session virtuelle, assurez-vous qu’elle est capable de fournir les preuves nécessaires. Bien que vous puissiez collecter quelques preuves (comme le trafic du réseau) à partir de l’extérieur d’une session virtuelle, certaines des meilleures preuves d’autopsie viendront d’une session virtuelle compromise. J’active toujours la journalisation pour tous les login/logout, processus, gestion de comptes, et événements de stratégie. Et j’augmente la taille des journaux d’événements.

Ensuite, il faut tester les profils externes et internes de chaque système virtuel pour s’assurer qu’ils fonctionnent comme prévu.

 Par exemple, pour exposer un système utilisant un serveur Web avec un pare-feu poste qui n’autorise que le trafic TCP entrant sur le port 80, il faut utiliser vos outils de test de pénétration pour vérifier que vous avez installé le profil correctement. L’aspect virtuel du profil externe d’une session virtuelle sera pratiquement indétectable. Hélas, il n’en va pas de même du profil interne d’une session virtuelle. Comme Virtual PC émule le matériel, les sessions virtuelles sont installées avec des drivers génériques, de sorte qu’un assaillant peut s’apercevoir rapidement que les sessions sont virtuelles. Le problème sera pratiquement identique avec des sessions VMware, à une exception près : dans Virtual PC, le disque dur a la description Virtual HD et vous ne pouvez pas cacher cette description. La bonne nouvelle est tout de même que l’adoption rapide de la virtualisation au cours des deux dernières années rend les sessions virtuelles plus courantes et, par conséquent, moins suspectes aux yeux d’un attaquant potentiel.

La dernière étape de préparation de sessions virtuelles consiste à faire une sauvegarde de chaque session. Trois raisons à cela : premièrement, l’installation et la configuration de vos sessions demandent beaucoup de travail, et une bonne sauvegarde vous évitera un risque de perte catastrophique. Deuxièmement, si un système est compromis, vous pourrez revenir à son état précédent pour comparaison et analyse. Et, finalement, vous voudrez souvent apporter de petites modifications à la configuration d’une session virtuelle spécifique, pour recueillir davantage de preuves, et la sauvegarde permettra dans ce cas de revenir rapidement à une configuration de base pour procéder aux changements voulus.