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

Securing Debian Manual
Chapitre 11 - Foire Aux Questions (FAQ)


Ce chapitre introduit quelques questions qui reviennent souvent sur la liste de diffusion de sécurité. Vous devriez les consulter avant de poster sur la liste ou certains pourraient vous dire d'aller RTFM.


11.1 La sécurité dans le système d'exploitation Debian


11.1.1 Debian est-il plus sûr que X ?

Un système est aussi sûr que l'administrateur est capable de le rendre. Debian essaye d'installer les services d'une façon sûre par défaut et ne peut pas être aussi paranoïaque que d'autres systèmes exploitations qui installent tous les services désactivés par défaut. Toutefois, l'administrateur système a besoin d'adapter la sécurité du système à la politique de sécurité locale.


11.1.2 De nombreux bogues Debian sont listés dans bugtraq, cela le rend il plus vulnérable ?

Debian contient un certains nombres de paquetages et différents logiciels, probablement plus que certains systèmes d'exploitation propriétaires. Cela signifie qu'il y a un plus grand risque de trouver des logiciels proposant des failles de sécurité exploitable que sur certains systèmes contenant moins de logiciels.

Cependant, il y a de nombreux papiers consultatifs liés à l'audit de code source effectué sur des composants logiciels majeurs livrés dans Debian. Lorsque un de ces audits de code source fait ressortir une faille majeur, elle est réparée et un papier est envoyé aux listes telle que celle de Bug Traq.

Les bugs présents dans la distribution Debian affectent également d'autres vendeurs et d'autres distributions. Vérifiez la partie "Debian specific: yes/no" en haut de chaque document (DSA). Si il est inscrit "yes", cela signifie que seul Debian est affecté, si il est inscrit "no", c'est probablement que d'autres distributions sont aussi affectées.


11.1.3 Debian possède t'il une certification touchant à la sécurité?

Réponse courte : non.

Réponse longue : la certification coûte de l'argent et personne n'a attribué de ressources pour faire certifier la distribution Debian GNU/Linux à n'importe quel niveau que ce soit, par exemple, la Common Criteria. Si vous êtes intéressés par l'obtention d'une distribution GNU/Linux certifié, essayez de fournir les ressources pour que cela devienne possible.


11.1.4 Existe-t-il un programme de durcissement pour Debian ?

Oui. Bastille Linux, orienté à la base vers certaines distributions Linux(RedHat et Mandrake), fonctionne actuellement sur Debian. La planification prévoit d'intégrer les changements à la version en amour, dans tous les cas, le paquetage Debian est nommé, bien sûr, bastille.

Certains pensent, cependant, qu'un outil de durcissement n'élimine pas la nécessité d'une bonne administration.


11.1.5 Comment sécuriser davantage un service XYZ dans la Debian ?

Les informations disponibles dans ce document vous permettront de rendre certains services (FTP, Bind) plus sécurisés dans la Debian GNU/Linux. Toutefois, pour les services non abordés ici, vous pouvez vérifier la documentation des programmes ou les informations générales Linux. La plupart des directives concernant la sécurité pour les systèmes Unix peut également s'appliquer à la Debian. Ainsi, la sécurisation d'un service X dans la Debian revient, la plupart du temps, à sécuriser un service comme pour n'importe quelle autre distribution Linux (ou Unix, peu importe).


11.1.6 Les paquets Debian sont-ils tous sûrs ?

L'équipe de sécurité Debian ne peut pas analyser tous les paquets inclus dans Debian pour tester des potentielles failles de sécurité, puisque il n'y a tout simplement pas assez de ressources pour auditer le code source de l'ensemble du projet. Cependant Debian bénéficie des audits de code source réalisés en amont par des développeurs d'autres projets comme Linux Kernel Security Audit Project or the Linux Security-Audit Project.

Au fond, un développeur Debian peut distribuer un trojan dans un paquet et il n'y a pas moyen de le vérifier. Même s'il était introduit dans la Debian, il serait impossible de couvrir toutes les situations imaginables dans lesquelles le trojan pourrait agir.

Cela colle a la clause aucune garanties de la license. Dans tous les cas, les utilisateurs Debian peuvent être assurés que le code stable rassemble une large audience et que la plupart des problèmes seront découvert de pendant l'utilisation (si problème il y a). Il n'est pas recommandé d'installer des logiciels non testés dans un système correct (si vous n'êtes pas en mesure de fournir un nécessaire audit de code). Pour finir, si des failles de sécurités étaient incluses dans la distribution, le processus permettant de les inclure (utilisation de signature numérique) assure que le problème pourra être remonté jusqu'au développeur, et que le projet Debian ne prend pas cela à la légère.


11.1.7 Les utilisateurs et les groupes du système d'exploitation


11.1.7.1 Tous les utilisateurs systèmes sont-ils nécessaires ?

Oui et non. Debian est livrée avec certains utilisateurs prédéfinis (id < 99 comme décrit dans Debian Policy) afin de faciliter l'installation de nouveaux services (ils sont déjà lancés par l'utilisateur approprié). Si vous n'avez pas l'intention d'en installer de nouveaux, vous pouvez supprimer sereinement ces utilisateurs qui ne possèdent aucun fichier sur votre système et qui n'exécutent aucun service.

Vous pouvez facilement trouver les utilisateurs ne possédant aucun fichier en exécutant la commande suivante (soyez sûr de l'exécuter en tant que root, étant donné qu'un utilisateur ordinaire pourrait ne pas avoir les droits nécessaires pour accéder à certains répertoires sensibles):

     cut -f 1 -d : /etc/passwd |
     while read i; do find / -user "$i" | grep -q . && echo "$i"; done

Ces utilisateurs sont fournis par base-passwd. Vous trouverez dans sa documentation plus d'informations sur la manière dont ces utilisateurs sont gérés dans Debian..

La liste des utilisateurs par défaut (avec un groupe correspondant):

Autres groupes qui n'ont pas d'utilisateur associé :


11.1.7.2 Quelle est la différence entre les groupes adm et staff ?

Le groupe 'adm' rassemble les administrateurs et est utile afin de le autoriser à lire les journaux d'activités sans avoir à utiliser su. Le groupe 'staff' est profitable pour des personnes du genre administrateur système helpdesk/junior et leur offre la capacité de faire des choses dans /usr/local et de créer des répertoires dans home.


11.1.8 Question concernant les services et les ports ouverts


11.1.8.1 Pourquoi tous les services sont-ils activés lors de l'installation ?

Ceci est juste une approche qui est, d'un côté, une sécurité présente et d'un autre coté l'utilisation amicale. Contrairement à OpenBSD, qui désactive tous les services à moins que ceux-ci soit activés par l'administrateur, Debian GNU/Linux activera tous les services installés à moins de les désactiver(see Désactivation de services daemon, Section 3.6.1 pour plus d'information). Après tout, vous avez installés ces services de votre propre chef, n'est ce pas?

Il y a un grand nombre de discussions sur les mailings listes Debian (sur debian-devel et debian-security) à propos de ce que doit être l'installation standart. Cependant, il n'y a pas de consensus à ce jour (10 mars 2002) sur la solution à adopter.


11.1.8.2 Puis-je retirer inetd?

Inetd n'est pas aisé à retirer étant donné que netbase dépend du paquet qui le fourni à savoir (netkit-inetd. Si vous voulez le retirer, vous pouvez soit le désactiver (voir Désactivation de services daemon, Section 3.6.1 ou retirer le paquet en utilisant le paquet equivs à la place.


11.1.8.3 Pourquoi ai-je le port 111 d'ouvert ?

Le port 111 est mappeur de port sunrpc, il est installé par défaut dans toutes les installations de base d'un système Debian puisqu'il est requit pour savoir lorsque le programme d'un utilisateur a besoin de RPX pour fonctionner correctement. Dans tous les cas, il est utilisé en grande partie pour NFS. Si vous n'en avez pas besoin retirer le comme décrit dans Désactivation des services RPC, Section 5.14.


11.1.8.4 Pour quel usage est employé identd (113)?

Identd est employé par les administrateurs pour fournir les détails userid aux systèmes distants qui veulent savoir qui est la personne responsable pour une connexion donnée sur votre machine. Cela inclus notamment les serveurs mail, FTP et IRC, cependant, il peut être utilisé pour remonter l'utilisateur qui attaque un système distant par l'intermédiaire de votre machine.

Pour suivre une longue discussion à ce propos, voir mailing list archives, basiquement, si vous ne savez pas à quoi cela sert, ne l'activez pas. Mais si vous le bloquez par un pare-feu, s'il vous plaît créez une règle de rejet et non pas une règle de déni, autrement la communication pourrait continuer jusqu'à réception d'une expiration de délai (timeout)(see reject or deny issues).


11.1.8.5 J'ai vérifié et j'ai le port suivant (XYZ) d'ouvert, puis-je le fermer ?

Bien sûr que vous pouvez, les ports que vous laissez ouvert doivent adhérer à la politique de votre site concernant les services publiques disponibles pour les autres systèmes. Vérifiez s'ils sont ouvert par inetd (voir Désactivation des services inetd, Section 3.6.2) ou par d'autres paquets installés et prenez les mesures adéquates (configuration d'inetd, suppression du paquet, éviter qu'il démarre au démarrage, ...)


11.1.8.6 J'ai retiré les services de /etc/services, suis-je ok ?

Non, le fichier /etc/services fourni juste une cartographie d'un nom virtuel à un numéro de port donné, la suppression des noms ne va pas (en général) prévenir les services d'être lancés. Certains daemons ne se lanceront pas si /etc/services est modifié mais ce n'est pas dans la norme et ce n'est pas la manière recommandée de faire. Pour ceci voir Désactivation de services daemon, Section 3.6.1.


11.1.9 J'ai perdu mon mot de passe et je ne peux plus accéder au système !

Les démarches à prendre afin de récupérer votre système dépend si vous avez ou pas appliqué les différentes procédures concernant la limitation d'accès à Lilo et au BIOS.

Si vous les avez limités tous les deux. Vous devez désactiver les fonctionnalités du BIOS (démarrer uniquement depuis le disque dur) avant de commencer, si vous avez également oublier votre mot de passe pour le BIOS, vous devrez ouvrir votre système et retirer manuellement la pile du BIOS.

Si vous avez des CD-Rom ou des disquettes de démarrage, vous pouvez :

Ceci retirera le mot de passe root. Vous pouvez démarrer le système et vous connecter en tant que root (avec un mot de passe vide) depuis le prompt login:. Ceci fonctionnera ainsi jusqu'à ce que vous ayez configuré le système plus solidement, par exemple, vous autorisez des utilisateurs avec des mots de passe nul et le root peut se loguer à partir de la console.

Si vous avez aussi introduit ces caractéristiques, vous devrez entrer en utilisateur unique. LILO nécessite de n'avoir aucune restriction, si vous en avez mis en place relancer lilo après le reset du root sus-mentionné. C'est rusé puisque votre /etc/lilo.conf devra être modifié pour obtenir un système de fichier / qui est un disque virtuel et non un réel disque dur.

Une fois que LILO n'est plus restreint, vous pouvez:


11.2 Mon système est vulnérable !


11.2.1 J'ai souffert d'une intrusion, que dois-je faire ?

Lire ce document et prendre les mesures appropriées récapitulés ici. Si vous avez besoin d'aide, vous pouvez utiliser debian-security@lists.debian.org pour demander conseil sur la manière de rétablir/raccommoder votre système.


11.2.2 Comment puis-je dépister une attaque ?

En regardant les logs (s'ils n'ont pas été modifiés), en utilisant un système de détection d'intrusion (voir Mise en place d'un système de détection d'intrusion, Section 9.1), traceroute, whois et outils similaires (incluant des analyses légales) vous pouvez rechercher la source de l'attaque. La manière dont vous devez réagir sur ces information dépend uniquement de vos règles de sécurité, et de ce que vous considérez comme une attaque Un scan distant est il une attaque? Un test de failles de sécurité est il une attaque?


11.2.3 le program X dans Debian est vulnérable, que dois-je faire?

Tout d'abord, prenez un moment pour regarder si la vulnérabilité a été annoncée sur les mailing listes publiques de sécurité (comme Bugtraq) ou autre forums. L'équipe de sécurité Debian se met à jour à l'aide de ces listes, ils sont donc peut être déjà conscient du problème. Ne lancez pas d'autres actions si vous avez vu paraître l'annonce sur http://security.debian.org.

Si vous n'avez rien vu de cela, envoyez s'il vous plaît sur les paquets affectés avec une description de la vulnérabilité rencontrée aussi détaillée que possible (la preuve par un code conçu est aussi bienvenue) à security@debian.org qui vous mettra en rapport avec l'équipe de sécurité.


11.2.4 Le numéro de version pour un paquet indique que j'utilise une version vulnérable!

Au lieu de mettre à jour une nouvelle version nous appliquons la rustine de sécurité à la version présente dans la version stable. La raison pour laquelle nous agissons ainsi est simple. Elle permet d'assurer qu'une version a le moins de changement possible, de cette manière les choses ne changeront pas ou ne se briseront pas et ce dû à une mise à jour de sécurité. Vous pouvez vérifier que vous utilisez une version sécurisée de votre paquet en regardant le changelog du paquet ou en comparant (version antérieure -slash- version Debian) exactement le numéro de version avec celui indiqué dans le journal de sécurité Debian (Debian Security Advisory).


11.2.5 J'ai trouvé des utilisateurs utilisant 'su' dans mes logs.

Vous pouvez trouver des lignes comme celles-ci dans vos logs:

     Apr  1 09:25:01 server su[30315]: + ??? root-nobody
      Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (uid=0)

Ne vous inquiétez pas trop, vérifiez d'abord si ceci n'est pas dû au travail d'un job placé dans la cron (habituellement /etc/cron.daily/find ou logrotate):

     $ grep 25 /etc/crontab
     25 6    * * *   root    test -e /usr/sbin/anacron || run-parts --report
     /etc/cron.daily
     $ grep nobody /etc/cron.daily/*
     find:cd / && updatedb --localuser=nobody 2>/dev/null

11.2.6 Logiciels spécifiques


11.2.6.1 Proftpd est vulnérable à une attaque du type "Denial of Service"

Ajouter DenyFilter \*.*/ à votre fichier de configuration, pour plus d'informations voir http://www.proftpd.org/critbugs.html.


11.3 Questions concernant l'Equipe Sécurité Debian


11.3.1 Qu'est ce qu'un rapport de sécurité Debian (Debian Security Advisory (DSA))

C'est l'information envoyée par l'Equipe de Sécurité Debian (voir ci-dessous) informant qu'une mise à jour de sécurité concernant une vulnérabilité est disponible pour le système d'exploitation Debian. Les DSAs signés sont envoyés aux mailing listes publique et postés sur le site Debian (sur la page de garde et sur security area).

Les DSAs incluent les informations sur les paquets affectés, le bug découvert et l'endroit où récupérer les paquets mis à jour (ainsi que leurs sommes MD5).


11.3.2 La signature sur le rapport Debian ne se vérifie pas correctement!

C'est la plupart du temps un problème de fin de message. La liste debian-security-announce a un filtre qui autorise uniquement le poste des messages ayant une signature correcte appartenant à un des membres de l'équipe de sécurité.

D'autre part, certains logiciels de courrier changent la fin des messages ce qui rompt la signature. Assurez-vous pour cela que votre logiciel ne fait aucun encodage ou décodage MIME, ou de conversion de taulation/espace.

Des coupables connus sont fetchmail (avec l'option mimedecode activée) et formail (pour procmail 3.14 uniquement).


11.3.3 Comment les incidents sont-ils gérés dans Debian ?

Dès que l'Equipe Sécurité reçoit une notification d'un incident, un ou plusieurs membres l'inspecte et délibère si Debian/stable est vulnérable ou pas. Si votre système est vulnérable, un travail est entrepris pour résoudre le problème. Le responsable du paquet est également contacté s'il n'a pas déjà contacter l'Equipe Sécurité. Finalement, la solution est testée et de nouveaux paquets sont préparés qui sont ensuite compilés sur toutes les architectures stables et mis à disposition après coup. Après que toutes ces tâches soient terminées un "Debian Security Advisory (DSA)" est envoyé sur les listes de diffusions publiques.


11.3.4 Combien de temps faudra-t-il à debian pour résoudre la vulnérabilité XXXX?

L'analyse du temps que prend l'Equipe de Sécurité Debian pour envoyer un rapport et produire un paquet réparé à partir du moment où une vulnérabilité est connue, démontre qu'il faut un temps minimal avant que cette vulnérabilité ne soit réparée dans la distribution stable.

Un rapport published in the debian-security mailinglist montre que durant l'année 2001, il fallait un temps moyen de 35 jours à l'Equipe de Sécurité Debian pour sécuriser les vulnérabilités découvertes. Cependant, plus de 50% de ces vulnérabilités ont été réparé dans un espace de dix jours, et plus de 15% de celles-ci ont été réparé le jour même de la sortie du rapport.

Cependant, quand ils posent cette question les gens ont tendance à oublier que:


11.3.5 Comment est assurée la sécurité pour les versions testing et unstable?

La réponse courte est: il n'y en a pas. Testing et unstable évoluent très rapidement et l'équipe de sécurité n'a pas les ressources nécessaires pour les supporter correctement. Si vous désirez un serveur stable et sécurisez nous vous encourageons fortement à rester sur une version stable.

Cependant, dans les faits, unstable est mis à jour très rapidement puisque les mises à jour de sécurité sont plus rapidement disponible en amont (Pour les autres versions, comme celles introduites dans la stable, il est nécessaire de faire un report).


11.3.6 Pourquoi n'y a t'il pas de miroir officiel de security.debian.org?

A: Le but de security.debian.org est de mettre à disposition les mises à jour de sécurité aussi vite et facilement que possible. Les mirrors ajouteraient un niveau de complexité qui n'est pas nécessaire et qui provoquerait une certaine frustration en cas de non mise à jour.


11.3.7 Comment joindre l'équipe Sécurité ?

A: Les informations de sécurité peuvent être envoyées à security@debian.org, qui est lu par tous les développeurs Debian. Si vous disposez d'informations sensible, utilisez team@security.debian.org qui n'est lu que par les membres de l'équipe de sécurité. Si vous le désirez, le mail peut être chiffré à l'aide de la clef de contact de la sécurité Debian(key ID 363CCD95).


11.3.8 Quelles différence existe-t-il entre security@debian.org et debian-security@lists.debian.org?

Lorsque vous envoyez des messages à security@debian.org, ceux-ci sont envoyés aux mailing listes des développeurs (debian-private) à laquelle tous les développeurs Debian sont inscrits; tous les envois à cette liste sont tenus confidentiels (i.e. ne sont pas archivés sur le site public). Debian-security@lists.debian.org est une mailing liste publique, ouverte à tous ceux qui le désirent, et des archives sont disponible pour la recherche à partir du site Internet.


11.3.9 Comment puis-je aider l'équipe sécurité Debian ?

Dans tous les cas, s'il vous plaît, passez en revue chaque problème avant de les rapporter à security@debian.org. Si vous êtes capable de fournir des rustines, cela accélérera le processus. Ne faites pas juste suivre le courrier de bugtraq étant donné qu'il a déjà été reçu. Fournir tout autre information est cependant toujours une bonne idée.


11.3.10 Qui compose l'Equipe de Sécurité ?

l'Equipe de Sécurité Debian se résume à cinq membres et deux secrétaires. l'Equipe Sécurité elle-même invite tout le monde à se joindre à l'équipe.


11.3.11 l'Equipe Sécurité Debian vérifie-t-elle chaque nouveau paquet dans Debian ?

Non, l'équipe securité Debian ne vérifie pas tous les paquets et il n'existe pas de vérification automatique (lintian) afin de déceler de nouveaux paquets malveillants étant donné que ces vérifications sont plutôt impossible à détecter automatiquement. Les développeurs, toutefois, sont complètement responsables du logiciel qui est introduit dans Debian et aucun logiciel n'est introduit tant qu'il n'est pas signé par des développeurs habilités. Ceux-ci ont la responsabilité d'analyser le logiciel qu'ils maintiennent et la sécurité afférante. <--! Attente d'une meilleure traduction. Fait. jpg -->


11.3.12 Je possède un ancienne version de Debian, la sécurité est-elle supportée ?

Malheureusement non, l'Equipe Sécurité Debian ne peut pas gérer les deux versions stables (officieusement elle ne gère pas non plus la version unstable) et d'autres anciennes versions. Cependant, vous pouvez espérer des actualisations de la sécurité pour une période limitée juste après la sortie de la nouvelle distribution Debian.


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

Securing Debian Manual

2.8 14 febrero 2004Mon, 18 Nov 2002 23:13:42 +0100

Javier Fernández-Sanguino Peña jfs@computer.org