[Relecture] securing-howto
Bonsoir
J'ai l'intention de relire le securing-howto.
Voila déjà ma relecture pour les chapitres 7, 8 et 9
eric
--- sec-tools.sgml 2005-04-20 21:45:34.000000000 +0200
+++ sec-tools.relu.sgml 2005-04-20 22:00:37.000000000 +0200
@@ -150,10 +150,10 @@
<p>Un réseau privé virtuel (VPN) est un groupe de deux ou plusieurs ordinateurs,
habituellement connecté à un réseau privé avec un accès réseau public limité,
-qui communiquent de façon sécurisée par un réseau public. Les VPN peuvent
+qui communiquent de façon sécurisée via un réseau public. Les VPN peuvent
connecter un seul ordinateur à un réseau privé (client-serveur) ou un réseau
local (LAN) distant à un réseau privé (serveur-serveur). Les VPN incluent
-souvent l'utilisation de chiffrage, une authentification forte des utilisateurs
+souvent l'utilisation du chiffrage, une authentification forte des utilisateurs
ou hôtes distants et des méthodes pour cacher la topologie du réseau privé.
<p>Debian fournit un nombre assez important de paquets pour mettre en place
@@ -221,8 +221,8 @@
<p>Vous devez cependant appliquer le correctif noyau fourni par le paquet
<package>kernel-patch-mppe</package> qui fournit le module pp_mppe pour pppd.
-<p>Prenez également en compte que le chiffrag dans pptp vous force à stocker les
-mots de passer utilisateur en clair et que le protocole MS-CHAPv2 contient des
+<p>Prenez également en compte que le chiffrage dans pptp vous force à stocker les
+mots de passe utilisateur en clair et que le protocole MS-CHAPv2 contient des
<url id="http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/";
name="failles de sécurité connues">.
@@ -287,7 +287,7 @@
<p>
Il n'y a pas beaucoup d'outils antivirus dans Debian GNU/Linux, probablement
-car les utilisateurs de GNU/Linux ne sont pas submergés réellement par
+car les utilisateurs de GNU/Linux ne sont pas réellement submergés par
les virus. Le modèle de sécurité UN*X fait une distinction entre les processus
privilégiés (root) et les processus appartenant aux utilisateurs, c'est pourquoi
un exécutable « hostile » reçu ou créé par un utilisateur et ensuite
@@ -295,7 +295,7 @@
autre manière le système entier. Il y a eu, toutefois, des vers et virus pour GNU/Linux même
s'il n'y pas (encore) eu de virus qui se soient étendus sur les
distributions Debian. Dans tous les cas, les administrateurs peuvent
-vouloir de mettre en place des passerelles antivirus pour se protéger contre les
+vouloir mettre en place des passerelles antivirus pour se protéger contre les
virus affectant d'autres systèmes plus vulnérables dans leur réseau.
<p>Debian GNU/Linux fournit à l'heure actuelle les outils suivants pour mettre
--- infrastructure.sgml 2005-04-20 21:45:33.000000000 +0200
+++ infrastructure.relu.sgml 2005-04-20 21:34:13.000000000 +0200
@@ -53,7 +53,7 @@
<sect id="dsa">Alertes de sécurité Debian
<p>Les alertes de sécurité Debian sont effectuées à chaque fois qu'une faille
-est découverte affectant un paquet Debian. Ces alerte, signées par l'un des
+est découverte affectant un paquet Debian. Ces alertes, signées par l'un des
membres de l'équipe de sécurité, incluent des informations sur les versions
touchées ainsi que l'emplacement des mises à jour et leurs MD5sums. Ces
informations sont :
@@ -220,7 +220,7 @@
id="security.debian.org:/org/security.debian.org/queue/unchecked"> ou
<url id="ftp://security.debian.org/pub/SecurityUploadQueue";>
avec un correctif approprié voient leur signature vérifiée dans les quinze
-minutes après l'envoir, une fois ceci fait, ils sont ajoutés à la liste des
+minutes après l'envoie, une fois ceci fait, ils sont ajoutés à la liste des
autoconstructeurs (qui n'est plus une exécution d'archive journalière). Les
paquets sont donc automatiquement construits pour <em>toutes</em> les
architectures trente minutes ou une heure après leur envoi. Cependant, les mises
@@ -228,7 +228,7 @@
responsables de paquets car, dans certains cas, avant d'être publiées, elles
doivent attendre de pouvoir être plus testés, qu'une alerte soit rédigée ou
attendre une semaine ou plus pour éviter de publier le défaut jusqu'à ce que
-tous les vendeurs aient eu une chance raisonnable de la corriger.
+tous les vendeurs aient eu une chance raisonnable de le corriger.
<p>L'archive d'envoi de sécurité fonctionner donc de la façon suivante (dénommée
<em>"Accepted-Autobuilding"</em>) :
@@ -258,7 +258,7 @@
système Debian et déplacé dans queue/accepted,
<item>quand l'équipe de sécurité trouve les paquets acceptable (i.e., ils sont
- correctement construits pour toutes les architectures pertinentes et ils
+ correctement construits pour toutes les architectures pertinentes et qu'ils
corrigent le trou de sécurité et n'introduisent pas de nouveau problème
par eux-même), ils exécutent un script qui :
@@ -281,7 +281,7 @@
<p>Cette procédure, auparavant fait à la main, a été testé et mise en place
pendant l'étape de gel de Debian 3.0 woody (juillet 2002). Grâce à cette
architecture, l'équipe de sécurité a pu avoir des paquets mis à jour pour les
-problèmes d'Apache et d'OpenSSH issues pour toutes les architectures supportées
+problèmes d'Apache et d'OpenSSH pour toutes les architectures supportées
(presque vingt) en moins d'un jour.
<sect1>Le guide du développeur aux mises à jour de sécurité
@@ -301,7 +301,7 @@
<sect2>Se coordonner avec l'équipe de sécurité
-<p>Si un développeur apprend un problème de sécurit, soit dans son paquet ou
+<p>Si un développeur apprend un problème de sécurité, soit dans son paquet ou
dans celui de quelqu'un d'autre, il devrait toujours contacter l'équipe de
sécurité (à team@security.debian.org). Il suivent les problèmes de sécurité
existants, ils peuvent aider les responsables avec des problèmes de sécurité ou
@@ -309,7 +309,7 @@
et maintiennent security.debian.org.
<p>Veuillez noter que les alertes de sécurité ne sont effectuées que pour des
-distributions de version, pas pour testing, unstable (voir <ref id="sec-unstable">)
+distributions stable, pas pour testing, ni pour unstable (voir <ref id="sec-unstable">)
ou d'anciennes distributions (voir <ref id="sec-older">).
<sect2>Prendre connaissance des problèmes de sécurité
@@ -368,7 +368,7 @@
possible. Les personnes s'attendent à un comportement identique dans une version
lorsque celle-ci est diffusée, donc tout changement qui est fait est susceptible
de casser le système de quelqu'un. Ceci est spécialement vrai pour les
-bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI, quelque
+bibliothèques : assurez-vous de ne jamais changer l'API ou l'ABI, aussi
minimal que soit le changement.
<p>
@@ -479,7 +479,7 @@
</footnote>
-<p>À ce jour (février 2003), Debian ne fournit pas de paquets
+<p>À ce jour (février 2004), Debian ne fournit pas de paquets
signés pour la distribution et la version <em>woody</em> (3.0) n'intègre pas cette fonctionnalité.
Il existe une solution pour les paquets signés qui sera, espérons-le, fournie dans les
prochaines versions (<em>sarge</em>).
@@ -522,7 +522,7 @@
souple que de signer chaque paquet un par un, mais peut être combiné
également avec ce schéma suivant (voir ci-dessous).
-<p>La signature de paquets a été abordée dans la Debian depuis pas mal de temps déjà,
+<p>La signature de paquets a été abordée dans Debian depuis pas mal de temps déjà,
pour plus d'informations vous pouvez lire :
<url id="http://www.debian.org/News/weekly/2001/8/";> et
<url id="http://www.debian.org/News/weekly/2000/11/";>.
@@ -572,7 +572,7 @@
<!-- à revoir (fbo)-->
<p>
-Ce code exmple, renommé en <prgn>apt-release-check</prgn>, devrait être
+Ce code exemple, renommé en <prgn>apt-release-check</prgn>, devrait être
utilisé de la manière suivante :
<example>
# apt-get update
@@ -607,7 +607,7 @@
</list>
<p>Ceci est le code exemple pour <prgn>apt-check-sigs</prgn>, la dernière
-version peut être récupérée de <url
+version peut être récupérée à l'adresse <url
id="http://people.debian.org/~ajt/apt-check-sigs";>.
Ce code est actuellement en bêta, pour plus d'informations, lisez
<url id="http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html";>.
--- before-compromise.sgml 2005-04-20 21:45:33.000000000 +0200
+++ before-compromise.relu.sgml 2005-04-20 21:33:47.000000000 +0200
@@ -6,7 +6,7 @@
<sect 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é bouchés à
+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
@@ -65,14 +65,14 @@
à l'administrateur système.
<p>Notez que vous pouvez vouloir vérifier la version de distribution comme
-décrant dans <ref id="check-releases">, si vous avez l'intention de mettre à
+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.
<sect1>Utilisez Tiger pour vérifier automatiquement les mises à jour de sécurité
-<p>Si vous recherchez un outil pour vérifier rapidement et donner un compte
+<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
@@ -93,7 +93,7 @@
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 mises à jour régulièrement.
+signatures doivent être mises à jour régulièrement.
<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 à
@@ -136,7 +136,7 @@
<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
+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>
@@ -145,8 +145,8 @@
<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 un courrier (à l'expéditeur désigné par <tt>Tiger_Mail_RCPT</tt> dans le
-fichier <file>/etc/tiger/tigerrc</file>) les nouveaux paquets :
+enverra par courrier (à l'expéditeur désigné par <tt>Tiger_Mail_RCPT</tt> dans le
+fichier <file>/etc/tiger/tigerrc</file>) la liste nouveaux paquets :
<example>
# Vérifie les mesures de sécurité Debian chaque jour à 1h00
@@ -173,7 +173,7 @@
<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és constamment aux applications fournies, ainsi
+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.
@@ -228,8 +228,8 @@
<sect1>Mises à jour automatiques dans un système Debian GNU/Linux
-<p>Tout d'abord, les mises à jour automatiques ne sont complètement recommandées
-car les administrateurs devraient vérifier les DSA et comprendre l'imact de
+<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
@@ -239,7 +239,7 @@
<item>Configurer <prgn>apt</prgn> pour que les paquets que vous ne voulez pas
mettre à jour restent à leur version actuelle, soit avec
-la fonctionnalité de <em>pinning</em> d'<prgn>apt</prgn>, soit en les marquant comme
+la fonctionnalité d'étiquetage 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
@@ -303,13 +303,13 @@
<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 de pinning ainsi
+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
+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
@@ -411,7 +411,7 @@
id="http://www.prelude-ids.org"; name="Prelude">.
<p>
-Le paquet <package>snort</package> de Debian est activé avec de nombreuses vérifications de sécurité
+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
@@ -424,10 +424,10 @@
signés) fournis par le responsable à
<url id="http://people.debian.org/~ssmeenk/snort-stable-i386/";>.
-<p>Il y a d'autres plus simples outils qui peuvent être utilisés pour détecter
+<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 que<package>ippl</package> ou
+D'autres outils comme que <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>).
@@ -438,7 +438,7 @@
<sect1>La détection d'intrusion fondée sur hôte
-<p>La détection d'intrusion fondée sur l'hôte implique de charger des logiciel
+<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
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
@@ -485,8 +485,8 @@
<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 proce, des fichiers,
-répertoires et même des connexions sans modifier les codes
+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
@@ -572,7 +572,7 @@
</list>
<p>
-Si vous n'avez pas l'utilité de toutes ces fonctionnalités de noayau sur votre
+Si vous n'avez pas l'utilité de toutes ces fonctionnalités du 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
Reply to: