Nous nous posons des questions comment améliorer la sécurité des données dans l’infrastructure de RésiLien. Aujourd’hui, les données sont stockées en clair sur des disques dur situés dans nos locaux. Les sauvegardes quant à elles sont stockées de manière chiffrée par Restic sur l’Object Storage de Scaleway.
La question du chiffrement des disques a été mise de côté pour l’instant car elle ajoute une couche de complexité à notre gestion. Si nous chiffrons l’intégralité des disques avec LUKS au démarrage, il est nécessaire d’entrer le mot de passe à chaque redémarrage des machines. Hors, nous souhaitons éteindre les machines chaque nuit et les rallumer automatiquement au matin.
Parmi les services que nous proposons, Nextcloud intègre une fonctionnalité de chiffrement qui a l’avantage que l’équipe d’administration de RésiLien ne pourrait pas facilement accéder aux données des utilisateurs. Cependant d’après la documentation de Nextcloud, les clés de chiffrement sont tout de même stockées sur ce même serveur, et nous ne sommes pas sûrs de la fiabilité de cette fonctionnalité si elle ne risque pas de nous ajouter des problèmes au moment des mises à jour.
Une idée que nous avons commencé à avoir est de chiffrer partiellement le disque. C’est-à-dire chiffrer seulement la partition /var/lib/docker (car tous les services proposés par RésiLien fonctionnent dans Docker). Cela permettrait aux serveurs de démarrer automatiquement et nous pourrions ensuite automatiser le montage de la partition chiffrée via SSH.
Est-ce que cette solution vous semble viable ?
Quelles sont les pratiques de chiffrement parmi les CHATONS ?
Pour ma part j’ai deux serveurs dédiés dont l’intégralité des partitions sont chiffrés via LUKS (en dehors de /boot). Par contre j’ai fait le choix de ne pas chiffrer les données des instances nextcloud que j’héberge car, comme tu le dis, non seulement les clés sont stockées dans l’instance même et certaines applis (comme collabora il me semble) ne fonctionnent pas si le chiffrement est activé.
De plus j’ai déjà eu des demandes d’utilisateurs qui me demandaient de leur restaurer des fichiers perdus, ce que j’ai pu faire facilement grâce à borg (sauvegarde chiffrée bien sûr).
La solution semble viable mais on ne connaît pas le problème. Je pense que pour savoir si tes mesures sont efficaces, il faut poser le problème un peu plus précisément que « améliorer la sécurité des données dans l’infrastructure ».
En effet, je n’ai pas précisé si on avait un modèle de menace.
Pour l’instant nous n’avons que peu d’usages et peu de recul sur les risques.
Cependant nous imaginons déjà des risques en cas de vol/cambriolage dans un de nos locaux. N’ayant pas de centre de données sécurisé, le risque d’attaque physique peut être important. Pour cette raison, je pense que ça serait une bonne précaution que de chiffrer au niveau des disques afin que les données soient inaccessibles en cas de vol.
Il y a aussi le risque en cas d’attaque virtuelle sur l’infrastructure. Nous prenons nos précautions en ayant chacun nos clés d’authentification, en fermant les ports et en changeant les numéros de ports standards, désactivant l’authentification à l’utilisateur root, etc. Mais du fait que nos machines soient physiquement distribuées et connectées via Wireguard pour le réseau virtuel, si quelqu’un arrive à accéder à une machine, le reste du réseau est probablement accessible aussi et les données avec, même avec le disque chiffré. Dans ce cas-ci, je ne suis pas certains des bonnes pratiques à suivre.
Je serais intéressé pour suivre une formation en cybersécurité mais je n’ai pas encore trouvé une qui pourrait me convenir.
Si nous chiffrons l’intégralité des disques avec LUKS au démarrage, il est nécessaire d’entrer le mot de passe à chaque redémarrage des machines. Hors, nous souhaitons éteindre les machines chaque nuit et les rallumer automatiquement au matin.
Il est possible en utilisant Clevis et Tang de deverouiller automatiquement les disques via le réseau. Ensuite, il faut juste garder une machine allumé pour que les autres puissent démarrer (machine elle même ayant un disque chiffré sans passer par ce système).
Voici comment je procède lorsque je redémarre mes serveurs chiffrés (à l’exception de /boot).
Je redémarre.
Lorsque le ping revient, cela signifie que l’initrd est en cours d’exécution, la partition contenant l’OS n’est pas encore déverrouillée. J’exécute un script depuis mon poste local qui va :
Envoyer les sommes sha512 du kernel vmlinuz et de l’initrd.gz afin de vérifier qu’ils n’ont pas été modifiés par un tiers.
Envoyer le fichier clé pour déverrouiller la partition puis l’utiliser.
Terminer l’initrd pour démarrer l’OS.
Les connexions ssh se font bien entendu grâce à une clé ssh et non par mot de passe. Ainsi je n’ai aucun mot de passe à saisir lors de cette manipulation, j’ai juste à attendre que l’initrd soit exécuté pour lancer mon script. Dans le cas d’une automatisation complète, on peut imaginer un cron qui va vérifier si le ping est revenu pour exécuter automatiquement ce genre de script.
En espérant que ces informations puissent être utiles.
Y a un truc qui m’échappe, tu envoies les sommes vers le serveur que tu déverrouilles, mais si le kernel est modifié, il est potentiellement modifié pour s’en foutre. Et si tu reprends les sommes sha512 depuis le serveur, comment tu vérifies que le kernel/initrd te donne ce qui est sur le disque et pas ce que tu voudrais lire ?
Je n’ai pas compris où tu veux en venir. Le kernel et initrd ne sont modifiés que lorsqu’il y a une MAJ du kernel, jamais à un autre moment.
À chaque MAJ du kernel, je récupère immédiatement la somme du nouveau kernel et initrd que je conserve sur mon poste local. Ainsi je suis sûr de la vérification avant de déverrouiller la partition Luks.
Non. Tu parles de vérifier qu’un tiers n’a pas modifié le kernel. Donc je comprends que la vérification des sommes sha512 est une mesure de détection contre les actions de ce tiers qui voudrait modifier le serveur (implicitement dans un but néfaste ).
Mais je ne pige pas ce que ça empêche, vu que si le serveur est modifié, alors il peut être modifié pour soit dire « tout va bien » en donnant les mêmes sommes de contrôles qu’avant la modif, soit en disant « ok, les sommes sont pas bonnes, mais je continue quand même à booter ».
Tout d’abord comme tu l’as compris, cette vérification permet de vérifier uniquement que le kernel et initrd n’ont pas été modifié par un tiers (par exemple pour écouter ce qui est saisi au clavier au moment du déverrouillage par mot de passe). Autrement dit, si c’est l’OS qui a été compromis à un autre moment, avant ou pendant la MAJ du kernel, alors cette vérification ne sert à rien, et là c’est un autre problème à résoudre.
Par contre si au redémarrage la vérification échoue, la partition n’est pas déverrouillée et l’OS ne démarre pas. À ce moment là, je redémarre en mode rescue pour réinstaller le kernel et régénérer un initrd. Mais cela ne m’est jamais arrivé.
OK, je n’avais pas compris. Merci pour ton explication.
J’avais plus ou moins pensé à cette attaque au moment où j’avais préparé le terrain mais ne pensais pas que c’était aussi simple à mettre en œuvre. Et surtout je voulais éviter de passer par une signature, mais je crois que c’est finalement la solution à retenir.
Merci à vous 2 d’avoir pointé cette faille.
Edit: ou finalement j’envoie également un binaire sûr de sha512sum sur le serveur pour vérifier les sommes.
Un binaire sûr pour le sha512sum, ça va pas totalement corriger le souci. Théoriquement, une attaque pourrait aussi rajouter un module kernel qui détourne l’ouverture de fichier ou ce genre de choses. Ou plus prosaïquement injecter une bibliothèque (via LD_PRELOAD) ferait l’affaire aussi.
Donc ton binaire pourrait se retrouver à lire le mauvais fichier, vu que le kernel n’est pas sur.
Un autre souci est aussi que ni grub, ni sa config ne sont couvert par les sommes sha512, donc même si le kernel n’est pas touché, grub peut booter avec une config qui va changer quelque chose (mais j’ai pas d’idée d’attaque facile à ce niveau)
J’ai un peu peur que la méthode de bloquer ce genre d’attaque, c’est de passer par SecureBoot, c’est un peu prévu pour exactement ça (si possible avec ta propre clé ). Ensuite, je ne sais pas à quel point c’est intégré et documenté sur les divers distributions, ni l’état du BIOS et de l’EFI sur les machines de nos jours.
