update cm6

Makefile

@@ -12,16 +12,14 @@ html: $(HTML)
 
 directories: $(OUTDIR)
 
-$(OUTDIR): 
+$(OUTDIR):
 	mkdir $(OUTDIR)
 
 $(OUTDIR)/%.html: %.md $(OUTDIR)
-	pandoc $< -o $@ -s
+	pandoc --from=markdown+lists_without_preceding_blankline $< -o $@ -s
 
 $(OUTDIR)/%.pdf: $(OUTDIR)/%.html
 	wkhtmltopdf $< $@
 
 clean:
 	\rm -rf *.html *.pdf $(OUTDIR)
-
-

README.md

@@ -4,37 +4,41 @@ _François Lesueur ([francois.lesueur@univ-ubs.fr](mailto:francois.lesueur@univ-
 
 Cette page recense les séances du module M3102 "Services réseaux". L'objectif est d'expliquer le fonctionnement d'Internet en tant que réseau de réseaux, Internet est donc notamment l'union des systèmes d'information de tous les acteurs. Séance après séance, vous allez créer un SI minimal (DNS, HTTP, Mail, etc.) interconnectable avec le reste du monde et ainsi constater qu'Internet est le résultat de chaque acteur/AS qui offre et consomme des services.
 
-Ce module se situe entre M2102 (Couches OSI, de la modulation à IP, avec un peu de routage/adressage IP) et M4101C. Il dure 6 semaines, avec chaque semaine 1 séance de cours (1h30) et 2 séances de TD (2*1h30) (attention, pour des raisons d'edt, la séance de cours a en fait lieu à la fin de la semaine précédent les TD). Le contenu sera détaillé au fur et à mesure de la période.
+Ce module se situe entre M2102 (Couches OSI, de la modulation à IP, avec un peu de routage/adressage IP) et M4101C. Il dure 7 semaines, avec chaque semaine 1 séance de cours (1h30) et 2 séances de TD (2*1h30) (attention, pour des raisons d'edt, la séance de cours a en fait lieu à la fin de la semaine précédent les TD).
 
-Une large part des séances pratiques sera réalisée sur la plateforme MI-LXC (https://github.com/flesueur/mi-lxc), pour laquelle il faudra télécharger une VM Virtualbox **avant** le TD1.1 "Découverte de MI-LXC" : [.ova à télécharger ici](https://filesender.renater.fr/?s=download&token=2ca6036b-49b8-4b4c-93bb-95c5de051400). Il faudra arriver en séance avec Virtualbox installé et le .ova de MI-LXC déjà téléchargé, l'installation et la découverte de la VM seront ensuite le programme de la séance TD1.2.
+Une large part des séances pratiques sera réalisée sur la plateforme MI-LXC (https://github.com/flesueur/mi-lxc), pour laquelle il faudra télécharger une VM Virtualbox **avant** le TD1 "Découverte de MI-LXC" : [.ova à télécharger ici](https://flesueur.irisa.fr/mi-lxc/images/milxc-debian-amd64-1.4.2pre3.ova), nous utiliserons la version 1.4.2pre3. Il faudra arriver en séance avec Virtualbox installé et le .ova de MI-LXC déjà téléchargé, l'installation et la découverte de la VM seront ensuite le programme de la séance TD1.
 
 
 ## Programme
 
-* S1 :
+* S19 :
   * [CM1](cm1.md) Introduction "C'est quoi internet ?" et panorama du cours
-  * [TD1.1](td1.1-milxc.md) Découverte MI-LXC
-<!--  * [TD1.2](td1.2-shell.md) Wargame shell -->
-* S2 :
+* S20 :
+  * [TD1](td1-milxc.md) Découverte MI-LXC
   * [CM2](cm2-crypto.md) Cryptographie et sécurité des communications (complément en ligne : [Section "Bases de la crypto"](https://github.com/flesueur/csc/blob/master/cours.md#bases-de-la-crypto))
-  * [TD2.1](td2.1-crypto.md) Cryptographie JdR
-  * TD2.2 Apache/CMS
-* S3 :
-  * CM3 DNS (complément en ligne : [S. Bortzmeyer](https://www.iletaitunefoisinternet.fr/post/1-dns-bortzmeyer/))
-  * TD3.1 DNS(SEC)
-  * TD3.2 CA ACME
-* S4 :
-  * CM4 Mail (complément en ligne : [B. Sonntag](https://www.iletaitunefoisinternet.fr/post/7-email-sonntag/))
-  * TD4.1 SMTP, POP, IMAP
-  * TD4.2 SPF, DKIM, Spam, webmail
-* S5 :
-  * CM5 Firewall (complément en ligne : [Filtrage et surveillance réseau](https://github.com/flesueur/srs/blob/master/cm3-filtrage.md))
-  * TD5.1 IPTables
-  * TD5.2 Architecture réseau
+<!--  * [TD1.2](td1.2-shell.md) Wargame shell -->
+* S21/S22 :
+  * [TD2](td2-crypto.md) Cryptographie JdR
+  * [TD3](td3-passwords.md) Mots de passe
+* S22 :
+  * [TD4](td4-apache.md) Apache/CMS/Tunnels
+  * [CM3](cm3-dns.md) DNS (complément en ligne : [S. Bortzmeyer](https://www.iletaitunefoisinternet.fr/post/1-dns-bortzmeyer/))
+* S23 :
+  * [TD5](td5-dns.md) DNS
+  * [CM4](cm4-mail.md) Mail (complément en ligne : [B. Sonntag](https://www.iletaitunefoisinternet.fr/post/7-email-sonntag/))
+* S24 :
+  * [TD6](td6-mail.md) SMTP, POP, IMAP
+  * [CM5](cm5-archi.md) Architecture réseau et firewall (complément en ligne : [ANSSI](https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/) (chapitre 2))
+* S25 :
+  * [TD7](td7-archi.md) Segmentation réseau et IPTables
+  * [CM6](cm6-wrapup.md) Révisions, questions/réponses
+
+<!--  * TD4.2 SPF, DKIM, Spam, webmail -->
+<!-- * S5 :
+  * [CM5](cm5-archi.md) Architecture réseau et firewall (complément en ligne : [ANSSI](https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/) (chapitre 2))
+  * [TD5.1](td5.1-archi.md) Segmentation réseau et IPTables
 * S6 :
-  * CM6 Administration centralisée
-  * TD6.1 DHCP
-  * TD6.2 SSH, Ansible
+  * [TD6.1](td6.1-tunnels.md) Tunnels et bonus -->
 
 ## Pour les curieux
 

attic/td3.2-https.md

@@ -0,0 +1,167 @@
+TD3.2 Autorités de certification et HTTPS
+=========================================
+
+_Compte-rendu à préparer et déposer en binôme_
+
+Ce TD présente le modèle des autorités de certification et l'applique au protocole HTTPS. L'objectif du TP est de permettre à la machine isp-a-home de naviguer de manière sécurisée sur le site `www.target.milxc` (hébergé sur la machine target-dmz).
+
+
+Ce TD sera réalisé dans la VM MI-LXC disponible [ici](https://filesender.renater.fr/?s=download&token=2f121a18-f94d-45d1-a079-f68229ebdfa9). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+
+> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import puis installer le paquet open-vm-tools-desktop dans la VM pour profiter du redimensionnement automatique du bureau (`apt install open-vm-tools-desktop` dans un shell).
+
+
+Cheat sheet
+===========
+
+Voici un petit résumé des commandes dont vous aurez besoin :
+
+| Commande | Description | Utilisation |
+| -------- | ----------- | ----------- |
+| print    | Génère la cartographie du réseau | ./mi-lxc.py print |
+| attach   | Permet d'avoir un shell sur une machine | ./mi-lxc.py attach root@target-commercial |
+| display  | Lance un affichage sur la machine cible | ./mi-lxc.py display target-commercial |
+| start    | Lance la construction du bac à sable    | ./mi-lxc.py start |
+| stop     | Éteint la plateforme pédagogique        | ./mi-lxc.py stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+Connexion en clair
+==================
+
+Depuis la machine isp-a-home, ouvrez un navigateur pour vous connecter à `http://www.target.milxc`. Vous accédez à une page web, qui est bien la page attendue.
+
+Nous allons maintenant attaquer depuis l'AS ecorp cette communication en clair, non sécurisée, entre isp-a-home et target-dmz. L'objectif est que le navigateur, lorsqu'il souhaite se connecter à l'URL `http://www.target.milxc`, arrive en fait sur la machine ecorp-infra. Deux pistes peuvent être explorées :
+
+* Attaque DNS qui, via le registrar, consisterait à altérer l'enregistrement DNS pour target.milxc dans la zone du TLD .milxc. Sur la machine milxc-ns :
+	* Altération de `/etc/nsd/milxc.zone` pour diriger les requêtes DNS pour `target.milxc` vers 100.81.0.2 (appartenant à ecorp)
+	* Puis `service nsd restart` (le DNS de ecorp est déjà configuré pour répondre aux requêtes pour target.milxc)
+* Attaque BGP qui consisterait à dérouter les paquets à destination de l'AS target vers l'AS ecorp (un [exemple de BGP hijacking réel en 2020](https://radar.qrator.net/blog/as1221-hijacking-266asns)) :
+	* Sur la machine ecorp-router : prendre une IP de l'AS target qui déclenchera l'annonce du réseau en BGP (`ifconfig eth1:0 100.80.1.1 netmask 255.255.255.0`)
+	* Sur la machine ecorp-infra : prendre l'IP de `www.target.milxc` (`ifconfig eth0:0 100.80.1.2 netmask 255.255.255.0`)
+
+Nous constatons ainsi le cas d'attaque que nous souhaitons détecter : un utilisateur sur isp-a-home qui, en tapant l'URL `www.target.milxc`, arrive en fait sur un autre service que celui attendu. Remettez le système en bon ordre de marche pour continuer (pour DNS, remettre la bonne IP 100.80.1.2 ; pour BGP, désactivez l'interface eth1:0 sur ecorp-router `ifconfig eth1:0 down`).
+
+
+Création d'une CA
+=================
+
+Pour sécuriser les communications vers `www.target.milxc`, nous allons créer, déployer et utiliser une CA. Cette CA sera hébergée dans l'AS mica et manipulée sur la machine mica-infra (son nom DNS dans l'infra sera `www.mica.milxc`). Nous utiliserons le protocole ACME (celui de Let's Encrypt) pour l'opération de la CA (challenges, émission des certificats) via la suite d'outils de Smallstep.
+
+Dans un premier temps, il faut initialiser une nouvelle CA en tant que root (création d'une paire de clés, d'un certificat racine, etc.) ([doc](https://smallstep.com/docs/step-ca/getting-started)) :
+
+	# step ca init                  <- le # dénote une commande shell à taper en root
+
+Pour cette initialisation, les paramètres ont peu d'importance (l'essentiel est la création du matériel cryptographique) et les choix suggérés par défaut à chaque question seront suffisants. Il faut juste faire attention aux questions :
+* "What DNS names or IP addresses would you like to add to your new CA?", à laquelle il faut répondre "www.mica.milxc"
+* "What address will your new CA listen at?", à laquelle il faut bien répondre ":443" (comme suggéré par défaut) et non "127.0.0.1:8443" (comme suggéré dans la doc liée précédemment). La CA doit, dans notre cas, écouter sur l'interface réseau externe et non sur localhost pour permettre l'émission du certificat de target-dmz dans la partie suivante.
+* "What do you want your password to be?", à laquelle il est préférable de choisir un mot de passe vous-mêmes
+
+Dans un second temps, il faut activer le protocole ACME pour cette CA ([doc](https://smallstep.com/docs/tutorials/acme-challenge), le protocole ACME est responsable des défis/réponse pour la génération automatique des certificats) : <!-- (https://smallstep.com/blog/private-acme-server/)-->
+
+	# step ca provisioner add acme --type ACME
+
+Il faut démarrer le serveur de la CA (il doit rester actif pour la suite du TP) :
+
+	# step-ca .step/config/ca.json
+
+> La commande step-ca est bloquante, soit vous la mettez en arrière plan avec Ctrl+z puis `bg`, soit vous ouvrez ensuite un autre terminal. Ne la lancez pas avec un &, elle doit en effet demander au lancement le mot de passe de la clé privée, ce qu'elle ne pourrait pas faire lancée avec un &.
+
+Vous aurez besoin du certificat public de la racine par la suite. Le plus simple est de le diffuser par le site web de la CA comme suit. Extrayez-le grâce à la commande suivante :
+
+	# step ca root root.crt         <- ceci extrait le certificat racine vers le fichier root.crt
+
+Puis copiez-le vers `/var/www/html` (avec les droits permettant sa lecture par le serveur web, donc `chmod 644 /var/www/html/root.crt`). Il sera ainsi accessible depuis toutes les autres machines par l'URL `http://www.mica.milxc/root.crt`.
+
+
+
+> Si, après avoir affiché à l'écran un document chiffré (par exemple avec la commande `cat`), votre terminal affiche de mauvais caractères, utilisez la combinaison de touches `Ctrl+v, Ctrl+o` pour retrouver un affichage fonctionnel (ou tapez `reset`).
+
+> Pour reprendre la configuration à 0, il faut supprimer le dossier `/root/.step` sur la machine mica-infra
+
+
+Intégration de la CA à l'écosystème HTTPS
+=========================================
+
+Pour que la CA soit opérationnelle, il faut qu'elle soit reconnue par les clients HTTPS, ie, les navigateurs web (Firefox ici). Cette reconnaissance, dans le cas d'une CA globale, passe par l'intégration du certificat racine dans le magasin de certificats fourni avec le navigateur, donc par l'éditeur de ce navigateur.
+
+> En entreprise, on rencontre souvent une CA locale qui est ajoutée localement au magasin de certificats. Dans ce TP, nous étudions le fonctionnement général de HTTPS global à travers le monde et non un déploiement à l'échelle locale.
+
+Vous devez pour cela :
+* Passer le filtre des éditeurs de navigateurs et les convaincre de reconnaître votre CA. Il s'agit bien évidemment d'une opération complexe, longue, coûteuse et rare. Ici, nous la simulerons chez l'éditeur de navigateur Gozilla. La machine `gozilla-infra` peut intégrer un certificat préalablement téléchargé au trousseau par défaut avec la commande `addcatofox.sh <certificate>` . Une fois cette commande exécutée, la distribution du navigateur (ou de ses mises à jour) intégrera ce nouveau certificat.
+* Déclencher la mise à jour du navigateur par le client, en exécutant `updatefox.sh` en tant que root sur la machine `isp-a-home`
+
+La nouvelle CA est ainsi devenue une CA par défaut, reconnue globalement. Vérifiez, après avoir redémarré Firefox, que vous la retrouvez bien dans le magasin de certiticats de Firefox.
+
+
+Certification du serveur target-dmz
+==================================
+
+Sur l'AS target, vous disposez du serveur target-dmz sur lequel il faut déployer du matériel cryptographique pour faire du HTTPS. Vous devrez notamment :
+
+* Générer une paire de clés et obtenir le certificat correspondant depuis la CA MICA, les clés arrivent dans `/etc/letsencrypt/live/www.target.milxc/` (les erreurs de certbot de type "InsecureRequestWarning" peuvent être ignorées, il faut par contre vérifier que son message final confirme bien la création des clés attendues). Durant cette étape, le serveur MICA va transmettre à certbot des défis (sous forme de chaîne aléatoire) puis va venir les requêter via le nom d'hôte demandé dans le certificat. Si cette requête fonctionne, cela montre que le client certbot est bien situé sur le serveur pour lequel il demande un certificat :
+
+		# certbot certonly -n --apache -d www.target.milxc --server https://www.mica.milxc/acme/acme/directory
+
+* Configurer le matériel cryptographique de ce nouveau site dans le fichier `/etc/apache2/sites-enabled/default-ssl.conf` (vous devrez utiliser la chaîne complète de certificats depuis la racine, c'est-à-dire `fullchain.pem`, et la clé `privkey.pem`).
+* Vous devez redémarrer le serveur apache2 après vos modifications : `service apache2 restart`
+
+Connectez-vous maintenant en HTTPS depuis `isp-a-home` (si vous aviez ajouté une exception de sécurité à un moment du TP, retirez-la avant). Tout doit se dérouler sans alerte, visualisez le certificat reçu. (Vous arrivez sur une page par défaut, le dokuwiki est accessible à l'URL `https://www.target.milxc/dokuwiki/`)
+
+<!-- ou apt install python3-certbot-apache puis un --apache au lieu du --standalone -->
+
+Attaques sur un serveur HTTPS
+=============================
+
+Attaque sur la connexion au serveur
+-----------------------------------
+
+Refaites l'attaque du début (DNS ou BGP) et vérifiez que la connexion depuis isp-a-home, lorsqu'elle est routée vers le serveur attaquant, génère bien une alerte de sécurité.
+
+<!-- il faudrait un certificat plus joli -->
+
+Quelle est d'habitude votre réaction face à ce genre d'alerte ? Que pouvons nous en conclure sur la protection et le risque restant avec HTTPS ?
+
+
+Attaque lors de la création du certificat
+-------------------------------
+
+En reprenant les attaques du début, obtenez depuis ecorp-infra un certificat bien signé par MICA lié à l'URL `www.target.milxc`. Ces attaques DNS/BGP vont vous permettre de vous faire passer pour Target auprès de mica, lors de la phase de création du certificat.
+
+Validez la réussite en vous connectant depuis isp-a-home vers ce faux serveur, maintenant sans alerte de sécurité.
+
+
+Bonus : Authentification mutuelle
+=========================
+
+Mettez en place une authentification des clients par le serveur au moyen de certificats clients.
+
+Déroulé général :
+* Côté serveur (donc target-dmz), vous devez limiter l'accès aux seuls clients détenteurs d'un certificat valide. Dans `/etc/apache2/sites-enabled/default-ssl.conf` :
+	* Paramétrez la directive [SSLCACertificateFile](https://httpd.apache.org/docs/2.4/fr/mod/mod_ssl.html#sslcacertificatefile) en obtenant et spécifiant le crt de la CA (root.crt, pas le crt de ce serveur www.target.milxc !)
+	* Décommentez les directive [SSLVerifyClient require](https://httpd.apache.org/docs/2.4/fr/mod/mod_ssl.html#sslverifyclient) et [SSLVerifyDepth](https://httpd.apache.org/docs/2.4/fr/mod/mod_ssl.html#sslverifydepth) pour forcer l'authentification des clients
+* Validez depuis isp-a-home que l'accès TLS à `https://www.target.milxc` vous est bien refusé
+* Générez un certificat client sur la machine `mica-infra`. Il faut faire un `step ca certificate "VotreNomÀCertifier" client.crt client.key` et utiliser le provisioner par défaut JWK (pas le ACME). Si le programme `step-ca` a été quitté, il faut le relancer préalablement (`step-ca .step/config/ca.json`)
+* Packagez ensemble ce certificat et cette clé client avec `openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12`
+* Le client (la machine isp-a-home) doit récupérer ce client.p12 et l'importer dans Firefox (Préférences -> Sécurité -> Certificats -> Mes certificats -> Importer)
+* Validez que l'accès est maintenant autorisé
+
+<!--
+Bonus : Révocation
+==========
+
+Expérimentez les mécanismes de révocation disponibles (CRL, OCSP en ligne ou agrafé) pour révoquer le certificat serveur ainsi que les certificats clients.
+-->
+
+Révocation
+========
+
+> Dans Smallstep, la révocation par CRL/OCSP n'est pas (encore) gérée. À la place, les certificats ont par défaut une durée courte (24h) et doivent être renouvelés automatiquement, ce qui limite largement le besoin de révocation explicite. Ce positionnement et toutes les limites de la révocation explicite sont très bien expliqués par les auteurs [ici](https://smallstep.com/blog/passive-revocation/)
+
+
+
+<!-- pinning, hsts -->
+
+
+**Votre compte-rendu doit être déposé sur Moodle en fin de journée au format PDF uniquement, un dépôt par binôme.**

attic/td8-tunnels.md

@@ -0,0 +1,106 @@
+TD bonus : Tunnels et bonus (3 heures)
+====================
+
+_Compte-rendu à préparer et déposer en binôme_
+
+Ce TD sera réalisé dans la VM MI-LXC disponible [ici](https://filesender.renater.fr/?s=download&token=2f121a18-f94d-45d1-a079-f68229ebdfa9). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+
+> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import puis installer le paquet open-vm-tools-desktop dans la VM pour profiter du redimensionnement automatique du bureau (`apt install open-vm-tools-desktop` dans un shell).
+
+
+Cheat sheet
+===========
+
+Voici un petit résumé des commandes dont vous aurez besoin :
+
+| Commande | Description | Utilisation |
+| -------- | ----------- | ----------- |
+| print    | Génère la cartographie du réseau | ./mi-lxc.py print |
+| attach   | Permet d'avoir un shell sur une machine | ./mi-lxc.py attach iutva-infra |
+| display  | Lance un affichage sur la machine cible | ./mi-lxc.py display isp-a-home |
+| start    | Démarre la plateforme pédagogique    | ./mi-lxc.py start |
+| stop     | Éteint la plateforme pédagogique        | ./mi-lxc.py stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+Tunnels
+=======
+
+* Dans le TP Firewall, vous avez protégé des _ports_ pour prévenir certains usages
+* En utilisant des tunnels, vous allez voir comment cacher une connexion (par exemple HTTP) dans une autre connexion (par exemple SSH)
+
+SSH
+---
+
+L'outil ssh permet de réaliser des tunnels avec ses options -L (Local) et -R (Remote). Deux exemples :
+* `ssh -L 8080:192.168.1.2:80 192.168.2.4`:
+  * La machine locale ouvre une connexion SSH vers la machine 192.168.2.4
+  * La machine locale ouvre le port 8080 en écoute
+  * Tout ce qui entre localement sur ce port 8080 emprunte le tunnel SSH jusqu'à 192.168.2.4 puis la machine 192.168.2.4 route ces paquets vers 192.168.1.2 sur le port 80
+* `ssh -R 8080:192.168.1.2:80 192.168.2.4` est symétrique :
+  * La machine locale ouvre une connexion SSH vers la machine 192.168.2.4
+  * La machine 192.168.2.4 ouvre le port 8080 en écoute
+  * Tout ce qui entre sur 192.168.2.4 sur ce port 8080 emprunte le tunnel SSH jusqu'au client SSH puis ce client SSH route ces paquets vers 192.168.1.2 sur le port 80
+
+Vous allez mettre en place deux tunnels SSH, chacun depuis target-dev vers isp-a-home :
+* Dans le premier, vous utiliserez -L pour qu'un `curl localhost:8080` exécuté sur target-dev récupère la page sur le serveur web (port 80) de 100.81.0.2 (un site externe dont on aurait souhaité interdire l'accès depuis target)
+* Dans le second, vous utiliserez -R pour qu'un `curl localhost:8080` exécuté sur isp-a-home récupère la page sur le serveur web (port 80) de 100.80.0.5 (l'intranet de target)
+
+> Question 1 : Recopiez les commandes ssh exécutées.
+
+> Question 2 : Utilisez Wireshark (avec le filtre ssh ou http) pour afficher les paquets SSH entre target-dev et isp-a-home et les paquets HTTP vers 100.81.0.2 et 100.80.0.5.
+
+Netcat
+------
+
+
+Imaginez que vous êtes le développeur et que vous souhaitez fournir un accès au serveur web interne de prototypage "target-intranet" à un client externe, alors que celui-ci n'est normalement pas accessible de l'externe ! Vous allez créer un tunnel pour contourner la politique de sécurité. Vous disposez pour cela des machines "target-dev" (votre poste de travail interne) et "isp-a-home" (une machine extérieure, à votre domicile).
+
+Nous allons utiliser l'outil `netcat` pour établir un tunnel très simple.
+
+Connectez-vous sur la machine "isp-a-home". Nous allons commencer par éteindre le service _Apache_ en écoute pour libérer le port 80 qui nous sera utile puis nous allons écouter les connexions sur le port HTTP (TCP/80).
+```bash
+service apache2 stop
+while true; do nc -v -l -p 80 -c "nc -l -p 8080"; done
+```
+
+Enfin, côté "target-dev", nous mettons en place la connexion sortante vers la machine distante:
+```bash
+while true; do nc -v 100.120.0.3 80 -c "nc 100.80.0.5 80"; sleep 2; done
+```
+
+>Pour rappel :
+>* 100.120.0.3 = isp-a-home
+>* 100.80.0.5 = target-intranet
+
+Testez avec la machine "isp-a-hacker" que vous pouvez bien accéder au serveur intranet depuis l'externe sans aucun contrôle via l'URL `http://100.120.0.3:8080`
+
+> Question 3 : À l'aide d'un schéma, expliquez ce tunnel.
+
+> Question 4 : Retrouvez-le dans Wireshark
+
+Il est très difficile de bloquer ou même détecter les tunnels (tunnel chiffré par SSH, ou qui mime une apparence de HTTP, etc.)
+
+> Pour la suite, vous pouvez aborder la section de votre choix entre HTTP, Mail et interactions. Expliquez le déroulé de vos actions dans votre compte-rendu.
+
+HTTP
+====
+
+* Maintenant que l'on a un DNS, configurez des virtualhosts : [doc apache, partie "Fonctionnement de plusieurs serveurs virtuels par nom sur une seule adresse IP."](http://httpd.apache.org/docs/2.4/fr/vhosts/examples.html), [doc adaptée debian](https://linuxize.com/post/how-to-set-up-apache-virtual-hosts-on-debian-10/). Prenez le temps de comprendre le concept : héberger plusieurs sites sur le même serveur, avec des CNAME (au niveau DNS) distincts pointant au final sur la même IP
+* Reprendre le TD2.2 à partir de "PHP"
+
+Le mail
+=======
+
+* Les bonus du TD 4.1
+* Installez un webmail
+
+Les interactions
+================
+Faîtes du Wireshark à plusieurs endroits, reprenez en main l'infra générale et expliquez les différents fonctionnements observés :
+* Par exemple, montrez un enchaînement DNS-SMTP (recherche du MX distant, puis envoi SMTP)
+* Proposez d'autres séquences de protocoles liées à une même action
+
+
+**Votre compte-rendu doit être déposé sur Moodle en fin de journée au format PDF uniquement, un dépôt par binôme.**

cm1.md

@@ -20,7 +20,7 @@ Comment est structuré internet ?
 
 Un réseau de réseaux :
 
-* Acentré (pas de chef, pas de décision unique sans consensus des acteurs indépendants, pas de point de défaillance unique (SPOF)). *Est-ce toujours aussi vrai ? De la panne Facebook aux clouds*
+* Acentré (**pas de chef, pas de décision unique sans consensus des acteurs indépendants, pas de point de défaillance unique (SPOF)**). *Est-ce toujours aussi vrai ? De la panne Facebook aux clouds*
 * Structuré autour de la notion d'AS (systèmes autonomes, environ 100 000) qui forment le découpage de premier niveau
 * Chaque AS (exemple : RENATER, Orange) est ensuite sous-divisé en interne
 * Les AS s'interconnectent entre eux et le protocole BGP assurent la glu entre ces AS
@@ -53,14 +53,12 @@ Panorama du cours
 * Un peu de sécurité des communications (crypto)
 * Du web (HTTP)
 * Du DNS
-* De l'autorité de certification
 * Du mail
 * Du firewall et de l'archi réseau
-* De la gestion centralisée ou à distance : DHCP, SSH, Ansible
 
 
 Les TODO
 ========
 
 * Venir en TD avec son laptop. Combien faut-il en prévoir en complément ?
-* Télécharger l'[ova de MI-LXC](https://filesender.renater.fr/?s=download&token=2ca6036b-49b8-4b4c-93bb-95c5de051400) et installer VirtualBox **avant le premier TD** !
+* Télécharger l'[ova de MI-LXC](https://filesender.renater.fr/?s=download&token=adb51140-dae2-4cc6-ba1c-15cd1f91c913) et installer VirtualBox ou VMWare **avant le premier TD** !

cm2-crypto.md

@@ -5,7 +5,7 @@ CM2 Cryptographie et sécurité des communications - Notes de cours
 À la rencontre d'Alice, Bob et Ernest
 =====================================
 
-Comment permettre à Alice et Bob de communiquer de manière *sûre* sur un canal *non sûr* ?
+Comment permettre à Alice et Bob de communiquer de manière *sûre* sur un canal *non sûr* ? Notion centrale en sécurité/crypto : le **modèle d'attaque**.
 
 * Alice et Bob veulent communiquer, Ernest écoute (attaque passive) ou altère (attaque active) les échanges
 * Le medium non sûr :
@@ -98,7 +98,7 @@ Exemple : le modèle HTTPS
   * nom = nom d'hôte DNS (par exemple www.univ-ubs.fr)
   * tiers = une autorité de certification (par exemple Let's Encrypt)
   * => On a bien une association entre un nom et une clé, ici certifiée par un tiers
-* Le client doit valider la signature de la CA :
+* Le client doit valider la signature de la CA, et ainsi vérifier l'association (clé publique, nom) :
   * Il lui faut donc vérifier avec la clé publique de la CA
   * Les clés publiques des CA reconnues par les clients sont pré-installées dans les navigateurs, pas de magie, il faut une *ancre de confiance* dans le logiciel
 
@@ -106,5 +106,5 @@ Exemple : le modèle HTTPS
 Ce qu'on va faire en TD
 =======================
 
-* TD2.1 : Crypto asymétrique
-* TD3.2 : CA
+* TD2 : Crypto asymétrique
+* TD3 : Stockage des mots de passe

cm3-dns.md

@@ -0,0 +1,169 @@
+CM3 DNS - Notes de cours
+========================
+
+Objectif
+========
+
+* Annuaire nom d'hôte -> IP (et plus largement identifiant -> ressource)
+* Par exemple : `www.univ-ubs.fr -> 51.77.203.125`
+* Une immense base de données distribuée, mise à jour en (presque) continu, multi-parties, robuste, venue des années 1980s...
+* Un élément d'une conception incroyablement visionnaire et pérenne, pierre angulaire qui a donc traversé les époques d'internet
+
+
+La structure
+============
+
+La structure est arborescente :
+
+* Une racine universelle '.'
+* Des nœuds intermédiaires :
+  * Des TLD géographiques ('.fr', '.ch', ...)
+  * Des TLD non-géographiques ('.com', '.net', ...)
+  * Des non-terminaux sous ces TLD ('.eu.org', '.gouv.fr', ...)
+  * Des domaines terminaux ('univ-ubs.fr', 'signal.eu.org', 'enseignementsup-recherche.gouv.fr')
+* Des noms d'hôtes (ou autres identifiants finaux) : 'www.univ-ubs.fr', 'smtp.enseignementsup-recherche.gouv.fr'
+* (la structure est en fait souple, un nœud intermédiaire peut contenir à la fois des identifiants finaux et des sous-domaines)
+
+
+Les acteurs
+===========
+
+* ICANN (gestion des TLD - domaines de premier niveau)
+* Registries (AFNIC pour .fr de France, filiale de Verisign pour .tv des îles Tuvalu)
+* Registrars (Gandi, OVH, ...)
+* Propriétaires de domaines
+
+
+Éléments techniques
+===================
+
+Protocole
+---------
+
+* Historiquement UDP, écoute sur le port 53. Progressivement TCP également.
+* Protocole binaire (et non texte comme HTTP, pas de netcat !)
+* Des outils de dialogue : dig, drill, nslookup
+
+Quelques types d'enregistrements
+--------------------------------
+
+| Type | Contenu | Exemple |
+| ---- | ------- | ------- |
+| A | Enregistrement IPv4 | 1.2.3.4 |
+| AAAA | Enregistrement IPv6 | 2001:0db8:0000:85a3:0000:0000:ac1f:8001 |
+| CNAME | Alias vers un autre nom | www.acme.org |
+| MX | Serveur mail d'entrée (smtp) | smtp.acme.org |
+| SRV | Généralisation du MX à d'autres services | _sip._tcp.acme.org |
+| NS | Serveur de nom | ns.acme.org |
+
+
+Exemple de zone DNS
+-------------------
+
+```
+$TTL	86400
+$ORIGIN target.milxc.
+@  1D  IN  SOA ns.target.milxc. hostmaster.target.milxc. (
+			      2002022401 ; serial
+			      3H ; refresh
+			      15 ; retry
+			      1w ; expire
+			      3h ; nxdomain ttl
+			     )
+      IN  NS     ns.target.milxc.
+      IN  MX  10 smtp.target.milxc.
+ns    IN  A      100.80.1.2
+ns    IN  AAAA   2001:db8:80::1:2
+dmz   IN  A      100.80.1.2
+dmz   IN  AAAA   2001:db8:80::1:2
+smtp  IN  CNAME  dmz
+imap  IN  CNAME  dmz
+www   IN  CNAME  dmz
+```
+
+DNSSEC
+------
+
+* Protocole en clair -> espionnage et altération des réponses
+* DNSSEC contre l'altération des réponses :
+  * Chaque domaine génère une paire de clés asymétriques
+  * Chaque enregistrement de la zone est signé (avec la clé privée, donc)
+  * La clé publique est enregistrée dans la zone supérieure (et donc signée par la clé privée supérieure)
+  * Le client peut donc valider la signature à réception
+
+
+L'architecture
+==============
+
+Serveurs faisant autorité (authoritative servers)
+----------------------------------
+
+* Les serveurs racine qui servent `.` :
+  * 13 entrées IPv4 + IPv6 (a.root-servers.net à m.root-servers.net)
+  * Pour chaque serveur racine, en réalité de nombreux serveurs répartis géographiquement (IP anycast)
+  * Chacune des 13 entrées opérée par une organisation distincte (Verisign (US), ICANN (US), RIPE NCC (NL), WIDE (JP), ...)
+  * Maintenus synchronisés mais gérés distinctement (résilience organisationnelle et logicielle)
+  * Servent la zone racine qui décrit où trouver '.com', '.net', '.fr', etc.
+* Les serveurs à chaque sous-niveau :
+  * Similaire de servir '.org' et '.eu.org', c'est toujours un enregistrement dans le niveau au-dessus
+  * Répondent où trouver dans la zone qui les concerne (ses sous-domaines et ses hôtes)
+* Sont interrogés par les résolveurs et non les clients finaux
+* Exemples : Bind, NSD, PowerDNS, Knot
+
+Résolveurs - Serveurs de résolution
+-----------------------------------
+
+* Sont interrogés par les clients finaux (les OS lors des requêtes par curl, ping, Firefox, ...)
+* Interrogent récursivement les serveurs d'autorité
+* Exemple : Quelle IPv4 pour `www.univ-ubs.fr` ?
+  1. Demande à a.root-servers.org : Qui gère `.fr` ? -> e.ext.nic.fr / 193.176.144.22
+  2. Demande à 193.176.144.22 : Qui gère `univ-ubs.fr` ? -> honehe.univ-ubs.fr. / 193.52.48.66
+  3. Demande à 193.52.48.66 : Qui est `www.univ-ubs.fr` ? -> 51.77.203.125
+* Connaissent donc préalablement les 13 IP des serveurs racine (et la clé publique de la racine pour DNSSEC)
+* Fournis par le FAI pour des raisons historiques mais peut être fait localement
+* Exemples : Bind, Unbound, Dnsmasq
+
+La robustesse (résistance + passage à l'échelle)
+------------------------------------------------
+
+* Grâce à l'architecture par la redondance des serveurs d'autorité
+* Grâce au protocole par le mécanisme de cache
+
+Illustration : [TCP/IP Guide](http://www.tcpipguide.com/free/t_DNSNameResolutionProcess-2.htm)
+
+Les usages autour
+=================
+
+Filtrage
+--------
+
+* Point de passage quasi-obligé, historiquement en clair et classiquement centralisé chez les FAI
+* Au niveau État pour la censure (application de blocage administratif de l'orient à l'occident)
+* Au niveau organisation pour limiter l'accès internet des employés
+* Attention, ce n'est pas une mesure de sécurité car facile à contourner...
+
+Open resolvers
+--------------
+
+* Résolveurs classiques : chez le FAI, dans le SI, chez soi
+* Pour contourner la censure passive, des open resolvers :
+  * Chez Google, Cloudflare, Cisco (à quel prix ?)
+  * Chez FDN
+
+DoT / DoH
+---------
+
+* Résolveurs ouverts ont encore le problème de l'espionnage des communications entre le client et le résolveur
+* DNS-over-TLS et DNS-over-HTTPS pour chiffrer la communication client <-> résolveur
+* Mêmes acteurs que précédemment
+
+Ce qu'on va faire en TD
+=======================
+
+* TD5 DNS
+
+Bonus
+=====
+
+https://jvns.ca/blog/2022/05/10/pages-that-didn-t-make-it-into--how-dns-works-/
+https://jvns.ca/blog/2022/02/01/a-dns-resolver-in-80-lines-of-go/

cm4-mail.md

@@ -0,0 +1,203 @@
+CM4 Mail - Notes de cours
+=========================
+
+Programme
+=========
+
+* Les protocoles du mail : SMTP, IMAP, POP
+* La lutte contre le spam : Antispam, SPF, DKIM, DMARC
+* Les acteurs et l'évolution des forces
+
+Les principes généraux
+======================
+
+* Un domaine = une zone de mail
+* Une adresse mail : idenfiant@domaine
+* Des boîtes à lettres / mailbox : espace disque au nom de 'identifiant' pour chaque compte mail sur le serveur appartenant à 'domaine'
+* Le chemin d'un mail :
+  * MUA - Mail User Agent : client mail (ex Thunderbird, Webmail PHP)
+  * MSA - Mail Submission Agent : serveur SMTP d'envoi (ex Postfix)
+  * MTA* - Mail Transfert Agent : succession de serveurs SMTP (ex Postfix)
+  * MDA - Mail Delivery Agent : Dépôt par un MTA dans une boîte à lettres (ex Dovecot, fdm, sieve)
+  * MUA : client mail en réception IMAP/POP (ex Thunderbird, Webmail PHP)
+
+
+Quelques packages
+=================
+
+* Zimbra : une suite complète SMTP/IMAP/POP/Webmail, avec par exemple Postfix côté SMTP
+* MS Exchange Server _on-premises_ : une suite complète également, basée sur une pile logicielle Microsoft
+* MS Exchange Server _Cloud_, Google suite : hébergement distant d'une suite complète
+
+
+Éléments techniques
+===================
+
+Un ensemble de protocoles en mode texte, le plus souvent utilisés en version TLS. Debug avec `netcat` ou `openssl s_client` (éventuellement avec -starttls).
+
+Envoi
+----
+
+SMTP : deux rôles, un (presque) même protocole :
+
+* Submission agent
+  * TCP, écoute sur 587 (clair + STARTTLS), 465 (TLS)
+  * Reçoit les mails depuis un client MUA
+  * Les transfère au MTA
+* Transfer agent
+  * TCP, écoute sur le port 25
+  * Reçoit des mails d'un MSA ou d'un autre MTA
+  * Les transfère à un MTA ou un MDA
+
+Consultation
+------------
+
+* IMAP : Protocole de consultation avec stockage et organisation côté serveur, port 143 (clair + STARTTLS) ou 993 (TLS)
+* POP : Protocole de consultation avec stockage et organisation côté client (et suppression côté serveur), port 110 (clair + STARTTLS) ou 995 (TLS)
+
+
+Architecture
+============
+
+* Sur les postes de travail : les MUA, clients SMTP et IMAP
+* Sur un serveur opéré par/pour l'organisation locale :
+  * Un MSA pour les envois *depuis* les utilisateurs locaux (au sens réseau ou authentification, à contrôler !), qui ensuite relaie au MTA
+  * Un MTA pour les envois *vers* les utilisateurs locaux, qui écoute donc sur l'extérieur, et dépose les mails
+* Comment un MSA/MTA trouve-t-il le MTA du domaine cible :
+  * Champ MX dans la zone DNS
+  * Un mail envoyé à `toto@acme.org` signifie :
+    * le MTA côté émetteur doit trouver le serveur MX de `acme.org` -> requête DNS
+    * lui envoyer le mail
+    * le serveur cible le dépose dans la boîte de son utilisateur local `toto`
+* On a ainsi un système fédéré :
+  * chaque organisation/domaine s'interconnecte avec les autres, tout le monde peut (en théorie, cf section spam) s'intégrer dans le système et opérer un domaine et ses serveurs SMTP
+  * mais chaque organisation/domaine est responsable de sa gestion interne
+
+
+Quelques aspects de sécurité
+============================
+
+**Le mail est un système peu sécurisé**
+
+Ce qui est sécurisé
+-------------------
+
+* On soumet ses mails en SMTP TLS : chiffré du MUA au MSA
+* Le MSA est généralement local au MTA : pas de communication réseau
+* Les serveurs SMTP discutent de plus en plus en TLS : chiffré entre MTA, mais pas toujours
+* On relève ses mails en IMAP TLS : chiffré du MUA au serveur IMAP
+
+Ce qui n'est pas sécurisé
+-------------------------
+
+* Pas chiffré de bout en bout mais par parties : chaque serveur intermédiaire accède au clair (Allo Google ?)
+* Le chiffrement entre serveurs SMTP n'est qu'opportuniste :
+  * Cela nécessite que le SMTP client demande du TLS
+  * Si un certificat valide est présenté, très bien
+  * Si un certificat non valide est présenté (auto-signé), la plupart l'acceptent encore (il n'y a pas d'interaction utilisateur possible pour accepter/refuser une exception de sécurité)
+  * Si le serveur dit "je ne fais de TLS !", le client reste en clair
+  * Cela laisse toute la marge de manœuvre nécessaire à un attaquant
+  * Conclusion : soit il n'y a pas d'attaquant et la communication sera probablement bien chiffrée (mais son chiffrement était quasi-inutile), soit il y a un attaquant et la communication sera probablement pas/mal chiffrée
+* L'authenticité des messages ! Pas de preuve de l'adresse de l'émetteur, les identités sont usurpables par SMTP spoofing
+
+
+Un peu de lutte contre le SPAM
+------------------------------
+
+Le spam est un fléau qui menace l'utilisabilité du mail et, indirectement par les contre-mesures mises en place, le caractère ouvert et fédéré du système mail.
+
+Les filtres :
+
+* Filtrage côté SMTP destination ou côté client MUA
+* Analyse du texte, de PJ, d'IP source (bases de réputation)
+* À la fois sur le contenu et sur l'éventuelle répétition sur plusieurs connexions (campagne)
+* Parfois avec de l'apprentissage
+* Risque de faux positifs
+* Aboutissent à un système qui responsabilise les SMTP émetteurs : si vous spammez, vos utilisateurs légitimes seront filtrés
+* Mais si votre SMTP est classé spam par Google ou MS, vous avez perdu
+* Ex SpamAssassin
+
+
+Le triptyque SPF/DKIM/DMARC
+===========================
+
+L'usurpation facile d'identité et le besoin de ne pas trop participer aux vagues de spams a amené SPF, DKIM et DMARC comme bonnes pratiques aujourd'hui.
+
+SPF
+---
+
+* Un domaine possède son infrastructure, ses serveurs SMTP
+* Les mails se prétendant d'adresses "@CeDomaine.org" devraient logiquement venir de ses SMTP
+* => Annoncer dans la zone DNS "CeDomaine.org" un enregistrement SPF déclarant les serveurs autorisés à envoyer en son nom
+* Le MSA de "CeDomaine.org" doit authentifier ses utilisateurs, s'assurer qu'il n'autorise à envoyer pour ce domaine que les utilisateurs légitimes. On limite ainsi les usurpations et l'usage de notre nom pour des spams
+* Quand un MTA tiers reçoit un mail "@CeDomaine.org", il fait une requête DNS :
+  - soit il provient du MTA autorisé et il peut l'accepter
+  - soit il provient d'une autre IP et il devrait le refuser
+* Sauf que...
+  - SPF pas toujours bien configuré
+  - Gestion pas toujours simple des tiers autorisés (prestataires de mailings commerciaux, mails automatiques, ...)
+  - Certains réseaux forcent à utiliser l'envoi par leur SMTP local (ex UBS), y compris pour des mails envoyés avec une adresse d'expéditeur externe
+  - Et des problèmes avec les mailing lists
+* Côté réception, on a jamais réussi à filtrer systématiquement sur le SPF, c'est resté une entrée non éliminatoire du filtre anti-spam
+* Il faut l'implémenter en envoi, mais ne pas être contraignant en réception...
+
+DKIM
+----
+
+* Un domaine possède son infrastructure, ses serveurs SMTP
+* Les mails se prétendant d'adresses "@CeDomaine.org" devraient logiquement venir de ses SMTP
+* => Générer une paire de clés cryptographiques, signer avec la clé privée sur ces serveurs, annoncer dans la zone DNS "CeDomaine.org" un enregistrement DKIM déclarant la clé publique autorisée à signer
+* Le MSA de "CeDomaine.org" doit authentifier ses utilisateurs, s'assurer qu'il n'autorise à envoyer pour ce domaine que les utilisateurs légitimes. On limite ainsi les usurpations et l'usage de notre nom pour des spams
+* Quand un MTA tiers reçoit un mail "@CeDomaine.org", il fait une requête DNS :
+  - il obtient la clé publique DKIM pour "@CeDomaine.org"
+  - soit la signature est valide et il peut l'accepter
+  - soit la signature n'est pas valide et il devrait le refuser
+* Sauf que...
+  - DKIM pas toujours bien configuré
+  - Gestion pas toujours simple des tiers autorisés (prestataires de mailings commerciaux, mails automatiques, ...)
+  - Certains réseaux forcent à utiliser l'envoi par leur SMTP local (ex UBS), y compris pour des mails envoyés avec une adresse d'expéditeur externe
+  - Et des problèmes avec les mailing lists
+* Côté réception, on a jamais réussi à filtrer systématiquement sur le DKIM, c'est resté une entrée non éliminatoire du filtre anti-spam
+* Il faut l'implémenter en envoi, mais ne pas être contraignant en réception...
+
+DMARC
+-----
+
+* Constat que SPF et DKIM sont durs à contraindre
+* Le destinataire est en fait mal placé pour refuser systématiquement les échecs SPF/DKIM
+* Permettre à l'émetteur de déclarer sa politique, dire à quel point son usage de SPF/DKIM est complet et ce que le destinataire devrait faire en cas d'échec
+* Ajouter, en plus, une boucle de rétro-action en cas d'échec SPF/DKIM (adresse mail pour les rapports d'échecs, charge à l'émetteur de distinguer ce qui est un échec normal (une usurpation, donc) et ce qui est une erreur de configuration)
+* Un nouvel enregistrement DNS qui dit :
+  - S'il y a du SPF/DKIM
+  - Si un échec doit être ignoré (en cours de déploiement), suspect (donc entrée pour antispam) ou rejet du mail
+* Sauf que...
+  - Peu de domaines à ma connaissance osent aller jusqu'à demander le rejet, mais au moins c'est possible
+  - Toujours les difficultés avec les mailing-lists, les redirections, ... bref, l'historique de l'usage du mail
+* Il faut l'implémenter également
+
+_De la difficulté à faire évoluer une infrastructure fédérée_
+
+
+Les acteurs
+===========
+
+* Plein de petits (chaque domaine peut être autonome, puisque fédéré)
+* Quelques très gros (Google, Microsoft)
+* Les très gros ont un avantage sur le corpus pour les antispam
+* Plus le temps passe, plus il devient difficile d'être un petit :
+  - De nombreuses règles pour limiter le spam complexifient l'administration, ce qui est bien mais augmente le coût
+  - Les gros acteurs poussent vers l'usage de meilleures pratiques, ce qui est bien mais augmente le coût
+  - Les choix des gros acteurs impactent tous les acteurs. Aujourd'hui, le seuil pour maintenir son autonomie mail est de ne *jamais* être classé spam par Google/Microsoft, sinon on a perdu (les clients partent)
+  - La lutte contre le spam, légitime, renforce ainsi les plus gros acteurs, qui ont donc un double intérêt dans cette lutte contre le spam...
+
+
+Ce qu'on va faire en TD
+=======================
+
+* TD6 Mail
+
+
+Biblio
+======
+
+* https://www.learndmarc.com/

cm5-archi.md

@@ -0,0 +1,189 @@
+CM5 Architecture réseau et firewall - Notes de cours
+====================================================
+
+Programme
+=========
+
+* L'objectif de la segmentation
+* Quelques exemples d'architecture
+* Le filtrage par pare-feu
+
+
+Il était une fois les réseaux à plat
+====================================
+
+* Naturellement, comme on l'a fait dans les TD successifs : un subnet, tout le monde dedans !
+* Sauf que c'est en fait une mauvaise idée pour plein de raisons...
+* On va donc sous-diviser en sous-réseaux au niveau IP
+
+Raisons humaines
+----------------
+
+* Un réseau s'administre, donc doit se comprendre
+* Le cerveau humain a ses limites (sisi)
+* Besoin de cartographier, décomposer pour s'y repérer
+* Besoin d'une certaine autonomie/indépendance entre les parties pour maîtriser la gestion de chacune au quotidien
+* Sous-division en sous-réseaux logiques au niveau IP
+* Par exemple géographiques (bâtiments, services, filiales, ...)
+
+Exemple :
+* Partant d'un réseau /16
+  * public (adresses globales) : 134.214.0.0/16 (allant donc de 134.214.0.0 à 134.214.255.255)
+  * ou privé (adresses locales) : 192.168.0.0/16 (allant donc de 192.168.0.0 à 192.168.255.255)
+* Découpage en
+  * 255 réseaux /24 : 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, ..., 192.168.255.0/24
+  * ou 16 réseaux /20 : 192.168.0.0/20, 192.168.16.0/20, 192.168.32.0/20, ... (oui, c'est déjà plus compliqué !)
+  * ou ...
+  * _Les séparations sur les octets (les '.'), c'est le plus simple ; mais la notation CIDR permet les frontières plus fines_
+
+
+Raisons réseau
+--------------
+
+* La couche "Liaison", typiquement Ethernet en-dessous d'IP, n'a pas une scalabilité infinie
+* Broadcast ARP, tables ARP (hôtes, switchs)
+* IP fait aussi du broadcast, sur cette notion de segment Ethernet
+* Tout ceci est du trafic réseau "non-métier", coût bande passante et calcul
+* Besoin de structurer/factoriser la notion de route avec du routage logique : IP
+
+
+Exemple :
+
+* Ethernet, adresses MAC hétérogènes, une table complète, non adapté à un grand nombre d'identifiants
+* IP, addresses IP homogènes, notion de route unique vers un ensemble de machines, passe à l'échelle du nombre d'identifiants
+
+
+Raisons sécurité
+----------------
+
+* La raison directrice aujourd'hui (à mon sens). Pourquoi ?
+  * Parce que les autres raisons sont déjà rentrées dans les mœurs
+  * Parce qu'elle va plus loin et donc, en quelque sorte, inclue les besoins des précédentes
+  * Parce que je suis biaisé !?
+* Limiter la propagation d'une attaque -> Avoir des points de limitation et de contrôle
+* Principe du moindre privilège (des utilisateurs, des machines) -> Limiter les accès
+* Segmentation fonctionnelle selon les rôles/les besoins de réseau/service des machines
+* Et il s'avère que tout ceci se conçoit au niveau IP
+* L'objectif est ainsi de brider les possibilités d'un attaquant par les équipements de confiance au niveau réseau
+
+Exemples de "patrons de segmentation"
+=====================================
+
+La segmentation va avoir pour but de découper son SI en zones isolées afin de :
+
+* Diminuer la surface d'attaque sur chaque zone
+  * Une zone est un ensemble homogène (en terme de sensibilité, d'exposition, de type de service, ...)
+  * Des règles générales limitent l'accessibilité de l'ensemble des machines
+* Compliquer le passage d'une zone à l'autre
+  * Les zones ont des expositions différentes
+  * Les zones ont des sensibilités différentes
+  * Souvent, exposition <> sensibilité
+  * Prévenir la compromission d'une zone sensible à partir d'une zone exposée
+* Un bon guide de l'ANSSI [ici](https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/).
+
+
+Modèle historique (**proscrit** mais on le trouve encore...)
+------------------------------------------------------------
+
+Modèle périmétrique à 3 zones pour limiter la surface d'attaque (les services/machines exposés) :
+
+* WAN : le monde extérieur
+* DMZ : zone tampon, perdable sans mettre en péril le SI, les services très exposés ouverts sur le WAN (exposés => sensibilité la plus faible possible)
+* LAN : les services internes, les postes de travail, tout à plat
+
+Flux :
+
+* WAN -> DMZ : spécifiques
+* WAN -> LAN : aucun !
+* DMZ -> LAN : aucun !
+* LAN -> DMZ, DMZ -> WAN : un peu de filtre mais c'est le sens des communications attendues
+* (évidemment les réponses passent dans l'autre sens)
+
+Par contre, une fois mis un pied dans le réseau, c'est fini... Ex ransomware ou [Paf TV5Monde](https://www.sstic.org/2017/presentation/2017_cloture/)
+
+
+Modèle moderne : segmentation
+-----------------------------
+
+* Parfois appelé le modèle de l'aéroport (des zones publiques, des contrôles successifs, chaque zone plus sécurisée demande des contrôles supplémentaires)
+* Généralisation du concept de DMZ à n segments
+* Considérer que l'attaquant est ou sera là, le limiter dans ses actions une fois entré
+* Une logique de dissocier l'exposition de la sensibilité (les zones exposées peu sensibles, les zones sensibles peu exposées)
+* Un élément de réponse face aux attaques à n sauts, aux ransomwares, ...
+
+Exemple :
+
+* WAN : le monde extérieur
+* Des zones de serveurs :
+  * DMZ externe : les services ouverts sur l'extérieur
+  * DMZ interne : les services internes
+* Des zones de postes de travail, liées aux besoins métiers :
+  * Des zones très peu privilégiées (secrétariat, compta, DIRECTION)
+  * Des zones de développeurs (qui déploient du code sur des sites interne par exemple)
+  * ...
+* Une zone de postes particuliers : les administrateurs, très privilégiés, donc on limite au maximum l'exposition (minimum de postes, règles strictes)
+
+Entre chaque paire de zones :
+* Limiter les flux
+* S'assurer de grader les zones / empêcher les passages vers du plus privilégié
+* Toujours ouvert à l'intérieur d'une même zone, pas de contrôle ici.
+
+
+Vers le zero-trust ?
+--------------------
+
+* Trouver le bon compromis entre la maintenabilité (pas trop de zones) et la précision (une zone par machine)
+* La mode va vers le zero-trust, mais c'est aujourd'hui plus une philosophie et/ou du marketing qu'une réalité
+* Aucun accès par défaut (donc, quelque part, pas de zones), ouverture de chaque flux sur droits spécifiques à chaque fois (SSO+++)
+* On imagine vite la complexité de mise en place
+* Ex Google
+
+
+Cas particuliers
+----------------
+
+* Authentification centralisée :
+  * Comment la rendre accessible à la DMZ ? Elle n'est pas perdable et est sensible !
+  * Proxy ou miroir poussé depuis l'interne
+
+* VPN :
+  * Chemin WAN -> DMZ externe -> zone interne, c'est mal !
+  * Vrai casse-tête en particulier avec toutes les ouvertures post-confinement
+  * Nécessaire, à réfléchir et limiter par utilisateur (un comptable ne doit pas avoir le même accès qu'un développeur)
+  * Dur !
+
+
+
+Quel outillage technique ?
+==========================
+
+(V)LAN
+------
+
+* LAN (physique) premier élément :
+  * Un brin réseau Ethernet
+  * Les LAN sont reliés par des routeurs au niveau IP -> Filtrage !
+* La séparation physique est coûteuse et peu souple :
+  * Un grand LAN unique
+  * Des VLAN administrés
+  * Un VLAN spécifié pour chaque prise réseau
+  * On revient sur la logique du LAN
+
+
+Pare-feu (_Firewall_)
+---------------------
+
+* Ouverture d'une liste de services contrôlés, diminution de la surface d'attaque, matrice de flux
+* Couche IP
+* Simplification (donc avec perte) : 1 service = 1 port
+* Système de règles
+* Une règle : (Interface_src, IP_src, Port_src, IP_dst, Port_dst, Interface_dst) (essentiellement)
+* Filtre uniquement entre des (V)LAN, lorsque le routage IP doit être fait
+* Exemple de règle
+* Ex [iptables](https://fr.wikipedia.org/wiki/Iptables)/[nftables](https://fr.wikipedia.org/wiki/Nftables)
+
+
+Ce qu'on va faire en TD
+=======================
+
+* TD7 IPTables, segmentation

cm6-wrapup.md

@@ -0,0 +1,42 @@
+CM6 Wrap-up + Questions/Réponses - Notes de cours
+================================================
+
+Wrap-up
+=======
+
+Ce que nous avons vu :
+* Internet est un réseau de réseaux autonomes : les AS
+* BGP permet d'établir le routage logique entre ces AS :
+  * Des liens locaux bas-niveau, connexions directes, permettent l'échange des paquets entre voisins. C'est entre ces voisins directs que l'on parle BGP, pour annoncer notre AS ainsi que les AS joignables via nous
+  * Chaque AS découvre ainsi quels autres préfixes sont joignables en multi-saut
+  * Le routage annoncé/paramétré via BGP permet d'établir le routage global, au niveau logique, permettant de communiquer avec l'ensemble du réseau IP
+  * À ce niveau, nous obtenons donc une interconnexion IP globale
+  * Résilience niveau interconnexion IP : BGP est auto-réparant, une route inaccessible sera immédiatement remplacée par une autre possible, si elle existe (et Internet est conçu de manière maillée)
+* DNS permet de nommer les objets sur Internet, typiquement les sites web ou adresses mail, par le système des domaines
+  * Un système arborescent, disjoint de la hiérarchie des adresses IP
+  * Une partie "serveurs faisant autorité", qui hébergent chacun le contenu de la zone dont ils sont responsables et répondent aux requêtes sur cette zone
+  * Une partie "serveurs de résolution/résolveurs", sollicités par les clients, qui vont parcourir les serveurs faisant autorité pour répondre au client
+  * Résilience niveau service DNS : Les serveurs faisant autorité doivent avoir un miroir (au moins), situé dans un autre AS, si possible très disjoint
+* SMTP permet d'échanger des mails entre domaines distincts
+  * Pour émettre un mail, un client (Thunderbird, webmail, ...) transmet cette tâche à son serveur SMTP (chez son FAI, chez son opérateur de mail, ...)
+  * Ce serveur SMTP est ensuite responsable de transmettre au serveur SMTP destination
+  * Les serveurs de réception de `@domain.tld` sont enregistrés en champ MX dans la zone DNS de `domain.tld`
+  * Le serveur côté réception stocke dans son spool
+  * Résilience niveau SMTP : Les serveurs émetteurs réessaient pendant quelques jours + Il faut enregistrer plusieurs MX au niveau DNS
+* IMAP(/POP) permettent de relever ses mails auprès du serveur
+  * SMTP est en charge de déposer (enfin presque... mais on va simplifier) sur le serveur responsable de la boîte mail du destinataire
+  * IMAP permet ensuite la relève par le destinataire
+  * Résilience niveau IMAP : Moins critique, mais on fera du miroir / des sauvegardes
+* Architecture globale et locale
+  * Globalement, à l'échelle d'internet, on a une architecture physique maillée, distribuée, hétérogène, variée et une architecture logique à plat permettant la connectivité totale
+  * Localement, à l'échelle d'un SI, on a une architecture physique arborescente, qui remonte souvent vers un (ou deux) points, moins hétérogène, plus structurée et une architecture logique segmentée pour limiter la connectivité interne
+* Tous les échanges aujourd'hui sont chiffrés
+  * Cryptographie hybride : crypto asymétrique + crypto symétrique
+  * Besoin d'obtenir/valider les clés publiques des interlocuteurs : notion de PKI (autorité de certification, PGP, DANE/TLSA, Keybase, ...)
+  * Il faut 1/s'assurer que l'on chiffre avec la bonne personne (PKI) et 2/chiffrer
+
+
+Questions/Réponses
+==================
+
+(pour l'instant, je fais semblant de ne pas connaître les questions...)

td1-milxc.md

@@ -1,7 +1,9 @@
-TD1.1 Découverte MI-LXC
+TD1 Découverte MI-LXC
 =======================
 
-Ce TP sera réalisé dans la VM MI-LXC disponible [ici](https://filesender.renater.fr/?s=download&token=2ca6036b-49b8-4b4c-93bb-95c5de051400). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+Ce TP sera réalisé dans la VM MI-LXC disponible [ici](https://filesender.renater.fr/?s=download&token=adb51140-dae2-4cc6-ba1c-15cd1f91c913). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+
+Pour vous connecter à la VM, utilisez le compte `root` avec le mot de passe `root`.
 
 MI-LXC simule un internet minimaliste que nous utiliserons tout au long de la matière. Ce TD couvre la découverte de l'environnement existant et les premiers éléments qui seront nécessaires pour l'étendre par la suite. Dans la suite de la matière, vous installerez et configurerez un réseau et des services qui s'interconnecteront avec cet existant.
 
@@ -9,8 +11,9 @@ MI-LXC simule un internet minimaliste que nous utiliserons tout au long de la ma
 
 > La VM peut être affichée en plein écran. Si cela ne fonctionne pas, il faut parfois changer la taille de fenêtre manuellement, en tirant dans l'angle inférieur droit, pour que VirtualBox détecte que le redimensionnement automatique est disponible. Il y a une case adéquate (taille d'écran automatique) dans le menu écran qui doit être cochée. Si rien ne marche, c'est parfois en redémarrant la VM que cela peut se déclencher. Mais il *faut* la VM en grand écran.
 
-> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import puis installer le paquet open-vm-tools-desktop dans la VM pour profiter du redimensionnement automatique du bureau (`apt install open-vm-tools-desktop` dans un shell).
+> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import.
 
+> Le compte-rendu est à déposer en binôme sur Moodle avant mardi 24 mai soir.
 
 Cheat sheet
 ===========
@@ -60,7 +63,7 @@ Toutes les machines ont les deux comptes suivants : debian/debian et root/root (
 
 > Question 3 : Depuis la machine isp-a-home, ouvrez un navigateur pour vous connecter au site web de l'UBS. Cela fonctionne-t-il ? Cette page est-elle hébergée dans l'infrastructure MI-LXC ?
 
-> Question 4 : Ouvrez un shell sur la machine target-dmz (commande attach, donc). Installez le package nano grâce à l'outil `apt` et vérfifiez que vous pouvez maintenant éditer des fichiers avec nano.
+> Question 4 : Ouvrez un shell sur la machine target-dmz (commande attach, donc). Installez le package nano grâce à l'outil `apt` et vérifiez que vous pouvez maintenant éditer des fichiers avec nano.
 
 > Dans la VM et sur les machines MI-LXC, vous pouvez donc installer des logiciels supplémentaires. Par défaut, vous avez mousepad pour éditer des fichiers de manière graphique.
 
@@ -126,7 +129,9 @@ Une fois ceci défini, un `./mi-lxc.py print` pour vérifier la topologie, puis
 
 On peut enfin faire un `./mi-lxc.py start` et vérifier le bon démarrage.
 
-> Attention, pour des raisons de gestion des IP et des routes, étonnamment, il n'y a pas de façon simple pour que le routeur puisse lui-même initier des communications. C'est-à-dire que si tout fonctionne bien il sera démarré, aura de bonnes tables de routage, mais pour autant ne pourra pas ping en dehors du subnet du transitaire. C'est le comportement attendu et donc vérifier la connectivité du routeur ne peut pas se faire comme ça. On verra ensuite comment vérifier cela depuis un poste interne et nous utiliserons, sur le routeur ou ses voisins BGP, les commandes `birdc show route all` et `birdc show protocols` pour inspecter les tables de routage et vérifier l'établissement des sessions BGP.
+<!-- > Attention, pour des raisons de gestion des IP et des routes, étonnamment, il n'y a pas de façon simple pour que le routeur puisse lui-même initier des communications. C'est-à-dire que si tout fonctionne bien il sera démarré, aura de bonnes tables de routage, mais pour autant ne pourra pas ping en dehors du subnet du transitaire. C'est le comportement attendu et donc vérifier la connectivité du routeur ne peut pas se faire comme ça. On verra ensuite comment vérifier cela depuis un poste interne et nous utiliserons, sur le routeur ou ses voisins BGP, les commandes `birdc show route all` et `birdc show protocols` pour inspecter les tables de routage et vérifier l'établissement des sessions BGP. -->
+
+> Sur le routeur ou ses voisins BGP, les commandes `birdc show route all` et `birdc show protocols` permettent d'inspecter les tables de routage et vérifier l'établissement des sessions BGP.
 
 > Question 5 : Quels ajouts avez-vous fait dans `global.json` ?
 

td2-crypto.md

@@ -1,4 +1,4 @@
-TD2.1 : Usage de la cryptographie asymétrique
+TD2 : Usage de la cryptographie asymétrique
 =============================================
 
 _Pas de compte-rendu pour ce TD_
@@ -53,8 +53,6 @@ Ensuite, afin de ne pas retomber dans un chiffrement par substitution simple, le
 
 Enfin, chaque bloc clair de 3 chiffres est chiffré indépendamment par la fonction RSA : bloc<sub>chiffré</sub> = bloc<sub>clair</sub><sup>e</sup>[n]. Attention, _(e,n)_ représente une clé publique, mais celle de qui ? L'utilisation de la clé _(7,1147)_ donne le chiffré `1116 751 245 1108`.
 
-> Attention, si vous utilisez python et non DCODE, lors de l'appel à la fonction `pow(a,b,c)` de python, n'écrivez pas de '0' en début d'entier. Par exemple, pour le bloc clair `031`, tapez `pow(31,7,1147)`. Commencer un entier par '0' le fait interpréter comme un nombre encodé en _octal_ (même principe qu'un nombre commençant par '0x' qui est interprété comme un hexadécimal).
-
 > Pour calculer les exponentiations modulaires, vous pouvez utiliser python (dans l'interpréteur, tapez `pow(a,b,c)` pour obtenir a<sup>b</sup>[c]) ou [DCODE](https://www.dcode.fr/exponentiation-modulaire)<!--[Wolfram Alpha](http://www.wolframalpha.com)-->. Attention, lors des calculs, n'écrivez pas de '0' en début d'entier. Par exemple, pour le bloc clair `031`, tapez `pow(31,7,1147)`. Commencer un entier par '0' le fait interpréter comme un nombre encodé en _octal_ (même principe qu'un nombre commençant par '0x' qui est interprété comme un hexadécimal).
 
 
@@ -116,4 +114,4 @@ Bonus : Attaques sur le cryptosystème proposé
 
 Toutes ces attaques sont possibles ici. Réfléchissez à leur cause et aux protections mises en place dans les cryptosystèmes réels. Implémentez une (ou plusieurs) attaque dans le langage de votre choix, proposez une contre-mesure et évaluez la complexité rajoutée par votre contre-mesure.
 
-!(Don't roll your own crypto)[https://image.slidesharecdn.com/signal-publickeycrypto-181018000453/95/signal-practical-cryptography-40-638.jpg?cb=1539821143]
+![Don't roll your own crypto](https://image.slidesharecdn.com/signal-publickeycrypto-181018000453/95/signal-practical-cryptography-40-638.jpg?cb=1539821143)

td3-code/skeleton.py

@@ -0,0 +1,131 @@
+#!/usr/bin/env python3
+
+import time
+import sys
+from toolbox import *
+
+# You should tweak these values during the work
+nblogins = 10         # would be larger in real-life
+nbpasswords = 1000000 # would be larger in real-life
+nbiterations = 10     # 10000 is currently recommended, should be adapted to the usecase and changed with time (improvement of computation power), like a key size
+
+
+############################################
+# Part of the script to edit               #
+############################################
+
+# Hint : you can call decrypt(key,data) to decrypt data using key
+def crackencrypted(database):
+    key = readfile("enckey")[0]
+    crackeddb = []
+    for i in database:
+        # i[0] is the login, i[1] is the encrypted password
+        #...
+        crackeddb.append((i[0],i[1])) # second argument should contain cleartext password
+    return crackeddb
+
+# Hint : - genshahashes(passwords) returns all the hashes of passwords dictionary
+#        - getpassfromshahash(hashes, hash) returns the password which hashed as "hash" in hashes
+def cracksha(database):
+    global nbpasswords
+    passwords = getPassDict(nbpasswords) # passwords contains a dictionary of passwords
+    #...
+    crackeddb = []
+    for i in database:
+        # i[0] is the login, i[1] is the hashed password
+        #...
+        crackeddb.append((i[0],i[1])) # second argument should contain cleartext password
+    return crackeddb
+
+# Hint : salthash(password, salt) return the salted hash of password
+def cracksaltedsha(database):
+    global nbpasswords
+    passwords = getPassDict(nbpasswords)
+    crackeddb = []
+    for i in database:
+        # i[0] is the login, i[1] is the hashed password, i[2] is the salt
+        #...
+        crackeddb.append((i[0],i[1])) # second argument should contain cleartext password
+    return crackeddb
+
+# Hint : pbkdf2(password, salt, nbiterations) returns the pbkdf2 of password using salt and nbiterations
+def crackpbkdf2(database):
+    global nbpasswords
+    passwords = getPassDict(nbpasswords)
+    crackeddb = []
+    for i in database:
+        # i[0] is the login, i[1] is the hashed password, i[2] is the salt, i[3] is the iteration count
+        #...
+        crackeddb.append((i[0],i[1])) # second argument should contain cleartext password
+    return crackeddb
+
+
+
+############################################
+# Nothing to change after this line !      #
+############################################
+
+
+if __name__ == '__main__':
+    # When called with init
+    if len(sys.argv) > 1 and sys.argv[1] == "init":
+        initworkspace(nblogins,nbpasswords,nbiterations)
+        print("Workspace initialized in files/ subdirectory")
+        exit(0)
+
+    # Test whether init has been called before
+    try :
+        readfile("plain")
+    except FileNotFoundError:
+        initworkspace(nblogins,nbpasswords,nbiterations)
+        print("Workspace initialized in files/ subdirectory")
+
+    # test plain DB
+    print("\n============\nPlain storage:")
+    plaindb = readfile("plain")
+    print("Plain DB is : " + str(plaindb))
+    print("Authenticating with plain DB : " + str(authplain(plaindb[0][0],plaindb[0][1],plaindb)))
+
+    #test encrypted db
+    print("\n============\nEncrypted storage:")
+    encdb = readfile("enc")
+    print("Encrypted DB is " + str(encdb))
+    print("Authenticating with encrypted DB : " + str(authencrypted(plaindb[1][0],plaindb[1][1],encdb)))
+    start = time.time()
+    crackedenc = crackencrypted(encdb)
+    end = time.time()
+    print("Time to crack encrypted DB : " + str(end-start) + " seconds")
+    print("Cracked encrypted DB is " + str(crackedenc))
+
+    #test SHA db
+    print("\n============\nSHA storage:")
+    shadb = readfile("sha")
+    print("SHA DB is " + str(shadb))
+    print("Authenticating with SHA DB : " + str(authsha(plaindb[0][0],plaindb[0][1],shadb)))
+    start = time.time()
+    crackedsha = cracksha(shadb)
+    end = time.time()
+    print("Time to crack SHA DB : " + str(end-start) + " seconds")
+    print("Cracked SHA DB is " + str(crackedsha))
+
+    #test Salted SHA db
+    print("\n============\nSalted SHA storage:")
+    saltedshadb = readfile("saltedsha")
+    print("Salted SHA DB is " + str(saltedshadb))
+    print("Authenticating with Salted SHA DB : " + str(authsaltedsha(plaindb[0][0],plaindb[0][1],saltedshadb)))
+    start = time.time()
+    crackedsaltedsha = cracksaltedsha(saltedshadb)
+    end = time.time()
+    print("Time to crack salted SHA DB : " + str(end-start) + " seconds")
+    print("Cracked salted SHA DB is " + str(crackedsaltedsha))
+
+    # test PBKDF2 DB
+    print("\n============\nPBKDF2 storage:")
+    pbkdf2db = readfile("pbkdf2")
+    print("PBKDF2 DB is " + str(pbkdf2db))
+    print("Authenticating with PBKDF2 DB : " + str(authpbkdf2(plaindb[0][0],plaindb[0][1],pbkdf2db)))
+    start = time.time()
+    crackedpbkdf2 = crackpbkdf2(pbkdf2db)
+    end = time.time()
+    print("Time to crack PBKDF2 DB : " + str(end-start) + " seconds")
+    print("Cracked PBKDF2 DB is " + str(crackedpbkdf2))

td3-code/toolbox.py

@@ -0,0 +1,250 @@
+#!/usr/bin/env python3
+
+# Avoir une lib avec des briques prêtes
+# Avoir un script qui crée les fichiers de password SHA/PB/etc. pour pouvoir les manipuler en texte
+# TD : associer les briques pour évaluer les attaques sur un pass / une base
+# mettre un « except ImportError » et ressayer avec « Cryptodome » a la place de « Crypto »
+
+import re
+import time
+import random
+import hashlib
+# tweak to (try to) handle different crypto lib naming across systems (Linux, Mac, Win)
+try:
+    from Crypto.Cipher import AES
+    from Crypto import Random
+except ImportError:
+    try:
+        from crypto.Cipher import AES
+        from crypto import Random
+    except ImportError:
+        from Cryptodome.Cipher import AES
+        from Cryptodome import Random
+import base64
+import os
+import urllib.request
+import string
+
+# returns an array of a dictionary of passwords
+def getPassDict(nbpasswords):
+    try:
+        f = open("files/passwords.txt")
+    except FileNotFoundError:
+        print("Downloading a passwords list...")
+        urllib.request.urlretrieve("https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt?raw=true", "files/passwords.txt")
+        print("Done !")
+        f = open("files/passwords.txt")
+    passwords = []
+    #nbpasswords = 10000
+    passtogen = nbpasswords
+    for password in f:
+        passwords.append(password.strip())
+        passtogen-=1
+        if passtogen == 0:
+            break
+    return passwords
+
+def genRandomPassword():
+    length = 6
+    chars = string.ascii_letters + string.digits
+    return ''.join(random.choice(chars) for i in range(length))
+
+# reads/writes shadow-style files
+def readfile(filename):
+    f = open("files/"+filename)
+    res = []
+    for line in f:
+        output = line.strip().split(":")
+        res.append(output)
+    return res
+
+def writeFile(filename, array):
+    f = open("files/"+filename,'w')
+    for line in array:
+        towrite = ""
+        for item in line:
+            towrite+=item + ":"
+        towrite = towrite[:-1]
+        f.write(towrite)
+        f.write('\n')
+
+
+# Plain storage
+def genplain(nblogins,nbpasswords):
+    passwords = getPassDict(nbpasswords)
+    logins = []
+    for i in range(0,nblogins):
+        login = "user" + str(i)
+        if (random.randint(0,10) < 4):
+            logins.append((login,passwords[random.randint(0,len(passwords)-1)]))
+        else:
+            logins.append((login,genRandomPassword()))
+    return logins
+
+def authplain(login, passwd, database):
+    for i in database:
+        if i[0] == login:
+            current = i[1]
+    return (current == passwd)
+
+# Encrypted storage
+def genencrypted(logins):
+    encdb = []
+    key = Random.new().read(16)
+    iv = Random.new().read(AES.block_size)
+    f = open("files/enckey",'wb')
+    f.write((base64.b64encode(key)))
+    f.write(b":")
+    #f = open("files/enciv",'wb')
+    f.write((base64.b64encode(iv)))
+    for i in logins:
+        cipher = AES.new(key, AES.MODE_CFB, iv)
+        enc =  (base64.b64encode(cipher.encrypt(i[1].encode('utf-8')))).decode("utf-8")
+        encdb.append((i[0],enc))
+        #print(enc)
+    return encdb
+
+def authencrypted(login, passwd, database):
+    for i in database:
+        if i[0] == login:
+            current = i[1]
+    keyiv = readfile("enckey")[0]
+    key = base64.b64decode(keyiv[0])
+    iv = base64.b64decode(keyiv[1])
+    #key = base64.b64decode(readfile("enckey")[0][0])
+    #iv =  base64.b64decode(readfile("enciv")[0][0])
+    cipher = AES.new(key, AES.MODE_CFB, iv)
+    return (passwd == cipher.decrypt(base64.b64decode(current)).decode('utf-8'))
+
+def decrypt(keyiv,data):
+    key = base64.b64decode(keyiv[0])
+    iv = base64.b64decode(keyiv[1])
+    cipher = AES.new(key, AES.MODE_CFB, iv)
+    return cipher.decrypt(base64.b64decode(data)).decode('utf-8')
+
+
+# SHA storage
+def gensha(logins):
+    db = []
+    for i in logins:
+        csum = hashlib.sha256(i[1].encode('utf-8')).hexdigest()
+        db.append((i[0],csum))
+    return db
+
+def authsha(login, passwd, database):
+    for i in database:
+        if i[0] == login:
+            current = i[1]
+    return (current == hashlib.sha256(passwd.encode('utf-8')).hexdigest())
+
+def genshahashes(passwords):
+    hashes = []
+    for passwd in passwords:
+        hashes.append([hashlib.sha256(passwd.encode('utf-8')).hexdigest(),passwd])
+    return hashes
+
+def getpassfromshahash(hashes, hash):
+    for j in hashes:
+        if j[0] == hash:
+            return j[1]
+    return None
+
+# Salted SHA storage
+def gensaltedsha(logins):
+    db = []
+    for i in logins:
+        salt = str(random.randint(0,65535))
+        csum = hashlib.sha256((i[1]+salt).encode('utf-8')).hexdigest()
+        db.append((i[0],csum,salt))
+    return db
+
+def authsaltedsha(login, passwd, database):
+    for i in database:
+        if i[0] == login:
+            current = i[1]
+            salt = i[2]
+    return (current == hashlib.sha256((passwd+salt).encode('utf-8')).hexdigest())
+
+def salthash(password,salt):
+    return hashlib.sha256((password+str(salt)).encode('utf-8')).hexdigest()
+
+# PBKDF2 storage
+def genpbkdf2(logins,nbiterations):
+    db = []
+    for i in logins:
+        salt = str(random.randint(0,65535))
+        csum = base64.b64encode(hashlib.pbkdf2_hmac('sha256',i[1].encode('utf-8'),str(salt).encode('utf-8'),nbiterations)).decode('utf-8')
+        db.append((i[0],csum,salt,str(nbiterations)))
+    return db
+
+def authpbkdf2(login, passwd, database):
+    for i in database:
+        if i[0] == login:
+            current = i[1]
+            salt = i[2]
+            nbiterations = int(i[3])
+    return (base64.b64decode(current) == hashlib.pbkdf2_hmac('sha256',passwd.encode('utf-8'),str(salt).encode('utf-8'),nbiterations))
+
+def pbkdf2(password,salt,nbiterations):
+    nbiterations = int(nbiterations)
+    return base64.b64encode(hashlib.pbkdf2_hmac('sha256',password.encode('utf-8'),str(salt).encode('utf-8'),nbiterations)).decode('utf-8')
+
+
+# Generate shadow-style files
+def initworkspace(nblogins,nbpasswords,nbiterations):
+    print("Generating " + str(nblogins) + " logins and " + str(nbpasswords) + " passwords")
+    try :
+        os.mkdir("files")
+    except FileExistsError:
+        pass
+    plaindb = genplain(nblogins,nbpasswords)
+    writeFile("plain", plaindb)
+    encdb = genencrypted(plaindb)
+    writeFile("enc", encdb)
+    shadb = gensha(plaindb)
+    writeFile("sha", shadb)
+    saltedshadb = gensaltedsha(plaindb)
+    writeFile("saltedsha", saltedshadb)
+    pbkdf2db = genpbkdf2(plaindb,nbiterations)
+    writeFile("pbkdf2", pbkdf2db)
+
+
+
+# Unit tests
+if __name__ == '__main__':
+    # create shadow files
+    initworkspace(10,100,1000)
+
+    print("======\nUnit tests of the toolbox, you must work in skeleton.py\n=========")
+
+    # test plain DB
+    print("\n============\nPlain storage:")
+    plaindb = readfile("plain")
+    print("Plain DB is : " + str(plaindb))
+    print("Authenticating with plain DB : " + str(authplain(plaindb[0][0],plaindb[0][1],plaindb)))
+
+    #test encrypted db
+    print("\n============\nEncrypted storage:")
+    encdb = readfile("enc")
+    print("Encrypted DB is " + str(encdb))
+    print("Authenticating with encrypted DB : " + str(authencrypted(plaindb[1][0],plaindb[1][1],encdb)))
+
+    #test SHA db
+    print("\n============\nSHA storage:")
+    shadb = readfile("sha")
+    print("SHA DB is " + str(shadb))
+    print("Authenticating with SHA DB : " + str(authsha(plaindb[0][0],plaindb[0][1],shadb)))
+
+    #test Salted SHA db
+    print("\n============\nSalted SHA storage:")
+    saltedshadb = readfile("saltedsha")
+    print("Salted SHA DB is " + str(saltedshadb))
+    print("Authenticating with Salted SHA DB : " + str(authsaltedsha(plaindb[0][0],plaindb[0][1],saltedshadb)))
+
+    # test PBKDF2 DB
+    print("\n============\nPBKDF2 storage:")
+    pbkdf2db = readfile("pbkdf2")
+    print("PBKDF2 DB is " + str(pbkdf2db))
+    print("Authenticating with PBKDF2 DB : " + str(authpbkdf2(plaindb[0][0],plaindb[0][1],pbkdf2db)))
+
+    print("\n======\nUnit tests of the toolbox, you must work in skeleton.py\n=========")

td3-passwords.md

@@ -0,0 +1,105 @@
+TD3 : Stockage et authentification par mot de passe
+=============================================
+
+_Pas de compte-rendu pour ce TD_
+
+Ce TD présente le stockage et l'authentification par mot de passe côté serveur. Il s'agit typiquement du problème rencontré par une application web qui souhaite authentifier ses utilisateurs, ou de ce qui est mis en œuvre dans une base de mots de passes système (/etc/shadow ou LDAP). Pour cela, l'application va stocker en base les comptes existants ainsi que le moyen de les authentifier. Comme il n'est évidemment pas souhaitable de stocker les mots de passe des utilisateurs en clair, nous allons analyser comment résoudre ce problème.
+
+Contexte général
+================
+
+Le scénario d'attaque est une exfiltration des fichiers de l'application (dont le fichier de la base de données ou le fichier `/etc/shadow` par exemple). Vous pouvez consulter une liste non exhaustive de bases ayant été dérobées sur le site [HaveIBeenPwned](https://haveibeenpwned.com/PwnedWebsites) pour vous rendre compte de l'étendue du problème. Dans ce cadre, nous posons les points suivants :
+
+* Le serveur est déjà compromis, l'obtention d'un compte valide sur ce serveur n'a pas d'intérêt pour l'attaquant.
+* Les victimes potentielles sont les utilisateurs du site qui y ont enregistré un compte. En effet, un attaquant pourrait alors essayer de se connecter en leur nom sur des services tiers grâce aux informations récupérées.
+
+Pour limiter ce risque, deux approches complémentaires doivent être mises en place :
+
+1. Le serveur doit compliquer autant que possible la tâche de l'attaquant qui a volé la base en maximisant le temps nécessaire pour obtenir des informations valides à partir de la base (objet de ce TD).
+2. Les utilisateurs, n'ayant pas la possibilité de connaître les contre-mesures mises en place par le serveur, doivent limiter l'impact de cette compromission en utilisant des mots de passes différents, idéalement un pour chaque site (ce qui passe souvent par un gestionnaire de mots de passe, non abordé dans ce TD).
+
+Ces deux mesures sont bien complémentaires car il est du devoir de chaque site de protéger les mots de passes des utilisateurs n'appliquant pas les meilleures pratiques et de chaque utilisateur de protéger au mieux de ses capacités ses mots de passes. Dans le cadre de ce TD, nous analysons la mesure (1), à appliquer côté serveur.
+
+
+Squelette de code fourni
+========================
+
+Vous devez télécharger le squelette de code [ici](td3-code). Vous pouvez récupérer l'intégralité du dépôt en tapant `git clone https://git.kaz.bzh/francois.lesueur/LPCyber.git`, puis aller dans le dossier `td3-code`. Vous pourriez avoir besoin d'installer la bibliothèque python PyCryptodome (de préférence, et nécessaire avec Python 3.8) ou PyCrypto (dépréciée, mais a priori fonctionnelle jusque Python 3.7). Par exemple avec pip3 pour avoir PyCryptodome uniquement (les deux ne peuvent pas coexister sur le système) :
+
+```
+pip3 uninstall PyCrypto
+pip3 install -U PyCryptodome
+```
+
+* `toolbox.py` est la bibliothèque contenant la boîte à outils, il peut être intéressant d'aller la consulter mais elle n'est pas à modifier ;
+* `skeleton.py` contient le programme à écrire.
+
+En début de TD, vous devez lancer `./skeleton.py init` pour créer votre espace de travail. Cette commande, que vous pourrez rappeler plus tard, génère les fichiers suivants (lisibles) dans le sous-dossier `files` :
+
+* `plain` contient la base login/password en clair
+* `enc` contient la base chiffrée en AES (la clé, volée également car nécessairement accessible à proximité sauf cas particulier est dans `enckey`)
+* `sha` contient la base hashée avec SHA256
+* `saltedsha` contient la base hashée/salée avec SHA256
+* `pbkdf2` contient la base avec n itérations de hash salé (PBKDF2)
+
+Vous pouvez visualiser tous ces fichiers dans un éditeur de texte classique et analyser les différents champs présents. Vous pouvez ensuite exécuter `./skeleton.py` (sans argument) qui affichera, pour chaque schéma de stockage :
+
+* le contenu de la base stockée
+* le résultat d'un test unitaire d'authentification (doit toujours être vrai)
+* l'appel (chronométré) à une fonction pour casser la base (fonctions non implémentées dans le squelette fourni)
+
+
+Analyse des différents schémas
+==============================
+
+Pour chaque schéma (clair `plain`, chiffré `enc`, hash `sha`, hash salé `saltedsha`, hash salé coûteux `pbkdf2`), vous devez :
+
+* analyser le processus de l'ajout d'un compte et de la vérification d'un mot de passe
+* proposer la procédure de récupération pour un utilisateur qui a perdu son mot de passe
+* évaluer l'information révélée directement par la base de mots de passe
+* évaluer le coût de cassage d'un mot de passe isolé
+* évaluer le coût de cassage de la base entière
+* implémenter la fonction pour casser la base
+
+
+<!--
+Notations
+=========
+
+* h(m) est le hash du message m
+* Si K<sub>A</sub> est une clé symétrique, {m}<sub>K<sub>A</sub></sub> est le chiffré de m avec la clé K<sub>A</sub>, m = { {m}<sub>K<sub>A</sub></sub>}<sub>K<sub>A</sub></sub>
+* Si Pub<sub>A</sub> et Priv<sub>A</sub> sont des clés asymétriques complémentaires publique/privée, {m}<sub>Pub<sub>A</sub></sub> est le chiffré de m avec la clé Pub<sub>A</sub> et m = { {m}<sub>Pub<sub>A</sub></sub>}<sub>Priv<sub>A</sub></sub>
+* m signé avec la clé Priv<sub>A</sub> est noté m.{h(m)}<sub>Priv<sub>A</sub></sub>
+-->
+
+
+
+
+<!--
+
+Côté client
+===========
+
+Un gestionnaire de mots de passe conserve une table liant un titre, un login et un mot de passe. Par exemple :
+
+| Titre | Login | Password |
+| - | - | - |
+| CDiscount | Alice31 | hujk15tr |
+| laposte.net | AliceLefur@laposte.net | jku78!io |
+| CB | 4785 1547 4554 6657 | 7514 |
+
+Considérons que l'utilisation de ce gestionnaire de mots de passe nécessite la saisie préalable d'un mot de passe maître, lors de l'ouverture.
+
+Proposez la mise en œuvre d'un gestionnaire de mots de passe local puis d'un gestionnaire de mots de passe en ligne. Analysez les risques d'attaques par les différents acteurs (eux-mêmes ou suite à comprommission de leur infrastructure).
+
+-->
+
+Pour approfondir
+================
+
+**Les schémas vus dans ce TD, de manière similaire à ce que nous avons vu côté RSA, sont simplifiés pour comprendre le principe (textbook)**. Pour référence plus précise, vous pouvez ensuite consulter (et garder) :
+
+* [SOPHOS : Serious Security: How to store your users’ passwords safely](https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/)
+* [OWASP : Password Storage Cheat Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)
+* [Micode : 30 000 MOTS DE PASSE CRACKÉS EN 5 MINUTES ! (vidéo)](https://youtu.be/_1ONcmFUOxE)
+* [Des exemples de dictionnaires](https://weakpass.com/wordlist)

td4-apache.md

@@ -0,0 +1,190 @@
+TD4 Apache/CMS/Tunnels
+================
+
+_Compte-rendu à préparer et déposer en binôme_
+
+Ce TD couvre la configuration et l'utilisation d'un serveur HTTP Apache ainsi qu'un CMS Wordpress.
+
+Ce TD sera réalisé dans la VM MI-LXC disponible [ici](https://filesender.renater.fr/?s=download&token=19a6f8f4-0cf8-47a4-bd05-db4b9ea2d4e4). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+
+> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import puis installer le paquet open-vm-tools-desktop dans la VM pour profiter du redimensionnement automatique du bureau (`apt install open-vm-tools-desktop` dans un shell).
+
+
+Cheat sheet
+===========
+
+Voici un petit résumé des commandes dont vous aurez besoin :
+
+| Commande | Description | Utilisation |
+| -------- | ----------- | ----------- |
+| print    | Génère la cartographie du réseau | ./mi-lxc.py print |
+| attach   | Permet d'avoir un shell sur une machine | ./mi-lxc.py attach root@target-commercial |
+| display  | Lance un affichage sur la machine cible | ./mi-lxc.py display target-commercial |
+| start    | Lance la construction du bac à sable    | ./mi-lxc.py start |
+| stop     | Éteint la plateforme pédagogique        | ./mi-lxc.py stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+Conception
+==========
+
+Vous allez étudier une pile serveur LAMP :
+
+* Linux
+* Apache
+* MariaDB (MySQL)
+* PHP
+
+> Question 1 : Sur quel serveur allez-vous installer/configurer cette pile LAMP ? Depuis quelle machine et comment allez-vous tester l'utilisation en tant que client ? Quelles sont les adresses IP de ces deux machines ?
+
+
+Apache - Serveur HTTP
+=====================
+
+Un serveur Apache est déjà installé par défaut. Validez que la connexion à l'Apache du serveur retenu dans la question 1 fonctionne bien avec Firefox depuis le poste client choisi.
+
+Wireshark
+---------
+
+Étudiez la connexion avec Wireshark depuis le poste client (en session graphique "display"). Il faut être root pour lancer wireshark (donc "su" dans le terminal graphique sur le bureau du client avant de lancer wireshark. Attention à faire juste "su" et non "su -" !). Dans wireshark, lancez la capture sur eth0, puis vous pouvez utiliser le filtre "http" pour n'afficher que ce qui a trait au HTTP.
+
+> Question 2 : Décrivez en quelques lignes la connexion HTTP entre le client et le serveur (les quelques échanges ou une capture d'écran de la zone wireshark montrant cet échange)
+
+Connectez-vous ensuite avec deux logiciels clients en ligne de commande (cherchez sur internet comment faire) :
+
+* curl ou wget d'une part
+* netcat (binaire "nc", à lancer avec l'option -C) d'autre part
+
+> Question 3 : Quelles commandes ont permis d'obtenir l'index ? À quoi sert l'option -C de netcat ?
+
+
+Ajout de pages HTML
+-----------------------
+
+La racine du serveur est dans le dossier `/var/www/html`, c'est-à-dire que le contenu de ce dossier est celui servi par le serveur Apache. Retrouvez le fichier d'index que vous aviez précédemment reçu côté client.
+
+Créez un sous-dossier dans `/var/www/html` et ajoutez-y un second fichier html. Récupérez ce nouveau fichier depuis un client.
+
+
+Contrôle d'accès
+----------------
+
+Nous allons maintenant contrôler l'accès au sous-dossier créé (par login/mot de passe).
+
+Vous devez tout d'abord créer un fichier `.htpasswd` qui va contenir les couples login/mot de passe autorisés. Vous pouvez par exemple le placer dans un dossier (à créer) `/etc/apache2/htpasswd/` (pour des raisons de sécurité, on évitera de le placer dans un dossier servi par Apache comme `/var/www/html/...`). Vous utiliserez pour cela la commande `htpasswd` en faisant attention à utiliser la fonction de hachage bcrypt (une option à htpasswd) au lieu du MD5 utilisé par défaut (Explication [ici](https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/), pas à lire en TD mais pour les curieux).
+
+> Question 4 : Quelles commandes avez-vous tapées ? Quel est votre fichier .htpasswd résultat ?
+
+Vous devez ensuite spécifier quel dossier doit être protégé. Vous trouverez le nécessaire dans la [documentation officielle](https://httpd.apache.org/docs/2.4/fr/howto/auth.html), à parcourir jusqu'à la section "Autorisation d'accès à plusieurs personnes" (incluse). Lisez attentivement la partie sur les prérequis, votre fichier de configuration apache2 est `/etc/apache2/apache2.conf` (et non `httpd.conf` comme mentionné à certains endroits de cette documentation).
+
+Vous devez réaliser ce contrôle de 2 façons distinctes :
+* D'abord en intégrant directement les directives `Auth*` dans une section `<Directory>...</Directory>`, par exemple en vous inspirant de la section concernant `/var/www/` dans le fichier de configuration `/etc/apache2/apache2.conf`. Attention à bien exécuter un `systemctl reload apache2` pour prendre en compte les changements dans les `.conf`
+* Ensuite en intégrant un `AllowOverride` dans la section concernant ce même répertoire puis en plaçant un fichier `.htaccess` dans le dossier `/var/www` (AllowOverride est décrit dans la partie "Les prérequis" de la page de documentation officielle)
+
+ Validez chaque fonctionnement en vérifiant que l'authentification est bien demandée au client lors d'une connexion graphique avec Firefox.
+
+> Question 5 : Quelles modifications/ajouts avez-vous fait ?
+
+> Question 6 : Retrouvez dans Wireshark la phase d'authentification.
+
+
+
+PHP
+===
+
+Ajoutez un fichier PHP (un simple hello world) dans le dossier `/var/www/html` puis récupérez-le depuis un client : que constatez-vous ?
+
+Le paquet PHP pour Apache est libapache2-mod-php. Installez-le et validez l'interprétation de votre fichier PHP.
+
+> Question 7 : Faîtes une capture d'écran de votre code source PHP et du résultat dans un navigateur.
+
+
+MariaDB
+=======
+
+MariaDB est un fork de MySQL que nous allons utiliser ici, avec PHPMyAdmin pour aider l'administration (création de bases, d'utilisateurs, etc.).
+
+Installez d'abord mariadb-server. Pour finaliser l'installation, exécutez `mysql_secure_installation`, qui permettra de mieux configurer MariaDB et de spécifier un mot de passe root (par défaut vide et non autorisé).
+
+Installez ensuite phpmyadmin (faîtes bien cela *après* avoir installé mariadb-server, dans un autre apt-get, sinon il y aura une erreur). Lors de l'installation de phpmyadmin, vous aurez à répondre à quelques questions : utilisez la fonctionnalité dbconfig, notez le mot de passe que vous choisirez pour l'utilisateur phpmyadmin et activez la configuration pour apache2.
+
+> Question 8 : Faîtes une capture d'écran de PHPMyAdmin connecté en tant que root
+
+
+WordPress
+=========
+
+Enfin, nous allons installer le CMS WordPress. Un CMS (Content Management System) permet de gérer du contenu. WordPress est un projet libre qui va s'exécuter sur notre pile LAMP.
+
+Vous pouvez procéder de deux façons différentes :
+
+* Installer le paquet debian "wordpress", présent dans les dépôts, puis suivre la documentation associée sur le [wiki Debian](https://wiki.debian.org/WordPress) (configuration apache, création de la base de données, configuration wordpress);
+* Ou suivre la documentation du site [WordPress](https://fr.wordpress.org/txt-install/) (téléchargement et extraction d'un tar.gz, configuration apache, création de la base de données, configuration wordpress).
+
+Enfin, installez un thème, un plugin et écrivez un premier billet
+
+> Question 9 : Faîtes une capture d'écran de votre WordPress fonctionnel
+
+> Question 10 : Comme tout logiciel (que ce soit un binaire compilé depuis un code source C comme le serveur HTTPD Apache ou un code source PHP interprété à l'exécution), WordPress doit être tenu à jour afin d'installer les correctifs de sécurité. Pour chacune des méthodes d'installation, comment se passera ce mécanisme de mise à jour ? Pouvez-vous trouver des avantages et inconvénients à ces méthodes ?
+
+
+Tunnels
+=======
+
+En utilisant des tunnels, vous allez voir comment cacher une connexion (par exemple HTTP) dans une autre connexion (par exemple SSH)
+
+SSH
+---
+
+L'outil ssh permet de réaliser des tunnels avec ses options -L (Local) et -R (Remote). Deux exemples :
+* `ssh -L 8080:192.168.1.2:80 192.168.2.4`:
+  * La machine locale ouvre une connexion SSH vers la machine 192.168.2.4
+  * La machine locale ouvre le port 8080 en écoute
+  * Tout ce qui entre localement sur ce port 8080 emprunte le tunnel SSH jusqu'à 192.168.2.4 puis la machine 192.168.2.4 route ces paquets vers 192.168.1.2 sur le port 80
+* `ssh -R 8080:192.168.1.2:80 192.168.2.4` est symétrique :
+  * La machine locale ouvre une connexion SSH vers la machine 192.168.2.4
+  * La machine 192.168.2.4 ouvre le port 8080 en écoute
+  * Tout ce qui entre sur 192.168.2.4 sur ce port 8080 emprunte le tunnel SSH jusqu'au client SSH puis ce client SSH route ces paquets vers 192.168.1.2 sur le port 80
+
+Vous allez mettre en place deux tunnels SSH, chacun depuis target-dev vers isp-a-home :
+* Dans le premier, vous utiliserez -L pour qu'un `curl localhost:8080` exécuté sur target-dev récupère la page sur le serveur web (port 80) de 100.81.0.2 (un site externe dont on aurait souhaité interdire l'accès depuis target)
+* Dans le second, vous utiliserez -R pour qu'un `curl localhost:8080` exécuté sur isp-a-home récupère la page sur le serveur web (port 80) de 100.80.0.5 (l'intranet de target)
+
+> Question 11 : Recopiez les commandes ssh exécutées.
+
+> Question 12 : Utilisez Wireshark (avec le filtre ssh ou http) pour afficher les paquets SSH entre target-dev et isp-a-home et les paquets HTTP vers 100.81.0.2 et 100.80.0.5.
+
+Netcat
+------
+
+
+Imaginez que vous êtes le développeur et que vous souhaitez fournir un accès au serveur web interne de prototypage "target-intranet" à un client externe, alors que celui-ci n'est normalement pas accessible de l'externe ! Vous allez créer un tunnel pour contourner la politique de sécurité. Vous disposez pour cela des machines "target-dev" (votre poste de travail interne) et "isp-a-home" (une machine extérieure, à votre domicile).
+
+Nous allons utiliser l'outil `netcat` pour établir un tunnel très simple.
+
+Connectez-vous sur la machine "isp-a-home". Nous allons commencer par éteindre le service _Apache_ en écoute pour libérer le port 80 qui nous sera utile puis nous allons écouter les connexions sur le port HTTP (TCP/80).
+```bash
+service apache2 stop
+while true; do nc -v -l -p 80 -c "nc -l -p 8080"; done
+```
+
+Enfin, côté "target-dev", nous mettons en place la connexion sortante vers la machine distante:
+```bash
+while true; do nc -v 100.120.0.3 80 -c "nc 100.80.0.5 80"; sleep 2; done
+```
+
+>Pour rappel :
+>* 100.120.0.3 = isp-a-home
+>* 100.80.0.5 = target-intranet
+
+Testez avec la machine "isp-a-hacker" que vous pouvez bien accéder au serveur intranet depuis l'externe sans aucun contrôle via l'URL `http://100.120.0.3:8080`
+
+> Question 13 : À l'aide d'un schéma, expliquez ce tunnel.
+
+> Question 14 : Retrouvez-le dans Wireshark
+
+Il est très difficile de bloquer ou même détecter les tunnels (tunnel chiffré par SSH, ou qui mime une apparence de HTTP, etc.)
+
+
+**Votre compte-rendu doit être déposé sur Moodle au format PDF uniquement**

td5-dns.md

@@ -0,0 +1,157 @@
+TD5 DNS (3 heures)
+====================
+
+_Compte-rendu à préparer et déposer en binôme_
+
+Ce TD couvre la configuration et l'utilisation du DNS, à la fois côté serveurs d'autorité et de résolution.
+
+Ce TD sera réalisé dans la VM MI-LXC disponible [ici](https://filesender.renater.fr/?s=download&token=19a6f8f4-0cf8-47a4-bd05-db4b9ea2d4e4). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+
+> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import puis installer le paquet open-vm-tools-desktop dans la VM pour profiter du redimensionnement automatique du bureau (`apt install open-vm-tools-desktop` dans un shell).
+
+
+Cheat sheet
+===========
+
+Voici un petit résumé des commandes dont vous aurez besoin :
+
+| Commande | Description | Utilisation |
+| -------- | ----------- | ----------- |
+| print    | Génère la cartographie du réseau | ./mi-lxc.py print |
+| attach   | Permet d'avoir un shell sur une machine | ./mi-lxc.py attach target-commercial |
+| display  | Lance un affichage sur la machine cible | ./mi-lxc.py display target-commercial |
+| start    | Démarre la plateforme pédagogique    | ./mi-lxc.py start |
+| stop     | Éteint la plateforme pédagogique        | ./mi-lxc.py stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+DNSVIZ (1h)
+===========
+
+Depuis un navigateur quelconque (dans MI-LXC, dans la VM, ou sur l'hôte), allez consulter le site [https://dnsviz.net/](https://dnsviz.net/). Étudiez les noms suivants (on se contentera, sauf mention contraire, de la vue "DNSSEC" qui permet la visualisation de la chaîne DNS en plus de DNSSEC) et notez les réponses aux questions dans votre compte-rendu (question 1) :
+
+* univ-ubs.fr
+	* La zone est-elle signée (intégrité DNSSEC) ?
+	* La zone est-elle bien servie par plusieurs serveurs de noms (NS) distincts ? Ces serveurs de noms sont-ils géographiquement/administrativement bien séparés ? (vous pouvez obtenir leurs IP dans l'onglet "Servers", puis regarder leurs organisations/AS sur le site [https://ipinfo.io/](https://ipinfo.io/) par exemple)
+	* À quelle adresse IPv4 doivent être envoyés les mails à destination de 'contact@univ-ubs.fr' (enregistrement MX) ?
+* www.univ-ubs.fr
+	* L'entrée est-elle signée DNSSEC ?
+	* À quelle adresse IPv4 faut-il se connecter pour accéder à 'www.univ-ubs.fr' ?
+* www.google.com
+	* L'entrée est-elle signée DNSSEC ?
+	* Trouvez une adresse IPv6 correspondant à ce nom
+* www.elysee.fr
+	* Cet enregistrement contient-il certaines alertes (_warnings_) ?
+	* Cet enregistrement redirige vers une autre zone. Avec quelques recherches (le nom de domaine ciblé, wikipedia, etc.), vers quelle entreprise cela redirige-t-il ? Dans quel pays est-elle basée ?
+* www.ssi.gouv.fr
+	* Voyez-vous la zone parente 'gouv.fr' ?
+* www.enisa.europa.eu
+	* L'ENISA (organisme sécurité numérique EU) est-il dans une démarche d'utilisation de DNSSEC ?
+	* Est-ce bien réalisé ?
+* www.bortzmeyer.org et www.cloudflare.net
+	* L'entrée est-elle bien signée ?
+	* Les serveurs DNS sont-ils bien répartis dans des AS différents ?
+* www.whitehouse.gov et www.fbi.gov
+	* Ces domaines sont-ils simples ?
+	* Vous semblent-ils pour autant relativement bien construits et sécurisés ?
+* www.netflix.com et www.banque-france.fr
+ 	* Non, rien, pas de question ici...
+
+
+
+Focus sur le DNS dans MI-LXC (20 minutes)
+============================
+
+Pour acquérir un nom de domaine, une organisation va s'adresser à un _registrar_ (Gandi, OVH, etc.) et en obtenir la gestion (pour une dizaine d'euros par an sur les extensions classiques). Ce registrar va ensuite enregistrer vos données auprès du _registry_ de l'extension du domaine (l'AFNIC pour .fr par exemple). C'est le registry qui est responsable de servir la zone DNS (l'AFNIC sert la zone '.fr'). Et c'est donc le serveur DNS du registry qui est pointé par la zone parente (par exemple la zone racine).
+
+MI-LXC fournit une racine alternative qui, en plus des TLD classiques (.com, .net, .fr, etc.), intègre le TLD interne .milxc. Cette racine alternative est fournie par 2 serveurs racines spécifiques présents dans l'infrastructure MI-LXC, dans les AS root-o et root-p. Les résolveurs présents dans MI-LXC interrogent ces racines alternatives et non les racines officielles (de A à M).
+
+> Question 2 : Dans la machine root-o-rootns, ouvrez le fichier /etc/nsd/root.zone :
+>
+>* Recopiez/capturez les lignes mentionnant le TLD .fr (elles commencent par 'fr.'). Trouvez ensuite (plus loin dans le fichier) les IP qui correspondent aux 'NS' (nameservers) mentionnés pour ce '.fr'.
+>* Recopiez/capturez les 3 lignes correspondant au TLD .milxc. À quelle machine appartiennent les IP mentionnées sur ces lignes ?
+
+Le TLD .milxc est ensuite opéré par le registry simulé dans l'AS milxc.
+
+> Question 3 : Dans la machine milxc-ns, ouvrez le fichier /etc/nsd/milxc.zone et recopiez/capturez les 3 lignes mentionnant le domaine target.milxc. À quelle machine appartiennent les IP mentionnées sur ces lignes ?
+
+
+Résolution en ligne de commande (40 minutes)
+===============================
+
+Résolution manuelle
+-------------------
+
+`dig` est un outil en ligne de commande pour interroger les DNS. Il s'utilise de la façon suivante :
+
+```
+dig @80.67.169.12 www.univ-ubs.fr      # Interroge le serveur (résolveur) 80.67.169.12 pour résoudre le nom www.univ-ubs.fr
+```
+
+Le serveur racine alternatif O de MI-LXC est accessible à l'IP 100.100.0.10.
+
+Nous allons faire la résolution manuellement depuis la machine `isp-a-home`. Commencez par démarrer wireshark sur cette machine (écoute sur eth0 puis filtre "dns" pour ne voir que les paquets qui nous intéressent). En utilisant dig depuis la machine `isp-a-home` et en interrogeant successivement chaque nœud de l'arbre DNS depuis cette racine 100.100.0.10, résolvez le nom d'hôte `www.target.milxc`. À chaque étape, retrouvez les requêtes et les réponses dans Wireshark : dans la fenêtre d'analyse (zone du milieu), dépliez la partie DNS jusqu'à trouver le contenu décodé des questions et réponses DNS.
+
+> Question 4 : Notez le chemin de résolution vers ce nom d'hôte, les questions posées et reçues par dig auprès des différents serveurs faisant autorité, jusqu'à obtenir l'IPv4 souhaitée.
+
+Interrogation d'un résolveur
+----------------------------
+
+Évidemment, un service intermédiaire peut s'occuper de faire cette résolution récursive automatiquement. Un résolveur ouvert offrant ce service est disponible sur la machine `opendns-resolver`, son adresse IP est `100.100.100.100`. Connectez-vous à cette machine, démarrez-y Wireshark et filtrez les paquets DNS.
+
+Interrogez ensuite ce résolveur ouvert depuis la machine `isp-a-home` pour résoudre en un seul appel `www.target.milxc`.
+
+> Question 5 : Notez la question posée par dig et la réponse obtenue. Retrouvez l'ensemble de l'échange dans Wireshark sur `opendns-resolver` (les messages échangés avec `isp-a-home` et les messages échangés avec les serveurs faisant autorité) et décrivez cet enchaînement de messages (explication rédigée).
+
+> Remarque : si vous ne voyez pas de messages entre le résolveur et *plusieurs* serveurs faisant autorité (situés à différents niveaux de l'arbre), c'est que le résolveur avait déjà la réponse dans son cache. Patientez 30 secondes puis recommencez (pour des raisons pédagogiques, les durées de vie des caches DNS dans MI-LXC [TTL - Time To Live] sont volontairement très courtes).
+
+Enregistrement d'un nom de domaine dans MI-LXC (1 heure)
+========================================================
+
+Enfin, dans cette partie, vous allez simuler l'enregistrement d'un nouveau domaine en .milxc, par exemple "iutva.milxc". La zone "iutva.milxc" sera servie par la machine `iutva-infra` et contiendra un enregistrement pour le nom "www.iutva.milxc".
+
+
+Ajout d'un nouveau domaine
+--------------------------
+
+Vous allez d'abord simuler l'enregistrement du domaine "iutva.milxc". Vous jouerez ici le rôle du registry.
+
+> Question 6 : Dans quelle zone va devoir être réalisé cet enregistrement du _domaine_ iutva.milxc ? Sur quelle machine ? Aidez-vous de vos réponses aux questions 2 et 3 (iutva.milxc va prendre une place similaire à target.milxc) et faîtes valider ce point.
+
+Connectez-vous sur cette machine et éditez le fichier de zone pour ajouter ce "iutva.milxc". Inspirez-vous évidemment des modèles déjà présents dans ce fichier, en mettant à jour les adresses IP pour pointer vers la machine sur laquelle vous hébergerez la zone "iutva.milxc" : la machine `iutva-infra`. Enfin, relancez le serveur NSD (en root : `service nsd restart`) et assurez-vous qu'il n'y a pas d'erreur signalée dans les logs (`journalctl -xe`).
+
+Avec dig depuis la machine `isp-a-home`, vérifiez que le serveur répond bien la réponse attendue pour "iutva.milxc".
+
+> Question 7 : Quelles lignes avez vous ajoutées au fichier de zone ?
+
+Configuration et création d'une zone DNS
+----------------------------------------
+
+Vous allez maintenant installer un serveur faisant autorité sur la machine `iutva-infra`. Pour installer NSD, tapez la commande `apt install nsd`.
+
+La configuration de NSD se situe dans le dossier `/etc/nsd/`. Vous aurez 2 fichiers à créer :
+
+* `/etc/nsd/nsd.conf.d/server.conf` pour la configuration générale (tous les fichiers `*.conf` du dossier `/etc/nsd/nsd.conf.d/` sont inclus lors du lancement)
+* `/etc/nsd/iutva.milxc.zone` pour le contenu de la zone "iutva.milxc" (ce fichier sera mentionné dans `server.conf`)
+
+Dans `server.conf`, vous déclarez quelle zone vous servez et où trouver son contenu :
+```
+zone:
+	name: "iutva.milxc."
+	zonefile: "/etc/nsd/iutva.milxc.zone"
+```
+
+Dans `iutva.milxc.zone`, vous déclarez le contenu de la zone. Vous trouverez un exemple dans le cours [ici](https://git.kaz.bzh/francois.lesueur/M3102/src/branch/master/cm3-dns.md#exemple-de-zone-dns), à réfléchir et adapter (recherches sur internet encouragées). Pour l'instant, vous aurez besoin uniquement des types d'enregistrement SOA (Start Of Authority, paramètres généraux), NS, A, et CNAME. Votre zone doit déclarer :
+
+* votre NS
+* un champ A pour le nom "infra.iutva.milxc" pointant vers l'IP de la machine `iutva-infra`
+* un champ CNAME pour le nom "www.iutva.milxc" comme alias vers "infra.iutva.milxc"
+
+Relancez le serveur NSD et vérifiez l'absence d'erreurs dans les logs (`journalctl -xe`). Validez le fonctionnement avec dig depuis `isp-a-home`. Lorsque tout fonctionne, vous devez pouvoir vous connecter à l'URL "http://www.iutva.milxc" avec Firefox depuis la machine `isp-a-home` (si vous avez bien installé le serveur web sur `iutva-infra`...)
+
+> Question 8 : Recopiez votre fichier de zone `iutva.milxc.zone` dans votre compte-rendu.
+
+> Question 9 (bonus) : Afin d'obtenir un système robuste et conforme aux recommandations standards, il faudrait ensuite dupliquer cette zone sur un serveur secondaire, indépendant, qui serait aussi annoncé dans la zone parente .milxc (par exemple sur target-infra). Explorez cela et rédigez ce que vous aurez compris ou réalisé.
+
+**Votre compte-rendu doit être déposé sur Moodle au format PDF uniquement, un dépôt par binôme.**

td6-mail.md

@@ -0,0 +1,238 @@
+TD6 Mail (3 heures)
+====================
+
+_Compte-rendu à préparer et déposer en binôme_
+
+> Si vous n'aviez pas validé le TP précédent (DNS) et avez besoin de repartir d'une base DNS fonctionnelle, vous trouverez les fichiers et explications nécessaires sur Moodle.
+
+Ce TD couvre la configuration et l'utilisation du mail, côté client et serveur. Les interactions sont complexes, l'objectif n'est pas d'avoir absolument un système mail entièrement fonctionnel, mais plutôt de bien appréhender la construction générale de ce type de système. Soyez méthodiques dans votre travail car vous allez manipuler de nombreuses perspectives différentes !
+
+Ce TD sera réalisé dans la VM MI-LXC disponible [ici](https://flesueur.irisa.fr/mi-lxc/images/milxc-debian-amd64-1.4.2pre3.ova). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+
+> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import puis installer le paquet open-vm-tools-desktop dans la VM pour profiter du redimensionnement automatique du bureau (`apt install open-vm-tools-desktop` dans un shell).
+
+
+Cheat sheet
+===========
+
+Voici un petit résumé des commandes dont vous aurez besoin :
+
+| Commande | Description | Utilisation |
+| -------- | ----------- | ----------- |
+| print    | Génère la cartographie du réseau | ./mi-lxc.py print |
+| attach   | Permet d'avoir un shell sur une machine | ./mi-lxc.py attach iutva-infra |
+| display  | Lance un affichage sur la machine cible | ./mi-lxc.py display isp-a-home |
+| start    | Démarre la plateforme pédagogique    | ./mi-lxc.py start |
+| stop     | Éteint la plateforme pédagogique        | ./mi-lxc.py stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+Observation d'un mail (45 minutes)
+=====================
+
+En dehors de MI-LXC, ouvrez un mail quelconque sur une de vos boîtes mails personnelles. Affichez le code source de ce mail (souvent accessible par clic droit puis "Montrer l'original" (zimbra) ou "Afficher le source", ou Ctrl+u) et analysez le résultat. Vous y trouverez une partie d'en-têtes (au format `Mot-clé: Valeur`, en début de source) puis une partie contenu.
+
+> Question 1 : Sur ce mail :
+>
+> 1. Dissociez la partie en-têtes de la partie contenu
+> 2. Décrivez les en-têtes qui vous paraissent clairs et transparents.
+> 3. Les en-têtes `Received:`, ajoutés par chaque serveur intermédiaire, permettent de retracer le chemin du mail. Dans quel sens ce chemin est-il décrit ?
+> 4. Décrivez le chemin de votre mail en analysant les adresses IP : où a lieu chaque étape ? Vous pouvez utiliser `dig -x 1.2.3.4` pour obtenir le DNS inversé de l'IP 1.2.3.4, ou des sites comme [https://ipinfo.io/](https://ipinfo.io/), [https://www.onyphe.io/](https://www.onyphe.io/) ou [https://www.ipinfodb.com/](https://www.ipinfodb.com/) pour obtenir des informations supplémentaires sur les adresses IP. Lorsque les adresses IP sont de type local, locales à quelle organisation ?
+
+
+Installation et configuration d'un système de mail (1h45)
+============================================================
+
+Architecture (20 minutes)
+------------
+
+Dans votre organisation "iutva", vous allez ajouter 2 machines supplémentaires :
+
+* un serveur mail, qui hébergera les serveurs SMTP et IMAP pour votre domaine, et qui peut prendre l'IP 100.90.0.3
+* un poste de travail, sur lequel nous installerons un logiciel graphique pour écrire et lire des mails avec l'adresse `debian@iutva.milxc`, et qui peut prendre l'IP 100.90.0.4
+
+Pour cela, le contenu de votre fichier `groups/iutva/local.json` peut devenir :
+```json
+{
+  "comment": "IUTVA AS",
+  "containers": {
+    "infra": {
+      "container": "infra",
+      "interfaces": [
+        {"bridge": "lan", "ipv4": "100.90.0.2/16", "ipv6": "2001:db8:90::2/48"}
+      ],
+      "gatewayv4": "100.90.0.1",
+      "gatewayv6": "2001:db8:90::1",
+      "templates": [
+        {"template": "nodhcp", "domain": "iutva.milxc", "ns": "100.100.100.100"}
+      ]
+    },
+    "mail": {
+      "container": "mail",
+      "interfaces": [
+        {"bridge": "lan", "ipv4": "100.90.0.3/16", "ipv6": "2001:db8:90::3/48"}
+      ],
+      "gatewayv4": "100.90.0.1",
+      "gatewayv6": "2001:db8:90::1",
+      "templates": [
+        {"template": "nodhcp", "domain": "iutva.milxc", "ns": "100.100.100.100"}
+      ]
+    },
+    "poste": {
+      "container": "poste",
+      "interfaces": [
+        {"bridge": "lan", "ipv4": "100.90.0.4/16", "ipv6": "2001:db8:90::4/48"}
+      ],
+      "gatewayv4": "100.90.0.1",
+      "gatewayv6": "2001:db8:90::1",
+      "templates": [
+        {"template": "nodhcp", "domain": "iutva.milxc", "ns": "100.100.100.100"}
+      ]
+    }
+  }
+}
+```
+
+Une fois ce fichier local.json adapté, exécutez :
+
+* `./mi-lxc.py print` pour visualiser le résultat
+* `./mi-lxc.py create` pour créer ces deux nouveaux hôtes sur lesquels nous allons travailler dans la suite du TD
+* `./mi-lxc.py start` pour démarrer le tout
+
+Afin d'échanger des mails, vous aurez besoin d'un interlocuteur. Vous pourrez pour cela utiliser la machine target-commercial qui a un compte mail "commercial@target.milxc" configuré pour l'utilisateur local commercial. L'infrastructure DNS et mail de "target.milxc" est opérée sur la machine target-dmz (pour info, mais il est probable que vous n'ayez pas besoin de vous y connecter).
+
+Petit résumé :
+
+| Machine | Description | Connexion |
+| ------- | ----------- | --------- |
+| iutva-mail | Serveur SMTP/IMAP pour les adresses "@iutva.milxc" | `./mi-lxc.py attach iutva-mail` |
+| iutva-poste | Bureau graphique pour écrire/lire des mails avec l'adresse "debian@iutva.milxc" | `./mi-lxc.py display iutva-poste` |
+| iutva-infra | Serveur DNS pour le domaine "iutva.milxc" | `./mi-lxc.py attach iutva-infra` |
+| target-commercial | Bureau graphique pour écrire/lire des mails avec l'adresse "commercial@target.milxc" | `./mi-lxc.py display commercial@target-commercial` |
+
+**Attention ! La connexion à target-commercial se fait avec commercial@target-commercial (et non target-commercial tout court) afin de se connecter avec l'utilisateur local commercial, qui est celui pour lequel le mail est pré-configuré.**
+
+> Question 2 : Faîtes un schéma global (capture de `./mi-lxc.py print` ou juste les machines impliquées) inventoriant les 5 machines iutva-poste, iutva-mail, iutva-infra, target-dmz, target-commercial, leurs adresses IPv4, leurs noms DNS (déjà existants ou à configurer par la suite) et leur rôle dans le système de mail. Pour la partie Target, vous pouvez vous aider de l'extrait de la zone DNS de Target dans le [cours DNS](https://git.kaz.bzh/francois.lesueur/M3102/src/branch/master/cm3-dns.md#exemple-de-zone-dns).
+
+SMTP (50 minutes)
+----
+
+### Installation
+
+Nous allons installer un serveur SMTP (Postfix) sur la machine iutva-mail. Il aura pour rôle d'envoyer les mails issus de l'organisation iutva et de recevoir les mails à destination de "@iutva.milxc".
+
+Il faut d'abord l'installer avec `apt install postfix`. Lors de la configuration du paquet, choisissez la configuration "Internet Site" (vous allez recevoir et envoyer des mails) et spécifiez "iutva.milxc" comme "System mail name".
+
+### Envoi d'un mail avec netcat
+
+Depuis un shell sur la machine iutva-mail, nous allons envoyer un mail à l'adresse "commercial@target.milxc". SMTP est un protocole en mode texte, nous allons utiliser netcat. Pour vous connecter au serveur SMTP avec netcat : `netcat localhost 25`
+
+Ensuite, vous aurez à taper les textes suivants (sans les guillemets, entrée après chaque commande) :
+
+* "HELO" : message de présentation, par exemple "HELO iutva.milxc"
+* "MAIL FROM: " : spécifie l'adresse d'expédition, par exemple "MAIL FROM: debian@iutva.milxc"
+* "RCPT TO: " : spécifie l'adresse du destinataire, par exemple "RCPT TO: commercial@target.milxc"
+* "DATA" : annonce le contenu du message ensuite
+* Après avoir entré la commande DATA (+ entrée), tapez votre texte. C'est au début de ce texte qu'iraient les champs (non strictement nécessaires ici) From, To, Subject tels que vus dans les en-têtes à la question 1, puis le contenu du mail
+* En fin de mail, un "." seul sur une ligne, puis encore entrée pour valider la fin du message
+* "QUIT" pour se déconnecter ensuite
+
+> Question 3 : Faîtes une copie de votre session netcat.
+
+Sur le claws-mail de `./mi-lxc.py display commercial@target-commercial`, validez que vous avez bien reçu ce mail. Essayez en changeant l'adresse d'expéditeur, ou en écrivant à une adresse réelle hors de MI-LXC.
+
+**Attention ! Ne prenez pas une identité réelle comme expéditeur. Il s'agirait d'une usurpation d'identité qui est une infraction pénale.**
+
+Sur la machine iutva-mail, affichez les logs de Postfix qui sont dans le fichier "/var/log/mail.log", retrouvez la trace du mail que vous venez d'émettre.
+
+> Question 4 : Faîtes une copie de cette partie de log.
+
+### Réception d'un mail par iutva-mail
+
+Depuis le display de target-commercial, envoyez un mail à "debian@iutva.milxc". Vous constaterez a priori une erreur (un mail d'erreur qui arrive dans la boîte de réception de target-commercial); si vous ne recevez pas d'erreur explicite (dépendant d'éléments de configuration de votre côté), le mail est en fait toujours en tampon sur le serveur SMTP du côté de l'organisation Target, et donc non livré. En effet, le serveur SMTP côté Target ne sait pas trouver le serveur SMTP pour @iutva.milxc.
+
+Ajoutez maintenant le champ MX adapté dans la zone DNS de iutva. Ce champ MX doit être situé avant les champs CNAME/A déjà existants dans la zone et doit mentionner un nom (pas une IP) qui sera défini par un champ A ou CNAME ensuite. Reprenez l'exemple du cours DNS [ici](https://git.kaz.bzh/francois.lesueur/M3102/src/branch/master/cm3-dns.md#exemple-de-zone-dns), mettez à jour votre zone sur iutva-infra puis redémarrez le serveur NSD.
+
+> Question 5 : Faîtes une copie de votre zone DNS.
+
+> Si le champ MX n'est pas placé au début de la zone, avant les enregistrements de type CNAME/A, il faut commencer sa ligne en ajoutant un @ pour "retourner en haut de zone".
+
+Renvoyez un mail depuis target-commercial et vérifiez qu'il n'y a plus d'erreur retournée. S'il y a une erreur, depuis cette même machine, vérifiez que vous avez bien enregistré le champ MX avec `dig iutva.milxc MX`
+
+Enfin, retrouvez la trace de ce mail dans les logs sur iutva-mail. Une fois arrivé, vous pouvez voir ce mail sur iutva-mail dans le fichier `/var/spool/mail/debian`. Il est reçu, stocké et prêt à être récupéré par le destinataire !
+
+> Question 6 : Faîtes une copie de cette partie de log.
+
+> Une documentation assez complète pour un déploiement complet et sain est proposée sur le [Wiki Debian](https://wiki.debian.org/Postfix).
+
+IMAP (15 minutes)
+----
+
+Toujours sur iutva-mail, installez dovecot-imapd : `apt install dovecot-imapd`
+
+IMAP est aussi un protocole en mode texte : `netcat localhost 143`. Ensuite, vous aurez à taper :
+
+* a LOGIN debian debian
+* a SELECT INBOX
+* a FETCH 1 full
+* a LOGOUT
+
+Vous verrez normalement ainsi le contenu du mail précédemment envoyé.
+
+> Question 7 : Faîtes une copie de votre session netcat.
+
+
+Client (20 minutes)
+------
+
+Nous allons maintenant installer et configurer un client mail sur la machine iutva-poste. En graphique : `./mi-lxc.py display iutva-poste`
+
+Installons claws-mail : `apt install claws-mail`. Lors du premier lancement, vous aurez à configurer le compte : le compte est debian, mot de passe debian, sur le serveur mail précédemment entré dans le DNS. Vous aurez à accepter des certificats auto-signés (c'est mal, cf cours crypto et rappels ensuite, on le fait ici car nous n'avons pas déployé la CA dans MI-LXC mais c'est évidemment à proscrire dans un vrai déploiement).
+
+> La configuration des clients mail peut être plus ou moins automatisée. Par exemple, Thunderbird essaie automatiquement les serveurs dont l'entrée DNS vaut "mail.<le domaine de l'adresse>", "smtp.<le domaine de l'adresse>", etc. Des champs DNS de type SRV permettent également d'annoncer les serveurs :
+>
+> * _imap._tcp   			SRV   0 1 143 mail
+> * _submission._tcp  SRV 	0 1 587 mail
+
+La consultation des mails doit fonctionner. Lors de l'envoi d'un mail vers commercial@target.milxc, votre serveur SMTP va par contre refuser votre demande : dans sa configuration par défaut, il n'accepte pas de relayer les mails qui ne sont pas pour son domaine (éviter d'être un relais ouvert). Il faudrait configurer une authentification sur le serveur SMTP (afin qu'il puisse authentifier ses utilisateurs légitimes à expédier du courrier par son biais), comme décrit par exemple [ici](https://doc.dovecot.org/configuration_manual/howto/postfix_and_dovecot_sasl/). Dans ce TD, on se contentera d'accepter le relai pour le réseau local : sur iutva-mail, éditez le fichier `/etc/postfix/main.cf` et modifiez le paramètre `mynetworks` pour lui faire accepter "100.90.0.0/16", ie, votre réseau interne, puis redémarrez Postfix.
+
+> Question 8 : Faîtes une capture d'écran de la boîte de réception de claws-mail.
+
+Un peu de Wireshark (30 minutes)
+===================
+
+Certaines communications passent en clair ici. Pour un vrai déploiement, il faudrait évidemment chiffrer toutes les communications avec des certificats valides, mais nous pouvons du coup observer le protocole.
+
+> Question 9 : Proposez où lancer des wireshark pour observer, lors d'un mail envoyé depuis target-commercial vers l'adresse debian@iutva.milxc qui sera relevée sur iutva-poste : l'envoi depuis claws-mail, l'échange entre les SMTP, la relève par claws-mail. Décrivez les points de capture, intégrez des screenshots de vos captures, précisez les communications claires ou chiffrées.
+
+> Question 10 : Avez-vous selon vous un "bon" certificat sur le SMTP de iutva-mail ? Qu'en déduire sur la sécurité de l'échange entre target-dmz et iutva-mail ? En notant que ceci est bien le comportement par défaut lors de l'installation.
+
+
+SpamAssassin (Bonus)
+============
+
+SpamAssassin est un filtre antispam à intégrer sur les mails reçus. Pour l'installer sur iutva-mail : `apt install spamassassin`. Vous utliserez ensuite la partie "Setup Postfix with SA 3.4.2 (Buster) as a Content Filter", sous-partie "Postfix" du guide du [Wiki Debian](https://wiki.debian.org/DebianSpamAssassin)
+
+Envoyez un mail depuis target-commercial à l'adresse debian@iutva.milxc et vérifiez, dans les logs de postfix (sur iutva-mail) et dans le code source du mail reçu, le bon passage par SpamAssassin.
+
+> Question 11 : Intégrez la partie de log postfix et la partie d'en-têtes du mail reçu qui montre le bon passage par SpamAssassin.
+
+
+SPF/DKIM/DMARC (Bonus)
+==============
+
+Vous trouverez un bon guide pour la configuration SPF/DKIM/DMARC pour Postfix sous Debian [ici](https://www.malekal.com/installer-configurer-postfix-spf-dkim-dmarc/)
+
+> Question 12 : Décrivez les modifications de fichiers de configuration.
+
+Un petit webmail ? (Bonus)
+==========================
+
+Roundcube est un webmail simple disponible dans les paquets Debian.
+
+> Question 13 : Décrivez l'installation et la configuration.
+
+
+
+**Votre compte-rendu doit être déposé sur Moodle au format PDF uniquement, un dépôt par binôme.**

td7-archi.md

@@ -0,0 +1,249 @@
+TD7 Architecture réseau et firewall (3 heures)
+====================
+
+_Compte-rendu à préparer et déposer en binôme_
+
+Ce TD couvre la segmentation réseau et l'utilisation du firewall IPTables.
+
+Ce TD sera réalisé dans la VM MI-LXC disponible [ici](https://flesueur.irisa.fr/mi-lxc/images/milxc-debian-amd64-1.4.2pre3.ova). Avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).
+
+> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import puis installer le paquet open-vm-tools-desktop dans la VM pour profiter du redimensionnement automatique du bureau (`apt install open-vm-tools-desktop` dans un shell).
+
+Avant de commencer le TP, vous devez lire le chapitre [Netfilter](https://fr.wikibooks.org/wiki/Administration_r%C3%A9seau_sous_Linux/Netfilter) du Wikilivre "Administration Réseau sous Linux". Prêtez une attention particulière au sens des 3 chaînes INPUT, OUTPUT et FORWARD.
+
+> Question 1 : Expliquez ces 3 chaînes INPUT, OUTPUT et FORWARD : à quels types de paquets s'appliquent-elles ?
+
+>Note 1 : Pour les plus aventuriers, il est possible d'utiliser nftables, le successeur d'iptables. Quelques infos de démarrage sont proposées [ici](https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management).
+
+>Note 2 : Le TP est prévu sur IPv4, mais l'infrastructure supporte également IPv6. Vous pouvez donc aussi regarder IPv6 si vous le souhaitez.
+
+
+Cheat sheet
+===========
+
+Voici un petit résumé des commandes dont vous aurez besoin :
+
+| Commande | Description | Utilisation |
+| -------- | ----------- | ----------- |
+| print    | Génère la cartographie du réseau | ./mi-lxc.py print |
+| attach   | Permet d'avoir un shell sur une machine | ./mi-lxc.py attach iutva-infra |
+| display  | Lance un affichage sur la machine cible | ./mi-lxc.py display isp-a-home |
+| start    | Démarre la plateforme pédagogique    | ./mi-lxc.py start |
+| stop     | Éteint la plateforme pédagogique        | ./mi-lxc.py stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+Topologie du routeur
+====================
+
+Connectez-vous sur la machine "target-router" : `./mi-lxc.py attach target-router`. En effet, lors de ce TP, nous allons travailler sur `target-router` et, plus globalement, sur la segmentation de l'AS Target, notamment parce que cet AS possède déjà quelques machines et services propices à réfléchir sur ce point.
+
+Une fois connectés sur target-router, regardez la configuration réseau avec notamment ses deux interfaces "eth0" et "eth1", par exemple avec `ifconfig` ou `ip addr`. Identifiez laquelle se situe côté interne et laquelle côté externe de l'entreprise et notez l'adresse IP de chacune.
+
+> Question 2 : Quelles sont les interfaces et adresses IP internes et externes ?
+
+Protection de la machine firewall
+=================================
+
+Nous allons maintenant mettre en place un firewall sur la machine "target-router" pour découvrir l'usage de l'outil de firewall IPTables. En utilisant la page de manuel d'iptables ou votre lecture préalable, affichez l'ensemble des règles actives. Vous devriez voir quelque chose qui ressemble à :
+
+```
+Chain FORWARD (policy DROP 0 packets, 0 bytes)
+ pkts bytes target     prot opt in     out     source               destination         
+    0     0 ACCEPT     all  --  eth0   eth1    0.0.0.0/0            100.80.1.2          
+    0     0 ACCEPT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
+    0     0 ACCEPT     all  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0           
+
+Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
+ pkts bytes target     prot opt in     out     source               destination         
+
+Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
+ pkts bytes target     prot opt in     out     source               destination         
+```
+
+Vous voyez donc pour chaque chaîne :
+
+* la "policy" (comportement par défaut) ;
+* le nombre de paquets qui ont traversé les règles de la chaîne ;
+* le nombre d'octets correspondants.
+
+Pour le moment, peu de règles sont définies ; par la suite, cette commande vous permettra de lister l'ensemble des règles actives dans la table "filter".
+
+Première règle iptables
+-----------------------
+
+Vérifiez que vous pouvez vous connecter en SSH sur la machine "target-router" depuis la machine "isp-a-hacker" (`./mi-lxc.py attach isp-a-hacker`) :
+
+`ssh root@100.64.0.10`
+
+Nous allons maintenant interdire toutes les connexions sur le port 22 (SSH). Pour cela, il faut interdire dans la chaîne INPUT les paquets TCP sur le port 22 avec la cible DROP.
+
+Appliquez la règle avec la commande iptables sur "target-router". Essayez maintenant de vous connecter en SSH sur votre machine "target-router" depuis la machine "isp-a-hacker". Vous devez constater que la connexion est bien refusée mais que le client SSH met un certain temps à s'en apercevoir.
+
+> Question 3 : Quelle commande IPTables avez-vous tapée ?
+
+> Question 4 : Nous avons ici utilisé l'action DROP et le client SSH met un certain temps à s'apercevoir du refus. Comprenez-vous pourquoi ? Comment changer ce comportement ?
+
+
+Priorité des règles
+-------------------
+
+Un même paquet peut correspondre à plusieurs règles de filtrage, éventuellement contradictoires : Netfilter applique les règles dans l'ordre et choisit systématiquement la première règle correspondant au paquet (attention, certains firewalls procèdent dans le sens contraire tandis que celui de Windows ne prend pas en compte l'ordre...). On parle alors de masquage de règles.
+
+Afin de tester ce comportement, nous allons utiliser les paramètres de filtrage de la [section "Critères" du Wikilivre](https://fr.wikibooks.org/wiki/Administration_r%C3%A9seau_sous_Linux/Netfilter#Crit%C3%A8res).
+
+* Montrez sur un exemple que l'ordre des règles compte. Pour modifier le filtrage, vous aurez besoin de supprimer des règles et d'en ajouter à des endroits spécifiques : référez-vous au manuel d'iptables.
+* Mettez en place un jeu de règles autorisant le SSH sur le routeur uniquement depuis le LAN de l'entreprise (testable depuis la machine "target-admin" par exemple).
+
+Dans la pratique, le masquage est souvent utilisé volontairement pour spécifier un cas général peu prioritaire et des cas particuliers plus prioritaires. Évidemment, c'est également source d'erreurs dans ces cas complexes.
+
+> Question 5 : Quelles commandes IPTables avez-vous tapées ?
+
+Modules iptables
+================
+
+iptables est extensible par un système de modules. Vous trouverez une description des modules existants dans le manuel de "iptables-extensions".
+
+Comment
+-------
+
+Le module `comment`, comme son nom l'indique, permet d'associer un commentaire à une règle afin d'assurer la bonne compréhension par tous des règles en place. Pour utiliser le module :
+`iptables -A INPUT -m comment --comment "Ceci est un commentaire" -j...`
+
+Multiport
+---------
+
+Le module multiport permet de créer une règle unique correspondant à plusieurs ports (plutôt que plusieurs règles) : `iptables -A INPUT -m multiport -p tcp --dports port1,port2,port3 -j...`
+
+Créez une règle avec multiport autorisant les ports 22 et 53. N'hésitez pas à ajouter un commentaire pour y voir plus clair (plusieurs modules peuvent être utilisés simultanément).
+
+Suivi de connexion ("state")
+----------------------------
+
+Netfilter permet le suivi des connexions via le module "state" (firewall _stateful_). Ce module permet d'identifier les nouveaux flux, les flux établis et les flux liés à un autre flux. Ce suivi de connexion permet d'affiner le filtrage de certains protocoles.
+
+Le module "state" définit plusieurs états possibles pour les flux réseau, dont :
+
+* NEW : c'est une nouvelle connexion
+* ESTABLISHED : cette connexion est déjà connue (elle est passée par l'état NEW il y a peu de temps)
+* RELATED : cette connexion est liée ou dépendante d'une connexion déjà ESTABLISHED. Attention, seul le premier paquet d'une connexion peut être RELATED, les suivants sont ESTABLISHED. Essentiellement utilisé pour le protocole FTP.
+
+Par exemple, la règle déjà existante dans la chaîne FORWARD : `    0     0 ACCEPT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED` signifie que seulement les paquets `RELATED` ou `ESTABLISHED` sont autorisés de `eth0` vers `eth1`, ie, seules les "réponses" peuvent passer dans ce sens.
+
+Pour voir l'effet de la question suivante, tout d'abord bloquez tout en sortie avec cette politique : `iptables -P OUTPUT DROP`
+
+Puis créez une règle pour autoriser, en sortie du firewall, uniquement les réponses à des connexions SSH entrantes (à destination du service SSH sur le firewall).
+
+> Question 6 : Quelles commandes IPTables avez-vous tapées ?
+
+
+Administration à distance
+=========================
+
+Le firewall est généralement configuré à distance, depuis le poste d'un administrateur. Pour reproduire cela, affichez le bureau de la machine target-admin (`./mi-lxc display target-admin`). Depuis le bureau de cet administrateur, connectez vous en SSH au routeur, comme vu précédemment.
+
+L'un des risques classiques, ensuite, est de scier sa branche pendant la configuration : écrivez via cette connexion SSH une règle qui bloque la connexion SSH d'administration et vous fait ainsi perdre la main sur la configuration du firewall...
+
+> Question 7 : Proposez et exécutez une commande iptables qui bloque votre connexion SSH. Comment parvenez-vous ensuite à vous débloquer ?
+
+
+Segmentation
+============
+
+Spécification
+-------------
+
+L'objectif d'une politique de sécurité réseau est de limiter les services accessibles depuis l'extérieur (approche historique) ainsi que de segmenter le réseau interne en zones distinctes (avec autorisations limitées entre ces zones, afin de limiter les risques de propagation automatique/pivot). Une telle politique se définit en trois étapes :
+
+1. Création de zones réseau logiques via des sous-réseaux
+2. Identification des services réseau portés, et accédés, par chaque machine
+3. Définition des flux réseau autorisés entre zones en fonction des besoins identifiés précédemment. Ceci constitue la "matrice de flux"
+
+**Par défaut, tout doit être interdit puis les services souhaités sont explicitement autorisés !**
+
+> Ci-dessous un exemple de matrice de flux qui pourrait correspondre aux 2 zones initiales (int est la zone interne LAN et ext est la zone externe WAN) (insuffisante, donc, et attention ce n'est pas ça qui est implémenté par l'iptables initial) :
+>
+> |   src\dst  |      ext           |     int                      |
+> |:----------:|:------------------:|:----------------------------:|
+> |    ext     |      X             | SMTP(S),IMAP(S),HTTP(S),DNS  |
+> |   int      |    tout            |        X                     |
+
+
+Pour rappel, le réseau de l'entreprise est composé de ces différents éléments (en plus du routeur, qui a le rôle particulier de gérer les échanges entre les zones et que vous pouvez ici ignorer dans la définition du contenu de vos zones) :
+
+| Machine           | Description |
+| :-------:         | ----------- |
+| target-admin      | Ordinateur de l'administrateur système. Il doit pouvoir administrer tout le parc en SSH. |
+| target-commercial | Ordinateur du commercial. Il doit pouvoir envoyer des mails, accéder à l'intranet (site web sur target-intranet) et naviguer sur le web. |
+| target-dev        | Ordinateur du développeur. Il doit pouvoir envoyer des mails, mettre à jour l'intranet par SSH sur target-intranet et naviguer sur le web. |
+| target-dmz        | Ensemble de services à l'interface entre le SI et le reste du monde (DNS, SMTP, IMAP, HTTP) |
+| target-ldap       | Authentification centralisée, nécessaire à tous les postes du SI (dont la DMZ), en LDAP (logiciel slapd) |
+| target-filer      | Partage de fichiers qui doit être accessible à tous les postes clients internes (partage en SSH) |
+| target-intranet   | Applications internes, non accessibles au reste du monde |
+
+Les noms des conteneurs peuvent être affichés avec `./mi-lxc.py` (sans paramètres), les machines ne commençant pas par "target-" représentent le "reste du monde" (WAN). Le plan d'adressage peut être affiché avec `./mi-lxc.py print`. Vous pouvez utiliser les commandes `netstat -laptn` ou bien `ss -lnptu` qui permettent d'afficher les ports en écoute, et donc les services, sur une machine donnée.
+
+Votre description (matrice de flux sous forme tabulaire avec les machines sources en lignes et destinations en colonnes et services autorisés dans les cases, ou graphique) doit être claire et suffisamment précise pour être non ambiguë : un autre étudiant, avec cette description uniquement, devrait pouvoir refaire _exactement_ la même implémentation avec iptables.
+
+> Question 8 : Décrivez sous forme de tableau (pas des commandes iptables !) une politique de sécurité réseau raisonnable pour le SI complet de l'entreprise.
+
+> La question 8 est longue : il faut explorer le réseau, les machines, les services, comprendre les interactions et proposer une segmentation pertinente. La partie essentielle du TP s'arrête ici.
+
+Implémentation
+--------------
+Une fois que la politique réseau a été précédemment définie sur le papier (phase de spécification), nous pouvons passer à l'implémentation dans les routeurs (sous-réseaux) et pares-feux (règles de filtrage).
+
+Implémentez votre matrice de flux sur la machine "target-router". Vous aurez besoin de procéder en deux étapes :
+
+* Segmenter le réseau "target" (**Prenez le temps de regarder le [tuto vidéo](https://flesueur.irisa.fr/mi-lxc/media/segmentation_milxc.mp4) !!!**) :
+	* Éditer `global.json` (dans le dossier mi-lxc) pour spécifier les interfaces sur le routeur, dans la section "target". Il faut ajouter des bridges (dont le nom doit commencer par "target-") et découper l'espace 100.80.0.1/16. Enfin, il faut ajouter les interfaces eth2, eth3... ainsi créées à la liste des `asdev` definie juste au-dessus (avec des ';' de séparation entre interfaces)
+	* Éditer `groups/target/local.json` pour modifier les adresses des interfaces et les bridges des machines internes (attention, pour un bridge nommé précédemment "target-dmz", il faut simplement écrire "dmz" ici, la partie "target-" est ajoutée automatiquement). Dans le même fichier vous devrez aussi mettre à jour les serveurs mentionnés dans les paramètres des templates "ldapclient", "sshfs" et "nodhcp", soit en remplaçant les noms de serveurs par leurs nouvelles adresses IP, soit en mettant à jour les enregistrements DNS correspondants (fichier `/etc/nsd/target.milxc.zone` sur "target-dmz")
+	* Exécuter `./mi-lxc.py print` pour visualiser la topologie redéfinie
+	* Exécuter `./mi-lxc.py stop && ./mi-lxc.py renet && ./mi-lxc.py start` pour mettre à jour l'infrastructure déployée
+* Implémenter de manière adaptée les commandes iptables sur la machine "target-router" (dans la chaîne FORWARD). Si possible dans un script (qui nettoie les règles au début), en cas d'erreur.
+
+> L'arborescence de MI-LXC et les fichiers json manipulés ici sont décrits [ici](https://github.com/flesueur/mi-lxc#how-to-extend).
+
+> Question 9 : Décrivez vos interfaces réseaux/leur segment et recopiez vos commandes IPTables.
+
+Contournement de la politique
+-----------------------------
+
+Imaginez que vous êtes le développeur et que vous souhaitez fournir un accès au serveur web interne de prototypage "target-intranet" à un
+client externe, alors que celui-ci n'est normalement pas accessible de l'externe ! Vous allez créer un tunnel pour contourner la politique de sécurité.
+Vous disposez pour cela des machines "target-dev" (votre poste de travail interne) et "isp-a-home" (une machine extérieure, à votre domicile).
+
+Nous allons utiliser l'outil `netcat` pour établir un tunnel très simple.
+
+Connectez-vous sur la machine "isp-a-home". Nous allons commencer par éteindre le service _Apache_ en écoute pour libérer le port 80 qui nous sera utile
+puis nous allons écouter les connexions sur le port HTTP (TCP/80).
+```bash
+service apache2 stop
+while true; do nc -v -l -p 80 -c "nc -l -p 8080"; done
+```
+
+Enfin, côté "target-dev", nous mettons en place la connexion sortante vers la machine distante:
+```bash
+while true; do nc -v 100.120.0.3 80 -c "nc 100.80.0.5 80"; sleep 2; done
+```
+
+>Pour rappel :
+>* 100.120.0.3 = isp-a-home
+>* 100.80.0.5 = target-intranet
+
+Testez avec la machine "isp-a-hacker" que vous pouvez bien accéder au serveur intranet depuis l'externe sans aucun contrôle via l'URL `http://100.120.0.3:8080`
+
+> Question 10 : À l'aide d'un schéma, expliquez ce phénomène.
+
+Il est très difficile de bloquer ou même détecter les tunnels (imaginez un tunnel chiffré par SSH, ou qui mime une apparence de HTTP, etc.)
+
+
+Bonus FTP
+=========
+
+FTP, comme quelques autres protocoles, présente des difficultés particulières pour les firewalls. En effet, la partie contrôle de FTP se passe sur une connexion (et un port) distinct de la partie données. Les firewalls modernes savent créer le lien entre ces deux connexions pour y appliquer un contrôle adapté.
+
+Un serveur FTP est installé sur "target-dmz", configurez le firewall pour permettre son usage (transfert de fichiers) depuis une machine externe au SI. Attention, le FTP demande une connexion avec un utilisateur existant, par exemple debian/debian.
+
+**Votre compte-rendu doit être déposé sur Moodle en fin de journée au format PDF uniquement, un dépôt par binôme.**