tuto2: Add new parts
This commit is contained in:
parent
bd1e8725b6
commit
90c9c5beca
@ -1,6 +1,6 @@
|
||||
include ../pandoc-opts.mk
|
||||
|
||||
SOURCES_2 = tutorial-2.md setup.md maatma.md what.md vitrine.md nameserver.md
|
||||
SOURCES_2 = tutorial-2.md setup.md maatma.md what.md netfilter.md anssi.md vitrine.md nameserver.md
|
||||
SOURCES_ANSIBLE = tutorial.md ansible.md deploiement-svc.md rendu.md
|
||||
|
||||
|
||||
|
Binary file not shown.
After Width: | Height: | Size: 168 KiB |
44
tutorial/ansible/anssi.md
Normal file
44
tutorial/ansible/anssi.md
Normal file
@ -0,0 +1,44 @@
|
||||
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 :\
|
||||
<https://www.ssi.gouv.fr/guide/recommandations-de-securite-relatives-a-un-systeme-gnulinux/>
|
||||
|
||||
![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).
|
BIN
tutorial/ansible/linux_configuration-fr.jpg
Normal file
BIN
tutorial/ansible/linux_configuration-fr.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 49 KiB |
@ -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,33 +58,56 @@ 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
|
||||
----------------------
|
||||
|
||||
En plus de vous fournir une IPv6, vous disposerez d'un nom de domaine ainsi
|
||||
qu'une délégation sur un sous-domaine.
|
||||
### Les IP
|
||||
|
||||
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.
|
||||
En plus de vous fournir une IPv6 publique, vous disposerez d'un sous-domaine
|
||||
propre ainsi qu'une délégation sur un domaine.
|
||||
|
||||
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
|
||||
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 sont cependant accessibles également en IPv4, car Maatma centralise
|
||||
services seront cependant accessibles également en IPv4, car Maatma transmet
|
||||
les requêtes faites en IPv4 et les distribue entre vos IPv6, **lorsque le
|
||||
protocole permet de faire cette distribution**. Par exemple, HTTP et HTTPS le
|
||||
protocole permet de faire cette redistribution**. Par exemple, HTTP et HTTPS le
|
||||
permettent, mais pas SSH. Vous ne pourrez donc pas vous connecter en SSH via
|
||||
l'IPv4 de Maatma.
|
||||
l'IPv4 de Maatma (ni en utilisant votre domaine).
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
:::::
|
||||
|
@ -3,6 +3,14 @@
|
||||
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
|
||||
|
215
tutorial/ansible/netfilter.md
Normal file
215
tutorial/ansible/netfilter.md
Normal file
@ -0,0 +1,215 @@
|
||||
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 <mytable>
|
||||
```
|
||||
|
||||
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 <mytable> <mychain> '{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 <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 :
|
||||
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 <mytable> <mychain> '{ 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.
|
||||
|
||||
:::::
|
BIN
tutorial/ansible/shodan-nemunai.re.png
Normal file
BIN
tutorial/ansible/shodan-nemunai.re.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 419 KiB |
@ -1,47 +1,59 @@
|
||||
\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 :
|
||||
<https://www.ssi.gouv.fr/guide/recommandations-de-securite-relatives-a-un-systeme-gnulinux/>
|
||||
|
||||
|
||||
Ma première vitrine
|
||||
-------------------
|
||||
|
||||
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.
|
||||
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).
|
||||
|
||||
::::: {.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é :\
|
||||
<https://www.ssi.gouv.fr/uploads/2013/05/anssi-guide-recommandations_mise_en_oeuvre_site_web_maitriser_standards_securite_cote_navigateur-v2.0.pdf>
|
||||
|
||||
![Le guide de recommandations de l'ANSSI pour les sites web](anssi-guide-recommandations_mise_en_oeuvre_site_web-couverture.png){width=22%}
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Vous pouvez utiliser les services de [Let's Encrypt](https://letsencrypt.org/)
|
||||
pour obtenir un certificat TLS.
|
||||
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.\
|
||||
|
||||
::::: {.warning}
|
||||
|
||||
Compte tenu [des limitations
|
||||
@ -57,7 +69,26 @@ 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, ...).
|
||||
|
||||
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.
|
||||
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.
|
||||
|
Reference in New Issue
Block a user