Chiffrer son dossier personnel (/home) sous Ubuntu

Ubuntu permet d’activer le chiffrement du dossier personnel lors de l’installation, grâce à eCryptfs.

Pourquoi chiffrer son dossier personnel ?

Parce que les documents personnels sont… personnels.

La demande du mot de passe à la connexion ou lors de la sortie de mise en veille ne protège absolument pas les données : il suffit de booter sur un LiveCD pour récupérer les données en clair très simplement.

Ces données peuvent être de toutes sortes :

  • des photos de vacances ;
  • l’historique de comptes en banque ;
  • les scans de documents administratifs ;
  • des mails ;
  • le contenu de discussions en messagerie instantanée ;
  • l’historique de navigation ;
  • les mots de passe enregistrés ;
  • bien d’autres choses…

Quand on sait que certains se font voler leur identité pour bien moins que ça… Vous me direz, certains n’ont pas besoin de se faire voler leurs données, ils donnent volontairement tous leurs mails privés à Google et plein d’autres infos à Facebook, alors… </troll>

Stockage des mots de passe

Je souhaiterais faire une parenthèse sur le stockage des mots de passe (sur un disque dur non chiffré).

Sur un système GNU/Linux, a priori il y a un trousseau de clés. Les logiciels peuvent l’utiliser pour enregistrer les mots de passe de manière sûre, en les chiffrant par une passphrase (par défaut le mot de passe du compte). C’est le cas par exemple d’Evolution, d’Empathy, de Gwibber… Pour voir les mots de passe enregistrés, il suffit d’ouvrir Applications > Accessoires > Mots de passe et clés de chiffrement.

Mais il y a un grand absent dans la liste des logiciels qui le gèrent : Firefox. Firefox enregistre les mots de passe quasiment en clair ; c’est dommage, c’est à lui qu’on donne la majorité de nos mots de passe. Du coup, si j’accède à un disque dur non chiffré, je peux récupérer tous les mots de passe enregistrés dans Firefox. D’ailleurs, c’est très simple : Édition > Préférences > Sécurité > Mots de passe enregistrés… > Afficher les mots de passe (ça devrait inciter les gens à verrouiller leur session quand ils s’absentent plus de 5 secondes). Il y a bien une option “Utiliser un mot de passe principal”, mais comme il n’est pas intégré au système, il faut le renseigner une fois par session Firefox (en plus du mot de passe système donc). Cela suffit à dissuader de l’activer.

Je ne sais pas si c’est prévu pour Firefox 4.0, mais je pense que la sécurité des mots de passe aurait été plus utile que des thèmes à la manière de WinAmp il y a 10 ans (pardon on dit des personas)…

Ceci donne un argument de plus pour chiffrer son dossier personnel… Parenthèse fermée.

Mise en place du chiffrement

Pour activer le chiffrement du dossier personnel lors de l’installation, il suffit de choisir la bonne option :

ubuntu-install-ecryptfs

(je vous conseille aussi d’utiliser une partition séparée pour /home)

Et voilà, c’est tout.

Enfin, pas tout-à-fait, car quand on chiffre ses données, il est certes important qu’elles soient protégées, mais il y a quelque chose d’encore plus important, c’est qu’elles soient récupérables…

Nous allons donc voir comment ça fonctionne, comment récupérer les données, ce à quoi il faut faire attention, etc.

Principe

Le système utilise une clé (une passphrase) pour chiffrer toutes les données avant de les écrire sur le disque. Elle est générée automatiquement, et devra être notée quelque part (sur un bout de papier à garder précieusement). Cette clé est elle-même chiffrée par une passphrase, qui est le mot de passe du compte utilisateur. Ainsi, lors de la connexion de l’utilisateur, la clé pourra être déchiffrée et utilisée pour lire et écrire des données.

Il faut bien distinguer ces deux passphrases :

  • la première est la passphrase de montage : c’est elle qui permet de monter et d’utiliser le répertoire chiffré ;
  • la seconde est la passphrase de login : c’est elle qui permet de déchiffrer la première, lors de la connexion de l’utilisateur.

Tant que vous connaissez la passphrase de montage, vous pourrez récupérer vos données. Si vous connaissez uniquement la passphrase de login, vous pourrez normalement récupérer la passphrase de montage (mais c’est plus sûr de garder dans un coin la passphrase de montage, car on peut effacer involontairement le fichier permettant de faire le lien). Si vous ne connaissez aucune des deux, vos données sont définitivement perdues…

Physiquement, les dossiers chiffrés sont stockés dans /home/.ecryptfs/USER/.Private. Les données servant au chiffrement et au déchiffrement sont dans /home/.ecryptfs/USER/.ecryptfs. Le répertoire /home/USER, quant à lui, n’existe pas physiquement : c’est juste une “vue” déchiffrée du répertoire .Private.

Remarque : les noms de fichiers étant eux-aussi chiffrés, ils ne comportent physiquement pas le même nombre de caractères que le nom de fichier “en clair” (d’autant plus qu’ils contiennent un préfixe). Ceci a une conséquence : en EXT4 les noms de fichiers ne doivent pas dépasser 256 caractères, mais un nom de fichier “en clair” d’environ 140 caractères entraîne un nom de fichier chiffré de 256 caractères. Les noms de fichiers sont donc limités à environ 140 caractères sur un dossier chiffré…

Connaître la passphrase de montage

Une fois le système démarré, il est possible de connaître la passphrase de montage :

$ ecryptfs-unwrap-passphrase
Passphrase: (entrer ici la passphrase de login)
6ebf259226f1d0859e707eb4349a9476

D’ailleurs, lors du premier démarrage, Ubuntu vous demandera d’exécuter cette commande et de noter quelque part le résultat.

Pour récupérer cette passphrase sans que le système en question soit démarré (par exemple en accédant à la partition à partir d’un LiveCD), il faut préciser le fichier qui contient la passphrase de montage chiffréer :

$ ecryptfs-unwrap-passphrase /media/DISK/.ecryptfs/USER/.ecryptfs/wrapped-passphrase
Passphrase: (entrer ici la passphrase de login)
6ebf259226f1d0859e707eb4349a9476

Changer la passphrase de login

On ne peut pas changer facilement la passphrase de montage, car il faudrait alors rechiffrer toutes les données. Par contre, la passphrase de login peut être aisément changée (puisque seule la passphrase de montage sera à rechiffrer).

En pratique, ce changement est fait automatiquement lors d’un changement de mot de passe du compte utilisateur.

Pour la changer manuellement (attention, il ne sera plus possible de démarrer correctement si la passphrase de login ne correspond pas au mot de passe de connexion) :

$ ecryptfs-rewrap-passphrase /home/.ecryptfs/USER/.ecryptfs/wrapped-passphrase
Old wrapping passphrase: (entrer ici l'ancienne passphrase de login)
New wrapping passphrase: (entrer ici la nouvelle passphrase de login)

Réinstaller le système d’exploitation

Pour réinstaller le système d’exploitation (par exemple pour y mettre une nouvelle version d’Ubuntu) en conservant son dossier personnel chiffré, il faut bien sûr avoir le /home sur une partition séparée, ne pas la formater lors de la nouvelle installation, mais il faut aussi utiliser le même login et le même mot de passe de connexion. Si vous respectez cette règle, vous n’avez rien de particulier à faire, tout est transparent.

Si vous avez changé le mot de passe, l’installation se déroule normalement sans avertissement, mais une fois le système installé, vous ne pourrez pas vous connecter (car vous n’avez pas de /home accessible). Si cela vous arrive, ce n’est pas bien grave, allez dans un TTY (Ctrl+Alt+F1), connectez-vous et changez manuellement votre passphrase de login (comme expliqué dans la section ci-dessus) pour la faire correspondre à votre mot de passe de connexion. Votre ancienne passphrase de login vous sera demandée.

Si malheureusement vous ne vous souvenez plus de votre ancienne passphrase de login (vous le faites exprès ou quoi ?), mais que vous possédez votre passphrase de montage, vous pouvez vous en sortir :

$ ecryptfs-wrap-passphrase /home/.ecryptfs/USER/.ecryptfs/wrapped-passphrase
Passphrase to wrap: (entrez ici la passphrase de montage)
Wrapped passphrase: (entrez ici la nouvelle passphrase de login)

Redémarrez le système, et normalement tout fonctionne.

Chiffrer son dossier personnel après installation

Il est également possible de chiffrer son dossier personnel une fois le système installé. Cependant, il y a une limitation très contraignante : il faut avoir comme espace libre 2,5× la taille de l’espace occupé par le dossier personnel, c’est-à-dire que la partition contenant /home ne doit pas être remplie à plus de 28%.

Avant toute chose, faire une sauvegarde sur un disque externe ou sur une autre machine (un problème pourrait entraîner la perte de toutes les données).

Le paquet ecryptfs-utils doit être installé :

sudo apt-get install ecryptfs-utils

La commande qui permet de migrer son home est ecyptfs-migrate-home. Cependant, aucune ressource de l’utilisateur du dossier personnel à migrer ne doit être utilisée (pas même un shell). On a donc besoin d’un autre utilisateur, par exemple root (provisoirement).

On réactive donc le compte root et on lui affecte un mot de passe :

sudo passwd root

Ensuite, il faut redémarrer la machine (déconnecter son compte ne suffit pas). Lors de l’écran de login, passer en TTY (Ctrl+Alt+F1), se connecter avec root, et exécuter :

ecryptfs-migrate-home -u USER

(en remplaçant USER par le nom de l’utilisateur dont le dossier personnel doit être migré)

Un peu de patience, il faut attendre un certain temps (qui se compte en heures selon la quantité de données et la puissance du processeur)…

Une fois terminé, se connecter avec l’utilisateur (repasser en mode graphique avec Ctrl+Alt+F7). Normalement tout doit fonctionner.

L’ancien dossier personnel (non chiffré) est dans /home/USER.xxxxxx.

Si tout s’est bien passé ce dossier doit être supprimé, et le compte root peut être désactivé :

sudo passwd --lock root

Récupérer ses données chiffrées

C’est la partie indispensable pour accepter d’utiliser un dossier personnel chiffré : être sûr de pouvoir récupérer ses données. Je vous conseille de tester cette procédure une fois le chiffrement mis en place.

Pour accéder aux données, il suffit d’un LiveCD d’une distribution avec un noyau Linux supérieur ou égal à 2.6.26. J’ai donc utilisé le LiveCD d’Ubuntu Lucid Lynx (10.04) pour mes tests, en m’inspirant de cette doc.

EDIT : Désormais, la commande ecryptfs-recover-private permet d’automatiser tout le processus manuel qui suit.

Tout d’abord, il faut monter la partition contenant les dossiers chiffrés (ça se fait graphiquement en cliquant sur le disque correspondant dans le menu Raccourcis). J’utiliserai l’emplacement /media/DISK comme exemple.

Tout ce que nous allons faire à partir de maintenant nécessite d’être root, passons donc root :

sudo -s

La signature de la clé de chiffrement des noms de fichiers sera nécessaire pour la suite :

root@ubuntu:/~# ecryptfs-add-passphrase --fnek
Passphrase: (entrer la passphrase de montage)
Inserted auth tok with sig [514d1d3af1a232cd] into the user session keyring
Inserted auth tok with sig [7890544814a5865f] into the user session keyring

C’est le code entre crochets de la dernière ligne qui est important.

On va monter le répertoire chiffré dans un répertoire qu’on va appeler decrypted, créons-le :

root@ubuntu:/~# mkdir decrypted

Ensuite, on monte et on répond aux questions :

root@ubuntu:/~# mount -t ecryptfs /media/DISK/.ecryptfs/USER/.Private decrypted
Selection [aes]:
Selection [16]:
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [514d1d3af1a232cd]: 7890544814a5865f

(pour la FNEK, il faut bien préciser la signature qu’on a récupéré juste au-dessus)

Si tout s’est bien passé :

Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=7890544814a5865f
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=514d1d3af1a232d
Mounted eCryptfs

Les données sont maintenant accessibles :

root@ubuntu:~# ls decrypted
Bureau     examples.desktop  Modèles  Public           Vidéos
Documents  Images            Musique  Téléchargements

Pour démonter :

root@ubuntu:~# umount decrypted

updatedb

updatedb indexe régulièrement les fichiers pour pouvoir les rechercher rapidement avec locate. Il faut lui indiquer de ne pas indexer les répertoires .Private afin de ne pas perdre du temps, de la place, et surtout éviter d’obtenir des résultats insignifiants lors d’une recherche avec locate.

Pour cela, ouvrir /etc/updatedb.conf, et éditer la ligne suivante pour y ajouter .Private (la décommenter si elle commençait par un #) :

PRUNENAMES=".git .bzr .hg .svn .Private"

Conclusion

Je pense qu’on a fait le tour de l’essentiel à savoir pour chiffrer son dossier personnel et pouvoir récupérer ses données. J’en ai profité pour chiffrer celui de mon ordinateur portable, tout fonctionne très bien.

Il faut cependant être conscient de deux choses.

Tout d’abord, les données personnelles ne sont pas présentes uniquement dans le répertoire /home, elles sont copiées dans /tmp, dans la RAM, dans le SWAP (il est également possible de chiffrer le SWAP, grâce à ecryptfs-setup-swap), etc. Le chiffrement est donc une étape essentielle dans la protection des données, mais il faut comprendre ce que ça protège (voir à ce sujet le guide d’autodéfense numérique).

Ensuite, ce chiffrement est là pour protéger la vie privée, pas pour cacher quelque chose à la justice. D’une part, le code pénal prévoit une peine de 3 ans et 45000€ d’amende pour refus de fournir la convention secrète de déchiffrement (autrement dit la clé). D’autre part, pour des sujets graves, nul doute que les États mettront les moyens pour casser la clé (qui est relativement faible, car proportionnée à l’objectif à atteindre, à savoir la protection de la vie privée).

Amusez-vous bien.

Sécuriser Apache2

Dans ce papier, nous allons faire petit un récapitulatif des bonnes pratiques pour sécuriser au mieux Apache contre les différentes attaques connues à ce jour.

Avec l’arrivée de Let’s Encrypt et donc de Certbot, nous n’avons plus d’excuse pour ne pas implémenter le TLS/SSL à notre Apache (https). Si ce n’est pas le cas chez vous, je vous recommande fortement à vous documenter et le déployer. Le chiffrement des connexions entre le client et le serveur pour des pages comme l’authentification est selon moi indispensable. 

Ici nous n’allons pas voir comment installer un certificat SSL avec Let’Encrypt et Apache mais plutôt revoir les paramètres de ce dernier pour le sécuriser en refusant, par exemple, l’utilisation de certains algorithmes de chiffrement et protocoles aujourd’hui vulnérable. Aussi, nous allons voir d’autres paramètres Apache à modifier pour se prémunir d’attaques de type Cross-site Scripting (XSS) et autre.
Pour commencer, ce billet se base sur la dernière version stable d’Apache2 (2.4). Aussi, nous nous basons sur le système d’exploitation Debian.

C’est important à savoir car sur certaines distributions, les fichiers de configurations ne sont pas les mêmes. Par exemple l’équivalent du fichier /etc/apache/apache2.conf sous RedHat et CentOS est /etc/httpd/conf/httpd.conf. De même que la syntaxe de certains paramètres peuvent différer entre la version 2.2 et 2.4 d’Apache.

Apache

Limiter les informations pouvant intéresser l’attaquant.

Dans le fichier /etc/apache/conf-available/security.conf:

# ne pas afficher la version d'apache dans les pages d'erreur
ServerSignature Off

# ne pas afficher les informations dans les en-têtes (headers)
ServerToken Prod

# ne pas afficher les informations comme les codes erreur aux clients
TraceEnable Off

# ne pas afficher les informations concernant PHP dans les en-têtes
Header unset X-Powered-By

# se protéger de fuites d'information lors de la mise en cache de données
FilETag none
Header unset ETag

# cet en-tête indique au navigateur d'activer la vérification des types mime (MSIE)
Header set X-Content-Type-Options "nosniff"

# cet en-tête indique au navigateur d'activer le filtre "anti-xss" s'il dispose de la fonctionnalité
Header set X-XSS-Protection "1; mode=block"

# se protéger des attaques dites clickjacking
Header always append X-Frame-Options SAMEORIGIN

Note: clickjacking

Vous aurez remarqué que la plupart de ces paramètres sont déjà présent dans la configuration par défaut mais commentés ou mal paramétrés. Concernant les en-têtes, cela s’explique par la nécessité de l’activation du module “mod_headers”. Pour que ces modifications soient donc prisent en compte, il faudra activer ce module avant de relancer Apache.

# activation du mod_headers
a2enmod headers

# relancer apache
service apache2 restart

Affinement au niveau du ou des sites. Ajouter cette modification des en-têtes afin de protéger vos Cookies dans le fichier vhost de votre site.

Header set Set-Cookie HttpOnly;Secure

Par défaut, les Cookies peuvent être accessible à tous programmes comme un script Javascript malveillant. Le flag “HttpOnly” permet d’indiquer au navigateur l’accès aux Cookies via des requêtes http. Le flag “Secure” permet de rediriger la requête “Cookie” initiale du navigateur vers un canal dit sécurisé, soit l’utilisation du https.

Dans la même lancée, nous allons en profiter pour modifier le (ou les) fichiers vhost_ssl afin d’y ajouter le mécanisme “HSTS”.

Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains; preload;"

Le HSTS permet d’imposer au navigateur si compatible l’utilisation du https. Ainsi, c’est le navigateur qui fait la redirection du trafic http vers https. Aussi, le navigateur va bloquer les pages ne s’affichant pas en https.
La valeur “max-age=2592000” permet d’indiquer au navigateur d’appliquer cette politique pendant une période de 30 jours. Il faut noter que cette configuration peut avoir un impacte si vous utilisez un proxy qui effectue le chiffrement https.

En parlant du canal https, passons maintenant à la sécurisation du TLS/SSL.

TLS/SSL

Pour commencer, il faut savoir que le terme “SSL” est largement employé par abus de langage alors que ce protocole est maintenant obsolète. En effet, même SSLv3 est aujourd’hui déchiffrable. Heureusement pour nous, il y a TLS. Protocole qui n’est pas sans failles non plus. Au même titre que SSLv3, TLSv1.0 est vulnérable à la faille dite “BEAST”. Ça date de 2011 tout de même.

Bref, commençons donc par limiter le choix des protocoles à utiliser en éditant le fichier de configuration du module SSL; /etc/apache/mods-available/ssl.conf.

SSLProtocol all -TLSv1 -SSLv2 -SSLv3

Notez que SSLv1 n’est plus du tout supporté.

Tout comme TLS/SSL, les algorithmes de chiffrements ne sont pas tous sans failles. Il faut donc aussi faire notre sélection et n’autoriser que ceux qui sont réputés fiable.

SSLCipherSuite SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

Notez que cette liste peut être amenée à changer dans le temps. Heureusement pour nous, le site cipherli.st ainsi que Mozilla mettent à disposition des outils pour nous aider à se mettre à jour.

Toujours dans les paramètres du module SSL, nous pouvons ajouter ces valeurs:

# prioriser l'algorithme par ordre
SSLHonorCipherOrder on
# désactiver la renégociation non sécurisé
SSLInsecureRenegotiation off
# désactiver la compression
SSLCompression off

Outils d’analyse

Voici quelques outils qui peuvent vous permettre un audit rapide de votre installation.

  • SSLLabs  : un tester web pour vérifier l’implémentation du SSL pour un site web donné
  • OpenVAS  : solution opensource permettant un audit complet pour une ou plusieurs machines
  • Nikto  : un script permettant de tester l’installation SSL avec support de proxy
  • testssl.sh  : un autre script permettant de tester l’installation SSL pour le web mais aussi pour les autres protocoles comme FTP, IMAP, SMTP etc

Nikto et testssl.sh m’ont été très utile pour la sécurisation de mon serveur mail et ftps. Je vous les recommandes vivement. Concernant testssl.sh, n’hésitez pas à l’utiliser avec “openssl1.0.2i-chacha”.

Comme vous l’avez constaté, cet article se consacre essentiellement sur Apache et le TLS/SSL. On voit brièvement comment sécuriser PHP mais cela ne sera pas suffisant, il faudra approfondir vos recherches pour modifier les paramètres du (ou des) fichier php.ini de vos sites par exemple.