Crazy Infra

Le cabinet fonctionne aujourd'hui sur un disque partagé sans droits, une application métier hébergée sur un poste de travail, et un réseau sans segmentation ni inventaire. Il vous confie la refonte complète de son système d'information.

Expression de besoin

Votre mission — 3 jours

1. Cadrer — rédiger le cahier des charges à partir de ces sept besoins
2. Concevoir — schéma réseau, plan d'adressage, matrice de flux
3. Déployer — réseau, serveurs Windows et Linux, services
4. Auditer — vérifier votre propre travail et documenter l'exploitation

Objectif général : à l'issue de ce projet, vous serez à même de vous projeter dans votre formation en conceptualisant et en réalisant un premier projet d'infrastructure réseau en équipe.

Ce que vous allez toucher, par domaine

Dotation permanente

Banc physique — en rotation

Chaque binôme réserve deux créneaux sur le banc. Objectif : que chacun ait au moins une fois branché un câble console et tapé une commande sur du vrai matériel.

Vos outils sont libres. Packet Tracer et les VM sont le minimum garanti par l'école. Si vous préférez GNS3, VirtualBox, VMware ou Proxmox, allez-y.

Vous êtes 2, parfois 3. Il n'y a donc pas de spécialiste : vous faites tout, tous les deux.

C'est volontaire. Dans une petite structure, personne n'a le luxe de ne faire qu'une seule chose — et c'est exactement la situation dans laquelle vous serez en alternance.

Les casquettes tournantes

Vous ne vous répartissez pas les rôles : vous les alternez. Chaque demi-journée, vous échangez.

La règle du « pourquoi »

Le formateur passera vous demander, au hasard : « pourquoi cette ligne ? »

Ce n'est pas un piège. C'est le seul moyen de distinguer ce que vous avez compris de ce que vous avez copié. Et le jour où quelque chose cassera, seul ce que vous avez compris vous servira.

Missions à répartir dès le départ

Voici un exemple schématisé de l'infrastructure cible

                        INTERNET
                            |
                    +-------+--------+
                    |  ROUTEUR /     |  NAT · relais DHCP
                    |  PARE-FEU      |  regles de filtrage
                    +-------+--------+
                            | trunk 802.1Q
                    +-------+--------+
                    |    SWITCH      |  VLAN · acces / trunk
                    +--+----+----+---+
            +----------+    |    +----------+
      +-----+-----+  +-----+-----+  +-----+-----+
      | VLAN 10   |  | VLAN 20   |  | VLAN 99   |
      | SERVEURS  |  | BUREAUX   |  | ADMIN     |
      | AD · DNS  |  | postes    |  | poste     |
      | DHCP      |  | joints    |  | d'admin   |
      | Linux     |  | au domaine|  |           |
      +-----------+  +-----------+  +-----------+
         SOCLE          SOCLE          SOCLE

      - - - - - - -  OPTIONS  - - - - - - -
      +-----------+  +-----------+  +-----------+
      | VLAN 30   |  | VLAN 40   |  | VLAN 50   |
      | INVITES   |  | DMZ       |  | DONNEES   |
      | Wi-Fi     |  | serveur   |  | base de   |
      | isole     |  | publie    |  | donnees   |
      +-----------+  +-----------+  +-----------+
                                    VLAN 999 natif blackhole

Architecture de référence. Les trois zones estompées sont des options, pas des attendus : le socle obligatoire est en section 5. Les adresses sont celles de la voie A.

Socle obligatoire — tous les binômes

Le syllabus exige les deux mondes. Vous devez mettre en place le projet « en utilisant du matériel physique et des solutions de virtualisation ». La colonne Support ci-dessus n'est donc pas décorative : elle doit figurer sur le schéma que vous rendez. Au minimum, votre switch est physique et vos serveurs sont virtuels. Les Raspberry Pi des bancs comptent comme matériel physique.

Le DHCP est sur le Windows Server, pas sur le pare-feu. C'est un choix, tenez-vous-y : le syllabus vous demande de répartir les rôles sur les deux systèmes, et un DHCP qui vit à deux endroits produit des baux incohérents que vous mettrez une demi-heure à comprendre.
Conséquence : le serveur est dans le VLAN 10, les postes à servir sont dans le VLAN 20. Une requête DHCP ne traverse pas un routeur toute seule. Il vous faut donc un relais sur le pare-feu — ip helper-address côté Cisco, « relais DHCP » côté pfSense. Une ligne à configurer, un concept à comprendre.

Menu d'options — une fois le socle terminé

Si vous ne prenez qu'une option, prenez sauvegarde + restauration. C'est celle qui vous sauvera le plus souvent la vie en entreprise, et personne ne la fait jamais parce qu'elle n'est pas spectaculaire.

Où placer la base de données

Le syllabus vous demande de choisir une solution de base de données. La question qui compte n'est pas laquelle, c'est où la poser. La réponse dépend d'une seule information : qui la consomme.

Pour ce workshop, prenez le VLAN dédié. Il rend visible le découpage en trois couches — présentation en DMZ, application, données — que vous retrouverez partout dans votre carrière. Et il crée une seconde impasse, miroir du VLAN Admin : celui-ci joint tout le monde sans être joignable, la base est jointe par une seule machine et ne joint personne.

Le principe de la DMZ

Si votre client a besoin d'un service accessible depuis Internet, il ne va pas sur le réseau interne. Il va dans une zone à part.

Le test qui prouve que votre DMZ est correcte : depuis le serveur en DMZ, vous tentez de pinguer votre contrôleur de domaine. Ça doit échouer. Si ça répond, votre DMZ n'est qu'un VLAN de plus avec un joli nom.

Vous concevez votre propre plan, cohérent avec le nombre d'utilisateurs annoncé dans votre cahier des charges. Deux voies possibles.

Voie A — un /24 par VLAN

Recommandée si vous découvrez l'adressage. Lisible, sans calcul, sans piège.

Les effectifs viennent de votre client, pas de ce tableau. « Nombre d'utilisateurs et de postes de travail » est la première ligne de l'analyse des besoins du syllabus : c'est ce qui justifie chacun de vos masques. Les chiffres ci-dessus correspondent à une PME d'une vingtaine de personnes — recomptez pour le vôtre.

Voie B — un seul /24 découpé en VLSM

Pour les binômes qui veulent aller plus loin. Plage majeure : 192.168.100.0/24

Conventions imposées — quelle que soit la voie

C'est le document central du projet. Vos règles de pare-feu ne sont que sa traduction. Écrivez-la avant de configurer quoi que ce soit.

Matrice de référence — à adapter à votre client

17 règles. Chacune doit répondre à quatre questions dans votre documentation : qui, vers qui, quel service, et surtout pourquoi.

La règle sortante de la base est celle que personne n'écrit. Une base de données répond à des requêtes ; elle n'a aucune raison d'initier une connexion vers quoi que ce soit. Interdire son trafic sortant arrête la moitié des exfiltrations, parce qu'une base compromise ne peut plus rien envoyer dehors.

L'erreur que vous allez commettre. Vous allez vouloir ouvrir Bureaux → Données sur le port de la base, parce que votre outil d'administration tourne sur votre poste et « il faut bien qu'il se connecte ». C'est ainsi que chaque poste du parc devient un point d'entrée vers les données. Deux issues acceptables, à trancher et à justifier dans votre rapport : soit l'accès passe par l'application, soit l'administration passe par un rebond sur le VLAN 99. Pas de troisième voie.

Audit de votre propre infrastructure

Vous auditez votre propre infrastructure. Vous jouez l'attaquant contre vous-mêmes.

nmap — découvrir ce que vous exposez

nmap -sn 192.168.10.0/24          # Qui est vivant sur le réseau ?
nmap -sV <IP_de_votre_serveur>    # Quels services, quelles versions ?
nmap -p-  <IP_de_votre_serveur>   # Tous les ports — c'est long

Le vrai exercice n'est pas de lancer la commande. C'est de regarder le résultat port par port :

Livrable : un tableau « avant / après » — ports ouverts au premier scan, ports fermés, et pourquoi vous avez gardé les autres.

La station d'audit — vérifier la matrice par la preuve

Dans la maquette 3D, la station d'audit se branche dans le VLAN de votre choix. Lancez le même scan depuis chaque VLAN et regardez ce qui répond. C'est votre matrice de flux, vérifiée empiriquement.

Refaites-le sur votre propre infrastructure, avec le Raspberry Pi du banc d'audit. Vous le débranchez d'un VLAN, vous le rebranchez sur un autre, vous relancez la même commande. Si le résultat ne change pas, votre segmentation n'existe pas.

John the Ripper — comprendre la faiblesse des mots de passe

Lancez l'outil et chronométrez :

Ce que vous devez en retirer et écrire dans votre documentation : la longueur bat la complexité. P@ssw0rd! respecte parfaitement une politique « majuscule + chiffre + caractère spécial » et tombe en quelques secondes. Vous rédigerez donc une politique de mots de passe pour votre client, justifiée par vos propres chronos.

Vous allez manipuler nmap et John the Ripper. Ce sont de vrais outils : ceux qu'utilisent les professionnels, et ceux qu'utilisent les attaquants. La différence entre les deux n'est pas technique. Elle est juridique, et tient en un mot : l'autorisation.

1. Relire le message d'erreur. En entier.
2. Vérifier la couche du dessous :
   câble → interface → VLAN → adresse IP → route → pare-feu → service
3. Demander à son binôme, puis à l'équipe d'à côté
4. Après 15 minutes sans avancer : appeler le formateur

Réflexe de diagnostic — toujours dans cet ordre

Neuf problèmes sur dix seront en couche 2, 3 ou 4. Ne débuggez jamais un service applicatif avant d'avoir vérifié que le paquet arrive.