Informations officielles

Un bogue très important a été découvert sur la version Debian de OpenSSL, disponible dans Debian Etch. Voici les textes qui concernent ce problème et ses implications :

• Annonce du bogue OpenSSL : http://www.debian.org/security/2008/dsa-1571

• Implications par type de clé et par logiciel : http://www.debian.org/security/key-rollover/.

• Particularités concernant OpenSSH : http://www.debian.org/security/2008/dsa-1576

• Page wiki Debian sur le sujet : http://wiki.debian.org/SSLkeys

Ci-dessous nous insistons sur les points importants concernant les serveurs AUF.

URGENCE 1 : Mettre à jour tous les serveurs

Vous devez immédiatement mettre à jour vos serveurs afin d'utiliser la version 0.9.8c-4etch3 (ou suivante) de OpenSSL et 1:4.3p2-9etch1 (ou suivante) de openssh-server :

• # aptitude update
  # aptitude dist-upgrade     <--- NB : openssh-server installe des dépendances en plus, il faut faire un dist-upgrade
  # apt-cache policy openssl
  openssl:
    Installé : 0.9.8c-4etch3
  # apt-cache policy openssh-server
  openssh-server:
    Installé : 1:4.3p2-9etch1

La nouvelle version de OpenSSH refuse toute connexion depuis une clé corrompue.

Il faut ensuite refaire toutes les clés qui ont été générées sur Etch (ou Ubuntu après 2006).

Les procédures, groupées par type de clé et par logiciel, sont indiquées ici sur la page http://www.debian.org/security/key-rollover/.

URGENCE 2 : Bloquer les accès à SSH trop permissifs

Note : cela devrait déjà être le cas...

Vous devez restreindre l'accès aux port ssh de vos serveurs. Seules les machines que vous contrôlez totalement doivent avoir un accès. Vous devez donc exclure «Internet» en général mais aussi les machines publiques des CNF.

Refaire les certificats pour les services SSL/TLS

Il faut refaire tous les certificats x509 pour tous les services qui utilisent SSL. A l'AUF c'est en général :

• https : certificats pour apache2 (ou apache)

• imaps et pops : certificats pour dovecot (ou courier-imap)

• smtps : certificat pour postfix

• certificats pour openvpn

La technique pour générer des certificats x509 corrects est indiquée sur la page OpenSSL de ce wiki.

Refaire la paire de clés pour Asterisk

Ceci n'est nécessaire que pour les clés générées sur Etch, après 2006. Pour vérifier si votre clé privée asterisk est compromise, copiez-la sur une station Ubuntu, installez-y le paquet openssl-blacklist et lancez la commande :

• $ openssl-vulnkey auf-ville.key 
  Not blacklisted: 15f478e3.....554613df33 auf-ville.key

Si Not blacklisted apparait, il n'est pas nécessaire de refaire la clé pour Asterisk.

Sinon, il faut :

1. refaire le couple de clé : clé privée et clé publique :

   $ cd ~/asterisk-future-clef/     <--- un répertoire temporaire où placer la future clé
   $ /usr/sbin/astgenkey -q -n auf-implantation

2. indiquer votre nouvelle clé publique sur Asterisk/Clefs afin qu'elle soit ajoutée au paquet asterisk-auf-config-connexion

3. lorsque la clé aura été ajoutée et que l'annonce du nouveau paquet aura été diffusée, activez cette nouvelle clé :

   # cd ~user/asterisk-future-clef/ 
   # cp auf-implantation.pub auf-implantation.key /usr/share/asterisk/keys
   # chown -R root.asterisk /usr/share/asterisk/keys/*
   # chmod 644 /usr/share/asterisk/keys/*.pub
   # chmod 640 /usr/share/asterisk/keys/*.key
   # /etc/init.d/asterisk restart   <--- attention cela va couper toutes les communications en cours !!! (un reload ne suffit pas)

NB : Pour éviter un maximum de désagrément, vous constatez que cette procédure conserve l'ancienne clef tant que la nouvelle n'a pas été ajoutée dans le paquet. En effet, si vous utilisez immédiatement une nouvelle clé, vous ne pourrez plus appeler les autres implantations tant qu'elles n'auront pas mis à jour le paquet. Attendez le dernier moment afin de ne pas trop géner vos utilisateurs...

Soyez très réactif lors de l'annonce d'une nouvelle version de asterisk-auf-config-connexion (sur la «liste tech»). Il faudra mettre à jour immédiatement votre serveur Asterisk afin de ne pas bloquer les appels depuis l'implantation qui aura changé sa clé.

SSH (OpenSSL est utilisé pour générer les clés SSH)

La procédure officielle est présentée ici : http://www.debian.org/security/2008/dsa-1576. Ci-dessous quelques indications plus concrètes correspondant à notre utilisation classique de ssh à l'AUF.

Sur tous les serveurs ssh

Il faut, pour les serveurs ssh de tous les systèmes :

• bloquer tout accès ssh (port 22/tcp) depuis l'extérieur (au niveau des pare-feux) ;

• refaire les clés (si cela n'a pas été fait lors de la mise à jour de OpenSSH) :

  • # ssh-keygen -t rsa -N "" -f /etc/ssh/ssh_host_rsa_key
    # ssh-keygen -t dsa -N "" -f /etc/ssh/ssh_host_dsa_key
    # /etc/init.d/ssh restart

Après la mise à jour de ces clés, vous obtiendrez une erreur lorsque vous voudrez vous connecter au serveur. Il faudra, comme vous le dira le message d'erreur, nettoyer votre fichier .ssh/known_hosts.

Sur votre poste : refaire vos clés ssh personnelles

Attention : changer votre clé va vous couper l'accès aux serveurs pour lesquels vous utilisez l'authentification par clé ! Assurez-vous de conserver l'accès à vos serveurs afin de pouvoir y remettre votre clé publique dans le authorized_keys (par exemple activez l'accès par mot de passe le temps de faire les modifications).

Pour refaire une clé SSH de type DSA 1024 bits :

• $ ssh-keygen -t dsa

Note : sur Ubuntu Hardy, l'outils ssh-vulnkey vous dira si votre clé est dans la blacklist. Si ce n'est pas le cas, a priori vous pouvez ne pas la changer... mais moi, je l'ai changée quand même !

Note 2 : si d'autres personnes que vous utilisent SSH, il faut également leur faire re-générer leurs clés. L'option -a de ssh-vulnkey peut vous aider à détecter les clés corruptibles.

Sur toutes les machines : nettoyer tous les fichiers authorized_keys

Attention : la suppression des fichiers authorized_keys vous empêchera d'accéder au serveur en utilisant l'authentification par clé. Assurez-vous de conserver l'accès à vos serveurs afin de pouvoir y remettre votre clé publique dans le authorized_keys (par exemple activez l'accès par mot de passe le temps de faire les modifications).

Sauf si vous êtes totalement sûr de vous (et j'espère que personne ne l'est !), vous devez supprimer tous les fichiers authorized_keys de vos serveurs. En effet les clés publiques qui y sont autorisées peuvent correspondre à des clés privées corruptibles, c'est-à-dire générées avec l'ancienne version boguée de OpenSSL.

Illustration...