tuto2: Ready

.drone.yml

@@ -120,12 +120,9 @@ steps:
   image: pandoc/latex:3.1.0
   commands:
   - sed -i s/v3.12/v3.14/ /etc/apk/repositories
-  - apk add --no-cache make ttf-linux-libertine
+  - apk add --no-cache make ttf-linux-libertine ttf-inconsolata
   - tlmgr update --self
-  - tlmgr install enumitem environ etoolbox preprint sectsty selnolig tcolorbox titling
-  - wget -O /tmp/FantasqueSansMono-Normal.tar.gz https://github.com/belluzj/fantasque-sans/releases/download/v1.8.0/FantasqueSansMono-Normal.tar.gz
-  - mkdir /usr/share/fonts/fantasque-sans-mono
-  - tar xf /tmp/FantasqueSansMono-Normal.tar.gz -C /usr/share/fonts/fantasque-sans-mono OTF/ TTF/ --strip-component=1
+  - tlmgr install enumitem environ etoolbox pdfcol preprint sectsty selnolig tcolorbox tikzfill titling
   - mkdir dist
   - make -C tutorial/ansible
   - mv tutorial/ansible/tutorial-2.pdf dist/tutorial-2-${DRONE_TAG##srs20??-tutorial2-}.pdf
@@ -175,12 +172,9 @@ steps:
   image: pandoc/latex:3.1.0
   commands:
   - sed -i s/v3.12/v3.14/ /etc/apk/repositories
-  - apk add --no-cache make ttf-linux-libertine
+  - apk add --no-cache make ttf-linux-libertine ttf-inconsolata
   - tlmgr update --self
-  - tlmgr install enumitem environ etoolbox preprint sectsty selnolig tcolorbox titling
-  - wget -O /tmp/FantasqueSansMono-Normal.tar.gz https://github.com/belluzj/fantasque-sans/releases/download/v1.8.0/FantasqueSansMono-Normal.tar.gz
-  - mkdir /usr/share/fonts/fantasque-sans-mono
-  - tar xf /tmp/FantasqueSansMono-Normal.tar.gz -C /usr/share/fonts/fantasque-sans-mono OTF/ TTF/ --strip-component=1
+  - tlmgr install enumitem environ etoolbox pdfcol preprint sectsty selnolig tcolorbox tikzfill titling
   - mkdir dist
   - make -C tutorial/nat
   - mv tutorial/nat/tutorial.pdf dist/tutorial-3-${DRONE_TAG##srs20??-tutorial3-}.pdf

tutorial/ansible/Makefile

@@ -1,6 +1,6 @@
 include ../pandoc-opts.mk
 
-SOURCES_2	= tutorial-2.md setup.md maatma.md what.md netfilter.md anssi.md vitrine.md nameserver.md
+SOURCES_2	= tutorial-2.md setup.md maatma.md what.md netfilter.md anssi.md vitrine.md nameserver.md nameserver-anssi.md nameserver-troubleshooting.md
 SOURCES_ANSIBLE	= tutorial.md ansible.md deploiement-svc.md rendu.md
 
 

tutorial/ansible/anssi.md

@@ -2,7 +2,7 @@ Durcir les configurations de base
 ---------------------------------
 
 Le pare-feu va vous aider à être moins susceptible d'attirer l'attention en
-présentant des scans épurés, et en n'exposant exclusivement que les ports
+présentant des scans épurés, et en exposant exclusivement que les ports
 nécessaires, aux bonnes personnes. Mais vous allez sans doute devoir présenter
 un certain nombre de services à Internet. Il convient donc de sécuriser au
 mieux ces services.

tutorial/ansible/nameserver-anssi.md

@@ -0,0 +1,44 @@
+Recommandations
+---------------
+
+Nouvelle page de publicité, l'ANSSI publie également un guide de bonnes
+pratiques sur l'aquisition et l'exploitation de noms de domaines :
+<https://www.ssi.gouv.fr/uploads/2014/05/guide_dns_fr_anssi_1.3.pdf>
+
+![Guide de recommandations pour les noms de domaines](guide_dns_fr_anssi_1.3-couverture.png){width=20%}
+
+Vous n'avez pas de recommandations à tirer de ce guide, mais dans le cas où
+vous auriez la responsabilité d'un domaine, c'est un guide à prendre en compte.
+
+
+### DNSSEC (bonus)
+
+Le DNS est un vieux protocole, particulièrement important sur Internet. Il
+souffre malheureusement de son âge, en particulier de part le manque de
+plusieurs mécanismes de sécurité. Citons notamment le fait que les paquets
+transitent en clair, souvent via UDP, sans mécanisme d'authentification ni de
+signature.
+
+Pour améliorer la situation, DNSSEC est une extension du protocole DNS qui
+permet de publier des signatures pour chaque enregistrement.
+
+Pour ce faire, et toujours parce que l'on se trouve dans le cadre d'une
+structure arborescente, les clefs publiques permettant de valider les
+enregistrements d'un domaine en particulier, sont à publier dans la zone
+parente. C'est pourquoi, vous disposez sur Maatma, d'une interface vous
+permettant d'indiquer vos clefs publiques.
+
+::::: {.exercice}
+
+Vous devriez sécuriser les réponses envoyées par votre serveur DNS en
+configurant DNSSEC.
+
+De nombreux articles sont disponibles sur Internet pour vous permettre de
+configurer DNSSEC en fonction du serveur faisant autorité que vous aurez
+choisi.
+
+Prenez garde, les signatures doivent être regénérées régulièrement. Ne
+choisissez pas une méthode ancestrale qui n'utiliserait pas les fonctionnalités
+de signature autonome du programme !
+
+:::::

tutorial/ansible/nameserver-troubleshooting.md

@@ -0,0 +1,73 @@
+Dépannage DNS
+-------------
+
+### Problèmes de cache
+
+Le DNS, comme on a pu le voir, est une structure hiérarchisée et fortement
+sollicitée.
+
+Afin d'éviter un engorgement excessif de certains serveurs (`.com` par
+exemple !) et de mieux répartir la charge entre les acteurs, un système de
+cache permet de garder en mémoire les derniers enregistrements consultés, dans
+la limite de leur durée de vie, annoncé par le champ TTL de chaque
+enregistrement.
+
+<div lang="en-US">
+```
+42sh$ dig adlin.nemunai.re A
+[...]
+;; ANSWER SECTION:
+adlin.nemunai.re.	78942	IN	A	82.64.31.248
+[...]
+```
+</div>
+
+`78942` c'est le nombre de secondes durant lequel l'enregistrement `A` pour le
+domaine `adlin.nemunai.re.` sera retourné par le résolveur, sans effectuer tout
+le cheminement de résolution.
+
+C'est vous dans le fichier de zone qui pouvez indiquer la durée que vous
+souhaitez utiliser : une durée faible vous permettra de plus facilement tester
+différents paramètres ou de changer régulièrement les enregistrements (pour
+tester c'est plutôt pratique), mais cela peut engendre une sollicitation
+excessive de votre serveur. À l'inverse, un cache long permet de se prémunir
+contre des problèmes de disponibilité, et tend à réduire les sollicitation du
+serveur faisant autorité.
+
+Tous les résolveurs étant indépendant, il n'existe pas de moyen[^PURGE_CACHE] pour vider le
+cache d'un résolveur que vous ne contrôlez pas, afin qu'il n'ait plus en cache
+une donnée potentiellement erronée. Il faut attendre la fin du TTL sur chaque
+résolveur.
+
+[^PURGE_CACHE]: Ce n'est pas exactement vrai, Cloudflare et Google ont des
+  formulaires pour forcer le vidage du cache de leurs résolveurs publics :
+  <https://1.1.1.1/purge-cache/> et
+  <https://developers.google.com/speed/public-dns/cache>.
+
+Ce problème cause parfois de gros problème, ce fût notamment le [cas pour Slack
+en
+2021](https://slack.engineering/what-happened-during-slacks-dnssec-rollout/).
+
+Si vous êtes confronté à un problème avec votre zone, commencez par regarder le
+TTL de l'enregistrement retourné par votre résolveur local.
+
+
+### Outils
+
+Lorsque vous allez établir votre délégation, vous pourriez utiliser l'outil
+[Zonemaster](https://www.zonemaster.fr/fr/) pour diagnostiquer d'éventuels
+problèmes avec vos enregistrements, les *GLUE records*, ...
+
+Pour diagnostiquer des problèmes liés à DNSSEC, vous pouvez utiliser :
+
+- [DNSViz](https://dnsviz.net/)
+- [DNSSEC Analyzer](https://dnssec-analyzer.verisignlabs.com/)
+
+
+#### happyDomain
+
+Enfin, pour gérer votre fichier de zone, vous pourriez vouloir passer par une
+interface web. Vous pouvez regarder du côté
+d'[happyDomain](https://www.happydomain.org/), que vous pouvez installer à côté
+de votre serveur DNS faisant autorité (exemple pour
+[knot](https://help.happydomain.org/fr/deploy/knot/)).

tutorial/ansible/nameserver.md

@@ -12,7 +12,7 @@ xxxx.wordpress.com fourni par le gestionnaire du service.
 Nous allons maintenant gérer notre propre domaine.\
 
 La deuxième solution proposée par Maatma est une délégation de nom de domaine.
-Alors que jusque-là, c'était les serveurs DNS de Maatma qui répondaient aux
+Alors que jusque-là, c'étaient les serveurs DNS de Maatma qui répondaient aux
 requêtes DNS, avec la délégation, ce sera à vous, dans votre VM, de répondre
 aux requêtes venues tout droit d'Internet.
 
@@ -149,9 +149,41 @@ Ce sont les administrateurs de la zone `wikipedia.org.` qui ont indiqué à
 `org.` quels étaient leurs serveurs de noms. Et ils ont également donné des
 *GLUE records*, pour permettre à la magie d'opérer.
 
+::::: {.exercice}
+
 À vous maintenant de créer votre zone, en envoyant sur Maatma, le nom de
 domaine votre serveur de noms, ainsi que le *GLUE record* qui lui correspond.
 
+:::::
+
+::::: {.warning}
+
+Rappelez-vous que vous ne disposez que d'une plage IPv6 publique. La
+connectivité IPv4 est fournie par Maatma, lorsque les protocoles
+permettent de router les paquets entrant.
+
+Bien qu'il serait théoriquement possible de le faire pour le DNS,
+**Maatma n'assure pas la résolution de vos noms de domaines**.
+
+Lorsque vous définissez votre *GLUE record*, vous ne devez indiquer
+que l'adresse IPv6 de votre serveur faisant autorité. **N'indiquez pas
+l'IPv4 de Maatma pour le sous-domaine dédié au serveur de noms.**
+
+Même si vous êtes dans un réseau entièrement IPv4, le résolveur de ce
+réseau va *généralement*[^NOLOCALIPv6] transmettre les requêtes à un
+résolveur qui aura une connectivité IPv6.
+
+[^NOLOCALIPv6]: Un résolveur pour une entité peut faire le choix de
+    résoudre lui-même les noms de domaines, et de ne pas être relié en
+    IPv6. Néanmoins vous ne serez pas confronté à ce cas de figure sur
+    les réseaux que vous utiliserez (EPITA, FAI français, ...). Si
+    vous l'êtes tout de même, changez l'adresse de votre résolveur
+    pour utiliser un résolveur public tel que celui de
+    [FDN](https://www.fdn.fr/actions/dns/) ou
+    [d'autres](https://en.wikipedia.org/wiki/Public_recursive_name_server).
+
+:::::
+
 
 ## À propos de Maatma et du portail IPv4
 
@@ -160,25 +192,9 @@ routable sur Internet. Mais aujourd'hui encore, de nombreuses
 installations ne disposent pas de ce protocole de communication et ne
 peuvent accéder aux machines connectées en IPv4 seulement.
 
-Pour palier cela, Maatma met à votre disposition une IPv4 mutualisée
+Pour pallier cela, Maatma met à votre disposition une IPv4 mutualisée
 entre tous les SRS. Un service écoute sur la machine au bout de cette
 IP, afin de distribuer le trafic entre vous, selon la demande du
 client. Tous les protocoles ne permettent pas d'identifier le domaine
 de destination, donc ce sont les protocoles HTTP et HTTPS qui sont
 transmis sur vos IPv6.
-
-
-
-## DNSSEC (bonus)
-
-En bonus, vous devriez sécuriser les réponses envoyées par votre serveur DNS.
-
-Pour ce faire, et toujours parce que l'on se trouve dans le cadre d'une
-structure arborescente, les clefs publiques permettant de valider les
-enregistrements d'un domaine en particulier, sont publiées dans la zone
-parente. C'est pourquoi, vous disposez sur Maatma, d'une interface vous
-permettant d'indiquer vos clefs publiques.
-
-De nombreux articles sont disponibles sur Internet pour vous permettre de
-configurer DNSSEC en fonction du serveur autoritaire que vous aurez choisi. À
-vous de jouer !

tutorial/ansible/netfilter.md

@@ -7,16 +7,16 @@ un minimum de sécurités pour anticiper les menaces potentielles.
 ### Identifier les menaces
 
 Il y a deux grandes catégories de menaces lorsque l'on rend visible
-une machine sur Internet :
+une machine sur Internet :
 
 - les scans automatiques ;
 - les individus/organisations.
 
 Dès qu'une machine est accessible sur Internet, celle-ci est scannée
 par des robots de nombreuses entités qui récoltent des informations ou
-même tente des attaques classiques.
+même tentent des attaques classiques.
 
-Voici des exemples :
+Voici des exemples :
 
 - [Shodan](https://www.safetydetectives.com/blog/what-is-shodan-and-how-to-use-it-most-effectively/),
 - [Wordpress/phpMyAdmin et autres scanner vulnérabilités](https://cirt.net/Nikto2),
@@ -47,10 +47,10 @@ en place un pare-feu.
 
 Sur un serveur Linux fraîchement installé, aucune règle de filtrage n'est
 appliquée. (Sur certaines version Desktop de distribution, un pare-feu est
-configuré pour n'accepte aucune connexion entrante).
+configuré pour n'accepter aucune connexion entrante).
 
 Avant de commencer notre filtrage, regardons quels programmes sont en écoute
-sur notre machine :
+sur notre machine :
 
 ```
 ss --listen --numeric --processes --tcp
@@ -71,16 +71,15 @@ les autres daemons pour faire en sorte qu'ils ne soient pas lancés inutilement
 
 ### Atténuer les menaces
 
-Avec `ss`, nous sommes en mesure de savoir précisément de quels ports nous
-avons besoin d'ouvrir sur notre machine. Cependant, nous faisons face à 2
-problèmes :
+Avec `ss`, nous sommes en mesure de savoir précisément quels ports nous avons
+besoin d'ouvrir sur notre machine. Cependant, nous faisons face à 2 problèmes :
 
 - on ne peut pas limiter facilement avec `bind(2)` les IP auxquelles on
-  voudrait autoriser l'accès du service (par exemple : tout Internet n'a pas
+  voudrait autoriser l'accès du service (par exemple : tout Internet n'a pas
   besoin d'accèder à notre serveur SSH, on en a seulement besoin pour
   administrer notre serveur, on arrivera sans doute d'une IP connue d'avance),
 - et si d'autres programmes se mettent à écouter sur des ports pendant le cycle
-  de vie d'un autre programme ?
+  de vie d'un autre programme ?
 
 Pour réduire les risques, nous devons mettre en place des règles de pare-feu.
 
@@ -106,11 +105,11 @@ Le pare-feu du noyau Linux est `netfilter`. On interagit avec lui avec des
 appels systèmes, et de nombreux logiciels permettent de gérer plus ou moins
 facilement les règles.
 
-Il y a 2 implémentations de référence :
+Il y a 2 implémentations de référence :
 
-- `iptables` : utilisé depuis 1998, il est aujourd'hui présent et utilisé par
+- `iptables` : utilisé depuis 1998, il est aujourd'hui présent et utilisé par
   la majorité des administrateurs système.
-- `nftables` : stable depuis 2021, il tend à remplacer `iptables`, aux
+- `nftables` : stable depuis 2021, il tend à remplacer `iptables`, aux
   fonctionnalités vieillissantes (séparation IPv4/IPv6, vitesse de traitement,
   ...).
 
@@ -120,13 +119,13 @@ utiliser `nftables`, mais libre à vous d'utiliser l'implémentation de votre
 choix.
 
 Pour afficher la liste des règles actuellement appliquées, on utilise les
-commandes suivantes :
+commandes suivantes :
 
 ```
 nft list ruleset
 ```
 
-ou avec `iptables` :
+ou avec `iptables` :
 
 ```
 iptables -t $TABLE --list
@@ -140,19 +139,19 @@ y a aussi `nat`, `mangle`, ...\
 
 ::::: {.warning}
 
-Faites attention lorsque vous changer les règles de pare-feu à distance, car
+Faites attention lorsque vous changez les règles de pare-feu à distance, car
 votre connexion passe par ce pare-feu. Si vous bloquez toutes les connexions
 entrantes avant d'autoriser votre connexion SSH, vous vous retrouverez à la porte.
 
 Dans le contexte de ce TP, vous avez accès à la console dans votre hyperviseur
-pour remédier à la situation, mais parfois vous pouviez n'avoir comme solution
+pour remédier à la situation, mais parfois vous pourriez n'avoir comme solution
 que le redémarrage (les règles ne sont pas persistantes), voire le déplacement
-dans le datacenter, si vos règles sont chargées automatiquement au démarrage !
+dans le datacenter, si vos règles sont chargées automatiquement au démarrage !
 
 :::::
 
 Avant d'interdire toutes les connexions entrantes, nous allons donc autoriser
-notre connexion SSH ! On commence par créer une table :
+notre connexion SSH ! On commence par créer une table :
 
 ```
 nft add table inet <mytable>
@@ -163,7 +162,7 @@ trafic IPv4 et IPv6 à la fois ([voir les autres types de table
 supportés](https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families)).
 
 Au sein de notre table, nous allons maintenant créer une chaîne de règle. C'est
-ici que l'on va indiquer à quel `hook` du noyau on souhaite s'accrocher :
+ici que l'on va indiquer à quel `hook` du noyau on souhaite s'accrocher :
 plutôt les paquets entrant, sortant, traversant, ...
 
 ```
@@ -177,7 +176,7 @@ Cela permet d'indiquer au noyau à quel niveau on souhaite appliquer ces
 règles.
 
 Ajoutons justement notre première règle pour autoriser les connections
-SSH :
+SSH :
 
 ```
 nft add rule inet <mytable> <mychain> tcp dport 22 accept
@@ -185,7 +184,7 @@ nft add rule inet <mytable> <mychain> tcp dport 22 accept
 
 Au sein d'un chaîne, sauf rares exceptions, les règles sont évaluées
 séquentiellement et la première décision qui valide les conditions est retenue.
-Dans notre exemple ci-dessus, la décision est d'accepter (`accept`) le paquet :
+Dans notre exemple ci-dessus, la décision est d'accepter (`accept`) le paquet :
 si aucune règle n'existe avant, validant aussi les conditions, cette règle sera
 la dernière d'un paquet TCP à destination du port 22, il sera ensuite délivré à
 l'espace utilisateur.
@@ -199,13 +198,13 @@ paquet](https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftabl
 Enfin, changeons la politique par défaut pour les paquets entrant pour lesquels
 aucune décision n'a été prise, qui est d'accepter tous les paquets, vers la
 politique `drop`, qui envoie vers un trou noir les paquets qui n'auront pas
-étéacceptés dans la chaîne.
+été acceptés dans la chaîne.
 
 ```
 nft add chain inet <mytable> <mychain> '{ policy drop; }'
 ```
 
-Eh voilà ! vous êtes en sécurité.
+Eh voilà ! vous êtes en sécurité.
 
 ::::: {.exercice}
 

tutorial/ansible/vitrine.md

@@ -42,11 +42,11 @@ Dans le cas d'un site web, nous retrouvons un guide de l'ANSSI dédié :\
 
 ::::: {.exercice}
 
-Le guide est une nouvelle fois fort passionant, mais nous nous concentrerons
+Le guide est une nouvelle fois fort passionnant, mais nous nous concentrerons
 aujourd'hui exclusivement sur la recommandation R1 : *Mettre en œuvre TLS à
 l'état de l'art*.
 
-Entre autres, il s'agit déjà de disposer d'un certificat valide pour votre
+Entre autre, il s'agit déjà de disposer d'un certificat valide pour votre
 vitrine.
 
 :::::
@@ -69,16 +69,16 @@ l'interface de Maatma pour pouvoir l'utiliser.
 
 :::::
 
-Let's Encrypt est une entitée qui génère de manière automatisée et gratuitement
+Let's Encrypt est une entité qui génère de manière automatisée et gratuitement
 des certificats TLS, dans le but de sécuriser l'accès aux services d'un domaine
 (que ce soit pour utiliser HTTPS, SMTPS, FTPS, ...).
 
-Leur service repose sur un test de propriété du domain, qui peut être réalisé
-de différentes manière (`http-01`, `dns-01`, ...). Une fois le test de
+Leur service repose sur un test de propriété du domaine, qui peut être réalisé
+de différentes manières (`http-01`, `dns-01`, ...). Une fois le test de
 propriété validé, il est possible de faire émettre un certificat pour une durée
 de 90 jours, pour le domaine validé.
 
-Ce court délais permet d'éviter d'avoir trop de révocations, mais cela implique
+Ce court délai permet d'éviter d'avoir trop de révocations, mais cela implique
 aux administrateurs d'automatiser la gestion des certificats (par exemple via
 une tâche *cron* qui va régulièrement venir renouveler les certificats et
 relancer les services qui les utilisent).
@@ -88,7 +88,7 @@ ACME](https://www.rfc-editor.org/rfc/rfc8555) : citons notamment
 [`certbot`](https://eff-certbot.readthedocs.io/en/stable/index.html)
 (implémentation officielle, mais dont l'installation et l'usage tendent à se
 complexifier même dans le cas des installations les plus simples), ou
-[`dehydrated`](https://github.com/dehydrated-io/dehydrated) (qui fourni un
+[`dehydrated`](https://github.com/dehydrated-io/dehydrated) (qui fournit un
 script dont le seul but est de générer un certificat sur une installation
 existante, avec moins de dépendances à l'installation). Mais de nombreux autres
 projets sont tout aussi viables pour utiliser le protocole ACME.