TP 5 – Laboratoire : SSH, HTTP et Pare-feu
Des éléments de correction pour ce TP sont disponibles dans le dépôt d'exercices : 👉 module-17 – Corrections
Ce TP utilise jusqu'à 3 cartes réseau par VM. Pour une explication détaillée des types de cartes (NAT, Internal Network, Host-Only, Bridged) et leur équivalent VMware, consultez : 👉 Module 15 - Bonus : Cartes réseau VirtualBox vs VMware
Travail en équipe de deux
| Nom | |
|---|---|
| Étudiant 1 | ........................ |
| Étudiant 2 | ........................ |
Objectifs
Ce laboratoire a pour objectif d'appliquer les connaissances acquises sur les protocoles et services étudiés jusqu'à maintenant (SSH, HTTP, Pare-feu) dans un environnement Linux.
Environnement requis
Hyperviseur
- VirtualBox (ou VMware Workstation / VMware Player)
Machines virtuelles à créer
| Machine | Système d'exploitation | RAM | Disque | CPU | Interfaces réseau |
|---|---|---|---|---|---|
| srvGateway | Ubuntu Server 24.04 LTS (ou 22.04 LTS) | 1 Go minimum | 20 Go | 1 vCPU | 3 interfaces : NAT + Réseau interne lan + Réseau interne clientnet |
| srvSSH | Ubuntu Server 24.04 LTS (ou 22.04 LTS) | 1 Go minimum | 20 Go | 1 vCPU | 1 interface : Réseau interne lan |
| srvWEB | Ubuntu Server 24.04 LTS (ou 22.04 LTS) | 1 Go minimum | 20 Go | 1 vCPU | 1 interface : Réseau interne lan |
| Client | Ubuntu Server 24.04 LTS (ou 22.04 LTS) | 1 Go minimum | 20 Go | 1 vCPU | 1 interface : Réseau interne clientnet |
- srvGateway a besoin de 3 cartes réseau :
- Adapter 1 : NAT (accès Internet)
- Adapter 2 : Internal Network →
lan(réseau LAN10.11.12.0/24) - Adapter 3 : Internal Network →
clientnet(réseau Client20.21.22.0/30)
- srvSSH et srvWEB : Internal Network →
lan - Client : Internal Network →
clientnet
Logiciels requis sur les VMs
| Machine | Logiciels à installer |
|---|---|
| srvGateway | iptables, net-tools |
| srvSSH | openssh-server |
| srvWEB | apache2, openssl, certbot (optionnel) |
| Client | openssh-client, curl, wget |
Le routage IP (ip_forward) doit être activé sur srvGateway pour que le trafic circule entre les réseaux.
Les autres machines (srvSSH, srvWEB, Client) doivent avoir srvGateway comme passerelle par défaut.
Topologie réseau
Description des machines
| Machine | Rôle | Interface(s) |
|---|---|---|
| srvGateway | Routage et passerelle Internet | Interface 1 : NAT (Internet) |
Interface 2 : 10.11.12.1/24 (LAN) | ||
Interface 3 : 20.21.22.1/30 (Client) | ||
| srvWEB | Serveur web Apache | 10.11.12.150/24 |
| srvSSH | Serveur SSH | 10.11.12.100/24 |
| Client | Machine cliente | 20.21.22.2/30 |
Connectivité attendue
srvGatewaya accès à Internet- Le client,
srvWEBetsrvSSHpeuvent accéder à Internet à traverssrvGateway - Le trafic SSH, HTTP et HTTPS est autorisé sur
srvGateway
Le non-respect de la topologie ou la fourniture de captures d'écran ne correspondant pas aux consignes entraînera une pénalité de points.
Partie 1 – Configuration du routage et du partage de connexion (40 points)
1.1 – Configurer les adresses IP statiques
Configurez les adresses IP statiques sur chacune des quatre machines selon la topologie.
Faites une capture des interfaces pour chacune des machines.
1.2 – Activer le routage permanent sur srvGateway
Activez le routage (IP forwarding) de manière permanente sur srvGateway.
Insérez la capture d'écran de l'activation du routage permanent.
1.3 – Configurer le partage de connexion Internet sur srvGateway
Ajoutez des règles iptables pour :
a) Autoriser le trafic sortant depuis le LAN, relayé par srvGateway
Capture requise.
b) N'autoriser que le trafic SSH, HTTP, HTTPS et ICMP pour les autres machines
Capture requise.
c) Activer le MASQUERADE
Capture requise.
d) Tester la connexion Internet
Testez la connexion Internet à partir du client, srvSSH et srvWEB.
Capture requise.
Partie 2 – Configuration des services (40 points)
2.1 – Configurer un serveur web Apache sur srvWEB
a) Créer deux hôtes virtuels
Créez deux hôtes virtuels sur srvWEB :
| Hôte virtuel | Nom de domaine |
|---|---|
| Site 1 | www.test.local |
| Site 2 | www.labo.local |
Capture requise.
b) Pages HTML avec les noms des étudiants
Insérez des pages HTML avec les noms des étudiants de l'équipe.
Capture requise.
c) Fichiers de configuration et pages web
Insérez les captures d'écran des fichiers de configuration et des pages web affichées.
2.2 – Configurer un accès sécurisé en HTTPS
a) Installer des certificats SSL
Installez des certificats SSL pour les deux hôtes virtuels.
Hôtes virtuels concernés :
- www.test.local → certificat auto-signé
- www.labo.local → certificat auto-signé
Capture requise : certificats et pages HTTPS.
2.3 – Restreindre l'accès à srvWEB depuis le client
a) Bloquer l'accès depuis 20.21.22.2
Modifiez la configuration pour bloquer l'adresse 20.21.22.2.
Capture requise.
b) Tester avec curl
Testez avec curl et insérez la capture d'écran du refus d'accès.
Partie 3 – Configuration d'un accès distant (20 points)
3.1 – Configurer un serveur SSH sur srvSSH
a) Créer l'utilisateur bob
Créez un utilisateur bob avec /home/bob et /bin/bash.
Captures requises :
- Sortie de
ss -tan - Sortie de
tail /etc/passwd
3.2 – Configurer une redirection SSH locale (tunnel)
Utilisez un tunnel SSH pour que le client puisse accéder à www.labo.local via srvSSH.
Principe du tunnel SSH :
Captures requises :
- Commande de tunnel SSH
- Accès réussi à
www.labo.localdepuis le client via le tunnel
Récapitulatif de la topologie et des flux
Grille d'évaluation
| Partie | Critères | Points |
|---|---|---|
| Partie 1 | Configuration du routage et du partage de connexion | 40 |
| Configuration des adresses IP statiques + captures | 10 | |
| Activation du routage permanent | 5 | |
| Règles iptables (SSH, HTTP, HTTPS, ICMP) | 10 | |
| MASQUERADE | 5 | |
| Tests de connexion Internet (client, srvSSH, srvWEB) | 10 | |
| Partie 2 | Configuration des services | 40 |
| Hôtes virtuels Apache (www.test.local, www.labo.local) | 10 | |
| Pages HTML avec noms des étudiants | 5 | |
| Fichiers de configuration + pages affichées | 5 | |
| Certificats SSL et HTTPS | 10 | |
| Restriction d'accès (blocage 20.21.22.2) | 5 | |
| Test curl + capture du refus d'accès | 5 | |
| Partie 3 | Configuration d'un accès distant | 20 |
| Utilisateur bob + captures (ss -tan, /etc/passwd) | 10 | |
| Tunnel SSH + accès à www.labo.local | 10 | |
| Total | 100 |
TP créé le : Février 2025
MODULE BONUS – Comprendre le handshake TLS (vulgarisé)
L’objectif ici est d’expliquer, avec des mots très simples, ce qui se passe quand vous tapez une adresse en HTTPS.
Une version “module bonus” (en dehors de ce TP) est disponible ici : Module 15 – Bonus : Handshake TLS (vulgarisé).
1) Avant TLS : le “handshake” TCP (SYN / SYN‑ACK / ACK)
Avant de parler de chiffrement (TLS), il faut d’abord établir la connexion réseau. Pour HTTPS, c’est généralement TCP sur le port 443.
TCP utilise une poignée de main en 3 messages :
- SYN : « Allô, je veux te parler, es-tu là ? »
- SYN‑ACK : « Oui je suis là, et j’ai bien reçu ton SYN. Tu m’entends ? »
- ACK : « Oui, je t’entends, j’ai bien reçu ton message. On peut commencer. »
ACK = Accusé de réception (ça veut juste dire : « j’ai reçu »).
👉 Important : ce handshake TCP ne chiffre rien. Il sert seulement à dire : « la connexion est prête ».
2) Ensuite : le handshake TLS (pour sécuriser la conversation)
Une fois TCP établi, on lance TLS (ce qui rend HTTP → HTTPS).
Pensez à TLS comme à : se mettre d’accord sur un cadenas, vérifier l’identité du serveur, puis parler dans une langue secrète.
Voici l’idée générale (sans entrer dans les détails cryptographiques) :
- ClientHello (client → serveur) :
- « Bonjour, je sais faire TLS, voici les versions et algorithmes que je supporte. »
- ServerHello (serveur → client) :
- « OK, on choisit telle version TLS et tels algorithmes. »
- Le serveur envoie aussi son certificat (sa “carte d’identité”).
- Vérification du certificat (côté client) :
- Le client vérifie que le certificat est valide, correspond bien au nom du site, et est signé par une autorité connue (ou accepté manuellement si auto-signé).
- Création d’un secret partagé :
- Client et serveur mettent en place des clés pour chiffrer (souvent via un échange de clés type Diffie‑Hellman).
- À partir de là, ils peuvent fabriquer des clés de session.
- Finished (des deux côtés) :
- Ils s’envoient un dernier message pour confirmer : « on a les mêmes clés, on est prêts ».
✅ Après ça, tout ce qui suit est chiffré : URL complètes, contenus, mots de passe, cookies, etc.
3) Petit résumé “en une phrase”
- TCP (SYN/SYN‑ACK/ACK) : on ouvre la porte (connexion)
- TLS (ClientHello… Finished) : on met un cadenas et on vérifie l’identité (sécurité)
- HTTP/HTTPS : c’est ce qu’on se dit une fois la porte ouverte et le cadenas en place
- En HTTP, vous verrez le contenu (souvent lisible).
- En HTTPS, vous verrez surtout le handshake TLS puis des paquets chiffrés (contenu illisible).