[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
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).
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 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 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 système de suivi des bogues de
Debian. Les administrateurs peuvent chercher les problèmes de
sécurité connus suivis pour stable,
oldstable,
testing
ou unstable.
Le système de suivi fournit des interfaces avec moteur de recherche (par nom
CVE et nom de paquet) et
d'autres outils (comme debsecan, consultez Vérification automatique des problèmes de sécurité avec
debsecan, Section 10.1.2.4) 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 Mettre à jour le système en permanence, Section
10.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.
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.
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 papier de 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.
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 Faire une mise à jour de sécurité, Section 4.2, 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 Faire une mise à jour de sécurité, Section 4.2 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 DSA-233 (pour
cvs) et DSA-232 (pour
cupsys).
Remarquez que le système doit être redémarré après une mise à jour du noyau.
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 Faire une mise à jour de sécurité, Section 4.2 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 Vérification
automatique des mises à jour avec cron-apt, Section 10.1.2.3). 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.
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 Vérification par version de distribution, Section 7.5.3 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 site d'administration
de Debian.
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 Surveillance des failles de sécurité, Section
10.1.1, 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 site de l'auteur.
Le paquet apticron, comme apt-cron, vérifiera les
mises à jour et enverra des messages à l'administrateur. Pour plus
d'informations, veuillez consulter le site d'administration
de Debian.
Vous pourriez également jeter un œil à 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 check_debian_updates.sh
écrit par Dean Wilson.
À 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 (consultez Comment est assurée la sécurité pour les versions testing et unstable ?, Section 12.3.8).
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 Surveillance des failles de sécurité, Section 10.1.1) pour suivre les failles de sécurité affectant cette branche.
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'équipe en
charge de la sécurité de Debian testing 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
Faire une mise à jour de sécurité,
Section 4.2) :
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'annonce.
Ce suivi a officiellement commencé en septembre 2005
dans un dépôt séparé avant d'être intégré à l'archive de sécurité
principale.
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 Vérification
automatique des mises à jour avec cron-apt, Section 10.1.2.3 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).[67]
Configurer cron pour que debconf ne pose pas de
question pendant les mises à jour, qui pourront ainsi être faites de façon
non interactive.[68]
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 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 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.[69]
En vous basant sur les informations de base générées après l'installation (c'est-à-dire l'instantané décrit dans Prendre un instantané (« snapshot ») du système, Section 4.18), vous pourriez 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.[70] C'est-à-dire, sans utiliser le système d'exploitation du système à contrôler, pour éviter un sentiment de sécurité erroné (c'est-à-dire des faux négatifs) produit, par exemple, par 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é.
Debian contient certains outils pour la détection d'intrusion qui permettent de défendre le système local ou d'autres systèmes du 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 de détection d'intrusion les plus communes sont la détection statistique d'anomalies 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 d'alerte et réaction. Un système de détection d'intrusion est inutile si personne n'est prévenu.
Quand une attaque particulière est détectée, la plupart des outils de
détection d'intrusion vont soit journaliser l'événement avec
syslogd, soit envoyer des courriers au superutilisateur (le
destinataire du courrier est habituellement configurable). Un administrateur
doit configurer convenablement les outils pour éviter les fausses alertes.
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à 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'informations intéressante est la liste de
vérification de détections d'intrusion du CERT.
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 journaliseur qui
détecte les attaques selon un dictionnaire de signatures d'attaque. Il
détecte diverses attaques et sondes, comme des débordements de capacité, des
scans dissimulés de ports, des attaques CGI, des sondes SMB, etc.
snort dispose également d'une capacité d'alerte en temps réel.
Vous pouvez utiliser snort pour un certain nombre d'hôtes du
réseau ainsi que pour l'hôte local. Cet outil 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, regardez 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 utilisés sur le système. Vous pourriez rechercher des
vérifications supplémentaires spécifiques à ces services.
D'autres outils plus simples peuvent être utilisés pour détecter les
attaques réseaux. portsentry est un paquet intéressant pour
informer lorsqu'un scan du réseau est effectué sur site. D'autres outils
comme ippl ou iplogger permettent de 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 essayer 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.
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 de problèmes communs liés aux failles de
sécurité, il vérifie la robustesse des mots de passe, les problèmes de
système de fichiers, les processus de communications et d'autres façons de
compromettre le compte du superutilisateur. Ce paquet contient de nouvelles
vérifications de sécurité spécifiques à Debian, y compris les
vérifications de sommes de contrôle MD5 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é quotidiennement, en générant un
compte-rendu 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. Consultez Utiliser et personnaliser logcheck,
Section 4.12.1.
De plus, des paquets scrutant l'intégrité du système de fichiers (consultez 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é. Une intrusion effective modifiera probablement certains fichiers du système de fichiers local 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.
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 LKM 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
source 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 donner des informations exactes à propos
des processus actuels du système.
Il existe deux approches pour défendre le 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 fatigante selon la mesure que vous choisissez.
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
pour 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, certains altèrent même directement /dev/kmem
(la mémoire du noyau) pour se rendre indétectables.
Debian GNU/Linux fournit quelques paquets à utiliser pour mettre en place une défense proactive :
lcap — interface utilisateur agréable pour retirer les
fonctionnalités (contrôle d'accès basé sur le noyau) dans le
noyau, rendant le système plus sécurisé. Par exemple, exécuter lcap
CAP_SYS_MODULE [71]
enlèvera des fonctionnalités de chargement des modules (même pour le
superutilisateur).[72] De
vieilles informations sur ces fonctionnalités sont dans la section de Jon
Corbet Kernel
development sur LWN datant de décembre 1999.
Si vous n'avez pas besoin de toutes ces fonctionnalités de noyau sur un
système GNU/Linux, vous pourriez désactiver la prise en charge des modules
chargeables lors de la configuration du noyau. Pour désactiver la prise en
charge des modules chargeables, positionnez simplement CONFIG_MODULES=n lors de
l'étape de configuration de construction du noyau ou dans le fichier
.config. Cela prévient des rootkits LKM mais vous ne pourrez
plus utiliser les modules avec le noyau GNU/Linux. La désactivation des
modules peut surcharger le noyau, rendant la gestion du chargement nécessaire.
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.
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.
S'amuser avec PAM (Pluggable Authentication Modules). Conformément à l'article PAM du phrack 56, ce qui est bien avec PAM, c'est qu'« il n'est limité que par votre imagination ». C'est vrai. Imaginez une connexion de superutilisateur seulement possible avec empreinte digitale ou un scan de l'œil ou une cryptocarte (pourquoi ai-je fait une conjonction de OU et pas de ET ici ?).
Journalisation fasciste. Je voudrais dire que tout ce dont nous avons discuté plus haut est de la « journalisation douce ». Si vous voulez effectuer une vraie journalisation, procurez-vous une imprimante avec du papier listing et journalisez tout en l'imprimant. Cela semble amusant, mais c'est fiable et ne peut être supprimé, ni altéré.
Distribution CD. Cette idée est très simple à réaliser et offre une assez bonne sécurité. Créez une distribution Debian durcie, avec les règles de pare-feu adéquate, faites-en une image ISO amorçable et gravez-la sur un CD. Vous avez maintenant une bonne distribution en lecture seule avec environ 600 Mo d'espace pour les services. Assurez-vous juste que toutes les données qui devraient être écrites soient écrites sur le réseau. Il est impossible pour des intrus d'obtenir un accès en lecture et écriture sur ce système et toute modification réalisée par un intrus sera désactivée avec un redémarrage du système.
Désactiver la prise en charge des modules. Comme décrit auparavant, une fois désactivée l'utilisation des modules du noyau à la compilation, beaucoup de portes dérobées basées sur le noyau sont impossibles à implémenter car la plupart d'entre elles sont basées sur l'installation de modules du noyau modifiés.
Journalisation par câble série (contribution de Gaby Schilders). Tant que les serveurs ont des ports série, imaginez une machine dédiée à la journalisation pour un certain nombre de serveurs. Le système de journalisation serait déconnecté du réseau, et connecté aux serveurs par un multiplexeur de ports série (cyclades ou similaire). Maintenant faites journaliser vos serveurs par leurs ports série en écriture seule. La machine de journalisation n'accepterait que du texte en clair en entrée sur ses ports séries et n'écrirait que sur un fichier journal. Branchez un graveur de CD ou DVD et transférez-y les fichiers journaux quand le fichier journal atteint la capacité du support. Maintenant il ne manque plus qu'un graveur avec chargeur de CD automatique… Pas autant « copie en dur » que la journalisation directe vers l'imprimante, mais cette méthode peut gérer de larges volumes et les CD prennent moins d'espace de stockage.
Modifiez les attributs de tous les fichiers avec chattr (tiré du
Tips-HOWTO écrit par Jim Dennis). Tout de suite après avoir installé et
configuré initialement le système, utilisez le programme chattr
avec l'attribut +i pour rendre les fichiers non-modifiables (le
fichier ne peut être supprimé, renommé, lié ou réécrit). Envisagez de
positionner cet attribut sur tous les fichiers de /bin,
/sbin/, /usr/bin, /usr/sbin,
/usr/lib et tous les fichiers noyau de la racine. Vous pouvez
également faire une copie de tous les fichiers de /etc/, en
utilisant tar, et marquer l'archive comme immuable.
Cette stratégie permettra de limiter les dégâts possibles une fois connecté
en superutilisateur. Cela empêchera d'écraser des fichiers avec un
opérateur de redirection mal placé, de rendre le système inutilisable avec
une espace mal placée dans une commande rm -rf (il est toujours
possible de faire pas mal de dégâts aux données, mais les bibliothèques et
binaires seront mieux protégés).
Cela limite aussi la réalisation d'un grand nombre d'exploitations de faille de sécurité et de dénis de service (car beaucoup d'entre eux dépendent de l'écrasement d'un fichier par les actions d'un programme SETUID qui ne fournit aucune invite de commandes).
Le seul inconvénient de cette stratégie survient lorsque vous compilez et
installez divers binaires systèmes. D'un autre côté, cela empêche aussi le
make install d'écraser les fichiers. Quand vous oubliez de lire
le Makefile et de faire un chattr -i, les fichiers qui vont être
réécrits (et les répertoires auxquels vous voulez ajouter des fichiers) - la
commande make échoue, utilisez juste la commande chattr et
relancez-le. Vous pouvez aussi profiter de l'occasion pour déplacer vos vieux
binaires et bibliothèques dans un répertoire .old/ ou dans une archive tar
par exemple.
Remarquez que cette stratégie empêche aussi de mettre à jour les paquets du
système car les fichiers existants ne peuvent être remplacés, vous pourriez
donc avoir un mécanisme pour désactiver l'attribut immuable sur tous les
binaires juste avant de faire un apt-get update.
Couper 2 ou 4 fils du câble réseau afin de rendre les communications UDP unidirectionnelles. Ensuite, utilisez des paquets UDP pour envoyer des informations à la machine destinatrice qui peut agir en tant que serveur de journalisation sécurisé ou système de stockage de carte de crédit.
Un pot de miel est un système conçu pour apprendre aux administrateurs système les techniques de sondage et d'exploitation des attaquants. 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[73] qui contrôle le pot de miel et un certain type de détecteur d'intrusion réseau, placez-le sur Internet et attendez. Prenez soin de vous assurer d'être averti à temps (consultez L'importance des journaux et des alertes, Section 4.12) si le système est victime d'une exploitation pour que vous puissiez prendre des mesures appropriées et mettre un terme à la compromission après en avoir assez vu. Voici quelques paquets et problèmes à considérer lors de la configuration de pot de miel :
la technologie pare-feu dont vous aurez besoin (fournie par les noyaux Linux) ;
syslog-ng pour envoyer les journaux du pot de miel vers un serveur
de journalisation système distant ;
snort pour configurer la capture de tout le trafic réseau
arrivant sur le pot de miel et détecter les attaques ;
osh, un interpréteur de commande restreint à sécurité
améliorée et SETUID root avec journalisation (consultez l'article de Lance
Spitzner référencé ci-dessous) ;
tous les démons à utiliser pour le serveur factice pot de miel. Selon le type d'attaque que vous voulez analyser, vous renforcerez ou non le pot de miel et vous le conserverez ou non à jour avec les mises à jour de sécurité ;
des vérificateurs d'intégrité (consultez Vérifier l'intégrité des systèmes de
fichiers, Section 4.16.3) et la boîte à outils du légiste (The Coroner's
Toolkit (tct)) pour faire des audits après l'attaque ;
honeyd et farpd pour mettre en place un pot de miel
qui écoutera les connexions vers des adresses IP non utilisées et les fera
suivre vers des scripts simulant des services actifs. Regardez également
iisemulator ;
tinyhoneypot pour mettre en place un serveur pot de miel simple
avec des services factices.
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 le noyau soit avec
kernel-patch-xen, soit avec kernel-patch-uml, ou
encore installer l'un des noyaux précompilés disponibles depuis Debian Lenny.
Vous pouvez en lire plus sur la construction des pots de miel dans l'excellent
article Construire
un pot de miel de Lance Spizner (dans la série des
« connaissez votre ennemi »). De même, le projet Honeynet fournit des
informations utiles sur la façon de configurer un pot de miel et de contrôler
les résultats d'une attaque.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
Securing Debian Manual
Version: 3.13, Sun, 08 Apr 2012 02:48:09 +0000jfs@debian.org