18 mai 2017

Haveged : ajouter de l'entropie à son VPS Linux

EntropyEntre deux bidouilles NetBSD, je me suis retrouvé à des bidouilles Linux. Plus particulièrement en jetant un œil à une certaine documentation utile, j'ai pu lire :

Les clés doivent être générées dans un contexte où la source d’aléa est fiable, ou à défaut dans un environnement où suffisamment d’entropie a été accumulée.

Et là, on commence à se poser des questions : qu'est-ce que l'entropie ? Pourquoi faut-il une source fiable ? Comment avoir une meilleure entropie ?

Entropie et aléa

Pour résumer, disons que l'entropie c'est la qualité de la génération de nombres aléatoires. C'est un raccourci assez grossier j'en conviens, mais cela évitera d'écrire ou de paraphraser des pavés mathématiques.

Mais alors, pourquoi générer des nombres aléatoires ? Tout simplement parce que cela fait partie de nombreuses bases d'outils cryptographiques, comme par exemple la génération de clés SSH. C'est d'ailleurs l'occasion d'aborder la question du risque qu'on prend si on ne génère pas assez d'aléa dans notre exemple : il devient possible de générer deux fois le même couple de clés SSH, et par conséquent, que quelqu'un soit en mesure de se connecter à une machine à laquelle il ne devrait pas avoir accès.

Si vous pensez que cela n'arrive jamais, il suffit de se rappeler la vulnérabilité OpenSSH Debian. En 2008, la version Debian d'OpenSSL s'est trouvée modifiée, et a eu pour conséquence un très faible nombre de possibilités pour générer des clés SSH. La preuve ? On peut trouver sur cette page l'intégralité des clés DSA (1024 et 2048 bits) et RSA (1024 à 4096 bits) possibles via cette version vulnérable. J'admets volontiers que c'est un cas extrême, mais il a le mérite d'être assez parlant.

Bref, tout ça pour dire que plus on a d'entropie, mieux c'est.

Mesurer la qualité de l'entropie

Pour mesurer la qualité de l'entropie, c'est très simple :

$ cat /proc/sys/kernel/random/entropy_avail
175

On voit que cela renvoie un nombre, qui désigne la quantité de nombres aléatoires générés. On dit que ce nombre est la taille de notre réservoir d'entropie. Et donc, plus il est grand, mieux c'est. Sauf que là, 175 sur une VM Vagrant CentOS 7, bein c'est pas glorieux.

Une autre manière de mesurer l'entropie consiste à utiliser l'outil rngtest (disponible dans le paquet rng-tools pour CentOS). Celui-ci va lancer un certain nombre de tests utilisant le standard FIPS-140.

Par exemple :

$ cat /dev/random | rngtest -c 1000
rngtest 5
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: 96
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 0
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: 0
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=0.000; avg=0.000; max=0.000)bits/s
rngtest: FIPS tests speed: (min=0.000; avg=0.000; max=0.000)bits/s
rngtest: Program run time: 21307295 microseconds

Et là, ce n'est toujours pas glorieux, car j'ai arrêté l'exécution faute de patience.

Avant de remédier à ce problème, comparons avec une machine physique notre premier indicateur :

$ cat /proc/sys/kernel/random/entropy_avail
3217

On peut aussi constater que le problème d'entropie affecte particulièrement les machines virtuelles. Cela s'explique surtout par le fait qu'elles disposent de beaucoup moins d'éléments qu'une machine physique, et donc moins d'éléments à lire pour espérer y trouver de l'aléa.

Bon, ce n'est pas tout, mais il est temps de remédier à ce problème d'entropie sur cette VM !

Haveged : générateur d'entropie en espace utilisateur

Haveged est un logiciel qui se présente sous la forme d'un démon qui reste en espace utilisateur. Il tire son nom de l'algorithme qu'il utilise, HAVEGE (HArdware Volatile Entropy Gathering and Expansion).

Côté installation, rien de plus simple, il suffit, pour CentOS, d'avoir accès au dépôt Fedora EPEL. Une fois que c'est fait, un simple yum -y install haveged suffit à disposer du logiciel.

Comme il s'agit d'un démon, il faut le démarrer. Sous CentOS 7, cela se fait via systemd :

# systemctl start haveged.service

Et voilà ! Bon d'accord, cela fait peu. Maintenant, vérifions que notre entropie augmente :

$ cat /proc/sys/kernel/random/entropy_avail
 1779

Voilà qui est mieux. Vérifions aussi avec rngtest :

$ cat /dev/random | rngtest -c 1000
rngtest 5
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: 1000
rngtest: FIPS 140-2 failures: 0
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: 0
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=2.057; avg=17.351; max=25.915)Mibits/s
rngtest: FIPS tests speed: (min=44.564; avg=139.836; max=161.640)Mibits/s
rngtest: Program run time: 1237535 microseconds

Dans ce dernier cas, la récupération des informations fut quasi-instantanée ! On peu d'ailleurs noter le nombre de tests réalisés avec succès, qui correspond mieux à nos attentes.

Pour ce qui est d'activer haveged au démarrage, il ne faut pas oublier la commande systemctl qui va bien :

# systemctl enable haveged.service
 Created symlink from /etc/systemd/system/multi-user.target.wants/haveged.service to /usr/lib/systemd/system/haveged.service.

Selon les distributions, certains paramètres supplémentaires sont accessibles, mais cela fera l'objet d'un autre article ;)

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : teatimer - Entropy

18 déc. 2014

On vit dans un monde formidable

J'ai déjà fait quelques billets sur OpenSSH, c'est toujours un plaisir d'apprendre de nouveaux trucs avec ce logiciel ! Parmi les trucs super chouette, il y a les possibilités d'utilisation transparente. Si vous avez la flemme de lire le lien, en gros quand je voulais passer au travers d'un serveur OpenSSH de manière transparente, j'utilisais ce genre de configuration :

Host serveurdmz1
        Hostname lenomouladresseipduserveurdepuislapasserelle
        Port 22
        Protocol 2
        User nils
        ProxyCommand ssh nils@passerelle "nc %h %p"

Depuis OpenSSH 5.4 (ouais, ça date, hein), il n'y a plus besoin de faire appel à Netcat ("nc" dans la directive "ProxyCommand"). Il suffit d'utiliser la commande "ssh -W". Cela donne donc :

Host serveurdmz1
        Hostname lenomouladresseipduserveurdepuislapasserelle
        Port 22
        Protocol 2
        User nils
        ProxyCommand ssh -W %h:%p passerelle

Y a pas à dire, on vit dans un monde formidable, où des développeurs prennent en compte les utilisations de leur logiciel.

26 août 2013

freeshell : votre accès terminal UNIX sur internet

Je me suis dit que ça serait sympa de vous faire découvrir l'association SDF (pour Super Dimension Fortress) et son projet freeshell : un accès en mode terminal sur une machine UNIX (NetBSD pour être exact). Cet accès, dans certaines conditions, est gratuit. C'est assez chouette, ça existe depuis très longtemps et permet d'apprendre les rudiments d'UNIX sans forcément installer en physique ou en virtuel ce type d'environnement. L'association fait cela à but éducatif et culturel, et est reconnue "non-profit" (oui, c'est une association américaine).

Pour accéder à freeshell, et créer un compte, il suffit de se munir d'un client SSH et de se connecter de la façon suivante :

ssh new@sdf.org

il existe d'autres moyens, qui reposent généralement sur SSH ou telnet, sur la page d'inscription au service.

J'ai indiqué plus haut que sous certaines conditions, ce service est gratuit : il y a en fait différent niveaux de services, selon ce que vous êtes prêts à payer. Une fois le compte et l'accès créé, vous disposez de certains outils, comme :

  • mutt, pop3, imap, icq, twitter, bsflite (aim), irc (sur le réseau SDF) ;
  • games, mud, lynx, gopher, TOPS-20 ;
  • hébergement HTTP statique de type http://yourlogin.sdf.org (d'autres domaines sont possibles) ;
  • traceroute, ping, whois, dig et d'autres.

mais tout ça est dans un shell limité. Si vous consentez à payer une petite somme (historiquement 1 Dollar US), un accès shell "classique" (comprendre : bash, ksh, tcsh, rc ou zsh) vous est alors ouvert, avec bien plus de possibilités, comme le webmail, FTP, SFTP (en entrée, pas en sortie), ou un accès à plus d'outils. Pourquoi le shell limité et pourquoi la somme ? Pour éviter le spam d'une part, et d'autre part car le traitement peut se faire par courrier papier, il suffit d'envoyer un billet de 1 Dollar (ou de 5 Euros) à l'adresse indiquée dans la page d'explication.

Encore plus d'outils et de possibilités sont offertes à qui est prêt à mettre un peu plus la main au portefeuille, et certains services sont facturés au mois, comme par exemple un accès VPN. Le tout est hébergé aux USA, et il existe aussi une version européenne, hébergée en Allemagne : SDFEU. Rien que pour l'accès shell, traceroute, dig, whois et autres lynx, c'est assez pratique je trouve, d'avoir un point "de sortie" ailleurs que dans son pays d'origine. Cela permet par exemple de tester des filtrages (géolocalisation ?). C'est aussi, à mon sens, un moyen de disposer d'un hébergement web (statique) peu coûteux et à taille plus humaine, et à finalité moins commerciale.

14 mar. 2011

Configuration d'OpenSSH

OpenSSH est un logiciel formidable, tout le monde le sait. Quelque chose que j'aime beaucoup avec ce logiciel, c'est la manière dont son fichier de configuration permet de simplifier certaines opérations. Je vous propose de voir ou de revoir certaines options qu'on peut ajouter à la suite d'un bloc de configuration qu'on stocke généralement dans ~/.ssh/config .

La base

On va configurer l'accès à la machine "testdrive" dont l'adresse IP est 192.168.13.37. Commençons avec les informations de base :

Host testdrive
        HostName 192.168.13.37
        User nils
        Protocol 2
        Port 22
        ServerAliveInterval 5

Lorsque que je taperai la commande "ssh testdrive", OpenSSH me connectera à la machine 192.168.13.37 en tant qu'utilisateur nils, en utilisant la version 2 du protocole SSH, sur le port 22 et vérifiera toutes les 5 secondes si la machine en question est toujours joignable, ce qui peut s'avérer pratique dans certains cas où on peut être déconnecté du réseau pour cause d'inactivité (réseau de téléphonie mobile, proxy...)

Connexion au travers d'un proxy HTTP

ProxyCommand /usr/bin/corkscrew monproxy.lan 3128 %h %p ~/.ssh/proxy_auth

Ici, j'utilise un utilitaire nommé Corkscrew qui me permet de me connecter via un proxy HTTP à mon serveur. Dans mon exemple, le proxy écooute sur le port 3128 et nécessite une authentification, j'ai donc ajouté un fichier proxy_auth contenant les identifiants. Les variables %h et %p désignent l'hôte vers qui se connecter et son port. A noter que la plupart des serveurs proxy qu'on peut trouver sont configurés pour ne pas autoriser les ports autres que les ports HTTP, HTTPS, et éventuellement FTP. Il faudra donc peut-être changer le port d'écoute de notre testdrive, et mettre notre serveur SSH sur le port 80 ou 443. A noter que selon l'organisation qui administre le proxy, cette manière de faire peut être vue comme une violation de la charte informatique du réseau, ou de tout autre règlement intérieur. Ne l'utilisez donc que si vous y êtes autorisés !

Créer un tunnel SOCKS

DynamicForward 1080

Cette option est très pratique si vous ne voulez pas vous casser la tête à créer un tunnel VPN. Une fois cette option ajoutée à la configuration de votre hôte, et la connexion à celui-ci effective, un tunnel SOCKS écoute sur la boucle locale de votre machine, sur le port 1080. Un cas concret d'utilisation est la connexion à vos sites préférés depuis un point d'accès sans fil public, comme une gare : une fois connecté au réseau, on se connecte en SSH à son serveur, puis on modifie les paramètres de proxy de notre navigateur web pour utiliser un proxy SOCKS dont l'adresse est 127.0.0.1 et le port est 1080. Tout le trafic web du navigateur passe ainsi dans la connexion SSH. Si vous faites souvent le va-et-viens dans votre configuration de proxy, Firefox possède une extension nommée FoxyProxy qui vous facilitera l'existence !

Créer un tunnel pour rediriger du trafic

LocalForward 5901 192.168.13.38:5900

Encapsuler un trafic réseau dans SSH est quelque chose de connu, et l'exemple ci-dessus est lui aussi archi-connu : le protocole VNC transite en clair sur le réseau, l'utilisation de SSH permet de chiffrer la transmission entre notre client et notre serveur. On transfère donc le port 5900 de la machine 192.168.13.38 (qui doit être joignable depuis notre machine testdrive) vers le port 5901 local. On lance ensuite notre client VNC en direction la machine localhost sur le port 5901.

Spécifier l'algorithme de chiffrement

Ciphers aes128-cbc

De nombreux algorithmes de chiffrement sont disponibles avec OpenSSH, vous pourrez trouver la liste dans les pages de manuel. Certains processeurs (tels que l'AMD Geode LX ou le VIA C7) savent déchiffrer certains algorithmes, ce qui les rend plus rapide pour ces types d'opérations. Forcer le chiffrement en AES 128 si vous vous connectez à une machine ayant un CPU AMD Geode peut ainsi s'avérer très efficace pour limiter l'utilisation du CPU et alléger la charge.

22 déc. 2009

Utilisation transparente d'une passerelle SSH

Ou comment rebondir sans même le faire exprès !

Lire la suite...

Propulsé par Dotclear