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

Manuel de sécurisation de Debian
Chapitre 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-elle plus sûre que X ?

Un système est aussi sûr que l'administrateur est capable de le rendre. Debian essaie d'installer les services d'une façon sûre par défaut, mais elle n'est peut-être pas aussi paranoïaque que d'autres systèmes d'exploitation 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.

Pour une liste des données concernant les failles de sécurité pour plusieurs systèmes d'exploitation, voir http://securityfocus.com/vulns/stats.shtml. Est-ce que ces données sont utiles ? Le site liste plusieurs facteurs à considérer pour l'interprétation des données et avertit que les données ne peuvent être utilisées pour comparer les failles de l'un des systèmes d'exploitation par rapport à un autre.[60] Conservez également à l'esprit que certaines failles Bugtraq concernant Debian ne s'appliquent qu'à la branche unstable.

11.1.1.1 Est-ce que Debian est plus sécurisée que d'autres distributions Linux (comme Red Hat, SuSE, etc.)?

Il n'y a pas de grandes différences entre les distributions Linux, à l'exception de l'installation de base et du système de gestion des paquets. La plupart des distributions partagent une grande partie des mêmes applications, les différences étant seulement dans les versions de ces applications livrées avec la version stable de la distribution. Par exemple, le noyau, Bind, Apache, OpenSSH, XFree, gcc, zlib, etc sont tous communs entre les distributions Linux.

Par exemple, Red Hat a été joué de malchance et a livré une version stable quand la version de foo était la 1.2.3, version dans laquelle il a été trouvé par la suite un trou de sécurité. Debian, d'un autre côté, a été plus chanceuse de livrer foo 1.2.4, qui incorpore la correction du bogue. Cela a été le cas avec le gros problème de rpc.statd il y quelques années.

Il y a beaucoup de collaboration entre les équipes de sécurité respectives des majeures distributions Linux. Les mises à jour de sécurité connues sont rarement, si même jamais, laissés non corrigées par un vendeur d'une distribution. La connaissance d'une faille de sécurité n'est jamais conservée au détriment d'un autre vendeur de distribution, tout comme les corrections sont habituellement coordonnées en amont ou par le CERT. Le résultat de cela est que les mises à jour de sécurité nécessaire sont habituellement diffusés en même temps et que la sécurité relative des différentes distributions est très semblable.

L'un des principaux avantages de Debian concernant la sécurité est la facilité des mises à jour du système par l'utilisation d'apt. Voici quelqu'uns des autres aspects de la sécurité dans Debian à considérer :

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

Debian contient un grand nombre de paquets et différents logiciels (et s'aggrandissant), probablement plus que beaucoup de 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é exploitables que sur certains systèmes contenant moins de logiciels.

De plus en plus de personnes examinent le code source à la recherche de failles. Il y a de nombreux papiers consultatifs liés à des audits de code source effectués 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 une alerte est envoyée aux listes telle que celle de Bug Traq.

Les bogues 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).

11.1.3 Debian possède-t-elle une certification touchant à la sécurité ?

Réponse courte : non.

Réponse longue : la certification coûte de l'argent (particulièrement, une certification de sécurité sérieuse 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é par l'obtention d'une distribution GNU/Linux certifiée, essayez de fournir les ressources pour que cela devienne possible.

Il existe actuellement au moins deux distributions Linux certifiées à différents niveaux EAL. Veuillez noter que certains des tests CC sont en cours d'intégration dans le Linux Testing Project qui est disponible dans Debian dans le paquet ltp.

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

Oui. Bastille Linux, orienté à la base vers certaines distributions Linux (Red Hat et Mandrake), fonctionne actuellement sur Debian. Des étapes sont prévues pour intégrer les changements de la version amont dans le paquet Debian nommé bastille.

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

11.1.5 Je veux fournir le service XYZ, lequel dois-je choisir ?

L'une des grandes forces de Debian est la grande variété de choix disponibles entre les paquets fournissant la même fonctionnalité (serveurs DNS, serveurs de messagerie, serveurs FTP, serveurs web, etc.). Ceci peut être déroutant pour l'administrateur débutant lorsqu'il essaie de déterminer quel est le bon outil pour lui. Le mieux pour une situation donnée dépend d'un équilibre entre les fonctionnalités et la sécurité dont vous avez besoin. Voici quelques questions à vous poser pour décider entre des paquets semblables :

11.1.6 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 à 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.7 Comment supprimer toutes les informations de version pour les services ?

Si vous voulez pas ques des utilisateurs se connectent à votre démon POP3, par exemple, et récupèrent des informations à propos de votre système, vous pouvez vouloir supprimer (ou modifier) les informations de version affichées aux utilisateurs. [62] Faire cela dépend du logiciel que vous utilisez pour un service donné. Par exemple, dans postfix, vous pouvez placer votre bannière SMTP dans /etc/postfix/main.cf : 

      
       smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

D'autres logiciels ne sont pas aussi faciles à changer. Ssh devra être recompilé pour pouvoir changer la version qu'il affiche. Faites attention à ne pas supprimer la première partie (SSH-2.0) de la bannière, car les clients l'utilisent pour identifier quel(s) protocole(s) est(sont) supporté(s) par votre paquet.

11.1.8 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 par des développeurs amont.

De fait, un développeur Debian pourrait distribuer un trojan dans un paquet et il n'y a pas moyen de le vérifier. Même s'il était introduit dans une branche Debian, il serait impossible de couvrir toutes les situations imaginables dans lesquelles le trojan pourrait agir. C'est pourquoi Debian a une clause de licence de « non-garantie ».

Cependant, les utilisateurs Debian peuvent être assurés que le code stable rassemble une large audience et que la plupart des problèmes seront découverts pendant l'utilisation. Il n'est pas recommandé d'installer des logiciels non testés dans un système critique (si vous n'êtes pas en mesure de fournir l'audit de code nécessaire). Dans tous les cas, si des failles de sécurités étaient incluses dans la distribution, le processus permettant d'inclure les paquets (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.9 Pourquoi certains fichiers journaux/fichiers de configuration sont-ils lisibles par tous les utilisateurs, est-ce que c'est sûr ?

Vous pouvez naturellement changer les permissions Debian par défaut de votre système. La règle actuelle concernant les fichiers journaux et les fichiers de configuration est qu'ils doivent être lisibles par tous les utilisateurs à moins qu'ils fournissent des informations sensibles.

Soyez attentifs si vous faites des modifications car :

FIXME: Vérifier si c'est écrit dans la Charte. Certains paquets (par exemple, les démons FTP) semblent nécessiter différentes permissions.

11.1.10 Pourquoi est-ce que /root/ (ou UserX) a 755 comme permissions ?

De fait, la même question s'applique pour tout autre utilisateur. Comme l'installation de Debian ne place aucun fichier dans ce répertoire, il n'y a aucune information sensible à y protéger. Si vous pensez que ces permissions sont trop laxistes pour votre système, vous pouvez les renforcer en 750. Pour les utilisateurs, veuillez lire Limiter l'accès aux informations d'autres utilisateurs, Section 4.10.12.1.

Ce file de la liste de diffusion de sécurité Debian contient plus d'informations sur ce problème.

11.1.11 Après l'installation de grsec/d'un pare-feu, j'ai commencé à recevoir beaucoup de messages de console ! Comment est-ce que je les supprimer ?

Si vous recevez des messages de console et que vous avez configuré /etc/syslog.conf pour les rediriger soit dans des fichiers, soit dans un TTY spécial, vous pouvez voir des messages envoyés directement à la console.

Le niveau par défaut de log de la console pour tout noyau donné est de 7, ce qui veut dire que tout message avec une priorité inférieure apparaîtra dans la console. Habituellement, les pare-feux (la règle LOG) et d'autres outils de sécurité logguent à des priorités inférieures à cette priorité et les messages sont donc envoyés directement à la console.

Pour réduire les messages envoyés à la console, vous pouvez utiliser dmesg (l'option -n option, voir dmesg(8)), qui examine et contrôle le tampon anneau du noyau. Pour corriger cela après le prochain redémarrage, changez /etc/init.d/klogd de : 

       KLOGD=""

à : 

       KLOGD="-c 4"

Utilisez un nombre plus faible pour -c si vous les voyez toujours. Une description des différents niveaux de log peut être trouvée dans /usr/include/sys/syslog.h: 

       #define LOG_EMERG   0  /* le système est inutilisable */
       #define LOG_ALERT   1  /* une action doit être entreprise immédiatement */
       #define LOG_CRIT    2  /* conditions critiques */
       #define LOG_ERR     3  /* conditions d'erreur */
       #define LOG_WARNING 4  /* conditions d'avertissement */
       #define LOG_NOTICE  5  /* normal, mais conditions significatives */
       #define LOG_INFO    6  /* informatif */
       #define LOG_DEBUG   7  /* messages de niveau déboguage */

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

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

Oui et non. Debian est livrée avec certains utilisateurs prédéfinis (id utilisateur (UID) < 99 comme décrit dans la charte Debian ou /usr/share/doc/base-passwd/README) afin de faciliter l'installation de certains services qui imposent d'être lancés par un utilisateur/UID approprié. Si vous n'avez pas l'intention d'en installer de nouveaux, vous pouvez supprimer sans problème ces utilisateurs qui ne possèdent aucun fichier sur votre système et qui n'exécutent aucun service. Dans tous les cas, le comportement par défaut est que les UID de 0 à 99 sont réservées dans Debian et les UID de 100 à 999 sont crées par des paquets lors de l'installation (et supprimées quand le paquet est purgé).

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.12.2 J'ai supprimé un utilisateur système ! Comment puis-je le récupérer ?

Si vous avez supprimé un utilisateur système et que vous n'avez pas de sauvegardes de vos fichiers password et group, vous pouvez essayez de récupérer de ce problème en utilisant update-passwd (voir update-passwd(8)).

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

Le groupe « adm » est habituellement celui des administrateurs et est utile afin de le autoriser à lire les journaux d'activités sans avoir à utiliser su. Le groupe « staff » est généralement 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.13 Pourquoi y a-t-il un nouveau groupe quand j'ajoute un nouvel utilisateur ? (ou pourquoi Debian attribue-t-elle un groupe à chaque utilisateur ?)

Le comportement par défaut dans Debian est que chaque utilisateur a son propre groupe privé. Le schéma traditionnel Unix place tous les utilisateurs dans le groupe users. Des groupes supplémentaires étaient créés et utilisés pour restreindre l'accès à des fichiers partagés associés aux différents répertoires de projets. La gestion des fichiers devenait difficile quand un seul utilisateur travaillait sur plusieurs projets car quand quelqu'un créait un fichier, ce dernier était associé au groupe primaire auquel il appartenait (c.-à-d. « users »).

Le schéma Debian résoud ce problème en attribuant à chaque utilisateur son propre groupe  ainsi avec un umask correct (0002) et le bit SETGID positionné dans un répertoire de projet donné, le groupe correcte est automatiquement attribué aux fichiers créés dans ce répertoire. Cela facilite le travail sur plusieurs projets car il n'y a pas besoin de changer les groupes ou les umask quand on travaille sur des fichiers partagés.

Vous pouvez, cependant, changer ce comportement en modifiant /etc/adduser.conf. Changez la variable USERGROUPS à « no », pour qu'aucun nouveau groupe ne soit créé quand un nouvel utilisateur est créé. Positionnez également USERS_GID vers le GID du groupe users auquel appartiennent tous les utilisateurs.

11.1.14 Question concernant les services et les ports ouverts

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

Ceci est juste une approche du problème qui est, d'un côté,d'avoir une sécurité présente et d'un autre coté l'utilisation facile. 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 (voir Désactivation de services démon, Section 3.6.1 pour plus d'informations). Après tout, vous avez installé ces services de votre propre chef, n'est-ce pas ?

Il y a un grand nombre de discussions sur les listes de diffusion 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 (mars 2002) sur la solution à adopter.

11.1.14.2 Puis-je retirer inetd ?

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

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

Le port 111 est le mappeur de port sunrpc, il est installé par défaut dans toutes les installations de base d'un système Debian puisqu'il est requis pour savoir lorsque le programme d'un utilisateur a besoin de RPC pour fonctionner correctement. Dans tous les cas, il est principalement utilisé pour NFS. Si vous n'en avez pas besoin, retirez-le comme décrit dans Sécurisation des services RPC, Section 5.13.

Dans les versions du paquet portmap après la version 5-5, vous pouvez en fait avoir le portmapper d'installé, mais n'écoutant que pour localhost (en modifiant /etc/default/portmap).

11.1.14.4 Quelle est l'utilisation d'identd (port 113) ?

Le service identd est un service d'authentification identifiant le propriétaire d'une connexion TCP/IP spécifique au serveur distant acceptant la connexion. Par exemple, quand un utilisateur se connecte sur un hôte distant, inetd de l'hôte distant va envoyer une demande sur le port 113 pour déterminer les informations du propriétaire. Cela est souvent utilisé pour les serveurs de courriers, FTP et IRC et peut également être utilisé pour remonter la trace de l'utilisateur qui attaque un système distant par l'intermédiaire de votre machine.

Il y a eu des discussions complètes sur la sécurité d'identd (voir les archives de la liste de diffusion). En règle générale, identd est plus utile sur un système multi-utilisateurs que sur un poste de travail mono-utilisateur. Si vous n'en avez pas l'utilité, désactivez-le, pour ne pas laisser un service ouvert au monde extérieur. 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 à un serveur utilisant identd pourrait être en attente jusqu'à l'expiration d'un délai (voir les problèmes sur le rejet ou le déni).

11.1.14.5 J'ai des services utilisant les ports 1 et 6, quels sont ces services et comment puis-je les enlever ?

Si vous exécutez la commande netstat -an et que vous recevez : 

       Active Internet connections (servers and established)
       Proto Recv-Q Send-Q Local Address           Foreign Address         State
       PID/Program name
       raw        0      0 0.0.0.0:1               0.0.0.0:*               7
       -
       raw        0      0 0.0.0.0:6               0.0.0.0:*               7
       -

Vous ne voyez aucun processus écoutant sur les ports 1 et 6. En fait, vous voyez un processus écoutant sur une socket raw (brut) pour les protocoles 1 (ICMP) et 6 (TCP). Un tel comportement est courant pour les trojans et aussi pour certains systèmes de détection d'intrusions comme iplogger et portsentry. Si vous avez ces paquets, supprimez-les simplement. Si vous ne les avez pas, essayez l'option -p (processus) de netstat pour voir quel processus est à l'écoute.

11.1.14.6 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 ouverts doivent adhérer à la politique de sécurité de votre site concernant les services publiques disponibles pour les autres systèmes. Vérifiez s'ils sont ouvert par inetd (voir Désactivation d'inetd ou de ses services, Section 3.6.2) ou par d'autres paquets installés et prenez les mesures adéquates (par exemple, configuration d'inetd, suppression du paquet, éviter qu'il démarre au démarrage).

11.1.14.7 Est-ce que la suppression de services de /etc/services va m'aider à sécuriser ma machine ?

Non, le fichier /etc/services fournit 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ées. Certains démons ne se lanceront peut-être pas si /etc/services est modifié mais ce n'est pas la norme. Pour désactiver correctement les services, voir Désactivation de services démon, Section 3.6.1.

11.1.15 Problèmes courants de sécurité

11.1.15.1 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 non appliqué les différentes procédures concernant les limitations d'accès à lilo et au BIOS.

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

Une fois que vous avez activé l'amorçage depuis un CD-ROM ou une disquette, vous pouvez essayer de :

Ceci retirera le mot de passe root oublié, contenu dans le premier champ séparé par deux points après le nom d'utilisateur. Enregistrez le fichier, redémarrer le système et connectez-vous en tant que root (avec un mot de passe vide). Ceci fonctionnera à moins que vous n'ayez configuré le système plus strictement, par exemple, si vous n'autorisez pas aux utilisateurs de mots de passe vides ou à root de se connecter à partir de la console.

Si vous avez introduit ces caractéristiques, vous devrez passer en mode utilisateur unique. Si LILO a été restreint, vous devrez relancer lilo après le reset du root indiqué ci-dessus. C'est assez rusé puisque votre /etc/lilo.conf devra être modifié car le système de fichiers / est alors un disque virtuel et non le réel disque dur.

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

11.1.16 Comment puis-je mettre en place un service pour mes utilisateurs sans leur donner un compte shell ?

Par exemple, si vous voulez mettre en place un service POP, vous n'avez pas besoin de configurer un compte d'utilisateur pour chaquet utilisateur y accédant. Il est préférable de mettre en place une authentification basé sur un répertoire grâce à un service externe (comme Radius, LDAP ou une base de données SQL). Installez simplement la bibliothèque PAM appropriée (libpam-radius-auth, libpam-ldap, libpam-pgsql ou libpam-mysql), lisez la documentation (pour commencer, voir Authentification utilisateur : PAM, Section 4.10.1) et configurez le service en activant PAM pour utiliser la méthode que vous avez choisi. Cela est fait en éditer les fichiers sous /etc/pam.d/ pour vos services et en modifiant 

      
       auth   required    pam_unix_auth.so shadow nullok use_first_pass

en, par exemple pour ldap : 

       auth   required    pam_ldap.so

Dans le cas de répertoires LDAP, certains services fournissent des schémas LDAP à inclure dans votre répertoire et qui sont nécessaires pour utiliser l'authentification LDAP. Si vous utilisez une base de données relationnelle, une astuce utile est d'utiliser la clause where quand vous configurez les modules PAM modules. Par exemple, si vous avez une base de données avec les attributs de table suivants : 

       (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)

En changeant les attributs de service en champs booléens, vous pouvez les utiliser pour permettre ou interdire l'accès aux différents services en utilisant simplement les lignes appropriées dans les fichiers suivants :

11.2 Mon système est vulnérable ! (En êtes-vous certain ?)

11.2.1 Le scanneur X de vérification des failles indique que mon système Debian est vulnérable !

Plusieurs scanneurs de vérification de failles renvoient des faux positifs quand ils sont utilisés sur des systèmes Debian, car ils n'utilisent que le numéro de version pour déterminer si un paquet donné de logiciel est vulnérable, mais ils ne testent pas réellement la faille de sécurité elle-même. Comme Debian ne change de numéros de version lors de la correction d'un paquet (il est courant que la correction effectuée pour des versions plus récentes soit rétro-portée), certains outils ont tendance à croire qu'un système Debian mis à jour est vulnérable alors qu'il ne l'est pas.

Si vous pensez que votre système est à jour concernant les correctifs de sécurité, vous pouvez désirer utiliser les références croisées des bases de données des failles de sécurité publiées avec les DSA (voir Alertes de sécurité Debian, Section 7.2) pour éliminer les faux positifs, si l'outil que vous utilisez inclut des références CVE.

11.2.2 J'ai vu une attaque dans les fichiers journaux de mon système. Est-ce que mon système est compromis ?

Une trace d'une attaque ne veut pas toujours dire que votre système a été compromis et vous devriez effectuer les étapes habituelles pour déterminer si le système est vraiment compromis (voir Après la compromission (la réponse à l'incident), Chapitre 10). Notez également que le fait que vous voyez les attaques dans les fichiers journaux peut vouloir dire que votre système est déjà vulnérable (cependant, un attaquant déterminé pourrait avoir utilisé une autre faille en plus de celles que vous avez vu).

11.2.3 J'ai trouvé d'étranges lignes « MARK » dans mes journaux : est-ce que mon système est compromis ?

Il se peut que vous trouviez les lignes suivantes dans vos fichiers journaux du système : 

       Dec 30 07:33:36 debian -- MARK --
       Dec 30 07:53:36 debian -- MARK --
       Dec 30 08:13:36 debian -- MARK --

Cela n'indique pas un type de compromission et les utilisateurs changeant de versions de Debian peuvent trouver cela étrange. Si votre système n'a pas une charge importante (ou beaucoup de services actifs), ces lignes peuvent apparaître dans vos journaux. C'est une indication que votre démon syslogd fonctionne correctement. De syslogd(8) : 

            -m interval
                 Syslogd stocke dans un journal une marque d'horodatage
                 régulièrement. L'intervalle par défaut entre deux lignes
                 -- MARK -- est de 20 minutes. Ceci peut être changé avec
                 cette option. Positionner l'intervalle à 0 désactive
                 cela complètement.

11.2.4 J'ai trouvé des utilisateurs utilisant « su » dans mes journaux : mon système est-il compromis ?

Vous pouvez trouver des lignes comme ceci dans vos journaux : 

       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 que ces entrées sont dues à des tâches 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.5 J'ai trouvé un « possible SYN flooding » dans mes journaux : mon système est-il attaqué ?

Si vous voyez des entrées comme ceci dans vos fichiers journaux : 

       May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.

Vérifiez s'il y a un nombre élevé de connexions au serveur en utilisant netstat, par exemple : 

       linux:~# netstat -ant | grep SYN_RECV | wc -l
          9000

C'est une indication d'une attaque par déni de service (DoS) sur le port X de votre système (très certainement sur un service public comme un serveur web ou un serveur de courrier). Vous devriez activer TCP syncookies dans votre noyau, voir Configurer syncookies, Section 4.17.2. Cependant, notez qu'une attaque par DoS peut inonder votre réseau même si vous pouvez l'empêcher de planter vos systèmes (à cause de la raréfaction de descripteurs de fichiers, le système peut ne plus répondre jusqu'à ce que les connexions TCP expirent). Le seul moyen efficace pour stopper cette attaque est de contacter votre fournisseur d'accès réseau.

11.2.6 J'ai trouver des sessions root étranges dans mes journaux : mon système est-il compromis ?

Vous pouvez voir ce genre d'entrées dans votre fichier /var/log/auth.log : 

       May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
       May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
       May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
       (UID=0)
       May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root

Elles sont dues à l'exécution d'une tâche cron (dans cet exemple, toutes les cinq minutes). Pour déterminer quel programme est responsable de ces tâches, vérifiez les entrées dans : /etc/crontab, /etc/cron.d, /etc/crond.daily et la crontab de root dans /var/spool/cron/crontabs.

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

Il y a plusieurs étapes que vous pouvez effectuer en cas d'intrusion :

11.2.8 Comment puis-je pister une attaque ?

En regardant les logs (s'ils n'ont pas été modifiés), en utilisant un système de détection d'intrusions (voir Mise en place d'un système de détection d'intrusion, Section 9.3), 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 informations 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.9 Le programme 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 listes de diffusion 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à conscients 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 un courriel sur le(s) paquet(s) affecté(s) avec une description de la vulnérabilité rencontrée aussi détaillée que possible (la preuve par un code d'exploitation est aussi bienvenue) à team@security.debian.org. Cela vous mettra en rapport avec l'équipe de sécurité Debian.

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

Au lieu de mettre à jour vers une nouvelle version, nous appliquons la rustine de sécurité à la version présente dans la distribution stable. La raison pour laquelle nous agissons ainsi est simple. Elle permet d'assurer qu'une version a le moins de changements possible, de cette manière les choses ne changeront pas ou ne se briseront pas à cause 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 le numéro exact de version (version amont -slash- version Debian) avec celui indiqué dans l'alerte de sécurité Debian (Debian Security Advisory).

11.2.11 Logiciels spécifiques

11.2.11.1 proftpd est vulnérable à une attaque de déni de service

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

11.2.11.2 Après l'installation de portsentry, il y a un grand nombre de ports d'ouverts.

Il s'agit simplement de la façon dont fonctionne portsentry. Il ouvre environ 20 ports non utilisés pour tenter de détecter les scans de ports.

11.3 Questions concernant l'équipe de sécurité Debian

Cette information est tirée de la FAQ de l'équipe Debian sur la sécurité. Elle inclut les informations au 19 novembre et fournit plusieurs autres questions communes posées sur la liste de diffusion debian-security.

11.3.1 Qu'est ce qu'une alerte de sécurité Debian (Debian Security Advisory, DSA) ?

C'est l'information envoyée par l'équipe de sécurité Debian (voir ci-dessous) informant qu'une mise à jour de sécurité concernant une vulnérabilité d'un paquet de Debian GNU/Linux est disponible. Les DSA signés sont envoyées aux listes de diffusion publiques (debian-security-announce) et postées sur le site Debian (sur la page de garde et dans la zone concernant la sécurité).

Les DSA incluent des informations sur les paquets concernés, la faille de sécurité découverte et l'endroit où récupérer les paquets mis à jour (ainsi que leurs sommes MD5).

11.3.2 La signature des alertes Debian ne se vérifie pas correctement!

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

Le plus probable est qu'un logiciel de courrier de votre côté change légèrement le message, ce qui rompt la signature. Assurez-vous pour cela que votre logiciel ne fait aucun encodage ou décodage MIME, ou de conversion de tabulation ou espace.

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

11.3.3 Comment la sécurité est-elle gérée chez Debian ?

Dès que l'équipe de sécurité reçoit une notification d'un incident, un ou plusieurs membres l'inspecte et étudie si la distribution stable de Debian y est vulnérable ou pas. Si notre 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à contacté l'équipe de 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 ensuite. Après que toutes ces tâches sont terminées, une alerte de sécurité est publiée.

11.3.4 Pourquoi vous embêtez-vous avec une vieille version de tel paquet ?

La règle la plus importante lors de la création d'un nouveau paquet qui corrige un problème de sécurité est de faire le moins de changements possible. Nos utilisateurs et développeurs comptent sur le comportement exact d'une distribution une fois qu'elle est stable, donc tout changement que nous faisons peut peut-être casser le système de quelqu'un. Cela est particulièrement vrai dans le cas de bibliothèques : assurez-vous de ne jamais changer l'interface de programmation d'applications (API) ou l'interface binaire d'applications (ABI), quelque petit que soit le changement.

Cela veut dire que passer à une nouvelle version amont n'est pas une bonne solution, au lieu de cela, les changements pertinents devraient être rétro-portés. Habituellement, les responsables amont sont désireux d'aider si nécessaire, sinon l'équipe de sécurité Debian peut peut-être aider.

Dans certains cas, il n'est pas possible de rétro-porter un correctif de sécurité, par exemple quand de grandes quantités de code source doivent être modifiées ou réécrites. Si cela arrive, il peut être nécessaire de passer à une nouvelle version amont, mais cela doit obligatoirement être coordonné avec l'équipe de sécurité auparavant.

11.3.5 Quelle est la règle pour qu'un paquet fixé apparaisse sur security.debian.org ?

Les problèmes de sécurité dans la distribution stable garantisse qu'un paquet ira sur security.debian.org. Rien d'autre ne le peut. La taille du problème n'est pas un problème réel ici. Habituellement, l'équipe de sécurité va préparer des paquets avec le responsable du paquet. Pourvu que quelqu'un (de confiance) suive le problème, compile tous les paquets nécessaires et les propose à l'équipe de sécurité, même des problèmes de sécurité très triviaux peuvent faire aller le paquet sur security.debian.org. Voir ci-dessous.

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

Au lieu de mettre à jour vers une nouvelle version, nous appliquons la rustine de sécurité à la version présente dans la distribution stable. La raison pour laquelle nous agissons ainsi est simple. Elle permet d'assurer qu'une version a le moins de changements possible, de cette manière les choses ne changeront pas ou ne se briseront pas à cause 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 le numéro exact de version avec celui indiqué dans l'alerte de sécurité Debian (Debian Security Advisory).

11.3.7 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 sécurisé (et stable), nous vous encourageons fortement à rester sur une version stable. Cependant, les secrétaires de sécurité essaieront de corriger les problèmes dans testing et unstable après leur correction dans la distribution stable.

Dans certains cas, cependant, la branche unstable récupère les correctifs de sécurité très rapidement puisque les mises à jour de sécurité sont généralement disponibles en amont plus rapidement (pour les autres versions, comme celles introduites dans la branche stable, il est nécessaire de faire un rétro-portage).

11.3.8 Je possède un ancienne version de Debian, est-elle supportée par l'équipe de sécurité Debian ?

Malheureusement non. L'équipe de sécurité Debian ne peut pas gérer à la fois la version stable (officieusement elle ne gère pas non plus la version unstable) et d'autres anciennes versions. Cependant, vous pouvez espérer des mises à jour de sécurité pour une période limitée juste (habituellement plusieurs mois) après la sortie d'une nouvelle distribution Debian.

11.3.9 Pourquoi n'y a-t-il pas de miroirs officiels de security.debian.org ?

Le but de security.debian.org est de mettre à disposition les mises à jour de sécurité aussi vite et facilement que possible. Les miroirs 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.10 J'ai vu la DSA 100 et la DSA 102, que s'est-il passé avec la DSA 101 ?

Plusieurs vendeurs (la plupart pour GNU/Linux, mais aussi des dérivés BSD) coordonnent les alertes de sécurité pour certains incidents et se mettent d'accord pour un calendrier particulier pour que tous les vendeurs puissent diffuser l'alerte en même temps. Cela a été décidé afin de ne pas discriminer un vendeur en particulier qui aurait besoin de plus de temps (par exemple si le vendeur doit faire passer ses paquets par de longs tests de QA ou doit supporter plusieurs architectures ou distributions binaires). Notre propre équipe de sécurité prépare également les alertes à l'avance. De temps en temps, d'autres problèmes de sécurité doivent être traités avant que l'alerte en attente puisse être diffusée, cela laisse donc temporairement vide un ou plusieurs numéros d'alerte.

11.3.11 Comment joindre l'équipe de sécurité ?

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 sensibles, veuillez utiliser team@security.debian.org qui n'est lu que par les membres de l'équipe de sécurité. Si vous le désirez, le courriel peut être chiffré à l'aide de la clef de contact de la sécurité Debian (identifiant de clé 0x363CCD95).

11.3.12 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 listes de diffusion des développeurs (debian-private). Tous les développeurs Debian sont inscrits à cette liste et tous les envois à cette liste sont tenus confidentiels (i.e. ne sont pas archivés sur le site web public). La liste de diffusion publique debian-security@lists.debian.org est ouverte à tous ceux qui désirent s'y inscrire, et des archives sont disponible pour la recherche à partir du site Internet ici.

11.3.13 Comment puis-je aider l'équipe de 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 simplement suivre le courrier de Bugtraq étant donné qu'ils l'ont déjà reçu. Fournir des informations supplémentaires est cependant toujours une bonne idée.

11.3.14 Qui compose l'équipe de sécurité ?

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

11.3.15 L'équipe de sécurité Debian vérifie-t-elle chaque nouveau paquet dans Debian ?

Non, l'équipe de sécurité 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 impossibles à détecter automatiquement. Toutefois, les développeurs sont complètement responsables du logiciel qu'ils introduisent dans Debian et tout logiciel est d'abord signé par un développeur habilité. Celui-ci a la responsabilité d'analyser la sécurité du paquet qu'il maintient.

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

L'équipe de sécurité Debian travaille rapidement pour envoyer les alertes et produire des paquets corrigés pour la branche stable une fois que la vulnérabilité a été découverte. Un rapport publié sur la liste de diffusion debian-security a montré que durant l'année 2001, il a fallu un temps moyen de 35 jours à l'équipe de sécurité Debian pour corriger les vulnérabilités découvertes. Cependant, plus de 50 % de ces vulnérabilités ont été réparées dans une durée de dix jours, et plus de 15 % de celles-ci ont été réparées le jour même de la sortie de l'alerte.

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

Si vous désirez une analyse plus poussée du temps que cela prend à l'équipe de sécurité Debian de travailler sur les vulnérabilités, vous devriez considérer que les nouvelles DSA (voir Alertes de sécurité Debian, Section 7.2) publiées sur le site web de sécurité et les méta-données utilisées pour les générer incluent des liens vers les bases de données de vulnérabilités. Vous pouvez télécharger les sources depuis le serveur web (depuis le CVS) ou utiliser les pages HTML pour déterminer le temps que cela prend à Debian pour corriger les vulnérabilités et corréler cette donnée avec les bases de données publiques.

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

Manuel de sécurisation de Debian

Version: 3.4, Sun, 06 Nov 2005 22:34:04 +0100

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

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