Évalue la publication sécurisée d'un service Linux en DMZ

01Contrat de l’évaluation

assessmentId : BTS-SISR-Y2-DMZ-001
blocs        : Bloc 1 + Bloc 2 SISR + Bloc 3
format       : TP évalué + panne contrôlée + remédiation + dossier de preuves
contexte     : SORIA Distribution — laboratoire synthétique
objectif     : concevoir → publier → protéger → prouver → diagnostiquer → restaurer

L’enveloppe ne donne pas les commandes de réalisation. L’étudiant choisit les contrôles adaptés à partir des cours techniques et justifie chaque décision.

02Besoin à satisfaire

SORIA Distribution veut rendre un portail Linux accessible à des clients externes simulés sous le nom :

portal.dmz.soria.test

Contraintes imposées :

- le service public utilise HTTPS ;
- le serveur web backend n'est jamais directement accessible depuis la zone externe ;
- le LAN d'administration n'est pas accessible depuis la zone externe ;
- seuls les flux indispensables entre proxy et backend sont autorisés ;
- l'administration des serveurs vient d'une zone dédiée ;
- le certificat présenté est vérifiable et cohérent avec le nom ;
- le service possède une procédure de sauvegarde/restauration testée ;
- un durcissement mesurable est appliqué sans casser le service attendu ;
- les journaux permettent de distinguer problème réseau, proxy, TLS et backend.

Le laboratoire peut utiliser des adresses privées et un certificat de laboratoire. Ces limites doivent être écrites dans le dossier.

03Livrable de conception avant intervention

Avant configuration, remettre :

1. schéma des zones : EXTERNE / DMZ / LAN-ADMIN ;
2. emplacement du pare-feu et des deux serveurs Linux ;
3. rôle de Nginx et rôle d'Apache ;
4. chemin de résolution DNS ;
5. matrice de flux avec source, destination, protocole/port, décision et justification ;
6. liste des tests positifs et négatifs prévus ;
7. plan de retour arrière.

Une matrice dont la décision est « autoriser tout pour tester » est rejetée.

04Baseline saine exigée

Le dossier doit capturer avant changement :

adressage et routes utiles ;
ports en écoute ;
services en échec ;
état du pare-feu / règles utiles ;
état Apache et Nginx si déjà présents ;
résolution DNS initiale ;
point de retour ou snapshot du laboratoire.

Les preuves doivent être horodatées ou suffisamment contextualisées pour distinguer l’avant de l’après.

05Réalisation attendue

Sans procédure fournie, l’étudiant doit obtenir l’architecture logique suivante :

CLIENT-EXT
   |
   | HTTPS 443
   v
PARE-FEU
   |
   +--> NGINX / DMZ
           |
           | flux backend borné
           v
        APACHE / DMZ

ADMIN01 / LAN-ADMIN ---> administration des deux serveurs

Le DNS doit pointer vers le point de publication cohérent avec le laboratoire. Une redirection HTTP vers HTTPS peut être retenue si elle est explicitement justifiée.

06Recette fonctionnelle et de sécurité

L’étudiant choisit ses outils et doit démontrer au minimum :

Tests positifs

- résolution du nom public simulé ;
- connexion TCP au service HTTPS ;
- réponse applicative via le nom attendu ;
- certificat lisible avec SAN et dates ;
- communication Nginx -> Apache sur le flux prévu ;
- accès d'administration depuis la zone autorisée.

Tests négatifs

- CLIENT-EXT -> Apache backend : refusé ;
- CLIENT-EXT -> LAN-ADMIN : refusé ;
- flux DMZ -> LAN non nécessaire : refusé ;
- service sur un port non prévu : non exposé.

Un test négatif réussi signifie ici que l’accès interdit échoue comme prévu.

07Restauration avant durcissement

Avant de réduire davantage l’exposition, l’étudiant doit :

- identifier fichiers de configuration et contenu à protéger ;
- créer ou utiliser une copie de sauvegarde adaptée au laboratoire ;
- enregistrer l'identité du point de restauration ;
- vérifier son intégrité ;
- restaurer réellement sur snapshot, copie de test ou environnement prévu ;
- valider la configuration restaurée ;
- refaire un test applicatif.

Une archive jamais restaurée ne valide pas ce critère.

Le dossier doit distinguer :

snapshot de laboratoire
≠
sauvegarde indépendante de production

08Durcissement observable

L’étudiant propose puis applique au moins trois mesures cohérentes avec son état initial, par exemple :

réduction d'un service ou port inutile ;
suppression du site web par défaut ;
désactivation de l'indexation ;
restriction du chemin d'administration ;
permissions plus strictes sur la clé privée ;
versions TLS bornées ;
réduction d'informations de bannière ;
mise à jour contrôlée avec validation et rollback.

Pour chaque mesure :

risque ou exposition initiale
→ changement
→ vérification après changement
→ effet attendu
→ limite / risque résiduel

Le service doit être retesté après le durcissement.

09Incident imposé

Le formateur sélectionne une carte de panne. L’étudiant ne reçoit ni la commande de correction ni le composant fautif.

Cartes possibles :

A. règle 443 supprimée ou placée dans le mauvais sens ;
B. enregistrement DNS vers une mauvaise adresse ;
C. certificat dont le SAN ne correspond pas au nom ;
D. Nginx actif mais backend Apache arrêté ;
E. Nginx proxy_pass vers un mauvais port ;
F. règle autorisant par erreur CLIENT-EXT -> backend ;
G. permission de clé TLS rendant le rechargement impossible ;
H. configuration Apache invalide après une modification.

Le diagnostic doit procéder par couches. Il est interdit de « corriger » en désactivant globalement le pare-feu, en ouvrant tous les ports ou en supprimant TLS.

10Trace de diagnostic

Pour l’incident, produire une chronologie courte :

symptôme observé
→ hypothèses classées
→ contrôle discriminant
→ cause prouvée
→ correction bornée
→ test de non-régression
→ état final

Le dossier doit contenir au moins une preuve montrant que le composant supposé sain l’était réellement. Exemple : si le HTTPS externe échoue, prouver que le backend répond localement avant d’accuser Apache.

11Jeu minimal de preuves

P01 schéma des zones et flux
P02 matrice de flux validée
P03 baseline avant changement
P04 résolution DNS
P05 certificat : sujet/SAN/dates
P06 réponse HTTPS via le reverse proxy
P07 preuve proxy -> backend
P08 refus externe -> backend
P09 refus externe -> LAN-ADMIN
P10 sauvegarde + contrôle d'intégrité
P11 restauration réellement testée
P12 comparaison avant/après hardening
P13 incident : symptôme + diagnostic + cause
P14 correction + recette de non-régression
P15 limites du laboratoire et risques résiduels

Aucune capture ne doit révéler mot de passe, clé privée, jeton, cookie de session ou secret de production.

12Barème indicatif

Le barème est un outil pédagogique interne SORIA ; il ne prétend pas reproduire une grille officielle d’examen.

13Critères bloquants

Quel que soit le total obtenu, l’évaluation n’est pas considérée comme maîtrisée si l’un des points suivants reste vrai :

service externe accessible uniquement après ouverture générale du pare-feu ;
backend directement exposé sans justification ;
LAN interne accessible depuis la zone externe ;
identité TLS non vérifiée ;
restauration jamais testée ;
durcissement appliqué sans recette après changement ;
incident résolu en supprimant le contrôle de sécurité ;
preuve contenant un secret.

14État final attendu

À la fin, l’étudiant doit pouvoir expliquer en quelques minutes :

pourquoi le portail reste accessible ;
pourquoi le backend et le LAN restent isolés ;
où TLS commence et se termine ;
quels flux sont nécessaires et lesquels sont interdits ;
comment le service est restauré ;
quel durcissement a réellement réduit l'exposition ;
comment l'incident a été localisé sans désactiver les protections ;
quelles limites subsistent dans le laboratoire.

La réussite correspond donc à une publication fonctionnelle, bornée, vérifiable, restaurable et explicable.