[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]


Manuel de sécurisation de Debian
Chapitre 9 - Avant la compromission


9.1 Maintenez votre 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 rustines dès qu'elles 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 (i.e. installer des services supplémentaires dans leur compte local).


9.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 votre système. Ceci est particulièrement vrai quand vous utilisez un système exposé (i.e. connecté à Internet) et fournissez un service. Dans ce cas, les administrateurs systèmes devraient surveiller attentivement les sources d'informations connues pour être les premiers à être informés lorsqu'une faille qui pourrait affecter un service critique est détectée.

Ceci inclut habituellement de s'abonner à la liste de diffusion des annonces, sur le site web du projet ou le 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 liste des failles de sécurité connues et s'inscrire à la liste de diffusion des annonces du serveur Apache.

Pour suivre les failles de sécurité connues affectant Debian, l'équipe de sécurité de Debian de la version testing maintient un gestionnaire de la sécurité qui liste toutes les vulnérabilités connues qui n'ont pas encore été corrigées dans les paquets Debian. L'information est obtenue via plusieurs sources publiques et contient les failles connues qui sont disponibles soit par les bases de données de vulnérabilité ou le système de suivi des bogues de Debian. Les administrateurs peuvent chercher les problèmes de sécurité connus qui sont suivis pour stable, oldstable, testing, ou unstable.

Le système de suivi fourni une interface avec un moteur de recherches (par nom et nom de paquet via CVE) et d'autres outils (tel que debsecan, voir Vérifier automatiquement les problèmes de sécurité avec debsecan, Section 9.1.2.4) utilisant ces bases de données pour fournir de l'information sur les vulnérabilités qui n'ont pas encore été résolues pour un système donné.

Les administrateurs consciencieux peuvent utiliser cette information pour déterminer quelles failles de sécurité peuvent 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 supportées et suivis par l'équipe de sécurité de Debian vont généralement passer par un avis de sécurité Debian (DSA) et seront disponibles pour tous les utilisateurs (voir Mettre à jour le système en permanence, Section 9.1.2). 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 table de références croisées de sécurité disponible pour les DSA publiées.

Notez toutefois que l'information suivie par l'équipe de test de sécurité Debian ne concerne que les failles connues (i.e. celles qui ont déjà été rendues publiques). Parfois, l'équipe de sécurité Debian peut gérer et préparer des DSA pour des paquets selon des informations qui ne sont pas publiques et qu'ils ont obtenues par des listes de diffusions restreintes, par le découvreur de la faille ou par les développeurs du logiciel. Aussi, ne soyez pas surpris de découvrir des problèmes de sécurité affichés dans un DSA sans ne jamais avoir apparu dans le système de suivi des vulnérabilités.


9.1.2 Mettre à jour le système en permanence

Vous devriez effectuer des mises à jour de sécurité fréquemment. La grande majorité des exploits résulte de failles connues qui n'ont pas été corrigées à temps, comme l'explique ce papier par Bill Arbaugh (présenté lors du Symposium 2001 IEEE sur la sécurité et la confidentialité). Les mises à jour sont décrites dans Faire une mise à jour de sécurité, Section 4.2.


9.1.2.1 Vérifier manuellement si des mises à jour de sécurité sont disponibles

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é votre système comme décrit dans Faire une mise à jour de sécurité, Section 4.2, vous avez simplement à 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 ... ]

Et redémarrez les services dont les bibliothèques ont été mises à jour s'il y en a. Note : lisez Faire une mise à jour de sécurité, Section 4.2 pour plus d'informations sur les mises à jour de bibliothèques (et de noyau).

La première ligne téléchargera la liste des paquets disponibles depuis vos 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 vous dire quels paquets seraient téléchargés et/ou installés. À partir de cette sortie, vous pouvez en déduire quels paquets ont été corrigés dans Debian et sont disponibles comme 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 voir 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 de tels paquets sont nécessaires, vous devriez aller à http://security.debian.org et vérifier quelles alertes de sécurité Debian (DSA) ont été récemment publiées concernant ces paquets. Dans ce cas, les DSA concernées sont DSA-233 (pour cvs) et DSA-232 (pour cupsys).

Remarquez que vous devrez redémarrer votre système s'il y a eu une mise à jour du noyau.


9.1.2.2 Vérifier les mises à jour sur la 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 votre système et les installer. Il le 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. En conséquence, si le système est configuré correctement pour recevoir les mises à jour de sécurité tel que décrit dans Faire une mise à jour de sécurité, Section 4.2 et que vous avez une tâche cron qui 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 > Updates, 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, votre 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 (voir Vérifier automatiquement les mises à jour avec cron-apt, Section 9.1.2.3). Vous pouvez aussi simplement vérifier manuellement les mises à jour en utilisant cette application.

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


9.1.2.3 Vérifier automatiquement les mises à jour avec cron-apt

Une autre méthode pour des mises à jour de sécurité automatique 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 courriel à l'administrateur système.

Notez que vous pouvez vouloir vérifier la version de distribution comme décrit dans Alternative à la vérification des versions de distribution, Section 7.4.4, si vous avez l'intention de mettre à jour automatiquement votre système (même si vous ne faites que télécharger 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 plus d'informations, consultez le site d'administration de Debian.


9.1.2.4 Vérifier automatiquement les problèmes de sécurité avec debsecan

Le programme debsecan évalue l'état de la sécurité en listant à la fois les mises à jour de sécurité non effectuées et les vulnérabilités sans correctif alors que cron-apt ne fournit qu'un rapport sur les mises à jour non effectuées. debsecan obtient les informations 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, tel que décrit dans Surveillance des failles de sécurité, Section 9.1.1, il aide plus efficacement les administrateurs à suivre les failles de sécurité.

En installant le paquet debsecan, et si l'administrateur le choisit, une tâche cron qui exécutera périodiquement debsecan sera ajoutée et notifiera l'utilisateur spécifié lorsqu'un paquet vulnérable est détecté. L'emplacement de la base de données des vulnérabilités fait aussi partie des questions posées lors de l'installation et peut ensuite être modifié dans le fichier /etc/default/debsecan. Ceci est utile pour les systèmes qui n'ont pas un accès direct à l'Internet et qui doivent télécharger les nouvelles informations depuis un miroir local afin qu'il n'y ait qu'un seul chemin pour mettre à jour la base de données des vulnérabilité.

Notez toutefois que l'équipe de sécurité fait le suivi de beaucoup de failles, y compris des problèmes peu dangereux qui peuvent 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 notifiera toutes les failles, ce qui peut en faire un outil plus verbeux que les autres outils décrits ci-dessus.

Pour plus d'informations, vous pouvez consulter le site de l'auteur.


9.1.2.5 D'autres méthodes de mises à jour de sécurité

Il y a aussi le paquet apticron qui, comme apt-cron, vérifiera les mises à jour et enverra des courriels à l'administrateur. Pour plus d'informations, vous pouvez consulter le site d'administration de Debian.

Vous pourriez également regarder du côté de secpack qui est un programme non officiel pour effectuer des mises à jour de sécurité depuis security.debian.org écrit par Fruhwirth Clemens et qui vérifie les signatures, ou encore le module d'extension Nagios check_debian_updates.sh écrit par Dean Wilson.


9.1.3 Évitez d'utiliser la branche unstable

À moins que vous ne vouliez dédier 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 de production. La raison principale à cela est qu'il n'y a pas de mises à jour de sécurité pour unstable (voir Comment est assurée la sécurité pour les versions testing et unstable ?, Section 11.3.7).

Le fait est que certains problèmes de sécurité peuvent 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 incluses qui peuvent ne pas encore avoir été testées en profondeur.

Pour effectuer des mises à jour de sécurité dans la branche unstable, il se peut que vous deviez 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 pour des problèmes importants.

Notez que vous pouvez utiliser le système de suivi de sécurité (décrit dans Surveillance des failles de sécurité, Section 9.1.1) pour suivre les failles de sécurité affectant cette branche.


9.1.4 Support de la sécurité pour la branche testing

Si vous utilisez la branche testing, il y a plusieurs problèmes que vous devez prendre en compte concernant la disponibilité des mises à jour de sécurité :

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


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

Tout d'abord, les mises à jour automatiques ne sont pas complètement 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 votre système automatiquement, vous devriez :

Une alternative plus sure peut être d'utiliser l'option -d (ou --download-only) qui téléchargera les paquets nécessaires, mais ne les installera pas. Puis, si l'exécution de cron affiche que le système doit être mis à jour, cela peut être fait manuellement.

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 dans Faire une mise à jour de sécurité, Section 4.2.

Cependant, cela n'est pas recommandé pour unstable sans analyse attentive, car vous pourriez placer votre système dans un état inutilisable si un bogue sérieux s'introduit dans un paquet important et est installé sur votre système. Testing est un peu mieux sécurisé concernant ce problème car les bogues sérieux ont une meilleure chance d'être détecté avant que le paquet ne soir placé dans la branche testing (cependant, vous pouvez n'avoir aucune mise à jour de sécurité disponible de quelque façon).

Si vous avez 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 ainsi qu'avec l'option --target-release d'apt-get pour ne mettre à jour que les paquets que vous avez mis à jour. [53]


9.2 Faites des tests d'intégrité périodiques

En vous basant sur les informations de base que vous avez générées après l'installation (i.e. l'instantané décrit dans Prendre un instantané (snapshot) du système, Section 4.18), vous devriez pouvoir effectuez un test d'intégrité de temps en temps. Un test d'intégrité pourra détecter des modifications du système de fichiers réalisées par un intrus ou dues à une erreur de l'administrateur système.

Les tests d'intégrité devraient, si possible, être réalisés non connectés.[54] C'est-à-dire, sans utiliser le système d'exploitation du système à contrôler, pour éviter un sentiment de sécurité erroné (i.e. des faux négatifs) produit par, par exemple, des rootkits installés. La base de données d'intégrité par rapport à laquelle le système est vérifiée devrait également être utilisée depuis un support en lecture seule.

Vous pouvez envisager de faire des vérifications d'intégrité en ligne en utilisant l'un des outils d'intégrité de système de fichiers disponibles (décrits dans Vérifier l'intégrité des systèmes de fichiers, Section 4.16.3) s'il n'est pas possible de déconnecter le système. Cependant, des précautions devraient être prises pour utiliser une base de données d'intégrité en lecture seule et également pour assurer que les outils de vérification d'intégrité (et le noyau du système d'exploitation) n'ont pas été falsifiés.

Certains des outils mentionnés dans la section des outils d'intégrité, comme aide, integrit ou samhain, sont déjà préparés pour faire des vérifications périodiques (en utilisant la crontab dans les deux premiers cas et en utilisant un démon indépendant pour samhain) et ils peuvent avertir l'administrateur par différents moyens (habituellement par courriel, mais samhain peut également envoyer des pages, des alertes SNMP ou des alertes syslog) quand le système de fichiers est modifié.

Bien sûr, si vous exécutez une mise à jour de sécurité du système, l'instantané pris pour le système devrait être régénéré pour prendre en compte les modifications réalisées par la mise à jour de sécurité.


9.3 Mise en place d'un système de détection d'intrusion

Debian inclut certains outils pour la détection d'intrusion qui sont utiles pour défendre votre système local ou pour défendre d'autres systèmes dans le même réseau. Ce type de défense est important si le système est très critique ou si vous êtes vraiment paranoïaque. Les approches les plus communes dans la détection d'intrusion sont la détection d'anomalie statistique et la détection de correspondance de modèle.

Soyez toujours aux aguets de manière à réellement améliorer la sécurité du système avec n'importe lequel de ces outils, vous devez avoir un mécanisme alerte+réaction. Donc, n'utilisez pas de système de détection d'intrusion si vous n'avertissez personne.

Quand une attaque particulière est détectée, la plupart des outils de détection d'intrusion vont soit loguer l'événement avec syslogd, soit envoyer des courriers à l'utilisateur root (le destinataire du courrier est habituellement configurable). Un administrateur doit configurer convenablement les outils afin que de fausses alertes ne soient pas envoyées. Les alertes peuvent également indiquer une attaque en cours et ne seraient pas très utiles un jour plus tard, puisque l'attaque pourrait déjà alors avoir été couronnée de succès. Assurez-vous donc qu'une règle de sécurité correcte a été mise en place vis-à-vis des alertes et que les mécanismes techniques pour l'implémenter sont en place.

Une source d'information intéressante est la checklist de détection d'intrusion du CERT.


9.3.1 Détection d'intrusion provenant du réseau

Les outils de détection d'intrusions provenant du réseau scrutent le trafic sur un segment de réseau et utilisent cette information comme source de données. Spécifiquement, les paquets du réseau sont examinés et ils sont vérifiés pour voir s'ils correspondent à une certaine signature.

Snort est un renifleur flexible de paquets ou un logueur qui détecte les attaques selon un dictionnaire de signature d'attaques. Il détecte une variété d'attaques et de sondes, tels que des débordements de capacité, les scans dissimulés de ports, les attaques CGI, les sondes SMB, et bien d'autres. Snort dispose également d'une capacité d'alerte en temps réel. Vous pouvez utiliser snort pour un certain nombre d'hôtes de votre réseau ainsi que pour votre propre hôte. C'est un outil qui peut être installé sur n'importe quel routeur pour garder un œil sur le réseau. Installez-le simplement avec apt-get install snort, suivez les questions et surveillez ses journaux. Pour une infrastructure de sécurité un peu plus large, voir Prelude.

Le paquet snort de Debian est installé avec de nombreuses vérifications de sécurité activées par défaut. Toutefois, vous devriez prendre le temps de personnaliser l'installation pour prendre en compte les services que vous utilisez sur votre système. Vous pouvez très bien aussi demander des vérifications supplémentaires spécifiques à ces services.

Note : Les paquets snort disponibles pour Woody sont plutôt obsolètes et peuvent même être bogués, vous pouvez récupérer des paquets Snort rétroportés (et signés) fournis par le responsable à http://people.debian.org/~ssmeenk/snort-stable-i386/.

Il y a d'autres outils plus simples qui peuvent être utilisés pour détecter les attaques réseaux. portsentry est un autre paquet intéressant qui peut vous informer lorsqu'un scan de votre réseau est effectué sur votre site. D'autres outils comme ippl ou iplogger peuvent aussi détecter certaines attaques IP (TCP et ICMP), même s'ils ne fournissent pas de techniques avancées pour détecter les attaques réseaux (comme le ferait snort).

Vous pouvez testez chacun de ces outils avec le paquet Debian idswakeup, un générateur de fausses alertes et qui inclut un grand nombre de signature d'attaques communes.


9.3.2 La détection d'intrusion fondée sur l'hôte

La détection d'intrusion fondée sur l'hôte implique d'activer, sur le système à étudier, un logiciel qui utilise les journaux ou les programmes d'audit du système comme source de données. Il scrute les processus suspects, scrute les accès d'hôtes et peut même scruter les changements aux fichiers critiques du système.

Tiger est un ancien outil de détection d'intrusion qui a été porté sous Debian depuis la distribution Woody. Tiger fournit un ensemble de vérifications sur des problèmes communs liés aux failles de sécurité, il vérifie la force des mots de passe, les problèmes du système de fichiers, les processus de communications et d'autres façons par lesquelles root peut être compromis. Ce paquet inclut de nouvelles vérifications de sécurité spécifiques à Debian comprenant : les vérifications de MD5sums des fichiers installés, les emplacements de fichiers n'appartenant pas aux paquets et l'analyse des processus locaux à l'écoute. L'installation par défaut configure tiger pour être exécuté chaque jour, générant un compte-rendu qui est envoyé au superutilisateur à propos des compromissions possibles du système.

Des outils d'analyse de journaux comme logcheck peuvent également être utilisés pour détecter des tentatives d'intrusions. Voir Utiliser et personnaliser logcheck, Section 4.12.1.

De plus, des paquets scrutant l'intégrité du système de fichiers (voir Vérifier l'intégrité des systèmes de fichiers, Section 4.16.3) peuvent être utiles dans la détection d'anomalies dans un environnement sécurisé. Il est très probable qu'une intrusion effective modifiera certains fichiers du système de fichiers locaux pour court-circuiter les règles de sécurité locales, installer un cheval de Troie ou créer des utilisateurs. De tels événements peuvent être détectés avec les vérificateurs d'intégrité du système de fichiers.


9.4 Éviter les rootkits


9.4.1 Loadable Kernel Modules (LKM)

Les LKM (Loadable Kernel Modules ou modules de noyau chargeables) sont des fichiers contenant des composants de noyau chargeables dynamiquement utilisés pour étendre les fonctionnalités de noyau. Le principal avantage d'utiliser des modules est la possibilité d'ajouter des périphériques additionnels comme une carte réseau ou une carte son sans avoir à recompiler le noyau entièrement. Cependant certains pirates peuvent utiliser les LKMs pour les rootkits (knark et adore) afin d'installer des portes dérobées sur des systèmes GNU/Linux.

Les portes dérobées des LKM peuvent être plus sophistiquées et moins détectables que des rootkits traditionnels. Ils peuvent cacher des processus, des fichiers, des répertoires et même des connexions sans modifier les codes sources des binaires. Par exemple, un LKM peut forcer le noyau à cacher des processus spécifiques dans procps pour que même une bonne copie du binaire ps ne puisse lister des informations exactes à propose des processus actuels du système.


9.4.2 Détection des rootkits

Il existe deux approches pour défendre votre système contre les rootkits LKM, une défense proactive et une défense réactive. La détection peut être simple et sans douleur ou difficile et usante selon la mesure que vous choisissez.


9.4.2.1 Défense proactive

L'avantage de ce type de défense est qu'elle prévient des dommages que pourrait entraîner un rootkit au système. Une telle stratégie est de "les attraper en premier", c'est-à-dire, de charger un LKM bien défini afin de protéger le système d'autres LKM infectés. Une deuxième stratégie consiste à retirer la fonctionnalité de chargement des modules du noyau lui-même. Notez, cependant, qu'il existe des rootkits qui peuvent fonctionner même dans ce cas, il en existe certains qui altèrent directement /dev/kmem (la mémoire du noyau) pour se rendre indétectables.

Debian GNU/Linux fournit quelques paquets qui peuvent être utilisés pour mettre en place une défense proactive :

Si vous n'avez pas l'utilité de toutes ces fonctionnalités de noyau sur votre système GNU/Linux, vous pouvez vouloir désactiver le support des modules chargeables lors de la configuration du noyau. Pour désactiver le support des modules chargeables, positionnez simplement CONFIG_MODULES=n lors de l'étape de configuration de construction de votre noyau ou dans le fichier .config. Cela prévient des rootkits LKM mais vous ne pourrez plus utiliser les modules avec votre noyau GNU/Linux. Faites attention que la désactivation des modules peut surcharger le noyau, rendant le support du chargement nécessaire.


9.4.2.2 Défense réactive

L'avantage d'une défense réactive est qu'elle représente une faible surcharge au niveau des ressources systèmes. Elle fonctionne en comparant la table des appels systèmes avec une copie sûre d'un fichier du disque, System.map. Bien sûr, une défense réactive n'avertira l'administrateur qu'après la compromission du système.

La détection des rootkits dans Debian peut être accomplie avec le paquet chkrootkit. Le programme Chkrootkit cherche des signes de présence de plusieurs rootkits connus sur le système local, mais ce n'est pas un test définitif.


9.5 Idées géniales/paranoïaques — ce que vous pourriez faire

C'est probablement la section la plus instable et la plus amusante, car j'espère que quelques unes des idées « bah, ça semble dingue » pourraient être réalisées. Vous trouverez ci-dessous certaines idées pour améliorer la sécurité — suivant votre point de vue vous les qualifierez de géniales, paranoïaques, folles ou inspirées.


9.5.1 Construction d'un pot de miel

Un pot de miel est un système conçu pour apprendre aux administrateurs système comment des attaquants sondent et exploitent un système. Il s'agit d'une configuration système qui a pour but d'être sondée, attaquée et potentiellement exploitée. En apprenant les outils et méthodes utilisées par l'attaquant, un administrateur système peut apprendre à mieux protéger ses propres systèmes et son réseau.

Un système Debian GNU/Linux peut facilement être configuré comme un pot de miel, si vous y consacrez le temps de l'implémenter et de le surveiller. Vous pouvez facilement mettre en place le serveur de pot de miel factice ainsi que le pare-feu[57] qui contrôle le pot de miel et un certain type de détecteur d'intrusion réseau, placez-le sur l'Internet et attendez. Prenez soin de vous assurer d'être averti à temps (voir L'importance des logs et des alertes, Section 4.12) si le système est victime d'un exploit pour que vous puissiez prendre des mesures appropriées et terminer le compromis une fois que vous en avez assez vu. Voici quelques uns des paquets et problèmes à considérer lors de la configuration de votre pot de miel :

Si vous ne pouvez pas utiliser des systèmes de réserve pour construire les pots de miel et les systèmes réseau pour le protéger et le contrôler, vous pouvez utiliser la technologie de virtualisation disponible dans xen ou uml (User-Mode-Linux). Si vous choisissez cette route, vous devrez modifier votre noyau soit avec kernel-patch-xen, soit avec kernel-patch-uml, ou encore installer l'un des noyaux précompilés offerts depuis Debian Lenny.

Vous pouvez en lire plus sur la construction des pots de miel dans l'excellent article de Lance Spizner To Build a Honeypot (de la série des "connaissez votre ennemi"). De même, le Honeynet Project fournit des informations utiles sur la façon de configurer un pot de miel et d'auditer les résultats d'une attaque.


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]


Manuel de sécurisation de Debian

Version: 3.4, Fri, 03 Sep 2010 22:30:19 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Auteurs, Section 1.1

Version française par Simon Valiquette (traducteur actuel)
Frédéric Bothamy, Pierre Machard et Arnaud Assad (anciens traducteurs)
et les membres de la liste debian-l10n-french@lists.debian.org