smallies

.gitignore

@@ -0,0 +1,9 @@
+output/
+*.aux
+*.log
+*.nav
+*.out
+*.pdf
+*.snm
+*.synctex.gz
+*.toc

Makefile

@@ -0,0 +1,25 @@
+OUTDIR= output
+SRC= $(wildcard *.md)
+PDF= $(addprefix $(OUTDIR)/,$(SRC:.md=.pdf))
+HTML= $(addprefix  $(OUTDIR)/,$(SRC:.md=.html))
+
+
+all: $(PDF) $(HTML)
+
+pdf: $(PDF)
+
+html: $(HTML)
+
+directories: $(OUTDIR)
+
+$(OUTDIR):
+	mkdir $(OUTDIR)
+
+$(OUTDIR)/%.html: %.md $(OUTDIR)
+	pandoc --from=markdown+lists_without_preceding_blankline $< -o $@ -s
+
+$(OUTDIR)/%.pdf: $(OUTDIR)/%.html
+	wkhtmltopdf $< $@
+
+clean:
+	\rm -rf *.html *.pdf $(OUTDIR)

README.md

@@ -14,7 +14,7 @@ La matière se déroule sur la période 2 et est composée de :
 * 7 séances de cours (CM) de 45 minutes (en promo entière)
 * 7 séances de travaux dirigés (TD) de 1h30 (en groupe 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 "Découverte de MI-LXC" : [.ova à télécharger ici](https://flesueur.irisa.fr/mi-lxc/images/milxc-debian-amd64-1.4.2.ova), nous utiliserons la version 1.4.2. 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 des séances TD1 et TD2.
+Une large part des séances pratiques sera réalisée sur la plateforme MI-LXC (https://github.com/flesueur/mi-lxc) (plus précisément sa branche [SNSTER](https://github.com/flesueur/mi-lxc/tree/snster), méfiez-vous donc des docs pas forcément toujours cohérentes entre les branches), 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-snster-vm-2.0.0pre1.ova), nous utiliserons la version 2.0.0pre1. 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 des séances TD1 et TD2.
 
 Sur ce dépôt, vous trouverez les notes de cours ainsi que les sujets des TD/TP.
 
@@ -23,27 +23,27 @@ Programme
 
 Le programme prévisionnel est le suivant :
 * S44 :
-  * CM1 : Introduction et périmètre du cours
+  * [CM1](cm1-intro.md) : Introduction et périmètre du cours
 * S45 :
-  * TD1 : Découverte de MI-LXC 1/2
+  * [TD1](td1-milxc.md) : Découverte de MI-LXC 1/2
 * S46 :
-  * TD2 : Découverte de MI-LXC 2/2
-  * CM2 : Piles et protocoles de transport
+  * [TD2](td1-milxc.md) : Découverte de MI-LXC 2/2
+  * [CM2](cm2-piles.md) : Piles et protocoles de transport
 * S47 :
-  * TD3 : Wireshark
-  * CM3 : Adressage IP
+  * [TD3](td3-apache.md) : Apache/Tunnels/CMS 1/3
+  * [CM3](cm3-archi.md) : Architecture réseau 1/3
 * S48 :
-  * TD4 : Adressage IP
-  * CM4 : Architecture réseau
+  * [TD4](td3-apache.md) : Apache/Tunnels/CMS 2/3
+  * [CM4](cm3-archi.md) : Architecture réseau 2/3
 * S49 :
-  * TD5 : Segmentation réseau 1/2
-  * CM5 : Routage
+  * [TD5](td3-apache.md) : Apache/Tunnels/CMS 3/3
+  * [CM5](cm3-archi.md) : Architecture réseau 3/3
 * S50 :
-  * TD6 : Segmentation réseau 2/2
-  * CM6 : DNS 1/2
+  * [TD6](td6-archi.md) : Segmentation réseau 1/2
+  * [CM6](cm6-dns.md) : DNS
 * S01 :
-  * TD7 : DNS
-  * CM7 : DNS 2/2
+  * [TD7](td6-archi.md) : Segmentation réseau 2/2
+  * CM7 : Révisions, questions/réponses
 
 
 Évaluation

cm1-intro.md

@@ -0,0 +1,66 @@
+CM1 Introduction - Notes de cours
+=================================
+
+R3.06
+=====
+
+L’objectif de cette ressource est de comprendre l’organisation et le fonctionnement d’un _réseau_ informatique. Cette ressource permettra de découvrir les différentes technologies _matérielles et logicielles_ mises en œuvre dans l’_acheminement_ de données à l’intérieur d’un réseau (_local ou étendu_), de voir par quels types d’applications accéder au réseau.
+
+Savoirs de référence étudiés :
+* _Technologies_ des réseaux (piles protocolaires, couche transport, TCP/IP/UDP, DHCP, DNS…)
+* _Interconnexion_ de réseaux (par ex.: routage, NAT, filtrage, proxy...)
+* _Utilisation_ de services réseaux (côté client)
+
+
+Parlons un peu d'internet
+=========================
+
+Pourquoi ?
+* Internet est un réseau de réseaux
+* Les réseaux que l'on va voir sont reliés pour former Internet
+* Internet n'héberge pas de services en tant que tel, il n'y a pas de "zone de serveurs" : on ne fait qu'aller interagir avec les services hébergés dans un des autres réseaux d'internet.
+* Pour comprendre les motivations et technologies des réseaux, il faut les appréhender dans le cadre de leur association via Internet.
+* IP :
+  * Unification du local et du global dans un même protocole, utilisé autant localement que globalement
+  * A remplacé les autres protocoles locaux (IPX, NetBEUI, ...) _parce que_ (?) c'est le protocole global
+  * A remplacé les autres justement parce qu'il résout un problème plus large que les réseaux locaux
+  * Mutualisation du code, homogénéisation des interactions, connectivité de bout-en-bout sans rupture protocolaire (modulo NAT)
+
+
+C'est quoi internet, côté réseaux ?
+===================================
+
+* Des protocoles pour l'interopérabilité : IP, TCP, UDP, BGP, DNS, SMTP, HTTP, ...
+* Des organisations qui orchestrent : IETF, ICANN (dont IANA), RIR RIPE/NANOG/etc.
+* Du matériel : des ordinateurs, des routeurs, des câbles/fibres [J. Mau](https://www.iletaitunefoisinternet.fr/post/3-infra-maud/)
+* Des logiciels : du firmware de routeur, des services de cœur (BGP, DNS), des serveurs et clients à chaque bout de la chaîne
+
+
+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 ?*
+* 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
+* Un bon thread qui explique cela [ici](https://twitter.com/AtaxyaNetwork/status/1445096685286350849) : chaque AS est une île, BGP sert à construire les ponts, l'objectif étant de permettre de transmettre des messages d'une île à une autre île éloignée, par le passage donc de plusieurs îles et ponts intermédiaires.
+* Les communications se font de bout en bout à travers le protocole IP
+
+
+Panorama du cours
+=================
+
+* Introduction (aujourd'hui)
+* Piles réseau
+* Adressage IP
+* Architecture réseau
+* Routage
+* DNS
+
+
+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://flesueur.irisa.fr/mi-lxc/images/milxc-snster-vm-2.0.0pre1.ova) et installer VirtualBox ou VMWare **avant le premier TD** !

cm2-piles.md

@@ -0,0 +1,67 @@
+CM2 Piles et protocoles de transport - Notes de cours
+=====================================================
+
+Pile OSI, pile TCP/IP
+=====================
+
+Modèles
+-------
+
+![OSI/TCP](https://upload.wikimedia.org/wikipedia/commons/7/7e/Comparaison_des_mod%C3%A8les_OSI_et_TCP_IP.png){width=50%}
+
+[Pile OSI](https://en.wikipedia.org/wiki/OSI_model) :
+* Fin des années 70
+* Modèle à 7 couches adapté à un objectif des 70s
+* Isolation totale entre les couches
+
+[Pile TCP/IP](https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/IP_model) :
+* Dans les 80s
+* Modèle à 4 couches (+ exemples) :
+  * the scope of the software application - HTTP
+  * the host-to-host transport path - TCP
+  * the internetworking range - IP
+  * the scope of the direct links to other nodes on the local network - Ethernet
+* Quelques interactions entre des couches
+
+Les critiques du modèle OSI / de la vision en couches :
+* [Wikipedia](https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI#Le_monde_IP_et_le_mod%C3%A8le_OSI) : "S'il y a bien une correspondance grossière entre les protocoles de la pile IP et les couches du modèle, on ne peut pas considérer que la pile IP soit vraiment compatible avec le modèle OSI. En particulier, la séparation des couches dans la pile IP est nettement plus approximative. En voici 2 illustrations."
+* [Wikipedia](https://en.wikipedia.org/wiki/Internet_protocol_suite#Comparison_of_TCP/IP_and_OSI_layering) : "The IETF has repeatedly stated that Internet Protocol and architecture development is not intended to be OSI-compliant. RFC 3439, referring to the internet architecture, contains a section entitled: "Layering Considered Harmful". [...] The OSI protocol suite that was specified as part of the OSI project was considered by many as too complicated and inefficient, and to a large extent unimplementable", "the OSI model contains idiosyncrasies not found in later systems such as the IP stack in modern Internet"
+* Fin du game...
+* C'est _juste_ un guide de compréhension, une abstraction
+
+
+Encapsulation
+-------------
+
+* L'encapsulation est le principe à retenir !!!
+* Une couche = un objectif :
+  * Un switch ethernet ne se préoccupe *que* de l'en-tête ethernet
+  * Un routeur IP ne se préoccupe *que* de l'en-tête IP (presque)
+  * Un OS ne se préoccupe *que* de l'en-tête transport (presque)
+  * Une application ne se préoccupe *que* de la partie application
+* La logique de l'encapsulation de protocoles :
+  * Dans le "bon" sens : encapsuler dans une couche de niveau plus bas (usage général), exemple
+  * Dans l'autre sens : encapsuler dans une couche de niveau plus haut (boucle, exemple VPN), exemple
+
+Schéma : ![Encapsulation](https://upload.wikimedia.org/wikipedia/commons/thumb/3/3b/UDP_encapsulation.svg/1920px-UDP_encapsulation.svg.png){width=60%}
+
+Un peu de Wireshark
+===================
+
+Explorons sur target-router, une requête HTTP permet de voir :
+* De l'Ethernet
+* De l'IP
+* Du TCP, UDP
+* Du BGP, HTTP, DNS
+
+
+Internet, le routage, les services, les couches
+===============================================
+
+De manière *très* synthétique :
+* Chaque lien physique entre 2 machines/routeurs (fibre, câble, sans-fil) : un protocole couche 2
+* Internet c'est la connectivité IP (Internet Protocol) globale couche 3 de bout en bout
+* Au dessus d'IP, on retrouve classiquement TCP et UDP :
+  * Au-dessus de TCP : HTTP, SMTP, ...
+  * Au-dessus d'UDP : DNS, WebRTC et autres protocoles audio/vidéo, ...
+* (ICMP, qui véhicule notamment les paquets ping, est de même niveau que IP)

cm3-archi.md

@@ -0,0 +1,226 @@
+CM3 + CM4 Architecture réseau et firewall - Notes de cours
+==========================================================
+
+Programme
+=========
+
+* L'objectif de la segmentation
+* Quelques exemples d'architecture
+* Le filtrage par pare-feu
+* Routage, filtrage, NAT, proxy
+
+
+Il était une fois les réseaux à plat
+====================================
+
+* Naturellement, comme on l'a fait en TD : 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/).
+
+![Schéma](archi.jpg)
+
+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)
+
+
+NAT
+---
+
+* Des adresses IP privées/non routables sur Internet, des adresses IP publiques/routables sur Internet (RFC 1918). Plages privées :
+  * 10/8, 172.16/12, 192.168/16
+  * fd00::/8
+* Router = Rediriger sur la bonne patte réseau sans modifier les sources/destinations
+* Si une patte est sur une plage privée, la réponse sera non routable. NAT !
+
+Le NAT/PAT (Network/Port Address Translation) s'occupe de modifier les ports/adresses à la volée au niveau du routeur :
+* D'un côté des adresses privées, de l'autre des adresses publiques
+* Communication initiée de public vers privé, impasse : le routeur ne peut pas savoir à qui c'est destiné
+* Communication initiée de privé vers public, translation d'adresse :
+  * Paquet interne : IPsrc, PORTsrc, IPdst, PORTdst (avec IPsrc privée, IPdst publique)
+  * Au NAT :
+    * Substitution de IPsrc par IProuter : la réponse reviendra vers le routeur
+    * (Substitution du PORTsrc pour un libre)
+    * Enregistrement des paramètres de la communication sur le routeur NAT
+  * Paquet externe : IProuter, PORTrouter, IPdst, PORTdst (avec IProuter publique)
+  * La destination répond vers IProuter
+  * Le routeur avait enregistré les paramètres à l'aller et sait re-substituer au retour
+
+Intérêts du NAT :
+* Utiliser moins d'adresses IP publiques (rares et chères en IPv4)
+* Masquer l'architecture interne
+* Firewall par effet de bord (puisqu'entrée impossible)
+
+Proxy
+-----
+
+Proxy "classique", un relais applicatif vers l'extérieur :
+* Ajout d'un point de passage
+* Exemple HTTP : au lieu de se connecter au site distant, on se connecte au proxy qui fait la requête pour nous
+* Intérêts : mise en cache, journalisation/surveillance
+
+Reverse proxy, un relais applicatif pour répartir la charge sur plusieurs serveurs :
+* Ajout d'un point de passage vers l'infra interne
+* Plusieurs serveurs applicatifs
+* Le proxy reçoit les connexions et les répartit vers les serveurs applicatifs

cm6-dns.md

@@ -0,0 +1,146 @@
+CM6 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)
+
+
+É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
+```
+
+
+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
+
+
+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/

td1-milxc.md

@@ -0,0 +1,169 @@
+TD1 + TD2 Découverte MI-LXC/SNSTER (3h, 2 séances)
+===========================================
+
+Ce TP sera réalisé dans la VM MI-LXC/SNSTER disponible [ici](https://flesueur.irisa.fr/mi-lxc/images/milxc-snster-vm-2.0.0pre1.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).
+
+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.
+
+> Pour les curieux, le code de MI-LXC, qui sert à générer cette VM automatiquement, est disponible avec une procédure d'installation documentée [ici](https://github.com/flesueur/mi-lxc/tree/snster). Attention, nous utilisons ici la branche SNSTER de MI-LXC, qui utilise le framework [SNSTER](https://framagit.org/flesueur/snster) en cours de mise au point.
+
+> 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.
+
+> Le compte-rendu est à déposer en binôme sur Moodle avant mercredi 23 novembre soir.
+
+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 | snster print |
+| attach   | Permet d'avoir un shell sur une machine | snster attach target-sales |
+| display  | Lance un affichage sur la machine cible | snster display target-sales |
+| start    | Lance la construction du bac à sable    | snster start |
+| stop     | Éteint la plateforme pédagogique        | snster stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+
+Manipulation et navigation dans l'infrastructure pré-existante
+==============================================================
+
+Découverte du réseau
+--------------------
+
+Vous devez vous connecter à la VM en root/root. MI-LXC est déjà installé et l'infrastructure déployée, il faut avec un terminal aller dans le dossier `/root/mi-lxc`. Commencez par afficher le plan du réseau avec `snster print`. Les rectangles sont les machines et les ovales les switchs réseau. L'infrastructure déployée simule un internet minimaliste :
+
+* un réseau de réseaux indépendants
+* chaque réseau propose des services internes et expose des services externes utilisés par d'autres réseaux
+* des services globaux nécessaires à l'interconnexion de l'ensemble sont déjà en place (cœur de réseau, racine DNS, ...)
+
+Au milieu du plan, le cœur de réseau est constitué de 2 opérateurs nommés transit-a et transit-b (munis chacun d'une machine et d'un switch). D'autres organisations sont ensuite connectées à ces opérateurs afin de former globalement cet internet. Ces organisations sont classiquement construites avec une machine <organisation>-router en entrée de réseau, un switch interne et d'autres machines branchées sur ce switch interne.
+
+> Question 1 : À partir de l'image de la topologie accessible [ici](https://github.com/flesueur/mi-lxc/blob/master/doc/topologie.png), délimitez les réseaux (les AS) et essayez de préciser leur rôle dans le système global. Vous pouvez vous aider du listing présent dans le fichier [doc/MI-IANA.fr.txt](https://github.com/flesueur/mi-lxc/blob/master/doc/MI-IANA.fr.txt) du dépôt github.
+
+
+Utilisation
+-----------
+
+Pour démarrer l'infrastructure, tapez `snster start`. Ensuite pour vous connecter à une machine :
+
+* `snster display isp-a-home` : pour afficher le bureau de la machine isp-a-home qui peut vous servir de navigateur web à l'intérieur du réseau de MI-LXC (en tant qu'utilisateur debian)
+* `snster attach target-dmz` : pour obtenir un shell sur la machine target-dmz (en tant qu'utilisateur root)
+
+Toutes les machines ont les deux comptes suivants : debian/debian et root/root (login/mot de passe).
+
+> Question 2 : Depuis la machine isp-a-home, ouvrez un navigateur pour vous connecter à `http://www.target.milxc`. Vous accédez à une page Dokuwiki. Savez-vous sur quel serveur cette page est hébergée ?
+
+> 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é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.
+
+> Si la souris reste bloquée dans une fenêtre de display, appuyez sur CTRL+SHIFT pour la libérer. Un tuto vidéo de démarrage est proposé [ici](https://mi-lxc.citi-lab.fr/data/media/tuto.mp4) (attention, c'est pour une ancienne version avec des noms de commandes légèrement différents).
+
+
+
+Extension de l'infrastructure
+=============================
+
+MI-LXC permet le prototypage rapide d'une infrastructure. Nous allons maintenant ajouter un AS à l'infrastructure existante.
+
+Le déroulement va être le suivant :
+
+* Déclarer un numéro d'AS, une plage d'adresses IP et un nom de domaine pour cette nouvelle organisation
+* Créer cet AS minimaliste dans MI-LXC
+* Ajouter un autre hôte à cet AS
+* Modifier ce nouvel hôte
+
+Déclaration d'un nouvel AS
+-------------------------------
+
+Le fichier [doc/MI-IANA.fr.txt](https://github.com/flesueur/mi-lxc/blob/snster/doc/MI-IANA.fr.txt) représente l'annuaire de l'IANA. Vous pouvez y trouver un numéro d'AS libre ainsi qu'une plage d'IP libre. Les IPv4 routables sont attribuées dans l'espace 100.64.0.0/10 (réservé au CG-NAT et donc normalement sans risque de conflit local).
+
+Vous pouvez aussi en profiter pour prévoir un nom de domaine en .milxc, qui sera utilisé lors d'une prochaine séance.
+
+**Faîtes valider ce plan par l'enseignant**
+
+> Si vous n'êtes pas très à l'aise avec le choix de numéros d'AS et de plages d'IP, vous pouvez utiliser les paramètres de l'AS 9 "Evil" (cet AS n'est pas présent dans l'infrastructure fournie, ses paramètres sont donc libres).
+
+Création de cet AS dans MI-LXC
+------------------------------
+
+Un AS est représenté par un groupe d'hôtes. La première étape est ainsi de déclarer ce nouveau groupe dans le dossier configuration, en créant un nouveau dossier dans `~/mi-lxc/` contenant la description du groupe dans un fichier `group.yml`. Par exemple, le groupe existant "gozilla", proche de vos besoins, est défini de la manière suivante :
+* un sous-dossier `~/mi-lxc/gozilla`
+* un fichier `~/mi-lxc/gozilla/group.yml` de description des hôtes du groupe (un routeur et une machine d'infrastructure)
+
+Inspirez-vous de ce `group.yml` pour votre nouveau dossier en ne déclarant pour l'instant qu'un seul hôte routeur.
+
+Les _interfaces_ de l'hôte "router" décrivent sa connexion réseau et doivent être ajustées pour votre nouveau groupe. Pour chaque interface, il faut spécifier son bridge, son ipv4 et son ipv6 (optionnelle) de manière statique ici. Dans cet exemple :
+  * _transit-a_ est le bridge opéré par l'opérateur Transit-A, s'y connecter permet d'aller vers les autres AS, il faut utiliser une IP libre dans son réseau 100.64.0.1/24 et cette interface sera l'interface externe _eth0_
+  * _gozilla-lan_ est le bridge interne de l'organisation gozilla, on y associe une IP de son AS. Son nom doit **impérativement** commencer par le nom du groupe + "-", ici "gozilla-", et ne pas être trop long (max 15 caractères, contrainte de nommage des interfaces réseau niveau noyau). L'interface _eth1_ doit, pour vous, être connectée à un nouveau bridge dédié à votre nouvel AS et avoir une IP de votre nouvelle plage.
+
+Le _template_ bgprouter de l'hôte "router" décrit le paramétrage du routeur. Les champs _asn, asdev, neighbors4, neighbors6_ et _interfaces_ doivent également être ajustés pour votre nouveau groupe :
+
+* _asn_ est le numéro d'AS, tel que déclaré dans `MI-IANA.fr.txt`
+* _asdev_ est l'interface réseau qui sera reliée au réseau _interne_ de l'organisation (celle qui a les IP liées à l'AS, ce sera eth1 pour vous comme dans l'exemple)
+* _neighbors4_ sont les pairs BGP4 pour le routage IPv4 (au format _IP\_du\_pair as ASN\_du\_pair_)
+* _neighbors6_ sont les pairs BGP6 pour le routage IPv6 (optionnel, au format _IP\_du\_pair as ASN\_du\_pair_)
+
+Pour intégrer votre nouvel AS, il faudra donc choisir à quel point de transit le connecter et avec quelle IP. Un `snster print` vous donne une vue générale des connexions et IP utilisées (tant que le YAML est bien formé...).
+
+Une fois ceci défini, un `snster print` pour vérifier la topologie, puis `snster create` permet de créer la machine routeur associée à cet AS (ce sera un Alpine Linux). L'opération create est paresseuse, elle ne crée que les conteneurs non existants et sera donc rapide.
+
+> **DANGER ZONE** On va détruire un conteneur et uniquement un. Si vous faîtes une fausse manipulation, vous risquez de détruire l'infra complète et de mettre ensuite 15 minutes à tout reconstruire, ce n'est pas le but. Donc spécifiez bien le nom du conteneur à détruire et, si vous êtes dans une VM, ça peut être le moment de faire un snapshot...
+
+À ce moment, par contre, le pair BGP (l'autre bout du tunnel BGP, par exemple le conteneur transit-a-router) ne connaît pas encore ce nouveau routeur. Il faut également déclarer ce nouveau pair de l'autre côté du tunnel BGP (ici, ce routeur du groupe "gozilla" est par exemple listé dans les pairs BGP du groupe "transit-a", défini dans le fichier `~/mi-lxc/transit-a/group.yml` : il *faut* mettre à jour la liste des voisins de transit-a-router dans ce fichier !). Il faut ensuite le détruire et le re-générer : `snster destroy transit-a-router` (détruit _uniquement_ le conteneur transit-a-router) puis `snster create` pour le re-générer.
+
+On peut enfin faire un `snster start` et vérifier le bon démarrage.
+
+> 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 `group.yml` de votre nouveau groupe ?
+
+> Question 6 : Vérifiez les sorties de `birdc show route all` et `birdc show protocols` de chaque côté de la connexion que vous avez rajoutée. Dans protocols, tout doit être "Established". Mettez des screenshots des sorties "protocols" dans votre compte-rendu.
+
+
+Ajout d'un hôte dans le nouvel AS
+--------------------------------------
+
+Nous allons maintenant ajouter un nouvel hôte dans cet AS. Dans le dossier du groupe, nous allons compléter le fichier `group.yml` qui décrit la topologie interne du groupe.
+
+> Si vous explorez les autres groupes, vous verrez qu'en plus du `group.yml`, il y a un sous-dossier par machine pour le provisionning de chacun de ces hôtes. Ce sont les "recettes" de création de chaque hôte pré-existant. Vous n'aurez pas à procéder comme cela de votre côté mais les recettes des autres hôtes pourront parfois vous aider durant de prochaines séances.
+
+En vous inspirant de `~/mi-lxc/gozilla/group.yml`, ajoutez un second hôte à votre groupe. Ce YAML définit :
+* qu'il y a un conteneur qui s'appelle infra
+* qu'il a une interface réseau branchée sur le bridge _gozilla-lan_ avec les IP spécifiées
+* que sa passerelle IPv4 est 100.83.0.1
+* qu'il utilise un template "resolv" (nous ne détaillerons pas, il vous faudra utiliser le même) qui désactive le DHCP et fixe le domaine et le serveur DNS
+
+Une fois tout ceci fait, on peut faire `snster print` pour vérifier que le YAML est bien formé et que la topologie est conforme. Un `snster create` créera ce conteneur, puis `snster start` le lancera (inutile d'avoir stoppé les autres avant).
+
+> Question 7 : Quel contenu dans `group.yml` ?
+
+
+Modification de cet hôte
+-----------------------------
+
+Maintenant que cet hôte est créé, nous allons le modifier. Il s'agit d'une Debian basique sur laquelle il est donc possible d'ajouter des paquets, les configurer, etc. Installez le paquet nano et vérifiez son fonctionnement. Ouvrez enfin un display sur cette nouvelle machine et vérifiez que vous pouvez naviguer avec Firefox vers `http://www.target.milxc` et vers un site internet externe à MI-LXC.
+
+Enfin, vous pouvez éteindre proprement MI-LXC en tapant `snster stop` et en arrêtant la VM (proprement également). Vos changements sont persistants : rallumez la VM, redémarrez MI-LXC et vérifiez que nano est toujours disponible sur votre nouvelle machine.
+
+> Question 8 : Montrez avec une capture d'écran que l'installation a bien fonctionné et que vous pouvez bien accéder à 'http://www.target.milxc' depuis votre nouvel hôte.
+
+
+Organisation pour la suite de la matière
+----------------------------------------
+
+L'infrastructure pré-existante suit le paradigme de l'_infrastructure-as-code_, c'est à dire que la topologie, les installations et les configurations sont _programmées_ (les yaml que vous avez manipulé ainsi que les `provision.sh`, par exemple dans `~/mi-lxc/target/dmz/provision.sh`). Cela permet de sauvegarder/versionner les recettes et de facilement regénérer des hôtes en cas de mauvaise manipulation. La contrepartie est de programmer les configurations plutôt que de juste les faire.
+
+A priori, vous n'utiliserez pas ces fonctionnalités (ce n'est en tous cas pas exigé). Vos configurations seront persistantes mais vous ne pourrez donc pas facilement revenir sur des erreurs de manipulation sur les hôtes rajoutés. Au-delà des comptes-rendus, vous avez donc tout intérêt à documenter vos actions.
+
+**Votre compte-rendu doit être déposé sur Moodle avant mercredi 23 novembre soir au format PDF uniquement**

td3-apache.md

@@ -0,0 +1,190 @@
+TD3 + TD4 + TD5 Apache/Tunnels/CMS (4h30, 3 séances)
+============================================
+
+_Compte-rendu à préparer et déposer en binôme_
+
+Ce TD couvre la configuration et l'utilisation d'un serveur HTTP Apache, les tunnels ainsi que l'installation d'un CMS Wordpress. Vous utiliserez Wireshark tout au long de ce TD pour analyser les échanges réseau.
+
+Ce TD sera réalisé dans la VM MI-LXC/SNSTER disponible [ici](https://flesueur.irisa.fr/mi-lxc/images/milxc-snster-vm-2.0.0pre1.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.
+
+> Le compte-rendu est à déposer en binôme sur Moodle.
+
+
+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 | snster print |
+| attach   | Permet d'avoir un shell sur une machine | snster attach target-sales |
+| display  | Lance un affichage sur la machine cible | snster display target-sales |
+| start    | Lance la construction du bac à sable    | snster start |
+| stop     | Éteint la plateforme pédagogique        | snster stop |
+
+Rappel: Vous devez être dans le répertoire `/root/mi-lxc/` pour exécuter ces commandes.
+
+
+Conception
+==========
+
+Vous allez étudier un serveur LAMP :
+* Linux
+* Apache
+* MariaDB (MySQL)
+* PHP
+
+> Question 1 : Choisissez un serveur pour installer/configurer cette pile LAMP (par exemple votre machine infra ou gozilla-infra). Choisissez une machine pour tester l'utilisation en tant que client (par exemple isp-a-home). 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"). 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.
+
+
+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 7 : Recopiez les commandes ssh exécutées.
+
+> Question 8 : 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.
+
+> [Doc externe](https://iximiuz.com/en/posts/ssh-tunnels/)
+
+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 9 : À l'aide d'un schéma, expliquez ce tunnel.
+
+> Question 10 : 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.)
+
+
+PHP (Bonus)
+===
+
+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 11 : Faîtes une capture d'écran de votre code source PHP et du résultat dans un navigateur.
+
+
+MariaDB (Bonus)
+=======
+
+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 12 : Faîtes une capture d'écran de PHPMyAdmin connecté en tant que root
+
+
+WordPress (Bonus)
+=========
+
+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 13 : Faîtes une capture d'écran de votre WordPress fonctionnel
+
+> Question 14 : 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 ?
+
+**Votre compte-rendu doit être déposé sur Moodle au format PDF uniquement**

td6-archi.md

@@ -0,0 +1,249 @@
+TD6 + 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/SNSTER disponible [ici](https://flesueur.irisa.fr/mi-lxc/images/milxc-snster-vm-2.0.0pre1.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.
+
+> Le compte-rendu est à déposer en binôme sur Moodle.
+
+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 | snster print |
+| attach   | Permet d'avoir un shell sur une machine | snster attach target-sales |
+| display  | Lance un affichage sur la machine cible | snster display target-sales |
+| start    | Lance la construction du bac à sable    | snster start |
+| stop     | Éteint la plateforme pédagogique        | snster 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" : `snster 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" (`snster 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 (`snster 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-sales | 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 `snster` (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 `snster 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 :
+
+* Segmentez le réseau "target" :
+	* Éditez `~/mi-lxc/target/group.yml` pour spécifier les interfaces sur le routeur. Il faut ajouter des interfaces sur de nouveaux bridges 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` definies dans le template bgprouter de la machine router.
+	* Modifiez les adresses des interfaces et les bridges des machines internes dans ce même fichier. Vous devrez aussi mettre à jour les serveurs mentionnés dans les paramètres des templates "ldapclient", "sshfs" et "resolv", 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écutez `snster print` pour visualiser la topologie redéfinie
+	* Exécutez `snster stop && snster renet && snster start` pour mettre à jour l'infrastructure déployée
+* Implémentez 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.
+
+> 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 au format PDF uniquement**