Chapitre 10. Avant la compromission

10.1. Maintenez le système sécurisé

Vous devriez faire tous les efforts nécessaires pour maintenir votre système sécurisé en surveillant son utilisation ainsi que les vulnérabilités qui pourraient l'affecter, en ajoutant les correctifs dès qu'ils sont disponibles. Même si vous avez installé un système vraiment sécurisé, vous devez garder à l'esprit que la sécurité d'un système se dégrade avec le temps. Des failles de sécurité peuvent être découvertes pour les services offerts et les utilisateurs peuvent affaiblir la sécurité du système soit à cause d'une incompréhension (par exemple, en accédant au système à distance à l'aide d'un protocole non chiffré, ou en utilisant des mots de passe faciles à deviner), ou parce qu'ils essaient activement de corrompre la sécurité du système (c'est-à-dire installer des services supplémentaires dans leur compte local).

10.1.1. Surveillance des failles de sécurité

Bien que la plupart des administrateurs ne soient conscients des failles de sécurité affectant leur système que lorsqu'un correctif est rendu disponible, vous pouvez être proactif et tenter de prévenir les attaques en introduisant des contre-mesures temporaires contre ces vulnérabilités dès que vous détectez qu'elles peuvent affecter le système. C'est particulièrement vrai sur un système exposé (c'est-à-dire connecté à Internet) et qui fournit un service. Dans ce cas, les administrateurs système devraient surveiller attentivement les sources d'informations connues pour être les premiers informés lorsqu'une faille pouvant affecter un service critique est détectée.

Cela signifie habituellement au moins s'abonner à la liste de diffusion des annonces, au site web du projet ou au système de suivi des bogues fourni par les développeurs pour les applications à surveiller. Par exemple, les utilisateurs d'Apache devraient surveiller régulièrement la http://httpd.apache.org/security_report.html et s'inscrire à la liste de diffusion des http://httpd.apache.org/lists.html#http-announce.

Pour suivre les failles de sécurité connues affectant Debian, l'équipe de sécurité de Debian de la version testing maintient un http://security-tracker.debian.net/ qui contient toutes les vulnérabilités connues avant même d'être corrigées dans les paquets Debian. L'information est obtenue depuis plusieurs sources publiques et contient les failles connues disponibles à l'aide des bases de données de vulnérabilité ou du http://www.debian.org/Bugs/. Les administrateurs peuvent chercher les problèmes de sécurité connus suivis pour http://security-tracker.debian.net/tracker/status/release/stable, http://security-tracker.debian.net/tracker/status/release/oldstable, http://security-tracker.debian.net/tracker/status/release/testing ou http://security-tracker.debian.net/tracker/status/release/unstable.

Le système de suivi fournit des interfaces avec moteur de recherche (par nom http://cve.mitre.org et nom de paquet) et d'autres outils (comme debsecan, consultez Section 10.1.2.4, « Vérification automatique des problèmes de sécurité avec debsecan ») utilisent ces bases de données pour fournir des informations sur les vulnérabilités qui n'ont pas encore été résolues pour un système donné.

Les administrateurs consciencieux peuvent utiliser ces renseignements pour déterminer les failles de sécurité pouvant affecter le système qu'ils gèrent, déterminer la sévérité du bogue et appliquer (si possible) des contre-mesures temporaires avant qu'un correctif soit disponible pour résoudre le problème.

Les problèmes de sécurité des versions suivies par l'équipe de sécurité de Debian devraient être traitées par une annonce de sécurité Debian (DSA) et seront disponibles pour tous les utilisateurs (consultez Section 10.1.2, « Mettre à jour le système en permanence »). Une fois que les problèmes de sécurité sont résolus et annoncés, ils ne seront plus affichés par le système de suivi, mais vous pourrez encore chercher les vulnérabilités par leur nom CVE en utilisant la http://www.debian.org/security/crossreferences disponible pour les DSA publiées.

Remarquez cependant que les renseignements suivis par l'équipe de suivi en sécurité de testing ne concernent que les failles connues (c'est-à-dire déjà rendues publiques). Parfois, l'équipe de sécurité Debian peut gérer et préparer des DSA pour des paquets en fonction de renseignements non publics qu'ils ont obtenus sur des listes de diffusions restreintes, par le découvreur de la faille ou par les développeurs du logiciel. Ainsi, ne vous étonnez pas de découvrir des problèmes de sécurité dans une annonce qui ne sont jamais apparus dans le système de suivi des vulnérabilités.

10.1.2. Mettre à jour le système en permanence

Vous devriez effectuer des mises à jour de sécurité régulièrement. La plupart des stratagèmes sont basés sur des failles connues qui n'ont pas été corrigées à temps, comme l'explique ce http://www.cs.umd.edu/~waa/vulnerability.html (présenté lors du Symposium 2001 IEEE sur la sécurité et la confidentialité). Les mises à jour sont décrites dans Section 4.2, « Faire une mise à jour de sécurité ».

10.1.2.1. Vérification par soi-même la disponibilité de mises à jour de sécurité

Debian dispose d'un outil spécifique pour déterminer si un système a besoin d'être mis à jour, mais beaucoup d'utilisateurs veulent simplement vérifier si des mises à jour de sécurité sont disponibles pour leur système.

Si vous avez configuré le système comme décrit en Section 4.2, « Faire une mise à jour de sécurité », il suffit de faire :

# apt-get update
# apt-get upgrade -s
[ … passer en revue les paquets à mettre à jour… ]
# apt-get upgrade 
# checkrestart
[ … redémarrer les services qui doivent être redémarrés… ]

Redémarrez ensuite les services dont les bibliothèques ont été mises à jour si c'est le cas. Remarque : consultez Section 4.2, « Faire une mise à jour de sécurité » pour de plus amples renseignements sur les mises à jour de bibliothèques (et de noyau).

La première ligne téléchargera la liste des paquets disponibles depuis les sources de paquets configurées. L'option -s effectuera une simulation d'exécution, c'est-à-dire qu'elle ne va pas télécharger ou installer de paquets, mais qu'elle va plutôt signaler les paquets à télécharger ou installer. À partir de ce résultat, vous pouvez en déduire les paquets corrigés dans Debian et disponibles en mise à jour de sécurité. Par exemple :

# apt-get upgrade -s
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Calcul de la mise à jour... Fait
Les paquets suivants seront mis à jour :
  cvs libcupsys2
2 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)

Dans cet exemple, vous pouvez constater que le système a besoin d'être mis à jour avec les nouveaux paquets cvs et cupsys qui sont récupérés depuis l'archive de mises à jour de sécurité de Woody. Si vous voulez comprendre pourquoi ces paquets sont nécessaires, vous devriez aller en http://security.debian.org et vérifier les alertes de sécurité Debian (DSA) récemment publiées concernant ces paquets. Dans ce cas, les DSA concernées sont http://www.debian.org/security/2003/dsa-233 (pour cvs) et http://www.debian.org/security/2003/dsa-232 (pour cupsys).

Remarquez que le système doit être redémarré après une mise à jour du noyau.

10.1.2.2. Vérification de mises à jour sur station de travail

Depuis Debian 4.0 Lenny, Debian fournit et installe par défaut update-notifier. C'est une application GNOME qui est lancée lors de l'ouverture de la session et qui peut être utilisée pour faire le suivi des mises à jour disponibles pour le système et les installer. C'est fait en utilisant le paquet update-manager.

Pour un système stable, les mises à jour sont seulement disponibles quand un correctif de sécurité est disponible ou pour les versions intermédiaires. Par conséquent, si le système est configuré correctement pour recevoir les mises à jour de sécurité comme décrit en Section 4.2, « Faire une mise à jour de sécurité » et qu'une tâche cron met à jour les informations sur les paquets, vous serez averti par une icône dans l'espace de notification du bureau.

La notification n'est pas intrusive et les utilisateurs ne sont pas forcés d'installer les mises à jour. Depuis l'icône de notification, un utilisateur du bureau (avec le mot de passe administrateur) peut accéder à une interface simple et voir les mises à jour disponibles puis de les installer.

Cette application fonctionne en consultant la base de données des paquets et en la comparant avec le système. Si cette base de données est mise à jour régulièrement par une tâche cron, alors son contenu sera plus récent que les paquets installés sur le système et l'application pourra vous avertir.

Apt installe une telle tâche cron (/etc/cron.d/apt) qui s'exécutera selon la configuration d'APT (plus spécifiquement APT::Periodic). Dans l'environnement GNOME, la valeur de la configuration peut être ajustée dans le menu Système > Administration > Sources de mise à jour > Mises à jour, ou en exécutant /usr/bin/software-properties.

Si le système télécharge quotidiennement la liste des paquets, mais ne télécharge pas les paquets eux-mêmes, le fichier /etc/apt/apt.conf.d/10periodic devrait ressembler à ceci :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";

Vous pouvez utiliser une tâche cron différente, comme celle installée par cron-apt (consultez Section 10.1.2.3, « Vérification automatique des mises à jour avec cron-apt »). Vous pouvez aussi simplement vérifier vous-même les mises à jour en utilisant cette application.

Les utilisateurs de l'environnement KDE préféreront probablement installer adept et adept-notifier. Ils fournissent des fonctionnalités similaires, mais ne sont pas installés par défaut.

10.1.2.3. Vérification automatique des mises à jour avec cron-apt

Une autre méthode pour des mises à jour de sécurité automatiques est l'utilisation de cron-apt. Ce paquet fournit un outil pour mettre à jour le système à intervalles réguliers (en utilisant une tâche cron). Par défaut, il va simplement mettre à jour la liste des paquets et télécharger les nouveaux paquets. Il peut également être configuré pour envoyer un courrier à l'administrateur système.

Remarquez que vous pourriez vérifier la version de distribution comme décrit en Section 7.5.3, « Vérification par version de distribution » pour mettre à jour automatiquement le système (même si vous ne téléchargez que les paquets). Sinon, vous ne pouvez pas être certain que les paquets téléchargés proviennent réellement d'une source de confiance.

Pour de plus amples renseignements, consultez le http://www.debian-administration.org/articles/162.

10.1.2.4. Vérification automatique des problèmes de sécurité avec debsecan

Le programme debsecan évalue l'état de la sécurité par rapport aux mises à jour de sécurité non effectuées et aux vulnérabilités sans correctif alors que cron-apt ne fournit qu'un rapport sur les mises à jour non effectuées. debsecan obtient les renseignements sur les failles qui ne sont pas corrigées à l'aide de la base de données des vulnérabilités qui est gérée par l'équipe de sécurité de Debian. Par conséquent, comme décrit en Section 10.1.1, « Surveillance des failles de sécurité », il aide plus efficacement les administrateurs à suivre les failles de sécurité.

En installant le paquet debsecan, et si l'administrateur l'accepte, une tâche cron exécutera périodiquement debsecan et notifiera l'utilisateur choisi lorsqu'un paquet vulnérable est détecté. L'emplacement de la base de données des vulnérabilités est aussi paramétrable lors de l'installation et peut ensuite être modifié dans le fichier /etc/default/debsecan. C'est pratique pour les systèmes sans accès direct à Internet qui doivent télécharger les nouvelles informations depuis un miroir local pour avoir un seul chemin de mise à jour de la base de données des vulnérabilités.

Remarquez toutefois que l'équipe de sécurité suit beaucoup de failles, y compris des problèmes peu dangereux qui pourraient ne pas être corrigés lors des mises à jour de sécurité. De plus, certaines failles initialement considérées comme affectant Debian peuvent, plus tard et après enquête, être abandonnées. debsecan indiquera toutes les failles, ce qui peut en faire un outil plus verbeux que les autres outils décrits précédemment.

Pour plus d'informations, veuillez consulter le http://www.enyo.de/fw/software/debsecan/.

10.1.2.5. Autres méthodes de mises à jour de sécurité

Le paquet apticron, comme apt-cron, vérifiera les mises à jour et enverra des messages à l'administrateur. Pour plus d'informations, veuillez consulter le http://www.debian-administration.org/articles/491.

Vous pourriez également jeter un œil à http://clemens.endorphin.org/secpack/, un programme non officiel pour effectuer des mises à jour de sécurité depuis security.debian.org écrit par Fruhwirth Clemens, qui vérifie les signatures ou encore le module d'extension Nagios http://www.unixdaemon.net/nagios_plugins.html#check_debian_packages écrit par Dean Wilson.

10.1.3. Évitez la branche unstable

À moins de vouloir passer du temps à corriger les paquets vous-même quand une faille survient, vous ne devriez pas utiliser la branche unstable de Debian pour des systèmes en production. La raison principale est l'absence de mises à jour de sécurité pour unstable.

Certains problèmes de sécurité peuvent en fait apparaître dans unstable et pas dans la distribution stable. Cela est dû aux nouvelles fonctionnalités ajoutées constamment aux applications fournies, ainsi qu'aux nouvelles applications qui peuvent ne pas encore avoir été testées en profondeur.

Pour effectuer des mises à jour de sécurité dans la branche unstable, vous risquez de devoir faire des mises à jour complètes vers de nouvelles versions (ce qui peut mettre à jour beaucoup plus que les paquets touchés). Bien qu'il y ait des exceptions, les correctifs de sécurité sont habituellement rétroportés dans la branche stable. L'idée principale étant qu'entre les mises à jour, aucun nouveau code ne doit être ajouté, seulement des correctifs aux problèmes importants.

Remarquez que vous pouvez utiliser le système de suivi de sécurité (décrit en Section 10.1.1, « Surveillance des failles de sécurité ») pour suivre les failles de sécurité affectant cette branche.

10.1.4. Suivi en sécurité de la branche testing

Si vous utilisez la branche testing, plusieurs problèmes sont à prendre en compte concernant la disponibilité des mises à jour de sécurité.

Quand un correctif de sécurité est préparé, l'équipe de sécurité rétroporte le correctif pour stable (car stable est habituellement en retard de quelques versions mineures ou majeures). Le responsable du paquet s'occupe de préparer les paquets pour unstable, habituellement basé sur une nouvelle version amont. Parfois, les modifications se produisent en même temps et parfois l'une des distributions reçoit le correctif de sécurité avant. Les paquets de la distribution stable sont testés plus en profondeur que ceux d'unstable car ces derniers peuvent fournir la dernière version amont (qui pourrait ajouter de nouveaux bogues inconnus).
Les mises à jour de sécurité sont disponibles pour la branche unstable quand le responsable du paquet crée une nouvelle version du paquet et pour stable quand l'équipe de sécurité effectue un envoi et publie une DSA. Veuillez noter que ni l'un, ni l'autre ne modifie testing.
Si aucun (nouveau) bogue n'est détecté dans la version unstable de paquet, il est déplacé dans testing après plusieurs jours. Le délai est habituellement de dix jours, bien que cela dépende de la priorité de l'envoi des modifications et si l'entrée du paquet dans testing est bloquée par ses relations de dépendances. Notez que si l'entrée du paquet dans testing est bloquée, la priorité d'envoi ne changera pas le temps nécessaire pour y entrer.

Ce comportement peut changer selon l'état de publication de la distribution. Quand une nouvelle version est imminente, l'équipe de sécurité ou les responsables de paquet peuvent fournir des mises à jour directement dans testing.

De plus, l'http://secure-testing-master.debian.net peut publier des annonces de sécurité de testing (« Debian Testing Security Advisories » ou DTSA) pour les paquets de la branche testing si un problème de sécurité doit être immédiatement corrigé dans cette branche sans attendre la procédure normale (ou que la procédure normale est bloquée par d'autres paquets).

Les utilisateurs voulant tirer partie de ce suivi devraient ajouter les lignes suivante à /etc/apt/sources.list (au lieu des lignes indiqué en Section 4.2, « Faire une mise à jour de sécurité ») :

    deb http://security.debian.org testing/updates main contrib non-free
# Cette ligne permet de télécharger aussi les paquets source
    deb-src  http://security.debian.org testing/updates main contrib non-free

Pour de plus amples renseignements sur ce suivi, veuillez lire l'http://lists.debian.org/debian-devel-announce/2006/05/msg00006.html. Ce suivi a officiellement commencé en http://lists.debian.org/debian-devel-announce/2005/09/msg00006.html dans un dépôt séparé avant d'être intégré à l'archive de sécurité principale.

10.1.5. Mises à jour automatiques dans un système Debian GNU/Linux

Tout d'abord, les mises à jour automatiques ne sont pas vraiment recommandées car les administrateurs devraient vérifier les DSA et comprendre l'impact de toute mise à jour de sécurité donnée.

Si vous voulez mettre à jour le système automatiquement, vous devriez suivre les conseils suivants.

Configurer apt pour interdire la mise à jour des paquets à garder dans leur version actuelle, soit avec la fonctionnalité d'étiquetage (pinning) d'apt, soit en les marquant comme hold (à garder) avec dpkg ou dselect.
Pour conserver les paquets à une version donnée, vous devez éditer /etc/apt/preferences (consultez apt_preferences(5)) et ajouter :
```
  Package: *
  Pin: release a=stable
  Pin-Priority: 100
```
FIXME : Vérifier si cette configuration est correcte.
Utiliser soit cron-apt comme décrit dans Section 10.1.2.3, « Vérification automatique des mises à jour avec cron-apt » et l'activer pour installer les paquets récupérés, soit ajouter une entrée cron vous-même pour exécuter la mise à jour quotidiennement, par exemple :
```
  apt-get update && apt-get -y upgrade
```
L'option -y forcera apt à répondre automatiquement oui aux questions lors de la mise à jour. Dans certains cas, vous pourriez préférer l'option --trivial-only à --assume-yes (qui est équivalent de -y).^[70]
Configurer cron pour que debconf ne pose pas de question pendant les mises à jour, qui pourront ainsi être faites de façon non interactive.^[71]
Vérifier les résultats de l'exécution de cron envoyées au superutilisateur (sauf si la variable d'environnement MAILTO est modifiée dans le script).

Une alternative plus sûre peut être d'utiliser l'option -d (ou --download-only) pour télécharger les paquets nécessaires sans les installer. Puis, si l'exécution de cron indique que le système doit être mis à jour, cela peut être fait par l'administrateur.

Pour accomplir ces tâches, le système doit être configuré correctement pour télécharger les mises à jour de sécurité comme décrit en Section 4.2, « Faire une mise à jour de sécurité ».

Cependant, cela n'est pas recommandé pour unstable sans analyse attentive, car vous pourriez placer le système dans un état inutilisable si un bogue sérieux s'introduit dans un paquet important et est installé sur le système. testing est un peu plus sûre de ce côté car les bogues sérieux ont une meilleure chance d'être détectés avant que le paquet n'entre dans la branche testing (cependant, vous pourriez n'avoir aucune mise à jour de sécurité disponible).

Si vous utilisez une distribution mixte, c'est-à-dire, une installation de stable avec des paquets mis à jour de testing ou d'unstable, vous pouvez jouer avec les préférences d'étiquetage et avec l'option --target-release d'apt-get pour ne mettre à jour que les paquets que de la nouvelle distribution.^[72]

^[70] Vous pourriez aussi utiliser l'option --quiet (-q) pour réduire la sortie d'apt-get, ce qui évitera la génération de message si aucun paquet n'est installé.

^[71] Remarquez que certains paquets pourraient ne pas utiliser debconf et les mises à jour seront bloquées car les paquets attendront une réponse de l'administrateur pendant la configuration.

^[72] C'est un problème courant car beaucoup d'utilisateurs veulent conserver un système stable tout en mettant à jour certains paquets avec unstable pour obtenir les dernières fonctionnalités. Ce besoin provient de l'évolution plus rapide de certains projets que le temps mis par Debian pour publier une nouvelle version stable de sa distribution.