HeartBleed : Qu'est-ce que c'est ? Par adrien_s, le 09 Avril 2014 13:48:43

Tags : newssiteinformatiqueévénementinternetespionnagegroumpflogicielLibreserveurwebsécuritéactu


Vous avez peut-être entendu parler d'HeartBleed, peut-être pas.
Il s'agit d'une faille qui a été découverte dans l'implémentation d'OpenSSL qui permet notamment d'avoir accès à des portions de mémoire du serveur.

OpenSSL ?

Il s'agit d'une boîte à outils logicielle qui est notamment utilisée pour la gestion des certificats de sécurité et des connexion en SSL/TLS (https par exemple, mais aussi IMAPS / SMTPS pour les emails passants par SSL/TLS).

Pourquoi HeartBleed ? C'est quoi ?

Il se trouve que cette faille touche l'extension HeartBeat d'OpenSSL. Cette faille permet à une machine quelconque de lire et d'écrire des portions de mémoire (64 ko par heartbeat) sur le serveur, sans autorisation préalable et sans laisser aucune trace.

C'est donc une faille très importante qui a été découverte.

Que faut-il faire ?

Tout d'abord mettre à jour OpenSSL (à la version 1.0.1g) pour bénéficier du correctif.
Ensuite, il faut regénérer des certificats SSL par précaution (quelqu'un vous a déjà peut-être volé les vôtres, moi je me fais attaquer tous les jours par des chinois alors bon…) car cette faille permet de récupérer les clés privées des certificats SSL générés.

Concernant ArtSoftWare ?

Concernant mes serveurs, j'ai effectué la mise à jour et surtout regénéré mes certificats.

Il vous faudra donc réimporter le nouveau certificat racine — que je devais de toute façon mettre à jour sous peu — pour pouvoir à nouveau utiliser l'interface HTTPS.

Bonne mise à jour :)


Sources :
Heartbeat.com
LinuxFR
Wikipédia


Sécurisation de son accès SSH Par adrien_s, le 09 Avril 2014 14:07:20

Tags : informatiquesécuritélinuxsshtuto


Bonjour à tous !

Si vous avez une machine (que ce soit un serveur, une machine perso ou encore un Raspberry Pi) qui tourne sous GNU/Linux (ou n'importe quel autre UNIX-like), vous savez sans doute ce qu'est SSH et à quoi il sert : à pouvoir se connecter sur sa machine via le réseau, en créant un tunnel chiffré entre la console de l'utilisateur et la machine en question.

Oui mais voilà : comme partout, il y aura forcément des gens qui tenteront de se connecter de manière plus ou moins légale chez vous (plus moins que plus en fait, mais là je m'embrouille). L'une des principales techniques pour rentrer chez quelqu'un en SSH sans avoir le mot de passe est de tester toutes les valeurs possibles. On appelle cela le brute-force.

Une première solution simple est de changer le port de SSH — qui est le port 22 par défaut — et le nombre de tentatives d'intrusions devrait significativement baisser (il y a au bas mot 65536 ports possibles, ça m'étonnerait qu'ils les testent tous :) ) mais cela n'est pas suffisant et cela reste relativement contraignant (vu qu'il faudra spécifier le port à chaque fois que l'on veut se connecter).

Une autre solution plus robuste consiste donc en la création de paires de clés privées / publiques et la désactivation de l'authentification par mot de passe, ce qui permet de grandement limiter le brute-force (faire du brute-force sur 1024 octets, ça calme).

C'est quoi ce machin ?

Je ne vais pas vous faire un cours de crypto ici (ce n'est pas mon but, et en plus je ne suis pas non plus expert en la matière), mais en gros le but est d'avoir une clé pour chiffrer les données, et une autre pour les déchiffrer.

Comment c'est possible ? La clé pour chiffrer est différente de la clé pour déchiffrer ? C'est de la magie ?

Non. C'est des maths :)

Bon, plus sérieusement, l'idée est effectivement d'avoir deux clés différentes : la clé pour chiffrer est publique (on s'en fout si tout le monde la connaît, elle ne peut pas servir pour déchiffrer les échanges, juste en chiffrer), et l'autre est privée et est bien gardée au chaud.

Le rapport avec SSH

Il existe principalement 3 algorithmes de chiffrement pour ce faire :

  • RSA, le plus ancien et le plus connu,
  • DSA (pour Digital Signature Algorithm), une déclinaison plus récente et plus robuste (qui date du temps où le RSA était soumis à des brevets),
  • ECDSA (pour Elliptic Curve DSA, plus difficile à casser).
  • ED25519 (comme ECDSA, mais avec une courbe plus difficile à casser)

Je vous déconseille l'utilisation de l'algorithme RSA, puisqu'au vu des événements récents (PRISM, la NSA qui fouine son nez un peu partout) certains algos permettant de calculer une clé RSA (un des générateurs de nombre aléatoire notamment, une partie très importante) semblent avoir étés compromis avec l'ajout de porte dérobée.

Le meilleur pour le moment est l'algorithme de chiffrement ED25519 (avec le ECDSA), qui s'appuie sur un calcul de courbe elliptique. Il est de fait un peu plus long à calculer (l'authentification met donc un tout petit peu plus longtemps), mais est en retour bien plus difficile à casser pour un nombre relativement restreint d'octets. Le seul défaut du ED25519 étant qu'il est pour le moment encore peu répandu (en tout cas sur mon ArchLinux je peux en générer, donc cela devrait être bon)

Génération des clés

Tout d'abord, il faut… Générer les clés :D

Pour ce faire, on va utiliser la commande ssh-keygen fournie avec le paquetage ssh (normalement). La syntaxe est la suivante :

Algorithme RSA

$ ssh-keygen -t rsa -b <nombre de bits de la clé à générer> -f <fichier de sortie>

Le nombre de bits de la clé à générer doit impérativement être un multiple de 2 (1024, 2048, 4096 etc.).
Gardez néammoins à l'esprit que plus la clé est grosse, plus elle est longue à calculer mais plus elle est dure à casser. Le fichier de sortie est par défaut dans votre dossier home, dans .ssh/id_rsa (pour la clé privée) et .ssh/id_rsa.pub (pour la clé publique). Il n'est pas nécessaire de le préciser, sauf si vous souhaitez par exemple générer une paire de clés pour une autre machine.

Juste une chose par contre :

N'envoyez jamais de clé privée par e-mail !

Cela tuerait tout l'intérêt du chiffrement assymétrique. La clé privée est censée rester… eh bien privée, quoi.

Algorithme DSA

$ ssh-keygen -t dsa -b <nombre de bits de la clé à générer> -f <fichier de sortie>

Sous GNU/Linux (tout du moins chez moi), les clés DSA sont limitées à 1024 bits (ce qui est déjà pas mal en soi).
Sur la génération de clés de PuTTY (pour Windows), cela peut monter bien plus haut (j'ai déjà fait une clé de 8192 bits :) )

Algorithme ECDSA

$ ssh-keygen -t ecdsa -b <nombre de bits de la clé à générer> -f <fichier de sortie>

ou

$ ssh-keygen -t ed25519 -b <nombre de bits> -f <fichier de sortie>

Ici, les valeurs pour le nombre de bits sont limitées — 256, 384 et 521 bits respectivement — mais comme ECDSA est un algorithme très robuste, cela n'est pas très grave (de toute façon une clé ECDSA de 4096 bits serait un peu trop longue à calculer :p ).

Pour l'algorithme Ed25519, ssh-keygen accepte la création de clés de n'importe quelle taille (dans la limite du raisonnable), vous pouvez donc créer des clés de 8192 bits sans crainte.

Autorisation de connexion

Une fois que vous avez généré vos clés, vous vous dites certainement :

C'est bien, mais moi j'en fais quoi de mes clés maintenant ?

La clé privée (celle qui se termine sans le .pub), vous la gardez au chaud dans votre répertoire .ssh. Le contenu de la clé publique devra être ajouté à la fin du fichier home/.ssh/authorized_keys sur la machine sur laquelle vous souhaitez vous connecter (vous devez donc avoir déjà un accès, que ce soit par ssh avec mot de passe, ou même physiquement).

Le transfert peut s'effectuer via sftp, scp, ou même par clé usb mais pas par e-mail (sauf si vous chiffrez auparavant le fichier avec openssl, j'y reviendrais sans doute dans un autre tutoriel) et encore moins en posant le fichier dans un espace de stockage en ligne (du style Google Drive, DropBox, SkyDrive…) .

Les droits d'accès de votre répertoire home, et du répertoire .ssh doivent être sur 0700 sur la machine cible et la machine sur laquelle vous avec la clé privée (seul vous et vous uniquement peut lire et écrire dans ces répertoires), sinon ssh vous refusera toute connexion (et à raison, car on pourrait vous voler votre clé privée).

Les droits d'accès sur vos clés privées doivent être positionnés sur 0600 et les clés publiques 0644.

Sur la machine cible, le fichier home/.ssh/authorized_keys ne doit être visible et modifiable que par vous (droits d'accès 0600 encore) pour des raisons évidentes de sécurité.

Pour régler les droits d'accès, cela se fait de la façon suivante :

$ chmod <valeur> <fichier ou dossier ciblé>

Vous pouvez aller voir le manuel de cette commande si vous souhaitez plus de détails sur sa façon de fonctionner.

Essais

Vous pouvez désormais tenter une connexion.

Il se présente alors deux cas de figure :

  1. SSH vous demande un mot de passe
    Cela signifie que SSH n'a pas pu lire la clé privée ou le fichier authorized_keys sur la machine cible, ou encore que la configuration du démon est mauvaise (allez voir dans les logs du système cible et/ou local, ssh vous en aura certainement expliqué la raison).
  2. SSH vous connecte à la machine cible sans même vous demander un mot de passe
    Yay ! L'authentification par clé assymétrique étant prioritaire sur l'authentification par mot de passe, si SSH trouve une clé valide, que les droits d'accès sont bien réglés et que cette clé est bien autorisée sur la machine cible pour l'utilisateur demandé alors la connexion s'effectue directement.

Vous pouvez vous arrêter là si cela vous convient, ou poursuivre si vous souhaitez désactiver la connexion par mot de passe pour une meilleure sécurité — cela n'est cependant possible que si vous avez un accès root bien entendu.

Désactivation de l'authentification par mot de passe

Modification de la configuration

Il vous faut maintenant vous diriger vers le fichier /etc/ssh/sshd_config, créer les options qui manquent et modifier celles qui n'ont pas la valeur de ce qui est spécifié ci-dessous :

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no

Redémarrage du démon SSH

Ces modification effectuées, vous pouvez redémarrer le démon ssh. Sur un système possédant Systemd, il vous faudra taper systemctl restart sshd.service. Sur un système basé sur les scripts init bsd, la commande sera de la forme /etc/rc.dX/sshd restart

Tests

Sur votre machine locale, renommez le répertoire .ssh en .ssh_backup par exemple (ne le supprimez surtout pas !).

Retentez une connexion.

Vous devriez voir quelque chose de la sorte :

The authenticity of host '<nom machine> (<ip>)' can't be established.
ECDSA key fingerprint is <valeur pas importante en hexa super longue>.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '<nom machine>,<ip>' (ECDSA) to the list of known hosts.
Permission denied (publickey).

La dernière ligne est très importante.

Elle signifie que SSH vous a refusé l'accès car vous n'avez pas de clé privée marquée comme valide dans le fichier .ssh/authorized_keys sur la machine cible et qu'il n'a pas pu exécuter l'authentification par mot de passe. Si au contraire il vous demande le mot de passe, c'est que :

  • vous avez oublié de redémarrer le démon ssh
  • les modifications du fichier de config n'ont pas été prises en compte (mauvais fichier, pas enregistré… )
  • vous êtes victime de sorcellerie.

Après avoir fini, n'oubliez pas de supprimer le répertoire .ssh qui vient d'être créé et de replacer celui que vous aviez renommé en .ssh_backup pour clôturer les tests.

Voilà, c'est tout pour aujourd'hui :)

Si vous souhaitez plus d'information, vous pouvez me contacter à l'adresse e-mail support@art-software.fr (ne pas envoyer de mail entre 01h30 et 07h30, le serveur de mails est en veille et de toute façon la nuit je dors :p ).

[edit 9/04/2014] ajout de l'algorithme ed25519 plus robuste que ecdsa