Aller au contenu principal

Authentification et chiffrement

Cette page est à destination des administrateurices, elle détaille les protocoles d'authentification et de chiffrement utilisés pour les opérations de maintenance. Le but de ces protocoles est de permettre une administration collaborative fluide et sécurisée tout en gardant une bonne traçabilité.

Authentification​

Authentification sur les services​

Authentification centralisée​

Afin de d'éviter de créer un compte (et donc un mot de passe) par service, ce que devient vite fastidieux et source d'insécurité pour les utilisateurices, nous utilisons un service d'authentification centralisé (SSO). Nous avons choisi Hiboo pour les raisons explicitées ici par les créateurices. L'un des principaux avantages de cet outil et qu'il permet de séparer le processus d'authentification et la gestion des profils.

Ce service est hébergé à l'adresse auth.felinn.org (voir la documentation).

Il est possible d'activer une double authentification avec TOTP (nécessite un client TOTP) sur Hiboo. Cf. doc utilisateurice.

Hiboo gère l'authentification via les protocoles SAML et OICD qui permettent notamment que les services n'aient pas connaissance des identifiants et mots de passe utilisés par les comptes.

Pour le moment tous les services ne sont pas connectés à Hiboo.

Compte administrateurice​

  • Pour s'occuper des services web, on utilise au un compte dédié aux tâches d'administration. Dans certains cas (par exemple sur GitLab) ce sont les utilisateurices administrateurices qui ont les privilèges admin directement depuis leur compte personnel.
  • Pour les services système, on utilise généralement l'authentification PAM. Dans la mesure du possible, les services utilisent des user avec les privilège strictement nécessaires (pas root).

Authentification sur les serveurs​

Accès​

L'accès à distance au serveur pour les opération de maintenance se font en SSH avec une authentification par clé publique personnelle. Votre clé doit être ajoutée aux clé autorisées .ssh/authorized_keys.

Les services tournent dans des containers séparés. À de rares exceptions, les services sont accessibles depuis l'extérieur uniquement en https. Pour entrer dans un container, il faut se connecter sur le serveur principale en SSH et utiliser la commande pct enter <id>.

Traçabilité​

Les services utilisent etckeeper pour le suivi des modifications. Dans la mesure du possible les fichiers de configuration des services sont ajoutés dans /etc pour pouvoir tracer leur modification, en utilisant des liens symboliques vers leurs emplacements fonctionnels si besoin. Les répertoires git sont ajoutés sur la forge, ce qui permet de mettre en relation des issues et leurs résolutions dans les commits des fichiers de configuration et d'avoir une traçabilité historique.

Identification​

Pour identifier l'auteurice des modifications, un petit réglage est nécessaire dans les paramètres shell et SSH :

  1. configurer localement git avec le nom et l'email de l'auteurice tels que connus par notre instance Gitlab :
$ git config --global user.name "me"
$ git config --global user.email "me@exemple.net"
  1. ajouter des variables d'environnement git et les exporter dans .zshrc, .bashrc, etc :
# export local git config to ssh
export GIT_AUTHOR_NAME=`/usr/bin/git config user.name`
export GIT_AUTHOR_EMAIL=`/usr/bin/git config user.email`
export GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL
  1. demander à ssh d'exporter ces variables lors d'une connexion
$HOME/.ssh/config
Host cs20
SendEnv LANG LC_* GIT_*
  1. côté serveur, SSH est déjà configuré pour autoriser ces variables
/etc/ssh/sshd_config
# Allow client to pass locale environment variables
AcceptEnv LANG LC_* GIT_*

Maintenant lorsqu'un commit est réalisé, c'est votre configuration qui est utilisée :

commit bb8eb94763ae247ce4f87a272243cb741a26d054 (HEAD -> master)
Author: f00wl
Date:   Thu Dec 17 16:28:39 2020 +0100

CSP bumped to nextcloud 20

 nginx/conf.d/cloud.felinn.org.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Authentification​

Pour authentifier l'auteurice, les commits sont signés sur la machine distante avec votre clé privée locale grâce à gpg-agent forwarding.

La partie serveur étant déjà implémentée, voici ce qu'il faut faire en local :

  1. utiliser gpgconf --list-dir agent-extra-socket pour obtenir le chemin vers l'extra socket.
  2. modifier votre configuration SSH
$HOME/.ssh/config
Host cs20 # utiliser /etc/hosts ou l'IP
RemoteForward /run/user/0/gnupg/S.gpg-agent <chemin-vers-votre-extra-socket>
  1. ajouter votre clé publique sur le serveur, comme la clé est utilisée uniquement pour signer vous pouvez envoyer uniquement la sous-clé dédiée à cette tâche
# Le "!" permet d'agir sur une sous-clé
gpg --export XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX! | ssh root@cs20 'gpg --import'
  1. se connecter au serveur en ssh et vérifier que ça fonctionne
# Affiche le message PGP
echo "It works" | gpg --sign --armor -r XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX!

PGP​

Sous-clés​

Pour s'authentifier, la FELINN utilise PGP. Pour éviter de compromettre la clé mère CD182B1C1A8519150B19F186F69F95B658570C00, on utilise des paires de sous-clés.

astuce

Si vous n'avez jamais utilisé GPG nous vous recommandons d'aller voir un guide, par exemple celui-ci

On utilise des paires de sous-clés pour les différentes fonctions offertes par PGP : (E)ncrypt/decrypt, (S)ign, (A)uthentification, (C)reate/revoke.

$ gpg --list-keys --with-subkey-fingerprints CD182B1C1A8519150B19F186F69F95B658570C00
pub   rsa4096 2021-11-14 [SC]
  CD182B1C1A8519150B19F186F69F95B658570C00
uid   [ultimate] FELINN (main key) contact [arobase] felinn [point] org
sub   rsa4096 2021-11-14 [E] [expires: 2023-11-14]
  D4E3417FFD78FFF8BCE8543401044519A43D662F
sub   rsa4096 2021-11-14 [S] [expires: 2023-11-14]
  08AED1233523B50FC579EC2AA5EBF0FF2E6E76A7
sub   rsa4096 2021-11-14 [A] [expires: 2023-11-14]
  0514960E28B1890252747751791637A65A78BA63
remarque

Il existe un ancienne clé qui a été révoquée : C2B1708DD2935BB2A6E53FFBB3A4AE5611CD4314

attention

En cas de compromission d'une sous-clé, un certificat de révocation est publié et une nouvelle sous-clé générée.

Clé mère​

Si les clés filles permettent les opérations PGP du quotidien, la clé mère est quant à elle nécessaire pour des opérations plus sensible :

  • créer un certificat de révocation
  • générer une clé fille
  • modifier les clés existantes (expiration)
  • signer et truster une autre clé

Dès lors, cette clé bénéficie d'une protection beaucoup plus importante que les clés filles :

Personne ne détient la clé, elle n'existe pas à proprement parler, elle est découpée en plusieurs parties qui doivent être rassemblées pour la reconstituer et l'utiliser.

Gestion des mots de passe​

La sous-clé privée (E) donne la possibilité de lire l'ensemble des mots de passe utilisés par la FELINN qui sont gérés avec pass. Les mots de passe sont partagés entre les administrateurice sur un répertoire git accessible ici.

En temps qu'administrateurices vous aurez besoin d'accéder à ces mot de passe, et donc être en possession de la sous-clé qui permet de les déchiffrer. Pour cela il faut que vous soyez authentifié en temps que membre administrateurice avec les droits associés.

Pour vous authentifier personnellement auprès de la FELINN il faut suivre les étapes suivante. :

protocole
  1. Faire une clé RSA 4096 bit avec une bonne phrase de passe pour votre compte personnel si vous n'en avez pas déjà une, si possible utiliser ou ajouter l'identité <username>@felinn.org (votre adresse mail par défaut).
  2. Il est recommandé d'utiliser également des sous-clés pour chaque fonction et de garder votre clé mère en lieu sûr.
  3. Publiez votre clé sur un serveur de clé ou envoyez là directement à la FELINN via un canal qui vous identifie bien, avec une double authentification, par exemple [matrix] avec visio si une rencontre physique est impossible.

Si vous êtes administrateurice, votre clé sera signée par la clé de la FELINN, ce qui permettra de vous certifier comme administrateurice fiable. En fonction des besoins les clés privées vous seront transmises chiffrées avec votre propre clé par les autres membres. Pour importer une clé sans l'écrire en claire sur le disque on peux utiliser:

gpg --decrypt clé_prvée_chifrée_avec_votre_clé.gpg | gpg --import

On peut utiliser shred -un 42 clé_privée.gpg pour la supprimer vraiment d'un support de stockage.

Structure du répertoire​

Les mots de passe sont organisés suivant l'arborescence suivante : <service>/<logiciel>/<uid.gpg>.

service représente un service (foo.felinn.org), un logiciel (mysql), uid un identifiant (root).

On inscrit un seul mot de passe par fichier, sur une seule ligne, pour pouvoir utiliser pass -c.

Exemple
├── foo.felinn.org # service de la FELINN
│   ├── user.gpg   # user PAM/Web
│   ├── mysql  # services system
│   │   ├── admin.gpg  # user du service
│   │   └── root.gpg
│   └── root.gpg

Utilisation​

attention

Ne faites rien avant d'avoir passé cette check-list :

  • vous utilisez Linux ou un OS libre dans lequel vous avez confiance (pas windows, ya trop de backdoor)
  • votre OS n'utilise pas ou très peu de code propriétaire et les grands méchants ne sont pas root dessus
  • le support sur lequel vous aller stocker la clé est chiffré
  • votre session utilisateurice est protégée par une solide phrase de passe
  • vous avez lu et compris les bases du chiffrement asymétrique et et de PGP
  • vous avez réussi à envoyer un email chiffré à la FELINN avec votre propre clé (que vous n'oublierez pas de communiquer en PJ), et vous avez réussi à lire la réponse
  • vous maîtrisez les bases de git
# 1. Importez la sous-clé privé de la FELINN (la clé publique est inclue)
gpg --import FELINN-PRIVATE-SUBKEY.key

# 2. Supprimez le fichier et réécrire par dessus
shred -u -n 42 FELINN-PRIVATE.key

# 3. Cloner le repo
git clone git@git.felinn.org:FELINN/pass.git ~/.password-store

# 4. Essayer
pass generate -n test
[master 84838d7] Add generated password for test.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test.gpg
The generated password for test is:
vuGR2BZYm3sFDfW3AtnZzOelB

pass show test
vuGR2BZYm3sFDfW3AtnZzOelB

pass rm test
Are you sure you would like to delete test? [y/N] y
removed '/home/f00wl/.password-store/test.gpg'
[master d5ab287] Remove test from store.
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 test.gpg

pass gère git automatiquement, et il est possible de passer des commandes git à pass (voir la doc).

attention

N'oubliez pas de pull/push les répertoires afin de garder à jour les mots de passe avec tout le monde.

Utiliser pass avec git submodule​

Si vous utilisez déjà pass pour vos mots de passe personnels parce que c'est super, voici une solution :

# On suppose que vous avez déjà votre clé personnelle XXXXXXXX et que vous avec importé la clé de la FELINN
# 1. Si besoin, initialiser le repo pass avec votre clé perso !AVANT de cloner le dossier FELINN!
pass init XXXXXXXX

# 2. init repo
cd ~/.password-store
git init
git add .

# 3. ajouter le repo FELINN (C'est possible d'en ajouter d'autre)
git submodule add git@git.felinn.org:FELINN/pass FELINN

# 4. initialiser le(s) sous-module(s)
git submodule update --init --recursive

# 5. first commit your personal repo
git commit -m "pass git repo init"

# 6. ajouter un remote pour le repo perso si besoin
git remote add origin git@git.felinn.org/<user>/pass

# Pour accéder au mdp FELINN depuis pass:
pass -c FELINN/foo.felinn.org/root

# Pour récupérer les mots de passe (il faut peut-être ajouter --allow-unrelated-histories la première fois) :
git pull FELINN master
astuce

Voir la documentation officielle de git submodules.

Chiffrement​

Chiffrement du serveur (server-side)​

Les serveurs utilisent ZFS, les datasets qui contiennent les données sont chiffrés avec le chiffrement natif de ZFS.

remarque

Voir l'installation et la maintenance du serveur pour le détail de la gestion du stockage.

Chiffrement des connexions​

La totalité des connexions aux services est réalisée par des protocoles chiffrés :

  1. les connexion en SSH sont chiffrées nativement. La plupart des services ne sont pas accessible en SSH depuis l'exterieur, on passe par le serveur principale pour s'y connecter avec pct. Quelques LXC et VM sont accessible en SSH sur des ports alternatifs.
  2. les service web sont accessible via https, les certificats sont signés par Let's encrypt avec certbot. Toutes les connexions http sur le port 80 sont redirigées vers https sur le port 443. Le proxy web concentre toutes les connexions entrantes sur le serveur web. Les connexions sont redirigées vers les bons services en se basant sur le nom de domaine, la plupart des connexions internes sont en http sur le port 80 mais certaines sont chiffrées. À terme la totalité des connexions seront chiffrées en interne.
  3. les connexions au service de mail SMTP et IMAP sont chiffrées, les certificats sont signés par Let's encrypt avec certbot. Les émails sortant sont authentifiés avec le protocole DKIM. L'interface webmail roundcube permet d'utiliser des clés de PGP pour chiffrer et signer les mails.
  4. les connexions ftp sont rootées dans une connexion SSH.
  5. les requêtes DNS ne sont pas chiffrées, une amélioration sera d'utiliser et héberger un serveur DOH.

Chiffrement des services​

En plus du chiffrement ZFS, certains services possèdent leur propre capacité de chiffrement.

Chiffrement du cloud​

Nextcloud permet une couche supplémentaire de sécurité aux personnes voulant stocker des données sensibles. Notre instance propose du chiffrement de bout en bout : une fois les données chiffrées par cette technique elles sont accessibles uniquement au propriétaire et aux personnes concernées par un partage, il n'est pas possible pour les administrateurices de les déchiffrés. L'utilisateurice peut utiliser cette méthode de chiffrement sur des dossiers uniquement, et ceux-ci ne seront lisibles que par les appareils possédant les clés de chiffrement (et par les autres utilisateurices autorisé.es).

Choisir de chiffrer des fichiers avec cette technique est donc à double tranchant : nous ne pouvont pas fournir les données en clair en cas de demande judiciaire, mais nous ne pouvons pas vous aider à les recouvrer en cas de perte des clés de chiffrement non plus.

Un récapitulatif du chiffrement sur le cloud est disponible en commentaire de cette issue.

Chiffrement de [matrix]​

Le protocole [matrix] stocke les messages chiffrés en E2E sur le serveur (pour les salons privés ayant activé le chiffrement de bout-en-bout).

Chiffrement des émails​

Les emails sont chiffrés pendant le transit (SSL/TLS) mais ne sont actuellement pas chiffrés sur le serveur. À terme, les mails seront chiffrés avec une clé, elle-même chiffrée avec le mot de passe de l'utilisateurice et seront donc illisibles pour tout autre personne. Voir ici pour suivre l'avancée.