diff --git a/checker/checks.go b/checker/checks.go index 89199e1..69821d5 100644 --- a/checker/checks.go +++ b/checker/checks.go @@ -44,42 +44,32 @@ const ( var CheckMap = map[int]map[AdlinTest]int{ 2: map[AdlinTest]int{ - HTTPonIP: 101, - HTTPonAssociatedDomain: 102, - HTTPSonAssociatedDomain: 103, - DNSDelegation: 104, - HTTPonDelegatedDomain: 105, - HTTPSonDelegatedDomain: 106, - HTTPSSNI: 107, - DNSSEC: 110, + HTTPonIP: 100, + HTTPonAssociatedDomain: 101, + HTTPSonAssociatedDomain: 102, + DNSDelegation: 103, + HTTPonDelegatedDomain: 104, + HTTPSonDelegatedDomain: 105, + HTTPSSNI: 106, + MatrixSrv: 107, + MatrixClt: 108, + DNSSEC: 109, }, 3: map[AdlinTest]int{ - HTTPonIP: 201, - HTTPonAssociatedDomain: 202, - HTTPSonAssociatedDomain: 203, - DNSDelegation: 204, - HTTPonDelegatedDomain: 205, - HTTPSonDelegatedDomain: 206, - HTTPSSNI: 207, - MatrixSrv: 208, - MatrixClt: 209, - DNSSEC: 210, - }, - 4: map[AdlinTest]int{ - PingResolver: 300, - HTTPonIP: 301, - DNSDelegation: 303, - HTTPonDelegatedDomain: 304, - HTTPSonDelegatedDomain: 305, - MatrixSrv: 306, - MatrixClt: 307, - DHCPonRH: 308, - DHCPonDG: 309, - DHCPonCM: 310, - DHCPonGuests: 313, - RHaccessNews: 311, - RHaccessNet: 312, - GuestNet: 314, + PingResolver: 200, + HTTPonIP: 201, + DNSDelegation: 203, + HTTPonDelegatedDomain: 204, + HTTPSonDelegatedDomain: 205, + MatrixSrv: 206, + MatrixClt: 207, + DHCPonRH: 208, + DHCPonDG: 209, + DHCPonCM: 210, + DHCPonGuests: 213, + RHaccessNews: 211, + RHaccessNet: 212, + GuestNet: 214, }, } diff --git a/token-validator/htdocs/js/adlin-common.js b/token-validator/htdocs/js/adlin-common.js index da444d4..5c6145a 100644 --- a/token-validator/htdocs/js/adlin-common.js +++ b/token-validator/htdocs/js/adlin-common.js @@ -28,41 +28,27 @@ const tuto_progress = [ 12: { title: "SSH evade", icon: "💊", label: "SSH"}, }, { - 100: { title: "Firewalled", icon: "FW", label: "Firewall"}, - 101: { title: "HTTP on IP", icon: "0", label: "HTTP IP"}, - 102: { title: "HTTP on associated domain", icon: "1", label: "HTTP domain"}, - 103: { title: "HTTPS on associated domain", icon: "2", label: "HTTPS domain"}, - 104: { title: "DNS Delegation", icon: "3", label: "DNS"}, - 105: { title: "HTTP on delegated domain", icon: "4", label: "HTTP on NS"}, - 106: { title: "HTTPS on delegated domain", icon: "5", label: "HTTPS on NS"}, - 107: { title: "HTTPS-SNI", icon: "6", label: "HTTPS-SNI"}, - //108: { title: "Matrix Federation (bonus)", icon: "7", label: "Matrix SRV"}, - //109: { title: "Matrix Client (bonus)", icon: "8", label: "Matrix CLT"}, - 110: { title: "DNSSEC (bonus)", icon: "9", label: "DNSSEC"}, + 100: { title: "HTTP on IP", icon: "0", label: "HTTP IP"}, + 101: { title: "HTTP on associated domain", icon: "1", label: "HTTP domain"}, + 102: { title: "HTTPS on associated domain", icon: "2", label: "HTTPS domain"}, + 103: { title: "DNS Delegation", icon: "3", label: "DNS"}, + 104: { title: "HTTP on delegated domain", icon: "4", label: "HTTP on NS"}, + 105: { title: "HTTPS on delegated domain", icon: "5", label: "HTTPS on NS"}, + 106: { title: "HTTPS-SNI", icon: "6", label: "HTTPS-SNI"}, + 107: { title: "Matrix Federation (bonus)", icon: "7", label: "Matrix SRV"}, + 108: { title: "Matrix Client (bonus)", icon: "8", label: "Matrix CLT"}, + 109: { title: "DNSSEC (bonus)", icon: "9", label: "DNSSEC"}, }, - /*{ - 200: { title: "Firewalled", icon: "FW", label: "Firewall"}, - 201: { title: "HTTP on IP", icon: "0", label: "HTTP IP"}, - 202: { title: "HTTP on associated domain", icon: "1", label: "HTTP domain"}, - 203: { title: "HTTPS on associated domain", icon: "2", label: "HTTPS domain"}, - 204: { title: "DNS Delegation", icon: "3", label: "DNS"}, - 205: { title: "HTTP on delegated domain", icon: "4", label: "HTTP on NS"}, - 206: { title: "HTTPS on delegated domain", icon: "5", label: "HTTPS on NS"}, - 207: { title: "HTTPS-SNI", icon: "6", label: "HTTPS-SNI"}, - 208: { title: "Matrix Federation (bonus)", icon: "7", label: "Matrix SRV"}, - 209: { title: "Matrix Client (bonus)", icon: "8", label: "Matrix CLT"}, - 210: { title: "DNSSEC (bonus)", icon: "9", label: "DNSSEC"}, - },*/ /*{ 200: { title: "PONG resolver", icon: "0", label: "PONG srv"}, - 202: { title: "HTTP on IP (bonus)", icon: "1", label: "HTTP IP"}, - 204: { title: "DNS Delegation", icon: "2", label: "DNS"}, - 205: { title: "HTTP on delegated domain", icon: "3", label: "HTTP on NS"}, - 206: { title: "HTTPS on delegated domain", icon: "4", label: "HTTPS on NS"}, - 208: { title: "Matrix Federation", icon: "5", label: "Matrix SRV"}, - 209: { title: "Matrix Client", icon: "6", label: "Matrix CLT"}, - 211: { title: "RH access net", icon: "7", label: "RH net"}, - 212: { title: "DG access net", icon: "8", label: "DG net"}, - 213: { title: "CM access net", icon: "9", label: "CM net"}, + 201: { title: "HTTP on IP (bonus)", icon: "1", label: "HTTP IP"}, + 203: { title: "DNS Delegation", icon: "2", label: "DNS"}, + 204: { title: "HTTP on delegated domain", icon: "3", label: "HTTP on NS"}, + 205: { title: "HTTPS on delegated domain", icon: "4", label: "HTTPS on NS"}, + 206: { title: "Matrix Federation", icon: "5", label: "Matrix SRV"}, + 207: { title: "Matrix Client", icon: "6", label: "Matrix CLT"}, + 208: { title: "RH access net", icon: "7", label: "RH net"}, + 209: { title: "DG access net", icon: "8", label: "DG net"}, + 210: { title: "CM access net", icon: "9", label: "CM net"}, },*/ ]; diff --git a/token-validator/htdocs/views/home.html b/token-validator/htdocs/views/home.html index 56a09ef..2b66920 100644 --- a/token-validator/htdocs/views/home.html +++ b/token-validator/htdocs/views/home.html @@ -33,7 +33,7 @@ - +

diff --git a/tutorial/ansible/Makefile b/tutorial/ansible/Makefile index 7ecad1f..a292fc9 100644 --- a/tutorial/ansible/Makefile +++ b/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 vitrine.md nameserver.md SOURCES_ANSIBLE = tutorial.md ansible.md deploiement-svc.md rendu.md diff --git a/tutorial/ansible/anssi-guide-recommandations_mise_en_oeuvre_site_web-couverture.png b/tutorial/ansible/anssi-guide-recommandations_mise_en_oeuvre_site_web-couverture.png deleted file mode 100644 index 4d9ec5f..0000000 Binary files a/tutorial/ansible/anssi-guide-recommandations_mise_en_oeuvre_site_web-couverture.png and /dev/null differ diff --git a/tutorial/ansible/anssi.md b/tutorial/ansible/anssi.md deleted file mode 100644 index 043ceb2..0000000 --- a/tutorial/ansible/anssi.md +++ /dev/null @@ -1,44 +0,0 @@ -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 -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. - -Avant même de regarder service par service, il est important de passer en revue -la configuration du système d'exploitation en lui-même. - -Un bon point de départ pour faire cela est de suivre les recommandations de -l'ANSSI que vous jugez adaptées à votre déploiement :\ - - -![Le guide de recommandations de l'ANSSI fait référence](linux_configuration-fr.jpg){width=30%} - -::::: {.question} - -#### Quel niveau de durcissement choisir ? {-} - -Vous devriez viser un niveau de durcissement **minimal** selon la -classification de l'ANSSI. - -Par ailleurs, les recommandations 1 à 8 et 28 ne sont pas applicables ici puisque -vous êtes dans une machine virtuelle, et le bootloader est figé sur l'ISO. Mais -peut-être que vous devriez songer à appliquer ces recommandations à vos propres -machines. - -::::: - -::::: {.exercice} - -Faites le tour des configurations afin de vous assurer qu'elles sont -suffisamment durcies. Pensez à noter vos changements, vous devrez les -reporter dans un fichier au prochain TP ! - -::::: - -Outre la difficulté supplémentaire qu'un attaquant aura à pénétrer un système -correctement configuré, les scans automatiques auront également moins -d'informations à afficher car la récolte d'empreinte sera d'autant plus -difficile (par exemple si un logiciel n'expose pas son numéro de version). diff --git a/tutorial/ansible/linux_configuration-fr.jpg b/tutorial/ansible/linux_configuration-fr.jpg deleted file mode 100644 index 585718d..0000000 Binary files a/tutorial/ansible/linux_configuration-fr.jpg and /dev/null differ diff --git a/tutorial/ansible/maatma.md b/tutorial/ansible/maatma.md index 71accd7..7ba9fe4 100644 --- a/tutorial/ansible/maatma.md +++ b/tutorial/ansible/maatma.md @@ -12,8 +12,8 @@ Ce service vous est proposé à titre éducatif. Vous savez combien Internet peut être un milieu hostile, il est donc de votre devoir de ne pas tenter le diable et de prendre toutes les mesures qui s'imposent pour vous protéger en conséquence. D'autre part, il va de soi que ce service vous est -fourni en échange de **votre consentement à ne pas l'utiliser d'une manière -condamnable** (mais libre à vous de tester la plate-forme en elle-même). +fourni en échange de votre consentement à ne pas l'utiliser d'une manière +condamnable (mais libre à vous de tester la plate-forme en elle-même). ::::: @@ -58,56 +58,33 @@ L'interface `wg0` correspond à la porte d'entrée du trafic Internet. C'est ell que vous devez garder avec attention. Votre passerelle répond aux `ping`, une fois la connexion établie, vous devriez -pouvoir : - -``` -ping 2a01:e0a:2b:2252::1 -``` +pouvoir `ping 2a01:e0a:2b:2252::1`. IPs et domaine de test ---------------------- -### Les IP +En plus de vous fournir une IPv6, vous disposerez d'un nom de domaine ainsi +qu'une délégation sur un sous-domaine. -En plus de vous fournir une IPv6 publique, vous disposerez d'un sous-domaine -propre ainsi qu'une délégation sur un domaine. +Commencez par demander un nom de domaine *Association simple*, dans un premier +temps. Ceci créera un domaine qui vous permettra d'accéder à votre machine sans +avoir à connaître son IP. -Notez que vous **ne disposez pas** d'IPv4 publique (c'est-à-dire routable sur +Dans un deuxième temps, nous verrons comment tirer parti de la délégation. Vous +pouvez l'ignorer pour le moment. + +Notez que vous ne disposez pas d'IPv4 publique (c'est-à-dire routable sur Internet), vous disposez seulement d'une IPv6 publique. L'ensemble de vos -services seront cependant accessibles également en IPv4, car Maatma transmet +services sont cependant accessibles également en IPv4, car Maatma centralise les requêtes faites en IPv4 et les distribue entre vos IPv6, **lorsque le -protocole permet de faire cette redistribution**. Par exemple, HTTP et HTTPS le +protocole permet de faire cette distribution**. Par exemple, HTTP et HTTPS le permettent, mais pas SSH. Vous ne pourrez donc pas vous connecter en SSH via -l'IPv4 de Maatma (ni en utilisant votre domaine). +l'IPv4 de Maatma. Voici un schéma reprenant ces explications : ![Schéma du tunnel mis en place par Maatma](maatma-tun.png) On voit bien que l'IPv6 est connectée directement au tunnel, mais que l'IPv4 -passe par une étape de sélection. Les protocoles qui exposent le domaine de -destinations tels que HTTP et HTTPS sont donc routés vers vos machines -virtuelles respectives. - -### Les domaines - -Dans l'interface de Maatma, vous avez la possibilité de demander un simple -sous-domaine (*Association simple*) : ceci créera un domaine qui vous permettra -d'accéder à votre machine sans avoir à connaître son IP. Avec l'*Association -simple* Maatma gère le serveur de noms, vous n'avez rien à faire. - -Dans un deuxième temps, nous verrons comment tirer parti de la délégation. Vous -pouvez l'ignorer pour le moment.\ - - -::::: {.question} - -##### J'ai un nom de domaine perso, puis-je l'utiliser ? {-} - -Oui ! Que ce soit pour l'association ou pour la délégation, un bouton est -disponible pour vous permettre de dédier un sous-domaine de votre domaine -personnel. Vous aurez à faire quelques configurations dans votre zone DNS, mais -tout est expliqué clairement dans la boîte de dialogue. - -::::: +passe par une étape de sélection. diff --git a/tutorial/ansible/nameserver.md b/tutorial/ansible/nameserver.md index 3ea8edd..3687a86 100644 --- a/tutorial/ansible/nameserver.md +++ b/tutorial/ansible/nameserver.md @@ -3,14 +3,6 @@ Délégation de nom de domaine ============================ -Ça y est, votre vitrine est sécurisée ! Néanmoins, nous avons un peu -triché car vous ne contrôliez pas le nom de domaine de votre -vitrine. C'était Maatma qui vous fournissait un domaine, un peu comme -si vous créiez un blog Wordpress et utilisiez un domaine -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 requêtes DNS, avec la délégation, ce sera à vous, dans votre VM, de répondre diff --git a/tutorial/ansible/netfilter.md b/tutorial/ansible/netfilter.md deleted file mode 100644 index 07b7c96..0000000 --- a/tutorial/ansible/netfilter.md +++ /dev/null @@ -1,215 +0,0 @@ -Sécuriser les alentours ------------------------ - -Avant de commencer votre travail, il est important de mettre en place -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 : - -- 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. - -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), -- [installation de site Wordpress avant même que l'administrateur ait connaissance de l'adresse](https://portswigger.net/daily-swig/wordpress-sites-getting-hacked-within-seconds-of-tls-certificates-being-issued). - -Généralement, notre machine ne sera pas ciblée directement par un individu ou -une entité, à moins d'avoir fait l'objet d'un scan rapportant des brèches -intéressantes (version de logiciel vulnérable, OS déprécié, port connu ouvert, -mots de passe par défaut, ...). Il est donc très important d'apparaître le plus -neutre possible sur les scans automatiques, en exposant le strict minimum -d'information et de services. - -![Capture d'écran des informations relevées par Shodan pour nemunai.re](shodan-nemunai.re.png) - -::::: {.warning} - -Le site Shodan.io est une source d'information pertinente, mais il ne faut pas -se contenter de ces infections qui ne sont pas exhaustives. D'autres robots -peuvent récolter et tester bien plus en profondeur chaque service/port exposé. - -::::: - - -### Réduire la surface d'attaque - -Pour garantir qu'aucun service n'échappe à notre vigilance, nous allons mettre -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). - -Avant de commencer notre filtrage, regardons quels programmes sont en écoute -sur notre machine : - -``` -ss --listen --numeric --processes --tcp -ss --listen --numeric --processes --udp -``` - -La commande `ss` affiche la liste des programmes qui écoutent (ont `bind(2)` -puis `listen(2)`). Chaque ligne affichée est une porte d'entrée pour de -potentielles vulnérabilités, on s'assure donc que l'on a une confiance absolue -envers chaque programme listé. - -::::: {.exercice} - -Si à ce stade vous avez plus qu'un serveur SSH, trouvez le fichier qui démarre -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 : - -- 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 - 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 ? - -Pour réduire les risques, nous devons mettre en place des règles de pare-feu. - -Le pare-feu est un élément du noyau qui vient s'interposer dans les flux réseau -pour individuellement prendre une décision sur chaque paquet ou éventuellement -l'altérer. Il va par exemple être sollicité juste avant de transmettre à -l'espace utilisateur un paquet qui arrive d'une interface réseau (on parle de -paquet entrant). - -Nous pourrions donc aisément filtrer le port 22 (utilisé par le serveur SSH) -pour limiter à certaines IP le droit d'accéder à ce port. - -En fait, on utilise un pare-feu surtout en liste blanche. C'est-à-dire que l'on -interdit de base tout paquet entrant, SAUF ceux qui nous intéressent. On est -alors assuré que si un programme se met à écouter sur un port en dehors de -notre surveillance, il ne sera pas joignable car les paquets qui lui seront -destinés seront bloqués par le pare-feu du système. - - -### Mise en place du pare-feu - -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 : - -- `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 - fonctionnalités vieillissantes (séparation IPv4/IPv6, vitesse de traitement, - ...). - -Quelque soit la distribution, vous pourrez installer le paquet au nom de -l'implémentation que vous souhaitez utiliser. Dans la suite, nous allons -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 : - -``` -nft list ruleset -``` - -ou avec `iptables` : - -``` -iptables -t $TABLE --list -ip6tables -t $TABLE --list -``` - -On remarque qu'avec `iptables` on ne peut pas avoir accès à toutes les règles, on -ne peut les afficher que par TABLE et selon la version IPv4 ou IPv6. La table -`filter` est la table par défaut et celle que l'on uti lisera le plus, mais il -y a aussi `nat`, `mangle`, ...\ - -::::: {.warning} - -Faites attention lorsque vous changer 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 -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 ! - -::::: - -Avant d'interdire toutes les connexions entrantes, nous allons donc autoriser -notre connexion SSH ! On commence par créer une table : - -``` -nft add table inet -``` - -Le paramètre `inet` indique que l'on souhaite créer une table qui agira sur le -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 : -plutôt les paquets entrant, sortant, traversant, ... - -``` -nft add chain inet '{type filter hook input priority 0; }' -``` - -On va donc créer ici une chaîne nommée `mychain`, agissant en filtrage -(`filter`) sur tous les paquets entrant (`input`). On crée l'équivalent ici de -la chaîne `INPUT` de la table `filter` d'`iptables` et `ip6tables` mélangés. -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 : - -``` -nft add rule inet 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 : -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. - -Vous devriez prendre connaissance des [conditions possibles sur lesquelles -filtrer les -paquets](https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes#Matches) -et les [décisions possibles pour un -paquet](https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes#Statements). - -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. - -``` -nft add chain inet '{ policy drop; }' -``` - -Eh voilà ! vous êtes en sécurité. - -::::: {.exercice} - -Faites en sorte maintenant de limiter les connexions SSH à votre IP ou à la -plage d'IP susceptible de se connecter, plutôt que d'accepter toutes les IP. - -::::: diff --git a/tutorial/ansible/shodan-nemunai.re.png b/tutorial/ansible/shodan-nemunai.re.png deleted file mode 100644 index 5d9e684..0000000 Binary files a/tutorial/ansible/shodan-nemunai.re.png and /dev/null differ diff --git a/tutorial/ansible/vitrine.md b/tutorial/ansible/vitrine.md index 7f5aa9a..8c134c0 100644 --- a/tutorial/ansible/vitrine.md +++ b/tutorial/ansible/vitrine.md @@ -1,59 +1,47 @@ +\newpage + Vitrine ======= +Vitrine sécurisée ? +------------------- + +Avant de commencer votre travail, il est important de mettre en place +toutes les sécurités nécessaires au bon déroulement de votre mise en +production. Vérifiez qu'aucun service n'écoute inutilement sur +Internet, et renforcez cela au moyen d'un pare-feu (`iptables` ou +`nftables` par exemple). + +Faites le tour des configurations afin de vous assurer qu'elles sont +suffisamment durcies. Pensez à noter vos changements, vous devrez les +reporter dans un fichier au prochain TP ! + +À ce stade, vous devez suivre les recommandations de l'ANSSI que vous +jugez adaptées à votre déploiement : + + + Ma première vitrine ------------------- -Sur Maatma, [vous avez pu demander un -sous-domaine](https://adlin.nemunai.re/maatma/domains)/*Association simple*, -qui vous a attribué un nom de domaine (ou vous avez pu choisir d'utiliser un -sous-domaine de votre propre nom de domaine). +Sur le domaine `login-x.adlin2024.example.tld`, déployez une vitrine +d'entreprise basique. Vous n'allez pas déployer tout un Wordpress, mais un +simple lot de pages HTML ... générées avec Hugo. ::::: {.exercice} -L'idée maintenant, ce sera de déployer sur le domaine -`login-x.adlin2024.example.tld`, une vitrine d'entreprise basique. Vous n'avez -pas nécessairement besoin de déployer tout un Wordpress : un simple lot de -pages HTML ... générées avec Hugo, fera l'affaire. - -::::: - Vous aurez pour cela besoin d'un serveur web, dont le choix est laissé à votre discrétion. -Une fois votre serveur web configuré et votre vitrine déployée, accédez à votre -domaine depuis votre poste pour constater la bonne marche de l'installation -(vous aurez sans doute à adapter les règles de votre pare-feu). - - -Vitrine sécurisée ------------------ - -Dès que l'on déploie un nouveau service, qui plus est à destination de tout -Internet, comme c'est le cas ici pour notre vitrine, il convient de faire -particulièrement attention à la sécurité du service. Même dans le cas d'une -simple vitrine, de nombreux éléments de configuration peuvent rendre -l'installation sujète à des attaques. - -Dans le cas d'un site web, nous retrouvons un guide de l'ANSSI dédié :\ - - -![Le guide de recommandations de l'ANSSI pour les sites web](anssi-guide-recommandations_mise_en_oeuvre_site_web-couverture.png){width=22%} +::::: ::::: {.exercice} -Le guide est une nouvelle fois fort passionant, 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 -vitrine. +Vous pouvez utiliser les services de [Let's Encrypt](https://letsencrypt.org/) +pour obtenir un certificat TLS. ::::: -Vous pouvez utiliser les services de [Let's Encrypt](https://letsencrypt.org/) -pour obtenir un certificat TLS.\ - ::::: {.warning} Compte tenu [des limitations @@ -69,26 +57,7 @@ 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 -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 -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 -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). - -De nombreux programmes sont disponibles pour exploiter le [protocole -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 -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. +Une fois votre serveur web configuré et votre vitrine déployée, accédez à +votre domaine depuis votre poste pour constater la bonne marche de +l'installation.