Le stage

La structure

J'ai fait mon stage de fin de deuxième année chez JUG_SEC, en distanciel, sur 200 heures effectives.

C'est une structure qui encadre des missions de cybersécurité opérationnelle et qui forme ses stagiaires sur des environnements d'infrastructure complets, du réseau jusqu'à la supervision.

Ce qui m'a décidé à postuler, c'est le format. La plupart des offres que j'avais vues proposaient une mission cloisonnée sur un seul outil. Ici on annonçait la chaîne entière : concevoir, déployer, durcir, superviser, puis attaquer sa propre infrastructure pour voir si elle tient. C'est à peu près ce que je bricolais seul sur mon homelab, sauf qu'il y avait une méthode et quelqu'un pour relire mes choix.

La mission

Le travail consistait à déployer de bout en bout l'infrastructure IT sécurisée d'une PME fictive, sous le nom d'« Operation Sentinel ».

Le scénario posait une entreprise d'une cinquantaine de salariés, avec les besoins classiques d'une boîte de cette taille : des services accessibles depuis Internet, des serveurs applicatifs internes, des postes de travail, et une équipe d'administration qui doit pouvoir tout piloter sans ouvrir de brèche.

Le cadre était fictif, pas la technique. Vraies machines virtuelles, vrais certificats, vrai pare-feu, vrai SIEM. Ce qui était simulé, c'était l'entreprise, pas l'infrastructure. Au bout de trois jours on oublie complètement que le client n'existe pas.

L'environnement de travail

Tout se passait à distance, sans aucun temps de présence sur site.

L'équipe. Trois stagiaires et un encadrant. Deux points fixes par semaine en visio, le lundi pour répartir le travail et le jeudi pour faire le point sur ce qui bloquait. Entre les deux, un salon de discussion pour les questions courtes, et une règle qui s'est installée d'elle-même : on écrit ce qu'on fait au moment où on le fait.

Les outils. Un espace Outline pour la documentation, tenu en continu et en collaboratif. Un dépôt Git partagé pour les fichiers de configuration. Proxmox comme socle de virtualisation, avec un accès à nos propres VM. Rien d'exotique, mais tout centralisé. Ce qui n'était pas dans Outline ou dans le dépôt n'existait pas.

Le rythme. Des journées assez classiques, avec une vraie autonomie sur l'organisation. L'encadrant ne suivait pas les heures, il regardait ce qui avançait et ce qui était documenté. La contrepartie, c'est qu'il fallait savoir se cadrer soi-même. J'en parle plus longuement dans mon billet sur les premiers jours.

Le mode de travail. Beaucoup de travail en parallèle sur une infrastructure commune, ce qui oblige à annoncer ses modifications. Une règle de pare-feu changée sans prévenir, et c'est le chantier d'un autre qui tombe. C'est sans doute ce qui m'a le plus changé par rapport à ma pratique perso.

Ce qu'on a construit

Le socle repose sur un hyperviseur Proxmox, avec un pare-feu OPNsense en coupure qui découpe le réseau en quatre VLAN aux rôles bien séparés.

Le principe tient en une phrase : rien ne traverse un VLAN sans une règle qui l'autorise nommément. Un poste du LAN n'atteint jamais directement un serveur du VLAN SRV, il passe par le reverse proxy. La DMZ, seule zone exposée, ne peut pas initier de connexion vers l'intérieur. Le VLAN d'administration n'est joignable que depuis des sources précises.

Mon périmètre

Sur les 200 heures, mon travail s'est réparti sur cinq chantiers.

Plus une phase de validation en fin de mission : reconnaissance au Nmap, test des règles de segmentation depuis chaque VLAN, et vérification que les permissions inter-VLAN correspondaient bien à la matrice décidée au départ. Autrement dit, attaquer ce qu'on venait de construire pour voir si ça tenait. On y a trouvé deux trous.

La documentation a été tenue en continu sur Outline, en collaboratif. C'est ce qui nous a permis de nous relire mutuellement et, plus d'une fois, de retrouver la raison d'être d'une règle écrite trois semaines plus tôt.

Les articles du blog reviennent en détail sur chacun de ces chantiers.