Création d'un lab de pentest à la maison

Posted on jeu. 18 octobre 2018 in vrac

Depuis un certain temps, j'avais dans la tête l'idée de me créer un lab de pentest chez moi. Le but était d'avoir un "micro-réseau" d'entreprise (avec les éléments qu'on retrouve souvent dans une entreprise classique) pour pouvoir tester des outils et méthodes et monter en compétences sur les différentes technos. Ce genre de lab peut également être utilisé en entreprise pour tester le niveau technique de candidats à un poste de pentester, quel que soit leur niveau théorique. En gros, il y a plein de possibilités, et je me suis dit que ça pourrait intéresser du monde donc je partage !

Conception

Il va falloir héberger plusieurs machines différentes, tout en prenant garde au WAF (ben oui, c'est un lab qui sera à la maison à la base !). Donc difficile de justifier l'achat d'une baie avec une dizaine de serveurs rackés qui tournent (je doute que l'argument "économies de chauffage" suffise à calmer votre moitié...)

Plusieurs solutions sont possibles :

  • Le cloud : En mettant en place des serveurs dédiés ou en utilisant une solution cloud avec provisionning dynamique, vous êtes assurés d'être WAF compliant, moyennant des frais mensuels. Cette solution est pratique puisqu'elle vous débarrasse de la gestion du matériel, mais vous oblige à avoir une connexion Internet pour accéder à votre lab. En plus, si vous souhaitez l'utiliser pour un test technique d'embauche par exemple les contraintes sont plus importantes.
  • La virtualisation : En utilisant un hyperviseur (ESXi ou Proxmox), on peut faire passer tout ce joli petit monde dans une seule machine physique. Au vu de la charge estimée (vous n'aurez pas 200 collaborateurs qui utiliseront votre lab en même temps), on peut faire très facilement cohabiter une petite dizaine de machines dans un PC standard, sans même parler de serveurs. Vous pouvez ainsi déployer facilement votre lab sur n'importe quel réseau en y raccordant votre machine physique.

Pour la virtualisation, pas besoin d'une config gamer à 8000€ avec RGB intégré. Il faut un CPU avec pas mal de coeurs, et de la RAM. Etant donné que les machines virtualisées seront basiques (pas de serveurs de rendu 3D ou de machines de jeu), pas besoin de GPU. En gardant cet aspect et le WAF en tête, je me suis dirigé vers les kits NUC d'Intel. En rajoutant RAM et stockage, on se retrouve avec un petit PC idéal pour ce genre d'usage !

J'ai imaginé les deux configurations suivantes :

(Note : je n'ai ni part ni partenariat avec LDLC, j'aime bien leur site et ils ont des NUCs, c'est tout)

(Note 2 : @LDLC, si vous voulez quand même m'offrir des trucs hésitez pas hein)

Config 1

  • Intel NUC NUC7I7BNHX1 avec un processeur i7-7567U (2 coeurs, 4 threads), un cache SSD intégré à la machine, et un emplacement pour un disque 2,5"
  • Seagate BarraCuda 500 Go : le SSD intégré au NUC servant de cache, le disque dur est là assurer le stockage en permettant d'avoir de l'espace à moindre coût.
  • Crucial SO-DIMM DDR4 16 Go 2400 MHz : en ne mettant qu'une barrette de 16Go, un slot reste disponible si je souhaite passer à 32Go plus tard

Prix total de la configuration : Environ 800€

Ses points forts : le budget reste faible, la présence d'un emplacement 2.5" permet une bonne marge de manoeuvre pour les évolutions et le boîtier est vraiment petit.

Ses points faibles : le CPU ! Un processeur i7 récent, certes, mais de la gamme "U". Destinées aux machines dites "mobiles", les puces de cette gamme ont une faible consommation, ce qui est positif, mais elles manquent cruellement de puissance. De plus, elles sont limitées à 2 coeurs/4 threads, un peu court pour notre projet donc...

Config 2

Prix total de la configuration : Environ 900€

Ses points forts : Le NUC est l'un des premiers de la gamme "gaming NUC" d'Intel : le CPU est d'une génération antérieure, MAIS de la gamme HQ qui offre de meilleures performances et un plus grand nombre de coeurs/threads, plus adaptés pour la virtualisation. En plus, des NUC gaming plus récents existent mais ils sont plus chers, et ils contiennent une carte graphique qui ne nous sert à rien ici.

Ses points faibles : Le prix est plus élévé, et l'absence d'emplacement 2.5" implique une dépense un chouïa plus importante pour le stockage (le double pour une quantité de stockage équivalente, mais de bien meilleures performances).

Le choix

Mon choix a été bien aidé par le fait que j'ai trouvé la RAM et le NUC sur amazon à des prix un peu moins élevés que sur LDLC. Je suis donc parti sur la config 2, ce qui m'a coûté 825€ au lieu des 900€ prévus, pour une puissance bien adaptée à l'usage !

Le système d'exploitation

Pour une solution en virtualisation, il est indispensable d'installer un hyperviseur. Là encore, j'ai envisagé deux possibilités : VMware ESXi ou ProxmoxVE. ESXi a à mon avis les avantages de la stabilité et d'une plus large utilisation dans le milieu professionnel. En revanche, Proxmox a un avantage sur ESXi dans notre cas : il repose sur un système debian complet là où le second repose sur un système minimal (hyperviseur de niveau 2). L'impact sur les performances est compensé par la flexibilité que cela apporte, notamment en termes de gestion du matériel : je n'ai constaté aucun problème avec Proxmox, tout en pouvant facilement faire des expériences avec la configuration des interfaces réseau, la mise en place d'un écran de monitoring, etc...

Attention : en installant Proxmox la première fois, j'ai utilisé pas mal d'options par défaut, dont le choix d'ext4 comme système de fichier. Au moment d'uploader des ISOs de système à installer, leur taille importante a entraîné un blocage du système (4Go, je te regarde Windows Server 2016...). Un suivi des I/O m'a permis de me rendre compte que le processus de journalisation d'ext4 saturait les écritures disque. J'ai donc réinstallé Proxmox en utilisant xfs, et n'ai plus eu de problèmes ensuite.

Réseau

Sur notre lab, on va distinguer plusieurs réseaux : d'une part le réseau permettant d'accéder à l'interface d'administration du Proxmox (qui est donc hors périmètre du lab), et d'autre part les réseaux qui constituent le lab lui-même, et dans l'un desquels on ajoutera l'ordinateur de notre attaquant. On a donc deux points d'entrée, et ça tombe bien, deux interfaces réseau (1 port ethernet et 1 antenne wifi). A noter que l'interface d'administration servirait aussi d'uplink à notre lab pour accéder à internet pendant l'installation des machines.

J'ai donc voulu mettre en place un bridge sur l'interface wifi qui aurait été mon interface d'administration. Et je me suis cassé les dents sur cette histoire : en effet, l'ajout d'une interface wifi à un bridge n'est pas vraiment supporté... Après différentes tentatives, je me suis résolu à utiliser une solution de contournement : un adaptateur USB3/Ethernet me permet d'avoir une interface filaire supplémentaire pour la partie administration/uplink.

Le lab en lui-même contient deux réseaux : un pour les serveurs et un pour les utilisateurs. Celui pour les serveurs est un simple bridge entre machines virtuelles, celui pour les utilisateurs est également un bridge mais il englobe aussi la prise ethernet du NUC pour raccorder la machine de notre attaquant comme un simple utilisateur.

Machines virtuelles

Pour ce réseau minimaliste, j'ai créé les machines virtuelles suivantes :

  • Poste administrateur : un ordinateur sous Windows 7, appartenant à un administrateur (keepass, documents intéressants, etc...)
  • Pare-feu : sous PfSense, assure l'interconnexion entre les réseaux utilisateurs et serveurs du lab. Attention, PfSense étant sous une base FreeBSD, il ne faut pas utiliser des interfaces réseau de type Virtio mais Intel E1000. Le cas contraire entraîne des malformations de paquets.
  • AD : un serveur Windows Server 2016 avec le rôle de contrôleur de domaine Active Directory
  • WSUS : un serveur Windows Server 2012R2 dans le domaine avec le rôle WSUS
  • Web : un serveur web sous debian avec une application PHP (WordPress, application custom...)
  • DB : un serveur MySQL sous debian
  • Mail : un serveur de mail (MTA/MDA) sous debian
  • Filer : un serveur de fichiers Samba sous Debian (raccordé au domaine)

Cet ensemble de services permet d'assurer un éventail de possibilités assez large pour faire des expériences. Il est tout à fait possible de rajouter d'autres machines pour un autre service précis.

Conclusion

Et voilà, votre lab est fini ! Libre à vous de laisser toutes sortes de vulnérabilités ou mauvaises configurations sur vos serveurs et services pour tester outils de détection et autres exploits, c'est votre jouet !

Happy testing !

pentest tools virtualisation lab

Previous Post Next Post