[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
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.
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, consultez les statistiques de
US-CERT ou générez des statistiques en utilisant la base de données nationale de
vulnérabilités (anciennement ICAT). Est-ce que ces données sont
utiles ? Plusieurs facteurs sont à considérer pour l'interprétation
des données, mais remarquez qu'elles ne permettent pas de comparer les failles
d'un système d'exploitation par rapport à un autre.[78] Rappelez-vous également que
certaines failles signalées concernant Debian ne s'appliquent qu'à la branche
unstable (c'est-à-dire non publiée).
Peu de grandes différences existent 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, Xorg, gcc, zlib, etc. sont tous communs entre les distributions Linux.
Par exemple, Red Hat a joué de malchance et a livré une version stable quand
truc était en version 1.2.3, où une faille sécurité a été
découverte plus tard. Debian, d'un autre côté, a été plus chanceuse de
livrer truc 1.2.4, qui contient la correction du bogue. Cela a été le
cas avec le gros problème de rpc.statd il y
quelques années.
Beaucoup de collaboration existe entre les équipes de sécurité respectives
des distributions Linux majeures. Les mises à jour de sécurité connues sont
rarement, voire jamais, laissées non corrigées par un distributeur. La
connaissance d'une faille de sécurité n'est jamais cachée à un autre
distributeur, tout comme les corrections sont habituellement coordonnées en
amont ou par le CERT. Par
conséquent, les mises à jour de sécurité nécessaires sont habituellement
diffusés en même temps et 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 quelques autres aspects de la sécurité dans Debian à considérer.
Debian fournit plus d'outils de sécurité que les autres distributions, consultez Outils de sécurité dans Debian, Chapitre 8.
L'installation standard de Debian est plus petite (moins de fonctionnalités)
et donc plus sûre. Les autres distributions, au nom de l'utilisabilité, ont
tendance à installer plusieurs services par défaut et parfois, ils ne sont
pas configurés correctement (rappelez-vous de Lion
et Ramen).
L'installation de Debian n'est pas aussi limitée que celle d'OpenBSD (aucun
démon n'est activé par défaut), mais c'est un bon compromis.[79]
Debian documente les meilleures pratiques de sécurité dans des documents comme celui-ci.
Debian distribue un grand nombre, en augmentation constante, de paquets logiciels, probablement plus que la plupart des systèmes d'exploitation propriétaires. Par conséquent le risque est plus grand de trouver des logiciels victimes de failles de sécurité exploitables que sur les systèmes contenant moins de logiciels.
De plus en plus de personnes examinent le code source à la recherche de failles. De nombreux annonces sont liées à des audits de code source effectués sur des composants logiciels majeurs livrés dans Debian. Lorsqu'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 comme celle de BugTraq.
Les bogues présents dans la distribution Debian affectent également d'autres distributeurs et distributions. Vérifiez la partie « Debian specific: yes/no » en haut de chaque annonce (DSA).
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.
Au moins deux distributions Linux sont actuellement certifiées à différents
niveaux EAL.
Remarquez que certains des tests CC sont en cours d'intégration dans le
Linux Testing Project
disponible dans le paquet Debian ltp.
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.
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.). Cela peut être déroutant pour l'administrateur débutant lorsqu'il essaie de déterminer l'outil adapté à son besoin. Le meilleur choix dans une situation donnée dépend d'un équilibre entre les fonctionnalités et la sécurité nécessaires. Voici quelques questions à se poser pour choisir parmi des paquets semblables.
Est-ce que le logiciel est maintenu en amont ? De quand date la dernière version ?
Le paquet est-il mûr ? Le numéro de version n'indiquera vraiment rien concernant sa maturité. Essayez de tracer l'histoire du logiciel.
Est-ce que le logiciel est truffé de bogues ? Y a-t-il eu des alertes de sécurité liées au logiciel ?
Est-ce que le logiciel fournit toutes les fonctionnalités nécessaires ? Fournit-il plus que le nécessaire ?
Les informations disponibles dans ce document vous permettront de rendre certains services (FTP, BIND) plus sécurisés dans 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 sur Linux. La plupart des directives concernant la sécurité des systèmes UNIX peut également s'appliquer à Debian. Ainsi, la sécurisation d'un service X dans Debian revient, la plupart du temps, à sécuriser un service dans n'importe quelle autre distribution Linux (ou UNIX, peu importe).
Si vous ne voulez pas que des utilisateurs se connectent au démon POP3, par
exemple, et récupèrent des renseignements sur le système, vous pourriez
supprimer (ou modifier) les versions affichées aux utilisateurs. [80] Faire cela dépend du logiciel
que vous utilisez pour un service donné. Par exemple, dans
postfix, vous pouvez placer la bannière SMTP suivante ans
/etc/postfix/main.cf :
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
D'autres logiciels ne sont pas aussi faciles à modifier. SSH
devra être recompilé pour pouvoir modifier la version affichée. Prenez
garde à ne pas supprimer la première partie (SSH-2.0) de la
bannière, car les clients l'utilisent pour identifier les protocoles pris en
charge par le paquet.
L'équipe de sécurité Debian ne peut pas analyser tous les paquets inclus dans Debian pour tester des potentielles failles de sécurité, simplement à cause du manque de ressources pour contrôler 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 cheval de Troie dans un paquet sans 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 cheval de Troie 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. Installer des logiciels non testés dans un système critique n'est pas recommandé (si vous ne pouvez pas fournir l'audit de code nécessaire). Dans tous les cas, si des failles de sécurité étaient intégrées à 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.
Vous pouvez bien sûr modifier les permissions Debian par défaut du 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 sauf s'ils fournissent des informations sensibles.
Soyez attentifs si vous faites des modifications car :
des processus pourraient ne plus pouvoir écrire dans des fichiers journaux si leurs permissions ont été restreintes ;
certains applications peuvent ne pas fonctionner si le fichier de configuration
dont elles dépendent est illisible. Par exemple, si vous supprimez la
permission en lecture pour tous les utilisateurs de
/etc/samba/smb.conf, le programme smbclient ne pourra
pas fonctionner pour un utilisateur normal.
FIXME : Vérifier si c'est écrit dans la Charte. Certains paquets (par exemple, les démons FTP) semblent nécessiter différentes 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 le 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 fil
de la liste de diffusion de sécurité Debian contient plus d'informations sur
ce problème.
Si vous recevez des messages en console et que /etc/syslog.conf
est configuré pour les rediriger dans des fichiers ou dans un TTY spécial,
vous pourriez voir des messages envoyés directement en console.
Le niveau de journalisation en console par défaut est 7 quel que soit le noyau, donc tous les messages avec une priorité inférieure apparaîtront dans la console. En général, les pare-feu (la règle LOG) et d'autres outils de sécurité journalisent à des priorités inférieures donc les messages sont envoyés directement en console.
Pour réduire les messages envoyés en console, vous pouvez utiliser
dmesg (l'option -n, consultez dmesg(8)),
qui examine et contrôle le tampon anneau du noyau. Pour corriger
cela après le prochain redémarrage, modifiez /etc/init.d/klogd
en substituant :
KLOGD=""
par :
KLOGD="-c 4"
Utilisez un nombre plus petit pour -c si vous les voyez toujours.
Une description des différents niveaux de journalisation est disponible 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 débogage */
Oui et non. Debian est livrée avec certains utilisateurs prédéfinis
(identifiant 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 ayant un UID approprié. Si vous n'avez pas l'intention
d'installer de nouveaux services, vous pouvez supprimer sans problème ces
utilisateurs qui ne possèdent aucun fichier sur le système et 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[81] (assurez-vous de l'exécuter en tant que superutilisateur, é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. Voici la liste des utilisateurs par défaut (avec un
groupe correspondant).
root : c'est (typiquement) le superutilisateur.
daemon : quelques démons sans droit ont besoin de pouvoir écrire
certains fichiers du disque en tant que daemon:daemon (par exemple,
portmap, atd, et probablement d'autres). Les démons
qui n'ont besoin d'aucune appartenance de fichier peuvent tourner en tant que
nobody:nogroup, et des démons plus complexes ou plus consciencieux de la
sécurité tournent en tant qu'utilisateurs spécifiques. L'utilisateur daemon
est aussi utile pour les démons installés localement.
bin : maintenu pour des raisons historiques.
sys : comme bin. Toutefois, /dev/vcs* et /var/spool/cups
appartiennent au groupe sys.
sync : l'interpréteur de commandes de l'utilisateur sync est /bin/sync. Donc, si son mot de passe est quelque chose de facile à deviner (comme « »), n'importe qui peut synchroniser le système depuis la console même sans compte sur le système.
games : de nombreux jeux sont SETGID à games pour pouvoir écrire dans les fichiers des meilleurs scores. C'est expliqué dans la Charte.
man : le programme man est (parfois) lancé en tant qu'utilisateur man, il
peut alors écrire les pages cat vers /var/cache/man.
lp : utilisé par les démons d'impression.
mail : les boîtes aux lettres de /var/mail appartiennent au
groupe mail, comme décrit dans la Charte. L'utilisateur et le groupe sont
également utilisés à d'autres fins par différents MTA.
news : plusieurs serveurs de nouvelles et autres programmes associés
(comme suck) utilisent l'utilisateur et le groupe news de
différentes façons. Les fichiers dans la file d'attente des nouvelles
appartiennent souvent à l'utilisateur et au groupe news. Les programmes comme
inews qui peuvent être utilisés pour envoyer des nouvelles sont
typiquement SETGID news.
uucp : l'utilisateur et le groupe uucp sont utilisés par le sous-système
UUCP. Les fichiers de file d'attente et de configuration lui appartiennent.
Les utilisateurs du groupe uucp peuvent exécuter uucico.
proxy : comme daemon, cet utilisateur et ce groupe sont utilisés par
certains démons (en particulier les démons de mandataire) qui ne possèdent
pas d'identifiant utilisateur et qui n'ont pas besoin de posséder des
fichiers. Par exemple, le groupe proxy est utilisé par pdnsd et
squid est exécuté en tant qu'utilisateur proxy.
majordom : majordomo a un identifiant utilisateur alloué
statiquement sur les systèmes Debian pour des raisons historiques. Il n'est
plus installé sur les nouveaux systèmes.
postgres : les bases de données postgresql appartiennent à
cet utilisateur et ce groupe. Tous les fichiers dans
/var/lib/postgresql appartiennent à cet utilisateur afin
d'imposer un niveau de sécurité convenable.
www-data : certains serveurs web tournent en tant que www-data. Le contenu web ne devrait pas appartenir à cet utilisateur, sinon un serveur Internet compromis serait en mesure de réécrire un site web. Les données transférées par les serveurs web, incluant les fichiers journaux, seront la propriété de www-data.
backup : de cette manière la responsabilité de sauvegarde ou restauration peut être localement déléguée à quelqu'un sans avoir à lui donner tous les droits du superutilisateur.
operator : c'est historiquement (et pratiquement) le seul compte « utilisateur » qui peut se connecter à distance, sans dépendre de NIS ou NFS.
list : les archives des listes de diffusion et les données appartiennent à cet utilisateur et à son groupe. Certains programmes de listes de diffusion utilisent aussi cet utilisateur.
irc : utilisé par les démons IRC. Un utilisateur alloué statiquement
est nécessaire à cause d'un bogue dans ircd, il se SETUID
lui-même vers un UID donné au démarrage.
gnats.
nobody, nogroup : les démons qui n'ont pas besoin d'être propriétaires de fichiers devraient fonctionner sous l'utilisateur nobody et le groupe nogroup. Donc, aucun fichier sur un système ne devrait appartenir à cet utilisateur ou à ce groupe.
Les autres groupes suivants n'ont pas d'utilisateur associé.
adm : utilisé pour les tâches de surveillance du système. Les membres
de ce groupe peuvent lire de nombreux journaux d'événements dans
/var/log et peuvent utiliser xconsole. Historiquement,
/var/log était /usr/adm (et plus tard
/var/adm) d'où le nom du groupe.
tty : les périphériques TTY appartiennent à ce groupe. C'est utilisé
par write et wall pour leur permettre d'écrire sur
les TTY d'autres personnes.
disk : accès brut aux disques. Quasiment équivalent à l'accès superutilisateur.
kmem : /dev/kmem et les fichiers similaires sont lisibles par
ce groupe. C'est la plupart du temps un reste de BSD, mais certains programmes
en ont besoin pour un accès direct en lecture sur la mémoire du système ce
qui peut ainsi être fait par SETGID kmem.
dialout : accès direct et total aux ports séries. Les membres de ce groupe peuvent reconfigurer les modems, téléphoner n'importe où, etc.
dip : le nom du groupe signifie « Dialup IP ». Être dans le
groupe dip permet d'utiliser des outils comme ppp,
dip, wvdial, etc. pour établir une connexion.
Les utilisateurs de ce groupe ne peuvent pas configurer le modem, ils peuvent
juste utiliser les programmes qui en font usage.
fax : autorise les membres à utiliser les logiciels de fax pour envoyer et recevoir des faxes.
voice : boîte vocale, utile pour les systèmes qui utilisent les modems comme répondeurs.
cdrom : utilisé localement pour donner à certains utilisateurs un accès aux lecteurs de CD.
floppy : utilisé localement pour donner à certains utilisateurs un accès aux lecteurs de disquettes.
tape : utilisé localement pour donner à certains utilisateurs un accès aux lecteurs de bandes.
sudo : les membres de ce groupe n'ont pas besoin de fournir un mot de
passe lors de l'utilisation de sudo. Consultez
/usr/share/doc/sudo/OPTIONS.
audio : utilisé localement pour donner à certains utilisateurs un accès aux périphériques audio.
src : ce groupe possède les codes source, y compris les fichiers de
/usr/src. Il peut être utilisé pour permettre à un utilisateur
de manipuler les codes source du système.
shadow : /etc/shadow est lisible par ce groupe. Certains
programmes ayant besoin d'accéder à ce fichier sont SETGID shadow.
utmp : les membres de ce groupe peuvent écrire dans
/var/run/utmp et dans fichiers similaires. Les programmes qui
nécessitent l'écriture sont SETGID utmp.
video : utilisé localement pour donner à certains utilisateurs un accès aux périphériques vidéo.
staff : autorise les utilisateurs à ajouter des modifications au système
local (/usr/local, /home) sans avoir les droits du
superutilisateur. À comparer au groupe « adm » plus apparenté à
la surveillance et la sécurité.
users : alors que les systèmes Debian utilisent le système de groupe privé par utilisateur par défaut (chaque utilisateur a son propre groupe), certains préfèrent d'utiliser un système de groupes plus traditionnel. Dans ce système, chaque utilisateur est un membre de ce groupe.
Si vous avez supprimé un utilisateur système et que vous n'avez pas de
sauvegardes des fichiers password et group, vous
pouvez essayez de récupérer de ce problème en utilisant
update-passwd (consultez update-passwd(8)).
Le groupe « adm » est normalement celui des administrateurs et leur
permet de lire les journaux d'activités sans utiliser su. Le
groupe « staff » est généralement pour les administrateurs
système secondaires afin de faire des choses dans /usr/local et
de créer des répertoires dans home.
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'est-à-dire « users »).
Le schéma Debian résout 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 correct est automatiquement attribué aux fichiers créés dans ce répertoire. Cela facilite le travail sur plusieurs projets sans modifier les groupes ou les umask pour travailler 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 au GID du
groupe users auquel appartiennent tous les utilisateurs.
C'est un compromis entre la présence de sécurité et la facilité d'utilisation. Contrairement à OpenBSD, qui désactive tous les services non activés par l'administrateur, Debian GNU/Linux activera tous les services installés à moins de les désactiver (consultez Désactivation de services démon, Section 3.6.1 pour plus de renseignements). Après tout, vous avez installé ces services de votre propre chef, n'est-ce pas ?
De nombreuses discussions sur les listes de diffusion Debian (sur debian-devel et debian-security) ont eu lieu sur l'installation standard. Cependant, il n'y a pas de consensus à ce jour (mars 2002) sur la solution à adopter.
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 (consultez Désactivation de
services démon, Section 3.6.1), soit retirer le paquet en utilisant
equivs.
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 nécessaire pour savoir quand 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 en Sécurisation des services RPC, Section 5.13.
Dans les versions du paquet portmap ultérieures à 5-5, le
portmapper peut être en fait installé en n'écoutant que localhost (en
modifiant /etc/default/portmap).
Le service identd est un service d'authentification du 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. C'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.
Des discussions complètes ont eu lieu sur la sécurité d'identd
(consultez les archives
de la liste de diffusion). En règle générale,
identd est plus utile sur un système multiutilisateur 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 une règle de déni, sinon la communication à un
serveur utilisant identd pourrait être en attente jusqu'à
l'expiration d'un délai (consultez les problèmes sur le rejet ou le
déni).
Si la commande netstat -an affiche :
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
-
Aucun processus n'écoute sur les ports 1 et 6. En fait, un
processus écoute sur une socket raw (brut) pour les protocoles 1
(ICMP) et 6 (TCP). Un tel comportement est courant pour les chevaux de Troie
et pour certains systèmes de détection d'intrusions comme
iplogger et portsentry. Si ces paquets sont
installés, supprimez-les simplement. Sinon, essayez l'option -p
(processus) de netstat pour voir le processus à l'écoute.
Bien sûr que vous pouvez, les ports laissés ouverts doivent adhérer à la
politique de sécurité du site concernant les services publiques disponibles
pour les autres systèmes. Vérifiez s'ils sont ouvert par inetd
(consultez 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).
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) empêcher 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, consultez Désactivation de
services démon, Section 3.6.1.
Les démarches pour récupérer le système dépendent des différentes
procédures appliquées pour limiter l'accès à lilo et au BIOS.
Si les deux accès sont limité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é le mot de passe du BIOS, vous devrez ouvrir le système et retirer manuellement la pile du BIOS.
Une fois activé l'amorçage depuis un CD ou une disquette, vous pouvez essayer de :
démarrer depuis une disquette de secours (rescue) et démarrer le noyau ;
accéder aux consoles virtuelles (Alt+F2) ;
monter le disque dur où est placé la partition /root ;
éditer (la disquette de secours de Debian 2.2 est livrée avec
ae, Debian 3.0 est livrée avec nano-tiny qui
est similaire à vi) /etc/shadow et modifier la
ligne :
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=n'importe quel nombre)
par :
root::XXXX:X:XXXX:X:::
Cela retirera le mot de passe superutilisateur 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 superutilisateur (avec un mot de passe vide). Cela fonctionnera sauf si le système est configuré plus strictement, par exemple sans autorisation des connexions avec mot de passe vide ou des connexions du superutilisateur à partir de la console.
Si ces caractéristiques ont été introduites, vous devrez passer en mode
utilisateur unique. Si LILO a été restreint, vous devrez relancer
lilo après la réinitialisation du superutlisateur précédente.
C'est assez rusé puisque /etc/lilo.conf devra être modifié car
le système de fichiers racine est alors un disque virtuel et non le vrai
disque dur.
Une fois que LILO n'est plus restreint, vous pouvez :
presser l'une des touches Alt, Maj ou Ctrl juste avant que le BIOS système ne finisse, pour obtenir l'invite de LILO ;
entrer linux single, linux init=/bin/sh ou linux 1 à l'invite ;
cela donnera accès à une invite de commandes un mode utilisateur unique (un mot de passe sera demandé, mais vous le connaissez déjà) ;
remonter en lecture/écriture la partition racine (/), en utilisant la commande de montage :
mount -o remount,rw /
modifier le mot de passe du superutilisateur avec passwd (étant
superutilisateur, l'ancien mot de passe ne sera pas demandé).
Par exemple, si vous voulez mettre en place un service POP, vous n'avez pas
besoin de configurer un compte d'utilisateur pour chaque 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), consultez la
documentation (pour commencer, consultez Authentification utilisateur : PAM, Section
4.10.1) et configurez le service en activant PAM pour utiliser la méthode
que vous avez choisi. C'est fait en éditant les fichiers de
/etc/pam.d/ pour les 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 le 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 en configurant les modules PAM. Par exemple, avec une base de données contenant les attributs de table suivants :
(user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
En modifiant les attributs de service en champs booléens, vous pouvez les utiliser pour permettre ou interdire l'accès aux différents services avec simplement les lignes appropriées dans les fichiers suivants :
/etc/pam.d/imap : where=imap=1 ;
/etc/pam.d/qpopper : where=pop=1 ;
/etc/nss-mysql*.conf : users.where_clause = user.sys =
1; ;
/etc/proftpd.conf : SQLWhereClause
"ftp=1".
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étroporté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 le système est à jour des correctifs de sécurité, vous pourriez utiliser les références croisées des bases de données des failles de sécurité publiées avec les DSA (consultez Alertes de sécurité Debian, Section 7.2) pour éliminer les faux positifs, si l'outil utilisé inclut des références CVE.
Une trace d'une attaque ne veut pas toujours dire que le système a été compromis et vous devriez effectuer les étapes habituelles pour déterminer si le système est vraiment compromis (consultez Après la compromission (la réponse à l'incident), Chapitre 11). Même si le système n'était pas vulnérable à l'attaque journalisée, un attaquant déterminé pourrait avoir utilisé une autre faille en plus de celles détectées.
Les lignes suivantes pourraient apparaître dans les 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 le système n'a pas une
charge importante (ou beaucoup de services actifs), ces lignes peuvent
apparaître dans les journaux. C'est pour indiquer que le démon
syslogd fonctionne correctement. De
syslogd(8) :
-m interval
Syslogd garde dans un journal une marque d'horodatage
régulièrement. L'intervalle par défaut entre deux lignes
-- MARK -- est de 20 minutes. Cela peut être modifié
par cette option. Positionner l'intervalle à 0 le
désactive complètement.
Vous pouvez trouver ce genre de lignes dans les 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 9 * * * 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
Si vous voyez ce genre d'entrées dans les 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 le nombre de connexions au serveur en utilisant netstat,
par exemple :
linux:~# netstat -ant | grep SYN_RECV | wc -l
9000
Cela peut indiquer une attaque par déni de service (DoS) sur le port X du système (très certainement sur un service public comme un serveur web ou un serveur de courrier). Vous devriez activer TCP syncookies dans le noyau, consultez Configurer syncookies, Section 4.17.2. Cependant, notez qu'une attaque par déni de service peut inonder le réseau même si vous pouvez l'empêcher de planter les systèmes (à cause de la raréfaction de descripteurs de fichiers, le système peut ne plus répondre avant que les connexions TCP expirent). Le seul moyen efficace pour arrêter cette attaque est de contacter le fournisseur d'accès réseau.
Ce genre d'entrées peut apparaître dans le 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 le programme responsable
de ces tâches, vérifiez les entrées dans : /etc/crontab,
/etc/cron.d, /etc/crond.daily et la
crontab du superutilisateur dans
/var/spool/cron/crontabs.
Plusieurs étapes sont à prendre en compte en cas d'intrusion.
Vérifiez que le système est à jour avec les correctifs de sécurité pour
les failles publiées. Si le système est vulnérable, les risques de
compromission réelle du système augmentent. Les risques augmentent encore
plus si la faille est connue depuis un certain temps, car il y a habituellement
plus d'activité en lien avec d'anciennes failles. Voici un lien vers les
20 principales failles de sécurité
selon le SANS.
Consultez ce document, en particulier la section Après la compromission (la réponse à l'incident), Chapitre 11.
Demandez de l'aide. La liste de diffusion debian-security permet de demander conseil sur la manière de récupérer ou corriger le système.
Informez le CERT local (s'il
existe, sinon vous pourriez contacter le CERT directement). Cela peut ou non
vous aider, mais au minimum, cela informera le CERT des attaques en cours.
Cette information est très précieuse pour déterminer les outils et attaques
utilisés par la communauté blackhat.
En regardant les journaux (s'ils n'ont pas été modifiés), en utilisant un
système de détection d'intrusions (consultez Mise en place de détection d'intrusion,
Section 10.3), traceroute, whois et outils
similaires (y compris des analyses post-mortem) vous pourriez trouver la source
de l'attaque. La réaction face à ces informations dépend uniquement des
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 ?
Tout d'abord, vérifiez 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, elle
peut donc déjà être consciente du problème. Ne lancez pas d'autres actions
si l'annonce est sur http://security.debian.org.
Si rien n'a été publié, veuillez envoyer un message à propos des paquets
concernés avec une description aussi détaillée que possible de la
vulnérabilité rencontrée (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.
Au lieu de mettre à jour vers une nouvelle version, Debian rétroporte le correctif de sécurité dans la version de la distribution stable. La raison d'agir ainsi est simple : cela permet d'assurer qu'une version a le moins de modifications 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 qu'une version sécurisée du paquet est utilisée en regardant le journal de modifications du paquet ou en comparant le numéro exact de version (version amont et révision Debian) avec celui indiqué dans l'alerte de sécurité Debian (« Debian Security Advisory »).
Ajoutez DenyFilter \*.*/ au fichier de configuration, pour plus
d'informations, consultez http://www.proftpd.org/bugs.html.
Il s'agit simplement du mode de fonctionnement de portsentry. Il
ouvre environ 20 ports non utilisés pour tenter de détecter les scans de
ports.
Cette information est tirée de la FAQ de l'équipe Debian sur la
sécurité. Elle inclut les informations jusqu'à janvier 2006
et fournit des réponses à d'autres questions souvent posées sur la liste de
diffusion debian-security.
C'est le bulletin d'informations envoyé 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).
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 le 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.
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.
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. C'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 modifications pertinentes devraient être rétroportées. Habituellement, les responsables amont veulent bien aider. Sinon l'équipe de sécurité Debian peut peut-être aider.
Dans certains cas, il n'est pas possible de rétroporter 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.
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.
Les mises à jour de sécurité ont un but : fournir un correctif à une faille de sécurité. Elles ne permettent pas d'ajouter des modifications supplémentaires dans la publication stable sans passer par la procédure normale de mise à jour de publication.
Certaines annonces couvrent des vulnérabilités qui ne peuvent pas être identifiées par le schéma habituel d'exploitation local ou à distance. Certaines vulnérabilités ne peuvent pas être exploitées à distance, c'est-à-dire ne correspondent pas à un démon qui écoute sur un port réseau. Si elles peuvent être exploitées par des fichiers particuliers qui pourraient être fournis par le réseau alors que le service vulnérable n'est pas connecté en permanence au réseau, « local (remote) » est alors écrit.
De telles vulnérabilités sont en quelque sorte à la fois locale et à distance, et concernent souvent des archives qui pourraient être fournies par le réseau, par exemple en tant que pièce jointe à un courrier électronique ou depuis une page de téléchargement.
Consultez Le numéro de version pour un paquet indique une version vulnérable !, Section 12.2.10.
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 suivre correctement. Si vous désirez
un serveur sécurisé (et stable), nous vous encourageons fortement à rester
sur une version stable. Cependant, il y a du travail de fait dans cette
direction, avec la formation d'une équipe en charge de la
sécurité de testing qui a commencé à offrir un suivi en
sécurité pour testing, et d'une certaine façon, pour unstable. Pour de plus
amples renseignements, veuillez consulter Suivi en sécurité de la
branche testing, Section 10.1.4.
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étroportage).
Vous pouvez consulter les vulnérabilités publique concernant les publications
testing et unstable sur le système de suivi en
sécurité.
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.
Les mises à jour de sécurité migrerons de la distribution unstable vers testing. Elles sont généralement envoyées avec une priorité haute, ce qui réduit le temps d'attente à deux jours. Après cette période, les paquets migreront automatiquement vers testing, étant données qu'ils sont construits pour toutes les architectures et que leurs dépendances sont disponibles dans testing.
L'équipe en charge de
la sécurité de testing prépare aussi des correctifs de sécurité
disponibles dans leur dépôt quand un processus de migration normal n'est pas
assez rapide.
La réponse courte est : elle ne l'est pas. contrib et non-free ne font pas officiellement partie de la distribution Debian et ne sont pas publiés, et ne sont de fait pas suivis par l'équipe en charge de la sécurité. Certains paquets de non-free sont distribués dans source ou sans licence permettant le distribution de versions modifiées. Dans ces cas, aucun correctif de sécurité ne peut être réalisé. S'il est possible de corriger le problème, et que le mainteneur du paquet ou quelqu'un d'autre fournit des paquets correctement mis à jour, alors l'équipe de sécurité les traitera normalement et publiera une annonce.
En fait il y en a. Plusieurs miroirs officiels existent, implémentés à l'aide d'alias DNS. Le but de security.debian.org est de mettre à disposition les mises à jour de sécurité le plus rapidement et facilement possible.
Encourager l'utilisation de miroirs non officiels ajouterait un niveau de complexité qui n'est généralement pas nécessaire et qui pourrait provoquer une certaine frustration si ces miroirs ne sont pas gardés à jour.
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 prendre en charge 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.
Si une correction de bogue plus récente remplace un paquet plus ancien de security.debian.org, il y a de fortes chances que l'ancien paquet soit retiré pendant que le nouveau est installé. Par conséquent, vous obtiendrez cette erreur de « fichier non trouvé ». Nous ne voulons pas distribuer de paquets avec des bogues de sécurité plus longtemps qu'absolument nécessaire.
Veuillez utiliser les paquets de la dernière annonce de sécurité, qui sont
annoncés sur la liste de diffusion
debian-security-announce. Il vaut mieux simplement exécuter
apt-get update avant de mettre à jour le paquet.
Les informations de sécurité peuvent être envoyées à security@debian.org, qui est lue
par tous les développeurs Debian. Si vous disposez d'informations sensibles,
veuillez utiliser team@security.debian.org qui
n'est lue que par les membres de l'équipe de sécurité. Si vous le désirez,
le message peut être chiffré à l'aide de la clef de contact de la sécurité
Debian (identifiant de clef 0x363CCD95).
Consultez également les clefs PGP/GPG de l'équipe
de sécurité.
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[82] (c'est-à-dire 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.
Si vous vous rendez-compte d'un problème de sécurité, dans un paquets que vous maintenez ou non, veillez contacter l'équipe de sécurité. Si l'équipe de sécurité confirme la vulnérabilité et que d'autres distributeurs sont aussi potentiellement vulnérables, ils seront contactés. Si la vulnérabilité n'est pas encore publique, l'équipe essayera de coordonner l'annonce avec les autres distributeurs, de telle sorte que les distributions principales soient synchronisées.
Si la vulnérabilité est déjà publiquement connue, n'oubliez pas de soumettre un rapport de bogue dans le système de suivi de bogue Debian, et de l'étiqueter security.
En contribuant à ce document, en résolvant les FIXME ou en fournissant un nouveau contenu. La documentation est importante et réduit le nombre de réponses aux problèmes courants. La traduction de ce document dans d'autres langues est également un bonne contribution.
En empaquetant des applications utiles pour vérifier ou améliorer la
sécurité d'un système Debian GNU/Linux. Si vous n'êtes pas un
développeur, remplissez un rapport de bogue WNPP et
proposez des logiciels que vous pensez utiles et qui ne sont pas encore
disponibles.
Contrôler les applications dans Debian ou aider à résoudre des bogues de sécurité et signaler les problèmes à security@debian.org.
Dans tous les cas, s'il vous plaît, passez en revue chaque problème avant de les signaler à security@debian.org. Si vous êtes capable de fournir des correctifs, 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.
L'équipe de sécurité Debian est constituée de plusieurs membres et
assistant. L'équipe de sécurité elle-même invite tout le monde
à se joindre à l'équipe.
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 contenant du code malveillant, étant donné que ces vérifications sont plutôt impossibles à réaliser 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.
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 :
Les DSA ne sont pas envoyées avant que :
les paquets soient disponibles pour toutes les architectures prises en charge par Debian (ce qui prend du temps pour les paquets qui font partie intégrante du système de base, spécialement si l'on considère le nombre d'architectures prises en charge dans la version stable) ;
les nouveaux paquets sont ensuite testés pour s'assurer qu'aucun nouveau bug n'est introduit.
Les paquets peuvent être disponibles avant que la DSA ne soit envoyée (dans la file d'arrivée ou sur les miroirs).
Debian est un projet basé sur le volontariat.
La licence de Debian comprend une clause de « non garantie ».
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 (consultez Alertes de sécurité Debian, Section 7.2)
publiées sur le site web de
sécurité et les métadonné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.
L'équipe de sécurité essaye de suivre la distribution stable pendant environ un an après la publication de la distribution stable suivante, sauf si une autre distribution stable a été publié dans l'année. Ce n'est pas possible de suivre trois distributions, c'est déjà bien assez difficile avec deux.
Ce processus consiste à contrôler la signature du fichier Release à l'aide
de la clef publique (disponible en http://ftp-master.debian.org/ziyi_key_2006.asc,
en remplaçant 2006 par l'année en cours) utilisée pour l'archive. Le
fichier Release contient les sommes de contrôle MD5 des fichiers Packages et
Sources qui contiennent respectivement les sommes de contrôle MD5 des paquets
binaires et des paquets source. Des instructions détaillées sur la façon de
contrôler l'intégrité des paquets peuvent être obtenues en La signature de paquet dans Debian, Section
7.5.
Premièrement, vous devez essayer de comprendre pourquoi le paquet est défaillant et comment il interagit avec la mise à jour de sécurité. Ensuite, prenez contact avec l'équipe en charge de la sécurité s'il s'agit de quelque chose de sérieux ou bien le responsable de la distribution stable s'il s'agit de quelque chose de moins grave. Nous parlons ici de paquets quelconques qui cessent de fonctionner après une mise à jour de sécurité d'un autre paquet. Si vous ne parvenez pas à identifier la cause du problème, mais que vous connaissez le correctif, parlez-en également à l'équipe en charge de la sécurité. Il est toutefois possible qu'on vous renvoie vers le responsable de la distribution stable.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
Securing Debian Manual
Version: 3.13, Sun, 08 Apr 2012 02:48:09 +0000jfs@debian.org