PAB's blog

Nextcloud 10 a introduit différentes améliorations de sécurité : notamment une protection contre les attaques de type force brute. Le principe en est simple : si l'instance détecte de multiples essais de connexion avec un mot de passe erroné depuis une même adresse IP, alors les requêtes de connexion de cette adresse ne recevront une réponse qu'après un temps d'attente d'une trentaine de secondes, rendant l'attaque par force brute délicate à mener.

Dans les logs, on verra alors des lignes similaires à :

{"reqId":"b4hUi89HUuji","remoteAddr":"10.20.30.40","app":"core","message":"Bruteforce attempt from "10.20.30.40" detected for action "login".","level":1,"time":"2016-10-17T04:08:55+00:00","method":"PROPFIND","url":"\/remote.php\/carddav\/","user":"--"}

qui nous apprennent que l'adresse 10.20.30.40 a fait un grand nombre d'essais de connexion ! Si l'on voulait renforcer la protection contre l'attaque de force brute, on pourrait alors également bannir cette adresse IP avec Fail2ban.

Et derrière un reverse proxy ?

Cependant, si l'on travaille derrière un reverse proxy (par ex. Pound ou Nginx) et si Nextcloud n'a pas été bien paramétré, alors l'adresse distante 'remoteAddr' sera celle du reverse proxy (192.168.1.1 dans l'exemple ci-dessous) :

{"reqId":"b4hUi89HUuji","remoteAddr":"192.168.1.1","app":"core","message":"Bruteforce attempt from "192.168.1.1" detected for action "login".","level":1,"time":"2016-10-17T04:08:55+00:00","method":"PROPFIND","url":"\/remote.php\/carddav\/","user":"--"}

Dès lors, toute attaque par la force brute pénalisera toutes les connexions qui passent par le reverse proxy ! Heureusement, il est possible d'indiquer à Nextcloud d'utiliser l'adresse fournie par le reverse proxy, par exemple dans le champ 'X-Forwarded-For', comme adresse distante !

Nextcloud et X-Forwarded-For

Pour l'exercice, considérons que l'adresse IP du reverse proxy est 192.168.1.1 et qu'il est paramétré pour indiquer l'adresse source dans le champ X-Forwarded-For.

Dès lors, ouvrons le fichier de configuration de Nextcloud (par ex. /var/www/nextcloud/config/config.php) et ajoutons ces 2 lignes :

  'trusted_proxies' => array('192.168.1.1'),
  'forwarded_for_headers' => array('HTTP_X_FORWARDED_FOR'),

La première ligne indique l'adresse IP du reverse proxy (Nextcloud ne doit regarder les en-têtes forwarded_for que pour les paquets provenant d'un reverse proxy autorisé, sans quoi un astucieux attaquant pourrait transmettre des paquets avec des en-têtes X-Forwarded-For forgées et aléatoires).

La seconde ligne indique quel est le champ à chercher dans les en-têtes : X-Forwarded-For dans notre cas (donc HTTP_X_FORWARDED_FOR dans les en-têtes $_SERVER retournées en PHP à Nextcloud).

Le tour est joué : au lieu de lire l'adresse IP du reverse proxy, Nextcloud lit désormais celle de l'hôte d'origine que lui fournit le reverse proxy et la protection contre les attaques de force brute se fait contre les adresse malfaisantes !

Complément

Le commit qui a ajouté cette fonctionnalité à ownCloud/Nextcloud se trouve ici.

Nous allons voir dans ce court article comment obtenir des certificats Let's Encrypt pour des services LemonLDAP::NG. Les chemins d'accès évoqués dans la suite correspondent à une installation de LemonLDAP::NG sur Debian Jessie à partir du paquet officiel fourni sur les dépôts de LemonLDAP::NG.

Étape 1 : obtenir un certificat pour le Manager

Nous allons commencer par autoriser l'accès au dossier .well-known dans lequel Let's Encrypt travaille (pour mémoire, il y place une clé qu'un serveur externe vient interroger, permettant ainsi d'affirmer que le demandeur gère le domaine). D'abord dans la configuration d'Apache, dans le fichier /etc/apache2/sites-available/manager-apache2.conf, nous allons remplacer la ligne

RewriteCond "%{REQUEST_FILENAME}" "!^/(?:static|doc|fr-doc|lib).*"

par

RewriteCond "%{REQUEST_FILENAME}" "!^/(?:static|\.well-known|doc|fr-doc|lib).*"

Puis, dans le manager lui-même, il faut demander à LemonLDAP::NG de ne pas bloquer l'accès au même dossier .well-known aux utilisateurs non authentifiés. Ainsi, il faut se rendre dans Virtual Hosts -> manager.mondomaine.fr -> Access rule, et ajouter une nouvelle règle :

• Regular expression: ^/\.well-known
• Rule: skip

Dès lors, Let's Encrypt devrait être capable d'accéder à la clé placée dans .well-known. Nous pouvons donc démarrer le processus avec le client Let's Encrypt :

certbot certonly --renew-by-default -a webroot --webroot-path /usr/share/lemonldap-ng/manager/ -d manager.mondomaine.fr

Étape 2 : obtenir un certificat pour le portail d'authentification

Facile :

certbot certonly --renew-by-default -a webroot --webroot-path /var/lib/lemonldap-ng/portal/ -d auth.mondomaine.fr

Étape 3 : obtenir un certificat pour une application placée derrière LemonLDAP::NG

Si l'application est protégée derrière LemonLDAP::NG, il faut commencer par indiquer à LemonLDAP::NG de laisser transiter les requêtes vers le dossier .well-known. A l'image de ce qui a été fait pour le manager, il faut se rendre dans Virtual Hosts -> manager.mondomaine.fr -> Access rule, et ajouter une nouvelle règle :

• Regular expression: ^/\.well-known
• Rule: skip

Puis tout simplement (si l'application sous-jacente ne filtre pas les accès à .well-known) :

certbot certonly --renew-by-default -a webroot --webroot-path /var/www/mon-app -d mon-app.mondomaine.fr

Face à la menace du "ransomware" Locky, j'ai décidé de protéger les données de mon serveur Samba à l'aide de Fail2ban. L'idée est simple : si des mouvements pouvant correspondre à une action de Locky sont détectés, alors l'IP à l'origine de l'action est bannie du serveur Samba.

Étape 1 : activer l'audit dans Samba

Samba dispose de puissantes fonctions d'audit qui permettent de garder trace de toutes les opérations sur un partage. Elles s'activent à l'aide des options full_audit dans le fichier /etc/samba/smb.conf. Attention toutefois à la volumétrie que cela peut représenter : si le serveur Samba est très sollicité, la taille des logs sera fort importante (surtout si l'on suit l'événement "open" qui est déclenché régulièrement lors de toute navigation sur le partage Samba) !

Plaçons donc le paramétrage suivante dans la section "Global" du fichier de configuration de Samba (/etc/samba/smb.conf par défaut) :

full_audit:priority = notice
full_audit:facility = local5
full_audit:success = mkdir rmdir rename unlink open
full_audit:prefix = %u|%I|%S

puis redémarrons Samba :

service samba restart

et voilà le fichier /var/log/samba/audit.log qui se remplit et recense tous les mouvements sur le serveur Samba. Une bonne rotation des logs sera nécessaire pour ne pas se faire piéger ! Attention également à la petite perte de performance que cette écriture régulière demandera.

Étape 2 : paramétrer le nouveau filtre d'exclusion pour Fail2ban

Nous allons demander à Fail2ban de bannir tout ordinateur qui effectuerait une opération sur fichier *.locky ou *.xxx sur le serveur. On crée le fichier /etc/fail2ban/filter.d/antilocky.conf suivant :

[Definition]
failregex = \|<HOST>\|NomDePartage\|.*\|ok\|.*\.(locky|xxx|mp3)

ignoreregex =

en remplaçant "NomDePartage" par le nom du partage Samba concerné.

Étape 3 : paramétrer une nouvelle prison dans Fail2ban

On paramètre comme il se doit Fail2ban dans /etc/fail2ban/jail.local en ajoutant notamment la section suivante :

[antilocky]
enabled = true
filter  = antilocky
backend = auto
logpath = /var/log/samba/audit.log
maxretry  = 2
banaction = iptables-allports
port = all

On peut alors redémarrer Fail2ban par :

service fail2ban restart

et vérifier dans les logs /var/log/fail2ban.log que la nouvelle prison se charge correctement.

Et voilà Fail2ban prêt à bannir tout ordinateur qui se connecterait au serveur Samba en manipulant des fichiers *.locky ou *.xxx. Evidemment il peut y avoir des faux positifs. Il est donc recommandé d'être vigilant et d'activer peut-être la notification par courriel des bannissements de ce type pour être en mesure de débannir dans le cas d'un faux positif et d'intervenir sur le poste infecté s'il s'avère qu'une réelle infection est en cours.

Étape 4 : limitations

La principale limitation est l'usage de l'extension de nom de fichier comme critère de signalement. Si des variantes du virus adoptent d'autres extensions (par exemple .pdf) alors il ne sera plus possible de détecter l'action frauduleuse de la sorte. On pourra éventuellement suivre le nombre d'opérations sur le partage Samba et alerter l'administrateur lorsque de trop nombreuses opérations de suppression sont en cours...

Dans un précédent article (ici), je proposais une méthode pour renouveler les certificats Letsencrypt en l'absence d'un mécanisme officiel pour le moment. Dans cette méthode (enfin ce script), je vérifiais la date du certificat avec "date -r", extrapolant la date de fin de validité à l'aide de la date de création du certificat et de la connaissance de la durée de validité par défaut des certificats de Letsencrypt.

Il y a en fait beaucoup plus intelligent ! Merci à mon beau-frère pour cette idée (toujours écouter au moins d'une oreille son beau-frère !)

Le manuel d'OpenSSL nous apprend l'existence de l'option suivante :

-checkend arg
checks if the certificate expires within the next arg seconds and exits non-zero if yes it will expire or zero if not.

Dès lors, il est facile de détecter si un certificat périme dans les 30 jours (2 592 000 secondes) :

if openssl x509 -checkend 2592000 -noout -in file.pem
then
  echo "Certificat valide encore au moins 30 jours"
else
  echo "Certificat périmant dans les 30 jours... à renouveler !"
fi

fail2ban-client set JAILNAME unbanip IPADDRESS

où l'on remplacera JAILNAME par le nom de la "jail" de Fail2ban à l'origine du bannissement et IPADDRESS par l'adresse bannie.

Par exemple :

fail2ban-client set ssh unbanip 1.2.3.4

Pour permettre la génération d'un certificat avec Let's Encrypt pour Gitlab, il m'a été nécessaire d'effectuer les opérations suivantes :

• Modifier la gestion des fichiers d'assets dans gitlab/config/environments/production.rb,

config.serve_static_assets = true

• Redémarrer Gitlab par

service gitlab restart

• Puis effectuer la génération du certificat avec le script Let's Encrypt en pointant le webroot vers le dossier public :

certbot certonly -a webroot --webroot-path /path/to/gitlab/public -d mongit.domaine.tld

Depuis le début du mois, il est possible d'utiliser "Let's Encrypt" pour obtenir des certificats TLS/SSL pour sécuriser ses sites et services en ligne (bien que le système soit toujours annoncé en bêta). Ce matin, je décidais donc de m'y mettre et de remplacer mes certificats StartSSL.

Depuis Mai 2016, le service Let's Encrypt n'est plus en bêta et les limitations de la bêta évoquées ici ne sont plus mordantes !

Depuis Mai 2016, le client letsencrypt est devenu certbot (https://certbot.eff.org/) ! les commandes évoquées plus bas sont sans doute valables en remplaçant letsencrypt-auto par certbot !

Première étape : comprendre le fonctionnement

Le principe est assez simple et n'est pas très différent de celui déjà rencontré pour l'obtention de certificats auprès des opérateurs "classiques" (les StartSSL et consors). Classiquement, (i) on démontre la possession réelle du nom de domaine, (ii) on génère une clé privée et une clé publique et on transmet la clé publique à l'opérateur de certification qui (iii) fournit en retour un certificat attestant le lien entre le nom de domaine et la paire de clés crypto utilisées pour l'établissement de communications sécurisées. Avec Letsencrypt, ces étapes ont lieu mais automatiquement. Dans l'utilisation commune, Letsencrypt vient avec un script Python (letsencrypt-auto) qui va faire tout le travail :

• le script va créer un fichier mondomaine.tld/.well-known/acme-challenge/chaîne-choisie-au-hasard et le serveur distant cherchera à accéder à ce fichier pour authentifier la possession/maîtrise du domaine mondomaine.tld
• puis le script génère et échange les clés cryptographiques avec l'autorité de certification Letsencrypt
• et le certificat est rapatrié
• enfin, dans certains cas, le script se charge même de l'installer !

Par rapport à ce qui est fourni habituellement par les acteurs privés :

• la chaîne de bout en bout est plus transparente et libre
• le certificat est gratuit
• le certificat n'a une validité que de 90 jours (mais le renouvellement est gratuit et peut être géré automatiquement par le script tous les 2 mois par exemple)
• les certificats n'autorisent pas les wildcards (e.g. *.mondomaine.tld) ce qui a déjà été fort amplement débattu partout sur le web mais ne semble pas devoir changer.

Deuxième étape : installer Let’s Encrypt

Nous allons commencer par le cas simple d'un site statique. Le script letsencrypt se télécharge sur la machine d'hébergement à l'aide de git :

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

puis on peut lancer le script (qui va effectuer les installations supplémentaires nécessaires) par :

./letsencrypt-auto

Cela fonctionne très bien sur Debian Jessie et sans doute les autres systèmes récents (c'est la version de Python qui semble être un des facteurs limitants pour les "vieilles" distributions). On reviendra sur ce point plus loin.

Troisième étape : utiliser Let’s Encrypt pour un site statique

Commençons par le cas simple d'un site statique hébergé dans /var/www/mon-site/ et servi par Apache.

./letsencrypt-auto certonly -a webroot --webroot-path /var/www/mon-site/ -d mondomaine.tld

certonly car nous demandons à Let’s Encrypt de générer le certificat et de s'arrêter là (donc de ne pas l'installer lui-même). -a webroot car nous indiquons à Let’s Encrypt où se trouve la racine du site afin qu'il puisse y placer le fichier de "challenge" (.well-known/acme-challenge/chaîne-choisie-au-hasard). Et -d mondomaine.tld pour indiquer le domaine. Il est possible d'indiquer plusieurs domaines s'ils partagent le même webroot par exemple :

./letsencrypt-auto certonly -a webroot --webroot-path /var/www/mon-site/ -d mondomaine.tld -d www.mondomaine.tld

Dans ce cas le certificat contiendra les 2 domaines en SAN (Subject Alternative Names).

Au premier lancement, le script demande de saisir l'adresse courriel qui sera rattachée au compte (et qui recevra les éventuelles notifications de péremption des domaines non renouvelés).

Et hop, le script travaille et un certificat tout neuf (et valide !) est déposé dans /etc/letsencrypt/live/mondomaine.tld/fullchain.pem. La clé privée correspondante se trouve dans /etc/letsencrypt/live/mondomaine.tld/privkey.pem. Ce certificat peut alors être utilisé comme il l'a toujours été (par ex. appelé dans la configuration d'Apache ou de votre load balancer) - je détaille ici comment l'utiliser avec le load balancer Pound.

Let’s Encrypt et un blog dotclear

Aucune surprise ni difficulté avec dotclear :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/blog/dotclear -d blog.bandinelli.net

et hop, /etc/letsencrypt/live/blog.bandinelli.net/fullchain.pem est créé ! Une commande pour un certificat, c'est classe et pratique !

Let’s Encrypt et Piwik

Aucune surprise ni difficulté avec Piwik :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/racine/piwik -d piwik.mondomaine.tld

et hop, /etc/letsencrypt/live/piwik.mondomaine.tld/fullchain.pem est créé !

Let’s Encrypt et Wordpress

Aucune surprise ni difficulté avec Wordpress :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/racine/wordpress -d mondomaine.tld

et hop, /etc/letsencrypt/live/mondomaine.tld/fullchain.pem est créé !

Let’s Encrypt et Drupal 7

Une petite astuce est nécessaire ici : par défaut le moteur de Drupal demande au serveur web de réécrire toutes les adresses et empêche l'accès à certaines adresses. Ainsi, le fichier .htaccess se trouvant à la racine d'un site Drupal contient la ligne suivante :

RewriteRule "(^|/)\." - [F]

Cette ligne ordonne à Apache de renvoyer vers la page "Accès interdit" toute requête qui débuterait par ".". Il faut bien évidemment désactiver cette sécurité pour Letsencrypt :

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule "(^|/)\." - [F]

La condition RewriteCond désactive la redirection qui suit pour le challenge de letsencrypt seulement.

Une fois cela effectué, on peut utiliser la commande classique pour obtenir le certificat valide dans /etc/letsencrypt/live/mondomaine.tld/fullchain.pem :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/site/drupal/ -d mondomaine.tld

Let’s Encrypt et ownCloud/Nextcloud

Une petite astuce est nécessaire ici : par défaut le moteur d'ownCloud demande au serveur web de réécrire toutes les adresses et empêche l'accès à certaines adresses. Ainsi, le fichier .htaccess se trouvant à la racine d'une instance ownCloud/Nextcloud contient la ligne suivante :

RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

elle renvoie vers 404 tous les appels à un chemin démarrant par ".". Il est bien sûr nécessaire de désactiver cette ligne conditionnellement :

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

Ensuite, sans surprise, pour obtenir le certificat valide dans /etc/letsencrypt/live/mondomainecloud.tld/fullchain.pem :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/owncloud/ -d mondomainecloud.tld

Let’s Encrypt et une application Ruby on Rails

Aucune surprise ni difficulté avec une application Ruby on Rails servie en production par Unicorn, à condition de bien choisir le dossier public comme webroot :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/application/public -d domaine.tld

et hop, /etc/letsencrypt/live/domaine.tld/fullchain.pem est créé !

Let’s Encrypt sur une vieille distribution ?

Si Let's Encrypt ne peut être lancé sur votre machine de production car elle dispose de versions trop anciennes des fichiers, rien n'est perdu ! Il est en effet possible de fournir au script un webroot qui serait par exemple partagé via SSH ! Par exemple :

apt install sshfs
mkdir /mnt/webroot-distant
sshfs user@machine:/path/to/webroot /mnt/webroot-distant
./letsencrypt-auto certonly -a webroot --webroot-path /mnt/webroot-distant -d mondomaine.tld

Conclusion

Très efficace et rapide, comment ne pas tomber sous le charme de Letsencrypt ? Il reste à valider : la procédure de renouvellement et la pérennité dans le temps de la structure. Pour y aider, on peut toujours faire un petit don sur la page d'accueil de Let’s Encrypt !

J'utilise Pound dans mon infrastructure, notamment pour sa capacité d'assurer tout le chiffrement en SSL/TLS entre mes serveurs et les clients.

Cependant, la version stable de Pound dans Debian Wheezy n'est pas patchée pour écarter les récentes "attaques" sur SSL/TLS à commencer par la corruption de SSLv3 (faille baptisée Poodle).

Si la version 2.7, la prochaine stable, disposera de tous les derniers raffinements, seule une branche non officielle pourra satisfaire le plus scrupuleux adminsys. Cette branche non officielle est maintenue par Joe Gooch (qu'il soit permis ici de le remercier !) et est disponible ici : https://github.com/goochjj/pound/tree/pcidss/v2.6.

Voici comment Joe décrit cette branche :

The other is called pcidss/v2.6, which is Pound 2.6, plus cipher and protocol patches necessary (initially) to pass PCI compliance, and as part of that is the directive to disable SSL3.

Compiler Pound 2.6-pcidss

• Télécharger la dernière version ici : https://github.com/goochjj/pound/archive/pcidss/v2.6.zip
• Dé-zipper l'archive et se rendre dans le dossier
• Réaliser ensuite la compilation (le système devra bien sûr comporter tout le nécessaire à cela : gcc, build-essentials, libssl-dev...) :

./configure
make
make install

• dans Debian, il semble que pound 2.6-pcidss s'installe dans /usr/local/sbin/pound alors que le paquet original l'installe dans /usr/sbin/pound. On peut donc remplacer l'ancienne version par la nouvelle et vérifier que l'utilitaire par défaut correspond bien à la nouvelle version :

pound -V

qui doit retourner 2.6-pcidss.

• on peut alors modifier la configuration de Pound avec ces paramètres :

	DisableSSLv2
	DisableSSLv3

	Ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:-RC4:EECDH+aRSA+RC4:EECDH+RC4:EDH+aRSA+RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:RC4+SHA"
    	SSLHonorCipherOrder 1
	SSLAllowClientRenegotiation     0

• et redémarrer Pound

Normalement, vous devriez désormais disposer d'un chiffrement SSL de qualité susceptible de vous faire obtenir un A (yes!) sur https://www.ssllabs.com/ssltest/ (si votre certificat est de bonne qualité - SSLLabs disqualifie tout de suite tout certificat auto-signé !).

Cette petite astuce ne suffira pas à sécuriser parfaitement votre serveur MariaDB/MySQL mais cela y contribuera fortement ! Et ça ne coûte que quelques secondes donc il serait bête de s'en priver.

La commande :

mysql_secure_installation

va automatiquement durcir votre installation et la rendre plus à même d'être déployée en production en :

• vérifiant que le(s) compte(s) 'root' dispose(nt) d'un mot de passe
• supprimer les comptes de test et la base de données de test accessible par défaut à tout utilisateur
• supprimer les comptes root (si vous le souhaitez) accessibles depuis un hôte autre que 'localhost'
• supprimer les comptes anonymes

Voilà qui permet d'être plus serein !

Nous allons utiliser dm-crypt+LUKS qui se basent sur les outils de cryptographie présents normalement dans le noyau linux. On pourra faire le reproche à cette solution de ne pas permettre mettre en place un déni plausible (i.e. ouvrir une partition avec des données à l'apparence normale sous la contrainte, TrueCrypt le permet).

Création de la partition

La partition à crypter se nomme : /dev/sdaX Choisissons le chiffrement aes-xts-plain avec un taille de clé de 512 bits :

cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdaX

Le système demande une 'passphrase' que l'on choisira bien sûr longue, avec de nombreux caractères accentués, des chiffres, des majuscules, des signes de ponctuation... Attention à ne pas perdre la 'passphrase' car sans elle, point de salut !

Puis accédons au périphérique :

cryptsetup luksOpen /dev/sdaX zonecryptee

et formatons l'espace comme souhaité puis montons le :

mkfs.ext3 /dev/mapper/zonecryptee
mount -t ext3 /dev/mapper/zonecryptee /mnt/dossiercrypte/

Pour fermer la partition cryptée :

umount /mnt/dossiercrypte/
cryptsetup luksClose zonecryptee

Pour obtenir des informations sur la partition crypée, on fera :

cryptsetup luksDump /dev/sdaX

Ajouter une clé pour accéder à la partition

Grâce à LUKS, on peut saisir plusieurs clés (jusqu'à 8) pour accéder à un même espace crypé. Commençons par générer une longe clé aléatoire :

dd if=/dev/urandom of=keyfile bs=1024 count=4

et ajoutons cette clé à l'espace crypté :

cryptsetup luksAddKey /dev/sdaX keyfile

On pourra désormais ouvrir l'espace, sans saisir la 'passphrase' secrète et sans crainte d'un keylogger ou d'une caméra qui filmerait nos mains sur le clavier, grâce à la commande :

cryptsetup --key-file=keyfile luksOpen /dev/sdaX zonecryptee

Après ouverture, la clé peut être retirée du système (elle n'est nécessaire qu'à l'ouverture) afin de limiter son exposition aux regards. Bien sûr, il ne faut pas perdre le fichier 'keyfile' et le conserver en sûreté ! S'il était compromis, on pourrait révoquer la clé avec la commande :

cryptsetup luksRemoveKey /dev/sdaX

Refermer la partition

Là rien ne change :

umount /mnt/dossiercrypte/
cryptsetup luksClose zonecryptee

Protégez-vous bien !