Réseau - Web - GNU/Linux

2020 06 janvier

Comment augmenter l'entropie sur un serveur avec havaged

Rédigé par Marc GUILLAUME | Aucun commentaire

Traduction de : https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Brève introduction à l'entropie et au hasard

Le générateur de nombres pseudo-aléatoires (PRNG) de Linux est un dispositif spécial qui génère des nombres aléatoires à partir d'interruptions matérielles (clavier, souris, E/S disque ou réseau) et d'autres événements du système d'exploitation. Ce caractère aléatoire est surtout utilisé pour le chiffrement comme SSL/TLS, mais a aussi de nombreuses autres utilisations. Même quelque chose d'aussi simple qu'un programme pour lancer une paire de dés virtuels dépend de l'entropie pour obtenir des nombres alléatoires de bonne qualité (c'est à dire non prédictibles à partir des précédents nombres générés).

Lorsque le réservoir d'entropie se vide

Il y a deux dispositifs de génération de nombres aléatoires sous Linux : /dev/random et /dev/urandom. Les nombres les plus aléatoires proviennent de /dev/random, puisque ce périphérique se bloque chaque fois que sa réserve d'entropie devient insuffisante et qu'il attendra qu'une entropie suffisante soit de nouveau disponible pour continuer à fournir une sortie. En supposant que votre entropie soit suffisante, vous devriez avoir la même qualité de caractère aléatoire dans /dev/urandom ; cependant, comme c'est un périphérique non bloquant, il continuera à produire des données « aléatoires », même lorsque le réservoir d'entropie sera épuisé. Cela peut conduire à générer des données aléatoires de moindre qualité, car les répétitions de données précédentes sont beaucoup plus probables. Une faible disponibilité d'entropie sur un serveur en production peut conduire à de gros ennuis, en particulier lorsque ce serveur exécute des calculs cryptographiques. Par exemple, si vous disposez d'un serveur cloud qui exécute les démons suivants (tous utilisant SSL/TLS ou des chiffrages par blocs) :

  • Serveur Web
  • Serveur de courrier entrant et sortant
  • SSH/SFTP

Si l'un de ces démons nécessite un caractère aléatoire alors que toute l'entropie disponible a été épuisée, ils est possible qu'il s'arrête pour en attendre d'autres, ce qui peut entraîner des ralentissements excessifs dans votre application. Pire encore, puisque la plupart des applications modernes vont soit utiliser leur propre nombre aléatoire créé à l'initialisation du programme, soit utiliser /dev/urandom pour éviter le blocage, vos applications vont pâtir de données aléatoires de moindre qualité. Cela peut affecter l'intégrité de vos communications sécurisées, et peut augmenter les chances de cryptanalyse sur vos données privées.

Alimenter sa source d'entropie dans l'espace utilisateur

Linux obtient des données aléatoires de très bonne qualité à partir des sources matérielles mentionnées plus haut, mais comme un serveur n'a généralement ni clavier ni souris, il génère beaucoup moins d'entropie qu'un poste de travail. Les E/S disque et réseau représentent la majorité des sources d'entropie pour ces machines, et ces sources produisent de très faibles quantités d'entropie. Dans la mesure où très peu de serveurs, dédiés ou cloud ou de machines virtuelles disposent d'une source d'entropie (RNG) matérielle spécialement dédiée à cet usage, il existe plusieurs solutions en mode utilisateur pour générer une entropie supplémentaire en utilisant des interruptions matérielles provenant de périphériques qui sont plus « bruyants » que les disques durs, comme les cartes vidéo, les cartes son, etc. Mais cela ne règle pas le problème des serveurs malheureusement, car ils ne contiennent généralement ni l'un ni l'autre. C'est ici que haveged entre en jeu.

Basé sur le principe de HAVEGE, et basé sur sa bibliothèque associée, haveged permet de générer du hasard en fonction des variations du temps d'exécution du code sur un processeur. Comme il est presque impossible qu'un morceau de code prenne exactement le même temps pour s'exécuter, même dans le même environnement sur le même matériel, le temps d'exécution d'un ou de plusieurs programmes devrait convenir pour alimenter une source aléatoire. L'implémentation haveged alimente la source aléatoire de votre système (habituellement /dev/random) en utilisant les valeurs du compteur d'horodatage (TSC) de votre processeur après l'exécution d'une boucle de façon répétée. Bien que cela semble devoir finir par créer des données prévisibles, vous serez peut-être surpris de voir les résultats du test FIPS au bas de cet article.

Installation de haveged sur Debian/Ubuntu

Vous pouvez facilement installer haveged sur Debian et Ubuntu en exécutant la commande suivante:

# apt-get install haveged

Si ce paquet n'est pas disponible dans vos dépôts par défaut, vous devrez compiler à partir des sources (voir ci-dessous)

Une fois le paquetage installé, vous pouvez simplement éditer le fichier de configuration situé dans /etc/default/haveged, en vous assurant que les options suivantes sont définies (ce sont généralement déjà les options par défaut):

DAEMON_ARGS="-w 1024"

Enfin, assurez-vous qu'il est configuré pour démarrer au boot:

# update-rc.d haveged defaults

Installation de haveged sur RHEL/CentOS/Fedora

Pour installer haveged sur RHEL/CentOS (passez cette étape pour Fedora), vous devez d'abord ajouter le dépôt EPEL en suivant les instructions sur le site officiel.

Une fois que vous avez installé et activé le repo EPEL (sur RHEL/CentOS), vous pouvez installer haveged en exécutant la commande suivante:

# yum install haveged

Les utilisateurs de Fedora peuvent exécuter la commande yum install ci-dessus sans modifier le référentiel. Les options par défaut sont généralement correctes, puis assurez-vous qu'il soit configuré pour démarrer au boot :

# chkconfig haveged on

Installation à partir des sources

Sur les systèmes où il n'y a tout simplement pas de binaire pré-packagé disponible pour haveged, vous devrez le construire à partir de l'archive source. C'est en fait beaucoup plus facile que ce à quoi vous pouvez vous attendre. Tout d'abord, vous visiterez la page de téléchargement et choisirez la dernière version de l'archive (1.7a au moment de l'écriture de ce document). Après avoir téléchargé l'archive, décompressez la dans votre répertoire de travail actuel:

# tar zxvf /path/to/haveged-x.x.tar.gz

Maintenant vous compilez et installez:

# cd /path/to/haveged-x.x
# ./configure
# make
# make install

Par défaut, ceci s'installera avec un préfixe /usr/local, donc vous devrez ajouter quelque chose de similaire à ce qui suit à /etc/rc.local (ou l'équivalent sur votre système, si par exemple il utilise systemd) pour le lancer automatiquement au démarrage (vous ajusterez bien entendu le chemin si nécessaire):

# Autostart haveged
/usr/local/sbin/haveged -w 1024

Lancez cette commande manuellement (en tant que root) pour démarrer le démon sans avoir à rebooter la machine, ou rebootez si vous avez pris cette habitude avec Windows.

Test de la disponibilité de l'entropie, de son amplification et qualité des données aléatoires

Après un minimum de travail d'installation/configuration, vous devriez maintenant avoir une installation fonctionnelle de haveged, et il devrait déjà commencer à remplir la réserve d'entropie de votre système. La sécurité ne serait pas de la sécurité si vous faisiez aveuglément confiance aux autres et à leurs prétentions d'efficacité, alors pourquoi ne pas tester vos données aléatoires en utilisant un test standard ? Pour ce test, nous utiliserons la méthode FIPS-140 utilisée par rngtest, disponible vraisemblablement dans toutes les distributions Linux majeures sous divers noms de paquetages comme rng-tools :

# cat /dev/random | rngtest -c 1000

Vous devriez voir une sortie similaire à la suivante :

rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 999
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.139; avg=22.274; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=19.827; avg=110.859; max=115.597)Mibits/s
rngtest: Program run time: 1028784 microseconds

Une très petite quantité d'échecs est acceptable dans tout générateur de nombres aléatoires, mais vous pouvez vous attendre à voir souvent des valeurs autour de 998-1000 comme résultat affichés sur la ligne « successes ».

Pour tester la quantité d'entropie disponible, vous pouvez exécuter la commande suivante :

# cat /proc/sys/kernel/random/entropy_avail

L'idée d'haveged est de remplir ce pool à chaque fois que le nombre de bits disponibles s'approche de 1024. Ainsi, bien que ce nombre fluctue, il ne devrait pas descendre en dessous d'environ 1000, à moins que vous n'exigiez beaucoup de hasard (comme lors de la génération de clé SSH par exemple).

Écrire un commentaire

Quelle est la troisième lettre du mot zhso ?

Fil RSS des commentaires de cet article

À propos

Yakati.com - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.024s  Compression GZIP activée - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.com
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml