Un petit article pour relayer l’information sur le problème de sécurité de OpenSSL sous Debian. Si vous suivez l’actualité vous aurez remarqué les nombreuses news sur les sujets ces derniers jours. Etant donné qu’un schéma vaut mieux qu’un long discours et qu’un peu d’humour est toujours le bienvenue je vous laisse savourer ce post.

edit : un nouveau dessin bien sympatique sur le blog de loldebian.

Pour faire court il s’agit d’un problème avec le générateur de nombre aléatoire utilisé par OpenSSH et OpenSSL. Toutes les clés délivrées par ces outils depuis deux ans sont affectées. Ceci rend les outils qui les utilisent vulnérables aux attaques par bruteforce et ce en un temps très court (20 minutes à une heure !).

Malgré le nombre impressionnant de services impactés et de clés à régénérer, ne cédons pas à la panique. Il est temps de passer à l’action. Il y de nombreux articles qui traitent déjà des procédures à suivre et je ne vais donc pas reprendre l’intégralité des informations ici.

Voici donc ma sélection de liens sur le sujet qui vous permettra de vous en sortir :

• Le wiki de debian pour faire un point complet sur la situation
• Branle-bas SSH/SSL sur l’excellent blog de Roland Mas
• Un bon résumé sur Debian Administration

Bonne lecture et bonne chance à tous.

Introduction

Le serveur HTTP Apache2 de la fondation apache est un programme modulaire. De nouvelles fonctionnalités viennent s’ajouter au serveur en greffant un ensemble de modules. Ils peuvent être soit statiques, compilés avec les binaires du serveurs, soit dynamiques.

Dans leur forme dynamique les modules sont compilés en tant que “dynamic shared objects” aussi appelés DSO et sont distribués séparément.

La gestion des modules dans Debian

Activer un module particulier implique d’éditer le fichier de configuration d’apache pour ajouter une directive de type LoadModule propre à ce module. En fonction du module des options de configuration sont nécessaires, c’est le cas pour le module ssl par exemple.

Debian simplifie la gestion des modules en groupant les aspects propres à chaque module dans deux fichiers :

• nom_du_module.load : instructions de chargement du module pour apache
• nom_du_module.conf : la configuration du module

Les répertoires qui interviennent dans la gestion des modules sont les suivants :

• mods-available : Contient les fichiers de configuration pour chaque module. Les nouveaux modules installés sont placés dans ce répertoire.
• mods-enabled : Liste de liens symboliques qui pointent vers les fichiers de configuration situés dans “mods-available”. Seuls les modules dans ce répertoire sont activés par le serveur web.

Il est tout à fait possible de créer et supprimer les liens symboliques manuellement. Néanmoins les scripts suivants permettent d’automatiser cette tache et de grandement simplifier l’administration des modules :

• a2enmod : Crée le(s) lien(s) symbolique(s) à partir du répertoire “mods-available” pour activer un module et charger sa configuration.
• a2dismod : Supprime les liens symboliques du répertoire “mods-enabled” pour désactiver les modules.

Les virtuals hosts

La configuration des modules et des virtual hosts est gérée de manière très similaire.

On trouve donc les répertoires suivants dans le dossier de configuration /etc/apache2:

• sites-available : Contient les fichiers de configuration pour chaque virtual host. Par convention de nommage, un fichier de configuration correspond à un site.
• sites-enabled : Ensemble de liens symboliques qui pointent vers les fichiers de configuration situés dans “sites-available”. Les sites présents dans ce répertoire sont ceux qui sont pris en compte par le serveur web. Ce sont les sites qui sont activés. Ils sont chargés dans un ordre alphanumérique.

Les scripts pour activer et désactiver les virtual hosts sont les suivants :

• a2ensite : Crée le lien symbolique à partir du répertoire “sites-available” pour activer la configuration d’un virtual host.
• a2dissite : Supprime les liens symboliques créés dans le répertoires “sites-enabled”. Permet de facilement désactiver un virtual host.

Configuration des services

La configuration ‘externe’ du serveur en revanche est située dans un seul répertoire : “conf.d”

Les applications Web qui s’installent avec le système de packages Debian placent bien souvent un fichier de configuration dans ce répertoire.

PhpMyAdmin par exemple, crée un lien symbolique /etc/apache2/conf.d/phpmyadmin.conf qui pointe vers le fichier /etc/phpmyadmin/apache.conf

Ce fichier contient des directives de protection des répertoires ainsi que les alias de l’application.

My little hack

Je vous propose donc de modifier légèrement votre installation d’Apache2 pour améliorer la prise en compte de la configuration et la rendre plus “modulaire” :).

Voici les étapes à suivre :

1. Se logguer en tant qu’administrateur ou utiliser sudo.

2. Renommer le répertoire “conf.d” en “conf-available” :

mv /etc/apache2/conf.d /etc/apache2/conf-available

3. Créer le répertoire “conf-enabled” :

mkdir -p /etc/apache2/conf-enabled

4. Pour ne pas casser les dépendances des programmes web, créer un lien symbolique conf.d vers conf-available :

ln -s /etc/apache2/conf-available /etc/apache2/conf.d

5. Modifier la configuration d’Apache :

Dans le fichier de configuration apache2.conf, remplacer la ligne

Include /etc/apache2/conf.d/

par

Include /etc/apache2/conf-enabled/

6. Relancer apache :

/etc/init.d/apache2 restart

Automatisation :

Je me suis très fortement inspiré des scripts a2ensite et a2dissite pour créer les scripts “a2enconf” et “a2disconf”

Téléchargez ces deux fichiers et placez les dans le répertoire /usr/sbin de votre serveur.

Vous disposez maintenant de deux nouveaux scripts pour ajouter et supprimer très rapidement les options de configuration des applications web que vous souhaitez appliquer à votre serveur web.

Très bonne et heureuse année 2008 à tous !
Des nouveautés pour ce début d’année :

• Le blog de spiroid change de serveur.
• Le nom de domaine du blog change ! En effet le nom de domaine du blog passe de spiroid.net à spiroid.org. Pour le moment il y a une redirection activée qui vous amènera sur les nouvelles pages je l’espère.

A bientôt pour plein de nouveaux articles.

Il y a un grand nombre de tutoriels et beaucoup de documentation sur l’installation de SNMP pour la version 1 et 2 du protocole.
Cependant les informations sur la version 3 sont très rares et ne sont souvent pas adaptées à la distribution Debian. En terme de sécurité, il est pourtant vivement recommandé d’utiliser la dernière version du protocole SNMP et profiter du chiffrement et d’un meilleur contrôle d’accès. C’est pourquoi, je vous propose un rapide tutoriel pour bien démarrer.

Installation

aptitude install snmp snmpd libsnmp-dev

Il est nécessaire de stopper le démon snmpd pour procéder aux modifications
/etc/init.d/snmpd stop

Création des utilisateurs

On a besoin de deux utilisateurs avec des rôles et des droits d’accès différents :

• un administrateur que nous appellerons “admin”
  Il aura le droit de lire et de modifier l’intégralité de la MIB
• un utilisateur “system”
  Avec un droit en lecture uniquement sur des parties spécifiques de MIB sur lesquelles on récupère des informations pour les statistiques.

L’ajout des utilisateurs ce fait à l’aide de la commande net-snmp-config.

Syntaxe :
net-snmp-config –create-snmpv3-user [-ro] [-A authpass] [-X privpass]
[-a MD5|SHA] [-x DES|AES] [username]

Deux mots de passes sont requis pour l’authentification et le chiffrement. Ce qui donne pour nos utilisateurs :
net-snmp-config --create-snmpv3-user -a SHA -A authpass1 -x DES -X chiffrepass1 admin
net-snmp-config --create-snmpv3-user -a SHA -A authpass2 -x DES -X chiffrepass2 system

Remplacez bien entendu authpass1, authpass2, chiffrepass1 et chiffrepass2 par vos propres mots de passe.

On démarre le service snmpd
/etc/init.d/snmpd start

Verification

On doit voir apparaitre dans le fichier /var/lib/snmp/snmpd.conf deux lignes qui commencent par usmUser pour les utilisateur créés.
Par exemple :
usmUser 1 3 0x800rezd80d2b487119d794947 0x61dsfsf00 0x61646d696e00 NULL .1.3.6.1.6.3.10.1.1.3 0xe8c96515050a3dfgddgdb05546d0404cb8846 .1.3.6.1.6.3.10.1.2.2 0x72cc4831fa873f9d6935cvxvfe78a1bd5e 0x00
usmUser 1 3 0x80001f8fdgrz0d2b487119d79494fsfs74656d00 0x73797374656d00 NULL .1.3.6.1.6.3.10.1.1.3 0xb9cf1ccd93cda175e59e4c8gfdgd106bb8806395 .1.3.6.1.6.3.10.1.2.2 0x6dd31d526ab5718e6bcxvx7f07152069 ""

Configuration

Le fichier à modifier est /etc/snmp/snmpd.conf
On créé une copie de sauvegarde du fichier : cp -a /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.sav

Nouveau contenu du fichier de configuration :

# Restriction du service à l'adresse du serveur
agentaddress xx.xx.xx.xx

# Création des groupes pour chaque user pour le contrôle d'accès
group rwgroup usm admin
group rogroup usm system

# Création des vues sur la MIB pour restreindre les accès des groupes
# incl/excl subtree mask
view all included .1
view system included .iso.org.dod.internet.mgmt.mib-2.system

# Autorisation pour chaque groupe sur les différentes vues
# context sec.model sec.level match read write notif
access rwgroup "" usm priv exact all all none
access rogroup "" usm priv exact system none none

# Personalisation des informations du serveur
syslocation locatlisation_du_serveur (configure /etc/snmp/snmpd.conf)
syscontact hostmaster (configure /etc/snmp/snmpd.conf)

Vous pouvez télécharger un exemple du nouveau fichier de configuration Ici
Remplacez xx.xx.xx.xx par l’adresse IP du serveur.
Pour prendre en compte les nouvelles modifications on relance le démon snmpd
/etc/init.d/snmpd restart

Tests

On verifie que le service est bien chargé : ps fax | grep snmpd
Les commandes suivantes doivent donner l’uptime du système (depuis l’installation du service snmpd) :

snmpget -v 3 -u admin -l authPriv -a SHA -A authpass1 -x DES -X chiffrepass1 localhost sysUpTime.0
snmpget -v 3 -u system -l authPriv -a SHA -A authpass2 -x DES -X chiffrepass2 localhost sysUpTime.0

Ce qui doit afficher :
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (431580) 1:11:55.80

Pour aller plus loin

La MIB fournie contient des données sur un certain nombre de paramètres du système. A vous de la personnaliser pour ajouter de nouveaux scripts de surveillance spécifiques à votre domaine. Il est maintenant temps d’installer un logiciel de monitoring qui va utiliser les informations fournies par SNMP pour réaliser des graphes ou lancer des alertes en cas de problème. Un prochain tutoriel portera sur la configuration de Cacti.

Quelques liens utiles

• Tutoriel sur le site de Net-SNMP
  La référence, attention cependant aux versions des documents proposés !

• Utilisation et Chargement de la MIB
  Un document sur l’ajout d’informations dans la MIB

Ce matin, je me suis aperçu que le blog spiroid n’était plus en ligne. En cherchant la cause sur le serveur et en analysant les logs d’erreur d’apache j’ai trouvé la ligne suivante :

[crit] (28) No space left on device: mod_rewrite: could not create rewrite_log_lock Configuration Failed

Je me suis cependant assuré qu’il restait de la place sur le disque dur à l’aide de la commande ‘df‘. Après une rapide recherche sur internet, j’ai trouvé que je n’étais pas le seul avoir ce problème.

Rapport de bug

Le bug a été signalé sur le système de bugtracking de debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450831

Les informations importantes :
Version d’apache concernée: 2.2.6-1
Debian : Lenny
Package : apache2-mpm-prefork

Cause

L’origine du problème pourrait venir de l’utilisation des sémaphores par le module rewrite (url rewriting).
On peut supposer qu’il s’agit d’un problème d’allocation mémoire.

Solution

Pas de patchs ni de correctifs ont été proposés pour le moment.

Solution temporaire

Pour débloquer la situation et libérer les ressources, entrez la commande suivante :
ipcs -s | grep www-data | awk ' { print $2 } ' | xargs ipcrm sem

Le problème est bloquant et risque de survenir après la rotation des logs configurée en général pour se produire chaque jour ou chaque semaine en temps normal. On peut ajouter temporairement la commande ci dessus dans les scripts de configuration de logrotate pour l’executer après chaque redémarrage d’apache lors des rotations de log (Non testé !)

A suivre …

EDIT : Corrigé depuis la version 2.2.8
EDIT : La correction du bug est prévue officiellement pour la version 2.2.9-3