[RFR] ddp://manuals.sgml/securing-howto/fr/before-compromise.sgml
Voici un 8e chaptitre à réviser.
La MAJ a été faite par Arnaud Février, suivi par une révision
importante par moi-même.
J'ai inclus le diff, mais idéalement ce serait mieux de réviser le
document au complet. Il reste encore plusieurs erreurs ou problèmes avec
l'ancienne traduction et je sais que je n'ai pas tout corrigé.
Simon
<!-- Subversion revision of original English document "4771" -->
<chapt>Avant la compromission
<!-- A traduire compromise!. C'est Ok! jpg -->
<sect id="keep-secure">Maintenez votre système sécurisé
<p>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).
<sect1 id="track-vulns">Surveillance des failles de sécurité
<p>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.
<p>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 <url id="http://httpd.apache.org/security_report.html";
name="liste des failles de sécurité connues"> et s'inscrire à la
liste de diffusion des
<url id="http://httpd.apache.org/lists.html#http-announce";
name="annonces du serveur Apache">.
<p>Pour suivre les failles de sécurité connues affectant Debian,
l'équipe de sécurité de Debian de la version <em>testing<em> maintient
un <url id="http://security-tracker.debian.net/"; name="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 base de données de vulnérabilité
ou <url id="http://www.debian.org/Bugs/"; name="le système de suivi des
bogues de Debian">. Les administrateurs peuvent chercher les problèmes
de sécurité connus qui sont suivis pour
<url id="http://security-tracker.debian.net/tracker/status/release/stable"; name="stable">,
<url id="http://security-tracker.debian.net/tracker/status/release/oldstable"; name="oldstable">,
<url id="http://security-tracker.debian.net/tracker/status/release/testing"; name="testing">,
ou
<url id="http://security-tracker.debian.net/tracker/status/release/unstable"; name="unstable">.
<p>Le système de suivi fourni une interfaces avec un moteur de
recherches (par nom et nom de paquet via <url id="http://cve.mitre.org/";
name="CVE">) et d'autres outils (tel que <package>debsecan</package>,
voir <ref id="debsecan">) 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é.
<p>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.
<p>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 <ref id="keep-up-to-date">). 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
<url id="http://www.debian.org/security/crossreferences";
name="table de références croisées de sécurité"> disponible pour
les DSA publiées.
<p>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.
<sect1 id="keep-up-to-date">Mettre à jour le système en permanence
<p>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 <url
id="http://www.cs.umd.edu/~waa/vulnerability.html"; name="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 <ref
id="security-update">.
<sect2>Vérifier manuellement si des mises à jour de sécurité sont
disponibles
<p>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.
<p>Si vous avez configuré votre système comme décrit dans
<ref id="security-update">, vous avez simplement à faire :
<example>
# 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 ... ]
</example>
<p>Et redémarrez les services dont les bibliothèques ont été mises à
jour s'il y en a. Note : lisez <ref id="security-update"> pour plus
d'informations sur les mises à jour de bibliothèques (et de noyau).
<p>La première ligne téléchargera la liste des paquets disponibles depuis vos
sources de paquets configurées. L'option <tt>-s</tt> effectuera une simulation
d'exécution, c'est-à-dire, qu'elle ne va <em>pas</em> 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 :
<example>
# 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)
</example>
<p>Dans cet exemple, vous pouvez voir que le système a besoin d'être mis à jour
avec les nouveaux paquets <package>cvs</package> et
<package>cupsys</package> qui sont récupérés depuis l'archive de
mises à jour de sécurité de <em>Woody</em>. Si vous voulez comprendre
pourquoi de tels paquets sont nécessaires, vous devriez aller à
<url id="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
<url id="http://www.debian.org/security/2003/dsa-233"; name="DSA-233">
(pour <package>cvs</package>) et
<url id="http://www.debian.org/security/2003/dsa-232"; name="DSA-232">
(pour <package>cupsys</package>).
<p>Remarquez que vous devrez redémarrer votre système s'il y a eu une
mise à jour du noyau.
<sect2 id="update-desktop">Vérifier les mises à jour sur la station
de travail
<p>Depuis Debian 4.0 <em>Lenny</em>, Debian fournit et installe
par défaut <package>update-notifier</package>. 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
<package>update-manager</package>.
<p>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 <ref id="security-update"> 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.
<p>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.
<p>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 <prgn>cron</prgn>, alors
son contenu sera plus récent que les paquets installés sur le système
et l'application pourra vous avertir.
<p><prgn>Apt</prgn> installe une telle tâche cron
(<file>/etc/cron.d/apt</file>) qui s'exécutera selon la configuration
d'APT (plus spécifiquement <em>APT::Periodic</em>). 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 <prgn>/usr/bin/software-properties</prgn>.
<p>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
<file>/etc/apt/apt.conf.d/10periodic</file> devrait
ressembler à ceci :
<example>
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
</example>
<p>Vous pouvez utiliser une tâche cron différente, comme celle
installée par <package>cron-apt</package> (voir <ref id="cron-apt">).
Vous pouvez aussi simplement vérifier manuellement les mises à jour
en utilisant cette application.
<p>Les utilisateurs de l'environnement KDE préféreront probablement
installer à la place <package>adept</package> et
<package>adept-notifier</package>. Ils fournissent des fonctionnalités
similaires, mais ils ne sont pas installés par défaut.
<sect2 id="cron-apt">Vérifier automatiquement les mises à jour avec cron-apt
<p>Une autre méthode pour des mises à jour de sécurité automatique est
l'utilisation de <package>cron-apt</package>. 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.
<p>Notez que vous pouvez vouloir vérifier la version de distribution comme
décrit dans <ref id="check-releases">, 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.
<p>Pour plus d'informations, consultez le
<url id="http://www.debian-administration.org/articles/162";
name="site d'administration de Debian">.
<sect2 id="debsecan">Vérifier automatiquement les problèmes de
sécurité avec debsecan
<p>Le programme <prgn>debsecan</prgn> évalue le statu 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 <package>cron-apt</package> ne
fournit qu'un rapport sur les mises à jour non effectuées.
<prgn>debsecan</prgn> 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 <ref id="track-vulns">, il aide
plus efficacement les administrateurs à suivre les failles de sécurité.
<p>En installant le paquet <package>debsecan</package>, et si
l'administrateur le choisi, une tâche cron qui exécutera périodiquement
<prgn>debsecan</prgn> 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
<file>/etc/default/debsecan</file>. 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é.
<p>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. <prgn>debsecan</prgn>
notifiera toutes les failles, ce qui peut en faire un outil
plus verbeux que les autres outils décrits ci-dessus.
<p>Pour plus d'informations, vous pouvez consulter le
<url id="http://www.enyo.de/fw/software/debsecan/";
name="site de l'auteur">.
<sect2>D'autres méthodes de mises à jour de sécurité
<p>Il y a aussi le paquet <package>apticron</package> qui,
comme <package>apt-cron</package>, vérifiera les mises à jour et
enverra des courriels à l'administrateur. Pour plus d'informations,
vous pouvez consulter le
<url id="http://www.debian-administration.org/articles/491";
name="site d'administration de Debian">.
<P>Vous pourriez également regarder du côté de
<url id="http://clemens.endorphin.org/secpack/"; name="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
<url id="http://www.unixdaemon.net/nagios_plugins.html#check_debian_packages";
name="check_debian_updates.sh"> écrit par Dean Wilson.
<sect1>Évitez d'utiliser la branche unstable
<p>À moins que vous ne vouliez dédier du temps à corriger les paquets vous-même
quand une faille survient, vous ne devriez <em>pas</em> 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 <em>unstable</em> (voir <ref
id="sec-unstable">).
<p>Le fait est que certains problèmes de sécurité peuvent apparaître dans
unstable et <em>pas</em> dans la distribution <em>stable</em>. 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.
<p>Pour effectuer des mises à jour de sécurité dans la branche <em>unstable</em>,
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étro-portés dans la branche <em>stable</em>. L'idée principale étant qu'entre
les mises à jour, <em>aucun nouveau code</em> ne doit être ajouté, seulement des
correctifs pour des problèmes importants.
<p>Notez que vous pouvez utiliser le système de suivi de sécurité
(décrit dans <ref id="track-vulns">) pour suivre les failles de
sécurité affectant cette branche.
<sect1 id="security-support-testing">Support de la sécurité pour la
branche testing
<p>Si vous utilisez la branche <em>testing</em>, il y a plusieurs problèmes que
vous devez prendre en compte concernant la disponibilité des mises à jour de
sécurité :
<list>
<item>Quand un correctif de sécurité est préparé, l'équipe de sécurité
rétroporte le correctif pour <em>stable</em> (car stable est habituellement
en retard de quelques versions mineures ou majeures). Le responsable
du paquet est responsable pour préparer les paquets pour
<em>unstable</em>, 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 <em>stable</em> sont testés plus en profondeur que ceux
d'<em>unstable</em> car ces derniers peuvent fournir la dernière version
amont (qui peut inclure de nouveaux bogues inconnus).
<item>Les mises à jour de sécurité sont disponibles pour la branche
<em>unstable</em> quand le responsable du paquet crée une nouvelle
version du paquet et pour <em>stable</em> quand l'équipe de sécurité
effectue un envoi et publie une DSA. Veuillez noter que ni l'un, ni l'autre
ne modifie <em>testing</em>.
<item>Si aucun (nouveau) bogue n'est détecté dans la version <em>unstable</em>
de paquet, il est déplacé dans <em>testing</em> après plusieurs jours.
Le délai est habituellement de dix
jours, bien que cela dépende de la priorité de l'envoi des changements
et si l'entrée du paquet dans <em>testing</em> est bloquée par ses
relations de dépendances. Notez que si l'entrée du paquet dans
<em>testing</em> est bloquée, la priorité d'envoi ne changera pas le
temps que cela lui prendra pour y entrer.
</list>
<p>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 <em>testing</em>
<sect1>Mises à jour automatiques dans un système Debian GNU/Linux
<p>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.
<p>Si vous voulez mettre à jour votre système automatiquement, vous
devriez :
<list>
<item>Configurer <prgn>apt</prgn> pour que les paquets que vous ne voulez pas
mettre à jour restent à leur version actuelle, soit avec
la fonctionnalité d'étiquetage (<em>pinning</em>) d'<prgn>apt</prgn>, soit en les marquant comme
<em>hold</em> (à garder) avec <prgn>dpkg</prgn> ou <prgn>dselect</prgn>.
<p>Pour conserver les paquets à une version donnée, vous devez éditer
<file>/etc/apt/preferences</file> (voir <manref section="5"
name="apt_preferences">) et ajouter :
<example>
Package: *
Pin: release a=stable
Pin-Priority: 100
</example>
<p>FIXME: vérifier si cette configuration est correcte.
<item>Utiliser soit cron-apt comme décrit dans <ref id="cron-apt"> et activez-le
pour installer les paquets récupérés, soit ajouter une entrée <prgn>cron</prgn>
vous-même pour que la mise à jour soit exécutée tous les jours, par exemple :
<example>
apt-get update && apt-get -y upgrade
</example>
<p>L'option <tt>-y</tt> fera qu'<prgn>apt</prgn> supposera une réponse
« yes » pour toutes les questions qui pourraient être posées lors de
la mise à jour. Dans certains cas, vous pouvez vouloir utiliser l'option
<tt>--trivial-only</tt> à la place de <tt>--assume-yes</tt> (qui est équivalent
à <tt>-y</tt>).<footnote>Vous pouvez aussi vouloir utiliser l'option <tt>--quiet</tt>
(<tt>-q</tt>) pour réduire la sortie de <prgn>apt-get</prgn>, ce qui empêchera
la génération de toute sortie si aucun paquet n'est installé.</footnote>
<item>Configurer <prgn>cron</prgn> pour que <prgn>debconf</prgn> ne demande
aucune entrée pendant les mises à jour, ainsi, elles sont faites non
interactivement.<footnote>Notez que certains paquets peuvent <em>ne pas</em>
utiliser <prgn>debconf</prgn> et les mises à jour seront bloquées car les
paquets demanderont des entrées de la part de l'utilisateur pendant la
configuration.</footnote>
<item>Vérifier les résultats de l'exécution de <prgn>cron</prgn> qui seront
envoyées au superutilisateur (sauf si la variable d'environnement
<tt>MAILTO</tt> est changée dans le script).
</list>
<p>Une alternative plus sure peut être d'utiliser l'option <tt>-d</tt> (ou
<tt>--download-only</tt>) qui téléchargera les paquets nécessaires, mais ne les
installera pas. Puis, si l'exécution de <prgn>cron</prgn> affiche que le système
doit être mis à jour, cela peut être fait manuellement.
<p>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 <ref
id="security-update">.
<p>Cependant, cela n'est pas recommandé pour <em>unstable</em> 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. <em>Testing</em> est un peu mieux <em>sécurisé</em> 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 <em>aucune</em> mise à jour de sécurité disponible de quelque façon).
<p>Si vous avez une distribution mixte, c'est-à-dire, une installation de
<em>stable</em> avec des paquets mis à jour de <em>testing</em> ou
d'<em>unstable</em>, vous pouvez jouez avec les préférences d'étiquetage ainsi
qu'avec l'option <tt>--target-release</tt> d'<prgn>apt-get</prgn> pour ne mettre
à jour <em>que</em> les paquets que vous avez mis à jour.
<footnote>C'est un problème courant car beaucoup d'utilisateurs veulent
conserver un système stable tout en mettant à jour certains paquets avec
<em>unstable</em> pour obtenir les dernières fonctionnalités. Ce besoin provient
de l'évolution plus rapide de certains projets que le temps entre les
distributions <em>stable</em> de Debian.</footnote>
<sect id="periodic-integrity">Faites des tests d'intégrité périodiques
<p>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 <ref
id="snapshot">), 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.
<p>Les tests d'intégrité devraient, si possible, être réalisés non
connectés.<footnote>
Une façon aisée de faire cela est d'utiliser un cédérom autonome (Live
CD), comme <url id="http://www.knoppix-std.org/"; name="Knoppix Std"> qui
inclurait à la fois les outils d'intégrité de fichier et la base de
donnée pour votre système.
</footnote>
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.
<p>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 <ref
id="check-integ">) 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.
<P>Certains des outils mentionnés dans la sections des outils
d'intégrité, comme <prgn>aide</prgn>, <prgn>integrit</prgn> ou
<prgn>samhain</prgn>, 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 <prgn>samhain</prgn>) et ils peuvent
avertir l'administrateur par différents moyens (habituellement par
courriel, mais <prgn>samhain</prgn> peut également envoyer des pages,
des alertes SNMP ou des alertes syslog) quand le système de fichiers est
modifié.
<p>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é.
</sect>
<sect id="intrusion-detect">Mise en place d'un système de détection d'intrusion
<p>
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. <!-- pattern-matching -->
<p>
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.<!-- (ne perdez pas de temps à configurer -->
<!-- des choses que vous n'utiliserez pas par la suite) -->
<p>
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 <prgn>syslogd</prgn>,
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.
<p>
Une source d'information intéressante est la
<url id="http://www.cert.org/tech_tips/intruder_detection_checklist.html";
name="checklist de détection d'intrusion du CERT">.
<sect1>Détection d'intrusion provenant du réseau
<p>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.
<p><package>Snort</package> 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. <prgn>Snort</prgn>
dispose également d'une capacité
d'alerte en temps réel. Vous pouvez utiliser <prgn>snort</prgn> 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
<tt>apt-get install snort</tt>, suivez les questions et surveillez ses
journaux. Pour une infrastructure de sécurité un peu plus large, voir
<url id="http://www.prelude-ids.org"; name="Prelude">.
<p>
Le paquet <package>snort</package> 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.
<p><em>Note</em> : Les paquets snort disponibles pour
<em>Woody</em> sont plutôt obsolètes et peuvent même être <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg02105.html";
name="bogués">, vous pouvez récupérer des paquets Snort rétroportés (et
signés) fournis par le responsable à
<url id="http://people.debian.org/~ssmeenk/snort-stable-i386/";>.
<p>Il y a d'autres outils plus simples qui peuvent être utilisés pour détecter
les attaques réseaux. <package>portsentry</package> 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 <package>ippl</package> ou
<package>iplogger</package> 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 <prgn>snort</prgn>).
<p>Vous pouvez testez chacun de ces outils avec le paquet Debian
<package>idswakeup</package>, un générateur de fausses alertes et qui inclut un
grand nombre de signature d'attaques communes.
<sect1>La détection d'intrusion fondée sur l'hôte
<p>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.
<p><package>Tiger</package> est un ancien outil de détection d'intrusion qui
a été porté sous Debian depuis la distribution Woody. <prgn>Tiger</prgn>
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
<prgn>tiger</prgn> pour être exécuté chaque jour, générant un compte-rendu qui
est envoyé au superutilisateur à propos des compromis possibles du système.
<p>Des outils d'analyse de journaux comme <package>logcheck</package> peuvent
également être utilisés pour détecter des tentatives d'intrusions. Voir <ref
id="custom-logcheck">.
<p>De plus, des paquets scrutant l'intégrité du système de fichiers (voir <ref
id="check-integ">) 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.
<sect>Éviter les rootkits
<p>
<sect1 id="LKM">Loadable Kernel Modules (LKM)
<p>
Les LKM (<em>Loadable Kernel Modules</em> 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.
<p>
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 <!-- malicious --> peut forcer le noyau à cacher des
processus spécifiques dans <file>procps</file> pour que même une bonne copie du
binaire <prgn>ps</prgn> ne puisse lister des informations exactes à propose des
processus actuels du système.
<sect1>Détection des rootkits
<p>
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.
<sect2 id="proactive">Défense proactive
<p>
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 <file>/dev/kmem</file> (la mémoire du noyau)
pour se rendre indétectables.
<p>
Debian GNU/Linux fournit quelques paquets qui peuvent être utilisés pour mettre
en place une défense proactive :
<list>
<item> <package>lcap</package> - Une interface utilisateur agréable pour retirer
les <em>fonctionnalités</em> (contrôle d'accès basé sur le noyau) dans le noyau,
rendant le système plus sécurisé. Par exemple, exécuter <tt>lcap
CAP_SYS_MODULE</tt>
<footnote>
Il existe 28 fonctionnalités incluant :
<tt>CAP_BSET</tt>,
<tt>CAP_CHOWN</tt>,
<tt>CAP_FOWNER</tt>,
<tt>CAP_FSETID</tt>,
<tt>CAP_FS_MASK</tt>,
<tt>CAP_FULL_SET</tt>,
<tt>CAP_INIT_EFF_SET</tt>,
<tt>CAP_INIT_INH_SET</tt>,
<tt>CAP_IPC_LOCK</tt>,
<tt>CAP_IPC_OWNER</tt>,
<tt>CAP_KILL</tt>,
<tt>CAP_LEASE</tt>,
<tt>CAP_LINUX_IMMUTABLE</tt>,
<tt>CAP_MKNOD</tt>,
<tt>CAP_NET_ADMIN</tt>,
<tt>CAP_NET_BIND_SERVICE</tt>,
<tt>CAP_NET_RAW</tt>,
<tt>CAP_SETGID</tt>,
<tt>CAP_SETPCAP</tt>,
<tt>CAP_SETUID</tt>,
<tt>CAP_SYS_ADMIN</tt>,
<tt>CAP_SYS_BOOT</tt>,
<tt>CAP_SYS_CHROOT</tt>,
<tt>CAP_SYS_MODULE</tt>,
<tt>CAP_SYS_NICE</tt>,
<tt>CAP_SYS_PACCT</tt>,
<tt>CAP_SYS_PTRACE</tt>,
<tt>CAP_SYS_RAWIO</tt>,
<tt>CAP_SYS_RESOURCE</tt>,
<tt>CAP_SYS_TIME</tt> et
<tt>CAP_SYS_TTY_CONFIG</tt>. Elles peuvent être toutes désactivées pour
renforcer votre noyau.
</footnote>
enlèvera des fonctionnalités de chargement des modules (même pour
l'utilisateur root).<footnote>
Vous n'avez pas besoin d'installer <package>lcap</package> pour faire cela, mais
c'est plus facile que de configurer <file>/proc/sys/kernel/cap-bound</file> à la main.
</footnote>
Il y a de vieilles informations sur ces fonctionnalités dans la
section de Jon Corbet <url id="http://lwn.net/1999/1202/kernel.php3";
name="Kernel development"> sur LWN datant de décembre 1999.
</list>
<p>
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
<file>.config</file>. 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.
<sect2>Défense réactive
<p>
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,
<file>System.map</file>. Bien sûr, une défense réactive n'avertira
l'administrateur qu'après la compromission du système.
<!-- AA rootkit ? traduction officielle ? kit d'intrusions furtifs ? -->
<p>La détection des rootkits dans Debian peut être accomplie avec le paquet
<package>chkrootkit</package>. Le programme <url name="Chkrootkit"
id="http://www.chkrootkit.org";> cherche des signes de présence
de plusieurs rootkits connus sur le système local, mais ce n'est pas un test
définitif.
<sect>Idées géniales/paranoïaques — ce que vous pourriez faire
<p><!-- AA duh ? -->
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.<!-- — pour -->
<!-- augmenter votre sécurité rapidement mais vous n'en sortirez pas indemne. -->
<list>
<item>S'amuser avec PAM (Pluggable Authentication Modules)
Comme il est dit dans l'article PAM du phrack 56, la chose bien avec PAM est
qu'« On est limité seulement par son imagination ». C'est vrai. Imaginez une
connexion root 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 ?).
<item>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
<!-- traduction de fanfold ? --> et journalisez tout en l'imprimant. Cela semble
amusant, mais c'est fiable et ne peut être supprimé, ni altéré.
<item>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 bonnes règles
pare-feu, faites-en une image ISO amorçable et gravez-la sur un cédérom.
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 via le réseau. Il est
impossible pour des intrus d'obtenir un accès en lecture/écriture sur ce système
et tout changement qu'un intrus ferait peut être désactivé avec un redémarrage
du système.
<item>Désactiver la capacité module. Comme décrit auparavant, quand vous
désactivez l'usage des modules 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 noyau modifiés.
<item>Journalisation par câble série (contribution de Gaby schilders).
Tant que les serveurs ont toujours des ports série, imaginez-vous ayant une machine
dédiée à la journalisation pour un certain nombre de serveurs. Le système de
journalisation serait déconnecté du net et connecté aux serveurs via 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 cédérom/dévédérom et
transférez-y les fichiers journaux quand le fichier journal atteint la capacité
du média. Maintenant si seulement ils faisaient des graveurs avec des
auto-changeurs... Pas aussi "copie-en-dur" <!-- AA hard-copy ?..jpg --> que
la journalisation directe vers l'imprimante, mais cette méthode peut gérer de
larges volumes et les cédéroms prennent moins d'espace de stockage.
<item>Changez les attributs de tous les fichiers avec <prgn>chattr</prgn> (tiré
du Tips-HOWTO écrit par Jim Dennis). Tout de suite après que vous ayez installé
et configuré initialement votre système, utilisez le programme
<prgn>chattr</prgn> avec l'attribut <tt>+i</tt> 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
<file>/bin</file>, <file>/sbin/</file>, <file>/usr/bin</file>,
<file>/usr/sbin</file>, <file>/usr/lib</file> et tous les fichiers noyau de la
racine. Vous pouvez également faire une copie de tous les fichiers de
<file>/etc/</file>, en utilisant <prgn>tar</prgn> et marquez l'archive comme
immuable.
<p>Cette stratégie vous aider à limiter les dégâts que vous pouvez faire quand
vous êtes connecté en root. Vous n'écraserez pas de fichiers avec un opérateur
de redirection égaré, et vous ne rendrez pas votre système inutilisable avec
un espace mal placé dans une commande <prgn>rm -fr</prgn> (vous pourriez encore
faire pas mal de dégâts à vos données — mais vos librairies et binaires
seront plus à l'abri).
<p>Cela rend aussi un large éventail d'exploits de sécurité et de dénis de
service soit impossibles soit plus difficiles (car beaucoup d'entre eux comptent
sur l'écrasement d'un fichier à travers les actions d'un programme SETUID qui
<em>ne fournit pas une commande shell arbitraire</em>).
<p>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
<prgn>make install</prgn> d'écraser les fichiers. Quand vous oubliez de lire le
Makefile et de faire un <prgn>chattr -i</prgn>, 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 <prgn>chattr</prgn> 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.
<p>Notez que cette stratégie vous empêche aussi de mettre à jour vos paquets
systèmes car les fichiers qu'ils fournissent ne peuvent être réécrits, vous
pourriez donc souhaiter avoir un mécanisme pour désactiver le drapeau immuable
sur tous les binaires juste avant de faire un <prgn>apt-get update</prgn>.
<item>Couper 2 ou 4 fils du câble 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.
</list>
<sect1>Construction d'un pot de miel
<p>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.
<!--
<p>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. Mettez
simplement en place le serveur factice avec un pare-feu et quelque sorte de
détecteur d'intrusion réseau, placez-le sur l'Internet et attendez. Prenez soin
de vous assurer d'être averti à temps (voir <ref id="log-alerts">) si le système
est victime d'un exploit pour que vous puissiez prendre des mesures appropriées
et terminer le compromis quand vous en avez assez vu. Voici quelques uns des
paquets et problèmes que vous devez considérez lors de la configuration de votre
pot de miel :
-->
<p>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<footnote>Vous utiliserez généralement
un pare-feu pont pour que le pare-feu lui-même ne soit pas détectable,
voir <ref id="bridge-fw">.</footnote> 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
<ref id="log-alerts">) 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 :
<list>
<item>la technologie pare-feu dont vous aurez besoin (fourni par les
noyaux Linux).
<item><package>syslog-ng</package> pour envoyer les journaux du pot de miel
vers un serveur syslog distant.
<item><package>snort</package> pour configurer la capture de tout le trafic
réseau arrivant sur le pot de miel et détecter les attaques.
<item><package>osh</package>, un shell restreint à sécurité amélioré et SETUID
root avec journalisation (voir l'article de Lance Spitzner ci-dessous).
<!--
<item>bien sûr, tous les serveurs que vous pouvez imaginer pour votre faux serveur
pot de miel (mais ne durcissez <em>pas</em> le pot de miel).
<item>Le Deception Toolkit, qui utilise deception pour contrer les attaques.
Page d'origine : <url id="http://www.all.net/dtk/"; name="Deception Toolkit">
-->
<item>bien sûr, tous les serveurs que vous utiliserez pour votre serveur
mot de miel factice. Selon le type d'attaquant que vous voulez analyser,
vous renforcerez <em>ou non</em> le pot de miel et vous le conserverez
ou non à jour avec les mises à jour de sécurité.
<!-- <item>et aussi de faux services, fournis par <package>dtk</package> si vous -->
<!-- voulez aussi utiliser le honeynet comme un service de détection d'intrusion. -->
<item>des vérificateurs d'intégrité (voir <ref id="check-integ">) et la boîte à
outils du légiste (The Coroner's Toolkit (<package>tct</package>)) pour faire
des audits post-attaques.
<item><package>honeyd</package> et <package>farpd</package> 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 <package>iisemulator</package>.
<item><package>tinyhoneypot</package> pour mettre en place un serveur
pot de miel simple avec des services factices.
</list>
<p>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 <prgn>xen</prgn> ou <prgn>uml</prgn> (User-Mode-Linux).
Si vous choisissez cette route, vous devrez modifier votre noyau soit
avec <package>kernel-patch-xen</package>, soit avec
<package>kernel-patch-uml</package>, ou encore installer l'un des noyaux
précompilés offerts depuis Debian Lenny.
<p>Vous pouvez en lire plus sur la construction des pots de miel dans l'excellent
article de Lance Spizner
<url id="http://www.net-security.org/text/articles/spitzner/honeypot.shtml";
name="To Build a Honeypot"> (de la série des "connaissez votre ennemi").
<!--
, ou le
<url id="http://www.zdnetindia.com/techzone/resources/security/stories/7601.htm";
name="Building your own honeypot"> de David Raikow.
-->
De même, le <url id="http://project.honeynet.org/"; name="Honeynet Project">
fournit des informations de valeurs sur comment configurer un pot de miel et
comment auditer les résultats d'une attaque.
Index: securing-howto/fr/before-compromise.sgml
===================================================================
--- securing-howto/fr/before-compromise.sgml (révision 5612)
+++ securing-howto/fr/before-compromise.sgml (copie de travail)
@@ -1,22 +1,113 @@
-<!-- CVS revision of original english document "1.11" -->
+<!-- Subversion revision of original English document "4771" -->
<chapt>Avant la compromission
<!-- A traduire compromise!. C'est Ok! jpg -->
-<sect id="keep-up-to-date">Mettre à jour le système en permanence
+<sect id="keep-secure">Maintenez votre système sécurisé
+<p>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).
+
+<sect1 id="track-vulns">Surveillance des failles de sécurité
+
+<p>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.
+
+<p>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 <url id="http://httpd.apache.org/security_report.html";
+name="liste des failles de sécurité connues"> et s'inscrire à la
+liste de diffusion des
+<url id="http://httpd.apache.org/lists.html#http-announce";
+name="annonces du serveur Apache">.
+
+<p>Pour suivre les failles de sécurité connues affectant Debian,
+l'équipe de sécurité de Debian de la version <em>testing<em> maintient
+un <url id="http://security-tracker.debian.net/"; name="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 base de données de vulnérabilité
+ou <url id="http://www.debian.org/Bugs/"; name="le système de suivi des
+bogues de Debian">. Les administrateurs peuvent chercher les problèmes
+de sécurité connus qui sont suivis pour
+<url id="http://security-tracker.debian.net/tracker/status/release/stable"; name="stable">,
+<url id="http://security-tracker.debian.net/tracker/status/release/oldstable"; name="oldstable">,
+<url id="http://security-tracker.debian.net/tracker/status/release/testing"; name="testing">,
+ou
+<url id="http://security-tracker.debian.net/tracker/status/release/unstable"; name="unstable">.
+
+<p>Le système de suivi fourni une interfaces avec un moteur de
+recherches (par nom et nom de paquet via <url id="http://cve.mitre.org/";
+name="CVE">) et d'autres outils (tel que <package>debsecan</package>,
+voir <ref id="debsecan">) 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é.
+
+<p>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.
+
+<p>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 <ref id="keep-up-to-date">). 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
+<url id="http://www.debian.org/security/crossreferences";
+name="table de références croisées de sécurité"> disponible pour
+les DSA publiées.
+
+<p>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.
+
+<sect1 id="keep-up-to-date">Mettre à jour le système en permanence
+
<p>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 <url
id="http://www.cs.umd.edu/~waa/vulnerability.html"; name="papier par
-Bill Arbaugh"> (presenté lors du Symposium 2001 IEEE sur la sécurité et la
+Bill Arbaugh"> (présenté lors du Symposium 2001 IEEE sur la sécurité et la
confidentialité). Les mises à jour sont décrites dans <ref
id="security-update">.
-<sect1>Vérifiez manuellement quand des mises à jour de sécurité sont disponibles
+<sect2>Vérifier manuellement si des mises à jour de sécurité sont
+disponibles
+
<p>Debian dispose d'un outil spécifique pour déterminer si un système a besoin
-d'être mis à jour (voir Tiger ci-dessous), mais beaucoup d'utilisateurs
-veulement simplement vérifier si des mises à jour de sécurité sont disponibles
+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.
<p>Si vous avez configuré votre système comme décrit dans
@@ -40,7 +131,7 @@
d'exécution, c'est-à-dire, qu'elle ne va <em>pas</em> 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é.
+ont été corrigés dans Debian et sont disponibles comme mise à jour de sécurité.
Par exemple :
<example>
# apt-get upgrade -s
@@ -55,22 +146,82 @@
Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
</example>
+
<p>Dans cet exemple, vous pouvez voir que le système a besoin d'être mis à jour
-avec des nouveaux paquets cvs et cupsys qui sont récupérés depuis l'archive de
-mises à jour de sécurité de <em>woody</em>. Si vous voulez comprendre pourquoi
-de tels paquets sont nécessaires, vous devriez aller à
-<url id="http://security.debian.org";> et vérifier quelles Alerts de sécurité
-Debian (DSA) récentes ont été publiées concernant ces paquets. Dans ce cas, les
-DSA concernées sont
-<url id="http://www.debian.org/security/2003/dsa-233"; name="DSA-233"> (pour cvs)
-et
-<url id="http://www.debian.org/security/2003/dsa-232"; name="DSA-232"> (pour cupsys).
+avec les nouveaux paquets <package>cvs</package> et
+<package>cupsys</package> qui sont récupérés depuis l'archive de
+mises à jour de sécurité de <em>Woody</em>. Si vous voulez comprendre
+pourquoi de tels paquets sont nécessaires, vous devriez aller à
+<url id="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
+<url id="http://www.debian.org/security/2003/dsa-233"; name="DSA-233">
+(pour <package>cvs</package>) et
+<url id="http://www.debian.org/security/2003/dsa-232"; name="DSA-232">
+(pour <package>cupsys</package>).
<p>Remarquez que vous devrez redémarrer votre système s'il y a eu une
mise à jour du noyau.
-<sect1 id="cron-apt">Vérifiez automatiquement les mises à jour avec cron-apt
+<sect2 id="update-desktop">Vérifier les mises à jour sur la station
+de travail
+<p>Depuis Debian 4.0 <em>Lenny</em>, Debian fournit et installe
+par défaut <package>update-notifier</package>. 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
+<package>update-manager</package>.
+
+<p>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 <ref id="security-update"> 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.
+
+<p>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.
+
+<p>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 <prgn>cron</prgn>, alors
+son contenu sera plus récent que les paquets installés sur le système
+et l'application pourra vous avertir.
+
+<p><prgn>Apt</prgn> installe une telle tâche cron
+(<file>/etc/cron.d/apt</file>) qui s'exécutera selon la configuration
+d'APT (plus spécifiquement <em>APT::Periodic</em>). 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 <prgn>/usr/bin/software-properties</prgn>.
+
+<p>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
+<file>/etc/apt/apt.conf.d/10periodic</file> devrait
+ressembler à ceci :
+
+<example>
+APT::Periodic::Update-Package-Lists "1";
+APT::Periodic::Download-Upgradeable-Packages "0";
+</example>
+
+<p>Vous pouvez utiliser une tâche cron différente, comme celle
+installée par <package>cron-apt</package> (voir <ref id="cron-apt">).
+Vous pouvez aussi simplement vérifier manuellement les mises à jour
+en utilisant cette application.
+
+<p>Les utilisateurs de l'environnement KDE préféreront probablement
+installer à la place <package>adept</package> et
+<package>adept-notifier</package>. Ils fournissent des fonctionnalités
+similaires, mais ils ne sont pas installés par défaut.
+
+<sect2 id="cron-apt">Vérifier automatiquement les mises à jour avec cron-apt
+
<p>Une autre méthode pour des mises à jour de sécurité automatique est
l'utilisation de <package>cron-apt</package>. Ce paquet fournit un outil pour
mettre à jour le système à intervalles réguliers (en utilisant une tâche cron).
@@ -84,98 +235,63 @@
paquets). Sinon, vous ne pouvez pas être certain que les paquets téléchargés
proviennent réellement d'une source de confiance.
-<sect1>Utilisez Tiger pour vérifier automatiquement les mises à jour de sécurité
+<p>Pour plus d'informations, consultez le
+<url id="http://www.debian-administration.org/articles/162";
+name="site d'administration de Debian">.
-<p>Si vous recherchez un outil pour vérifier rapidement et fournir un compte
-rendu sur les failles de sécurité d'un système, essayez le paquet
-<package>tiger</package>. Ce paquet est un ensemble de scripts shell Bourne, de
-programmes C et de fichiers de données utilisés pour effectuer des audits de
-sécurité. Le paquet Debian GNU/Linux dispose d'améliorations supplémentaires
-orientés vers la distribution Debian, en fournissant plus de fonctionnalités que
-les scripts Tiger fourni par TAMU (ou même TARA, une version de tiger distribuée
-par ARSC). Voir le fichier <file>README.Debian</file> et la page de
-manuel <manref section="8" name="tiger"> pour plus d'informations.
+<sect2 id="debsecan">Vérifier automatiquement les problèmes de
+sécurité avec debsecan
-<p>L'une de ces améliorations est le script <tt>deb_checkadvisories</tt>. Ce
-script prend une liste de DSA et la vérifie par rapport à la base de paquets
-installés, en indiquant tout paquets qui serait vulnérables selon l'équipe de
-sécurité Debian. Cela est une approche légèrement différente et plus générale
-que celle implémentée par le script Tiger <tt>check_signatures</tt> qui vérifie
-les MD5sums de programmes vulnérables connus.
+<p>Le programme <prgn>debsecan</prgn> évalue le statu 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 <package>cron-apt</package> ne
+fournit qu'un rapport sur les mises à jour non effectuées.
+<prgn>debsecan</prgn> 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 <ref id="track-vulns">, il aide
+plus efficacement les administrateurs à suivre les failles de sécurité.
-<p>Comme Debian ne fournit pas actuellement une liste de MD5sums des programmes
-vulnérables connus (utilisée par certains autres systèmes d'exploitation comme Sun
-Solaris), l'approche <em>vérifier-par-rapport-aux-DSA</em> est utilisée.
-L'approche DSA et l'approche MD5sums souffrent toutes deux du problème que les
-signatures doivent être mises à jour régulièrement.
+<p>En installant le paquet <package>debsecan</package>, et si
+l'administrateur le choisi, une tâche cron qui exécutera périodiquement
+<prgn>debsecan</prgn> 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
+<file>/etc/default/debsecan</file>. 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é.
-<p>Cela est actuellement résolu en créant de nouvelles version du paquet Tiger,
-mais le responsable du paquet pourrait ne pas faire une nouvelle version à
-chaque fois qu'une DSA est annoncée. Un ajout agréable, qui n'est pas encore
-implémenté, serait de faire cela de façon proactive. C'est-à-dire, de
-télécharger les DSA du web, de faire la liste et d'exécuter la vérification. Les
-DSA sont actuellement mises à jour depuis la mise à jour CVS locale du
-responsable des sources WML utilisés pour construire <url
-id="http://security.debian.org";> (le serveur web).
+<p>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. <prgn>debsecan</prgn>
+notifiera toutes les failles, ce qui peut en faire un outil
+plus verbeux que les autres outils décrits ci-dessus.
-<p>Un programme pour analyser les DSA publiées, soit reçues par courriel ou
-disponible sur security.debian.org et qui générerait le fichier utilisé par
-<prgn>deb_checkadvisories</prgn> pour confirmer les failles serait apprécié. Envoyez un
-rapport de bogue pour <package>tiger</package>.
+<p>Pour plus d'informations, vous pouvez consulter le
+<url id="http://www.enyo.de/fw/software/debsecan/";
+name="site de l'auteur">.
-<p>La vérification mentionnée est exécuté par la configuration de programme
-standard une fois installé (voir <file>/etc/tiger/cronrc</file>) :
+<sect2>D'autres méthodes de mises à jour de sécurité
-<example>
-# Vérifie les mesures de sécurité Debian chaque jour à 1h00
-#
-1 * * deb_checkmd5sums deb_nopackfiles deb_checkadvisories
-#
-</example>
+<p>Il y a aussi le paquet <package>apticron</package> qui,
+comme <package>apt-cron</package>, vérifiera les mises à jour et
+enverra des courriels à l'administrateur. Pour plus d'informations,
+vous pouvez consulter le
+<url id="http://www.debian-administration.org/articles/491";
+name="site d'administration de Debian">.
-<p>Il y a une vérification supplémentaire que vous pourriez vouloir ajouter, qui
-ne fait pas partie des scripts standard <prgn>cron</prgn> scripts. Cette
-vérification est le script <tt>check_patches</tt>, qui fonctionne de la façon suivante :
-<list>
-
-<item>exécuter <tt>apt-get update</tt>
-
-<item>vérifier si de nouveaux paquets sont disponibles
-
-</list>
-
-<p>Si vous utilisez un système <em>stable</em> et que vous ajoutez la ligne de source
-<prgn>apt</prgn> pour security.debian.org à votre fichier
-<file>/etc/apt/sources.list</file> (comme décrit dans <ref
-id="security-update">), ce script sera capable de vous dire s'il y a de nouveaux
-paquets que vous devez installer. Comme les seuls paquets modifiés dans cette
-configuration sont les mises à jour de sécurité, vous pourriez avoir exactement
-ce que vous désirez.
-
-<p>Bien sûr, ceci ne fonctionnera par si vous utilisez <em>testing</em>
-ou <em>sid/unstable</em>, car actuellement, les nouveaux paquets sont
-probablement beaucoup plus que des mises à jour de sécurité.
-
-<p>Vous pouvez ajouter ce script aux vérifications effectuées par la tâche <prgn>cron</prgn>
-(dans le fichier de configuration ci-dessus) et <prgn>tigercron</prgn> vous
-enverra par courrier (à l'expéditeur désigné par <tt>Tiger_Mail_RCPT</tt> dans le
-fichier <file>/etc/tiger/tigerrc</file>) la liste des nouveaux paquets :
-
-<example>
-# Vérifie les mesures de sécurité Debian chaque jour à 1h00
-#
-1 * * deb_checkmd5sums deb_nopackfiles check_patches
-#
-</example>
-
-<sect1>D'autres méthodes de mises à jour de sécurité
-
<P>Vous pourriez également regarder du côté de
-<url id="http://therapy.endorphin.org/secpack/"; name="secpack"> qui est un
+<url id="http://clemens.endorphin.org/secpack/"; name="secpack"> qui est un
programme non officiel pour effectuer des mises à jour de sécurité depuis
-security.debian.org avec des vérifications de signatures écrit par Fruhwirth
-Clemens.
+security.debian.org écrit par Fruhwirth Clemens et qui vérifie les
+signatures, ou encore le module d'extension Nagios
+<url id="http://www.unixdaemon.net/nagios_plugins.html#check_debian_packages";
+name="check_debian_updates.sh"> écrit par Dean Wilson.
<sect1>Évitez d'utiliser la branche unstable
@@ -199,8 +315,13 @@
les mises à jour, <em>aucun nouveau code</em> ne doit être ajouté, seulement des
correctifs pour des problèmes importants.
-<sect1>Évitez d'utiliser la branche testing
+<p>Notez que vous pouvez utiliser le système de suivi de sécurité
+(décrit dans <ref id="track-vulns">) pour suivre les failles de
+sécurité affectant cette branche.
+<sect1 id="security-support-testing">Support de la sécurité pour la
+branche testing
+
<p>Si vous utilisez la branche <em>testing</em>, il y a plusieurs problèmes que
vous devez prendre en compte concernant la disponibilité des mises à jour de
sécurité :
@@ -337,7 +458,7 @@
connectés.<footnote>
Une façon aisée de faire cela est d'utiliser un cédérom autonome (Live
CD), comme <url id="http://www.knoppix-std.org/"; name="Knoppix Std"> qui
-incluerait à la fois les outils d'intégrité de fichier et la base de
+inclurait à la fois les outils d'intégrité de fichier et la base de
donnée pour votre système.
</footnote>
C'est-à-dire, sans utiliser le système d'exploitation du système à
@@ -419,9 +540,9 @@
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
-<tt>apt-get install snort</tt>, suivez les questions et regardez les logs. Pour
-un cadre de travail de sécurité un peu plus large, veuillez voir <url
-id="http://www.prelude-ids.org"; name="Prelude">.
+<tt>apt-get install snort</tt>, suivez les questions et surveillez ses
+journaux. Pour une infrastructure de sécurité un peu plus large, voir
+<url id="http://www.prelude-ids.org"; name="Prelude">.
<p>
Le paquet <package>snort</package> de Debian est installé avec de nombreuses vérifications de sécurité
@@ -449,25 +570,26 @@
<package>idswakeup</package>, un générateur de fausses alertes et qui inclut un
grand nombre de signature d'attaques communes.
-<sect1>La détection d'intrusion fondée sur hôte
+<sect1>La détection d'intrusion fondée sur l'hôte
-<p>La détection d'intrusion fondée sur l'hôte implique de charger des logiciels
-sur le système à étudier qui utilise les fichiers de journaux et/ou les
+<p>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.
<p><package>Tiger</package> est un ancien outil de détection d'intrusion qui
-a été porté sous Debian depuis la distribution woody. <prgn>Tiger</prgn>
-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
+a été porté sous Debian depuis la distribution Woody. <prgn>Tiger</prgn>
+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
-<prgn>tiger</prgn> pour être exécuté chaquet jour, générant un compte-rendu qui
-est envoyé au super-utilisateur à propos des compromis possibles du système.
+<prgn>tiger</prgn> pour être exécuté chaque jour, générant un compte-rendu qui
+est envoyé au superutilisateur à propos des compromis possibles du système.
<p>Des outils d'analyse de journaux comme <package>logcheck</package> peuvent
également être utilisés pour détecter des tentatives d'intrusions. Voir <ref
@@ -575,9 +697,9 @@
Vous n'avez pas besoin d'installer <package>lcap</package> pour faire cela, mais
c'est plus facile que de configurer <file>/proc/sys/kernel/cap-bound</file> à la main.
</footnote>
-Pour plus d'informations sur ces fonctionnalités, vous pouvez vérifier la
+Il y a de vieilles informations sur ces fonctionnalités dans la
section de Jon Corbet <url id="http://lwn.net/1999/1202/kernel.php3";
-name="Kernel development"> sur LWN (décembre 1999).
+name="Kernel development"> sur LWN datant de décembre 1999.
</list>
@@ -608,14 +730,6 @@
de plusieurs rootkits connus sur le système local, mais ce n'est pas un test
définitif.
-<p>Vous pouvez aussi utiliser
-<url name="KSTAT" id="http://s0ftpj.org/en/site.html";> (Kernel Security Therapy Anti
-Trolls) du groupe S0ftproject.
-KSTAT vérifie la zone mémoire du kernel (<file>/dev/kmem</file>) pour des
-informations au sujet de l'hôte cible pour aider l'administrateur système à
-trouver et supprimer des LKM <!-- malicious -->.
-
-
<sect>Idées géniales/paranoïaques — ce que vous pourriez faire
<p><!-- AA duh ? -->
@@ -636,7 +750,7 @@
<item>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
-<!-- traduction de fanfold ? --> et journalisez tout en l'imprimant. Ca semble
+<!-- traduction de fanfold ? --> et journalisez tout en l'imprimant. Cela semble
amusant, mais c'est fiable et ne peut être supprimé, ni altéré.
<item>Distribution CD. Cette idée est très simple à réaliser et offre une assez
@@ -646,7 +760,7 @@
600 Mo d'espace pour les services. Assurez-vous juste que toutes les
données qui devraient être écrites, soient écrites via le réseau. Il est
impossible pour des intrus d'obtenir un accès en lecture/écriture sur ce système
-et tout changement qu'un intrus ferait peut être désactiver avec un redémarrage
+et tout changement qu'un intrus ferait peut être désactivé avec un redémarrage
du système.
<item>Désactiver la capacité module. Comme décrit auparavant, quand vous
@@ -687,7 +801,7 @@
faire pas mal de dégâts à vos données — mais vos librairies et binaires
seront plus à l'abri).
-<p>Cela rend aussi un large éventail d'exploits de sécurité et de denis de
+<p>Cela rend aussi un large éventail d'exploits de sécurité et de dénis de
service soit impossibles soit plus difficiles (car beaucoup d'entre eux comptent
sur l'écrasement d'un fichier à travers les actions d'un programme SETUID qui
<em>ne fournit pas une commande shell arbitraire</em>).
@@ -707,8 +821,8 @@
pourriez donc souhaiter avoir un mécanisme pour désactiver le drapeau immuable
sur tous les binaires juste avant de faire un <prgn>apt-get update</prgn>.
-<item>Jouez avec le cablage UTP de façon à couper 2 ou 4 brins et rendez le
-cable à sens unique. Puis utilisez des paquets UDP pour envoyer des informations
+<item>Couper 2 ou 4 fils du câble 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.
@@ -739,7 +853,7 @@
surveiller. Vous pouvez facilement mettre en place le serveur de pot de
miel factice ainsi que le pare-feu<footnote>Vous utiliserez généralement
un pare-feu pont pour que le pare-feu lui-même ne soit pas détectable,
-voir <ref id="bridge-fw"></footnote> qui contrôle le pot de miel et un
+voir <ref id="bridge-fw">.</footnote> 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
<ref id="log-alerts">) si le système est victime d'un exploit pour que
@@ -752,7 +866,7 @@
<item>la technologie pare-feu dont vous aurez besoin (fourni par les
noyaux Linux).
-<item><package>syslog-ng</package> pour envoyer les logs du pot de miel
+<item><package>syslog-ng</package> pour envoyer les journaux du pot de miel
vers un serveur syslog distant.
<item><package>snort</package> pour configurer la capture de tout le trafic
@@ -789,12 +903,6 @@
<item><package>tinyhoneypot</package> pour mettre en place un serveur
pot de miel simple avec des services factices.
-<!-- This one is not packaged and I don't believe it's useful anyway:
-<item>The Deception Toolkit, which uses deception to counter attacks.
-Homepage: <url id="http://www.all.net/dtk/"; name="Deception Toolkit">
--->
-
-
</list>
<p>Si vous ne pouvez pas utiliser des systèmes de réserve pour
@@ -803,9 +911,9 @@
disponible dans <prgn>xen</prgn> ou <prgn>uml</prgn> (User-Mode-Linux).
Si vous choisissez cette route, vous devrez modifier votre noyau soit
avec <package>kernel-patch-xen</package>, soit avec
-<package>kernel-patch-uml</package>.
+<package>kernel-patch-uml</package>, ou encore installer l'un des noyaux
+précompilés offerts depuis Debian Lenny.
-
<p>Vous pouvez en lire plus sur la construction des pots de miel dans l'excellent
article de Lance Spizner
<url id="http://www.net-security.org/text/articles/spitzner/honeypot.shtml";
Reply to: