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 essaye d'installer les services d'une façon sûre par défaut et ne peut pas être aussi paranoïaque que d'autres systèmes exploitations qui installent tous les services désactivés par défaut. Toutefois, l'administrateur système a besoin d'adapter la sécurité du système à la politique de sécurité locale.
Debian contient un certains nombres de paquetages et différents logiciels, probablement plus que certains systèmes d'exploitation propriétaires. Cela signifie qu'il y a un plus grand risque de trouver des logiciels proposant des failles de sécurité exploitable que sur certains systèmes contenant moins de logiciels.
Cependant, il y a de nombreux papiers consultatifs liés à l'audit de code source effectué sur des composants logiciels majeurs livrés dans Debian. Lorsque un de ces audits de code source fait ressortir une faille majeur, elle est réparée et un papier est envoyé aux listes telle que celle de Bug Traq.
Les bugs présents dans la distribution Debian affectent également d'autres vendeurs et d'autres distributions. Vérifiez la partie "Debian specific: yes/no" en haut de chaque document (DSA). Si il est inscrit "yes", cela signifie que seul Debian est affecté, si il est inscrit "no", c'est probablement que d'autres distributions sont aussi affectées.
Réponse courte : non.
Réponse longue : la certification coûte de l'argent et personne n'a attribué de ressources pour faire certifier la distribution Debian GNU/Linux à n'importe quel niveau que ce soit, par exemple, la Common Criteria. Si vous êtes intéressés par l'obtention d'une distribution GNU/Linux certifié, essayez de fournir les ressources pour que cela devienne possible.
Oui. Bastille Linux
,
orienté à la base vers certaines distributions Linux(RedHat et Mandrake),
fonctionne actuellement sur Debian. La planification prévoit d'intégrer les
changements à la version en amour, dans tous les cas, le paquetage Debian est
nommé, bien sûr, bastille
.
Certains pensent, cependant, qu'un outil de durcissement n'élimine pas la nécessité d'une bonne administration.
Les informations disponibles dans ce document vous permettront de rendre certains services (FTP, Bind) plus sécurisés dans la Debian GNU/Linux. Toutefois, pour les services non abordés ici, vous pouvez vérifier la documentation des programmes ou les informations générales Linux. La plupart des directives concernant la sécurité pour les systèmes Unix peut également s'appliquer à la Debian. Ainsi, la sécurisation d'un service X dans la Debian revient, la plupart du temps, à sécuriser un service comme pour n'importe quelle autre distribution Linux (ou Unix, peu importe).
L'équipe de sécurité Debian ne peut pas analyser tous les paquets inclus dans
Debian pour tester des potentielles failles de sécurité, puisque il n'y a tout
simplement pas assez de ressources pour auditer le code source de l'ensemble du
projet. Cependant Debian bénéficie des audits de code source réalisés en amont
par des développeurs d'autres projets comme Linux Kernel Security Audit
Project
or the Linux
Security-Audit Project
.
Au fond, un développeur Debian peut distribuer un trojan dans un paquet et il n'y a pas moyen de le vérifier. Même s'il était introduit dans la Debian, il serait impossible de couvrir toutes les situations imaginables dans lesquelles le trojan pourrait agir.
Cela colle a la clause aucune garanties de la license. Dans tous les cas, les utilisateurs Debian peuvent être assurés que le code stable rassemble une large audience et que la plupart des problèmes seront découvert de pendant l'utilisation (si problème il y a). Il n'est pas recommandé d'installer des logiciels non testés dans un système correct (si vous n'êtes pas en mesure de fournir un nécessaire audit de code). Pour finir, si des failles de sécurités étaient incluses dans la distribution, le processus permettant de les inclure (utilisation de signature numérique) assure que le problème pourra être remonté jusqu'au développeur, et que le projet Debian ne prend pas cela à la légère.
Oui et non. Debian est livrée avec certains utilisateurs prédéfinis (id <
99 comme décrit dans Debian Policy
) afin
de faciliter l'installation de nouveaux services (ils sont déjà lancés par
l'utilisateur approprié). Si vous n'avez pas l'intention d'en installer de
nouveaux, vous pouvez supprimer sereinement ces utilisateurs qui ne possèdent
aucun fichier sur votre système et qui n'exécutent aucun service.
Vous pouvez facilement trouver les utilisateurs ne possédant aucun fichier en exécutant la commande suivante (soyez sûr de l'exécuter en tant que root, étant donné qu'un utilisateur ordinaire pourrait ne pas avoir les droits nécessaires pour accéder à certains répertoires sensibles):
cut -f 1 -d : /etc/passwd | while read i; do find / -user "$i" | grep -q . && echo "$i"; done
Ces utilisateurs sont fournis par base-passwd
. Vous trouverez
dans sa documentation plus d'informations sur la manière dont ces utilisateurs
sont gérés dans Debian..
La liste des utilisateurs par défaut (avec un groupe correspondant):
/var/cache/man
/var/mail
appartiennent au
groupe mail, comme décrit dans la politique. L'utilisateur et le groupe sont
utilisés à d'autres fins de même que par différents MTA.
/var/lib/postgresql
appartiennent
à cet utilisateur afin d'imposer un niveau de sécurité convenable.
Autres groupes qui n'ont pas d'utilisateur associé :
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 l'usage.
/usr/share/doc/sudo/OPTIONS
.
/usr/src
. Il peut être utiliser afin de donner à un utilisateur
la capacité de manipuler les codes sources du système.
/etc/shadow
est lisible par ce groupe. Certains
programmes qui ont besoin d'accéder à ce fichier sont set gid shadow.
/var/run/utmp
et dans les
fichiers similaires. Les programmes qui nécessitent l'écriture sont sgid utmp.
/usr/local
, /home
) sans les privilèges root.
Comparé au groupe "adm" qui lui est plus apparenté à la
surveillance/sécurité.<--!traduction de monitoring. -> surveillance.
jpg -->
Le groupe 'adm' rassemble les administrateurs et est utile afin de le autoriser
à lire les journaux d'activités sans avoir à utiliser su
. Le
groupe 'staff' est profitable pour des personnes du genre administrateur
système helpdesk/junior et leur offre la capacité de faire des choses dans
/usr/local
et de créer des répertoires dans home
.
Ceci est juste une approche qui est, d'un côté, une sécurité présente et d'un autre coté l'utilisation amicale. Contrairement à OpenBSD, qui désactive tous les services à moins que ceux-ci soit activés par l'administrateur, Debian GNU/Linux activera tous les services installés à moins de les désactiver(see Désactivation de services daemon, Section 3.6.1 pour plus d'information). Après tout, vous avez installés ces services de votre propre chef, n'est ce pas?
Il y a un grand nombre de discussions sur les mailings listes Debian (sur debian-devel et debian-security) à propos de ce que doit être l'installation standart. Cependant, il n'y a pas de consensus à ce jour (10 mars 2002) sur la solution à adopter.
Inetd n'est pas aisé à retirer étant donné que netbase
dépend du
paquet qui le fourni à savoir (netkit-inetd
. Si vous voulez le
retirer, vous pouvez soit le désactiver (voir Désactivation de services daemon, Section
3.6.1 ou retirer le paquet en utilisant le paquet equivs
à la
place.
Le port 111 est mappeur de port sunrpc, il est installé par défaut dans toutes les installations de base d'un système Debian puisqu'il est requit pour savoir lorsque le programme d'un utilisateur a besoin de RPX pour fonctionner correctement. Dans tous les cas, il est utilisé en grande partie pour NFS. Si vous n'en avez pas besoin retirer le comme décrit dans Désactivation des services RPC, Section 5.14.
Identd est employé par les administrateurs pour fournir les détails userid aux systèmes distants qui veulent savoir qui est la personne responsable pour une connexion donnée sur votre machine. Cela inclus notamment les serveurs mail, FTP et IRC, cependant, il peut être utilisé pour remonter l'utilisateur qui attaque un système distant par l'intermédiaire de votre machine.
Pour suivre une longue discussion à ce propos, voir mailing
list archives
, basiquement, si vous ne savez pas à quoi cela sert,
ne l'activez pas. Mais si vous le bloquez par un pare-feu, s'il vous
plaît créez une règle de rejet et non pas une règle de déni, autrement la
communication pourrait continuer jusqu'à réception d'une expiration de délai
(timeout)(see reject
or deny issues
).
Bien sûr que vous pouvez, les ports que vous laissez ouvert doivent adhérer à la politique de votre site concernant les services publiques disponibles pour les autres systèmes. Vérifiez s'ils sont ouvert par inetd (voir Désactivation des services inetd, Section 3.6.2) ou par d'autres paquets installés et prenez les mesures adéquates (configuration d'inetd, suppression du paquet, éviter qu'il démarre au démarrage, ...)
/etc/services
, suis-je ok ?
Non, le fichier /etc/services
fourni juste une
cartographie d'un nom virtuel à un numéro de port donné, la suppression des
noms ne va pas (en général) prévenir les services d'être lancés. Certains
daemons ne se lanceront pas si /etc/services
est modifié mais ce
n'est pas dans la norme et ce n'est pas la manière recommandée de faire. Pour
ceci voir Désactivation de services daemon,
Section 3.6.1.
Les démarches à prendre afin de récupérer votre système dépend si vous avez ou pas appliqué les différentes procédures concernant la limitation d'accès à Lilo et au BIOS.
Si vous les avez limités tous les deux. Vous devez désactiver les fonctionnalités du BIOS (démarrer uniquement depuis le disque dur) avant de commencer, si vous avez également oublier votre mot de passe pour le BIOS, vous devrez ouvrir votre système et retirer manuellement la pile du BIOS.
Si vous avez des CD-Rom ou des disquettes de démarrage, vous pouvez :
ae
, la Debian 3.0 est livrée avec nano-tiny
qui est
similaire à vi
) /etc/shadow
et changer la ligne :
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=n'importe quel nombre)
to:
root::XXXX:X:XXXX:X:::
Ceci retirera le mot de passe root. Vous pouvez démarrer le système et vous connecter en tant que root (avec un mot de passe vide) depuis le prompt login:. Ceci fonctionnera ainsi jusqu'à ce que vous ayez configuré le système plus solidement, par exemple, vous autorisez des utilisateurs avec des mots de passe nul et le root peut se loguer à partir de la console.
Si vous avez aussi introduit ces caractéristiques, vous devrez entrer en
utilisateur unique. LILO nécessite de n'avoir aucune restriction, si vous en
avez mis en place relancer lilo
après le reset du root
sus-mentionné. C'est rusé puisque votre /etc/lilo.conf
devra être
modifié pour obtenir un système de fichier / qui est un disque virtuel et non
un réel disque dur.
Une fois que LILO n'est plus restreint, vous pouvez:
mount -o remount,rw /
passwd
(étant
donné que vous êtes le super-utilisateur, l'ancien mot de passe ne vous sera
pas demandé).
Lire ce document et prendre les mesures appropriées récapitulés ici. Si vous avez besoin d'aide, vous pouvez utiliser debian-security@lists.debian.org pour demander conseil sur la manière de rétablir/raccommoder votre système.
En regardant les logs (s'ils n'ont pas été modifiés), en utilisant un système
de détection d'intrusion (voir Mise en
place d'un système de détection d'intrusion, Section 9.1),
traceroute
, whois
et outils similaires (incluant des
analyses légales) vous pouvez rechercher la source de l'attaque. La manière
dont vous devez réagir sur ces information dépend uniquement de vos règles de
sécurité, et de ce que vous considérez comme une attaque Un scan
distant est il une attaque? Un test de failles de sécurité est il une attaque?
Tout d'abord, prenez un moment pour regarder si la vulnérabilité a été annoncée
sur les mailing listes publiques de sécurité (comme Bugtraq) ou autre forums.
L'équipe de sécurité Debian se met à jour à l'aide de ces listes, ils sont donc
peut être déjà conscient du problème. Ne lancez pas d'autres actions si vous
avez vu paraître l'annonce sur http://security.debian.org
.
Si vous n'avez rien vu de cela, envoyez s'il vous plaît sur les paquets affectés avec une description de la vulnérabilité rencontrée aussi détaillée que possible (la preuve par un code conçu est aussi bienvenue) à security@debian.org qui vous mettra en rapport avec l'équipe de sécurité.
Au lieu de mettre à jour une nouvelle version nous appliquons la rustine de sécurité à la version présente dans la version stable. La raison pour laquelle nous agissons ainsi est simple. Elle permet d'assurer qu'une version a le moins de changement possible, de cette manière les choses ne changeront pas ou ne se briseront pas et ce dû à une mise à jour de sécurité. Vous pouvez vérifier que vous utilisez une version sécurisée de votre paquet en regardant le changelog du paquet ou en comparant (version antérieure -slash- version Debian) exactement le numéro de version avec celui indiqué dans le journal de sécurité Debian (Debian Security Advisory).
Vous pouvez trouver des lignes comme celles-ci dans vos logs:
Apr 1 09:25:01 server su[30315]: + ??? root-nobody Apr 1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (uid=0)
Ne vous inquiétez pas trop, vérifiez d'abord si ceci n'est pas dû au travail
d'un job placé dans la cron (habituellement /etc/cron.daily/find
ou logrotate
):
$ grep 25 /etc/crontab 25 6 * * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily $ grep nobody /etc/cron.daily/* find:cd / && updatedb --localuser=nobody 2>/dev/null
Ajouter DenyFilter \*.*/ à votre fichier de configuration, pour
plus d'informations voir http://www.proftpd.org/critbugs.html
.
C'est l'information envoyée par l'Equipe de Sécurité Debian (voir ci-dessous)
informant qu'une mise à jour de sécurité concernant une vulnérabilité est
disponible pour le système d'exploitation Debian. Les DSAs signés sont envoyés
aux mailing listes publique et postés sur le site Debian (sur la page de garde
et sur security
area
).
Les DSAs incluent les informations sur les paquets affectés, le bug découvert et l'endroit où récupérer les paquets mis à jour (ainsi que leurs sommes MD5).
C'est la plupart du temps un problème de fin de message. La liste debian-security-announce a un filtre qui autorise uniquement le poste des messages ayant une signature correcte appartenant à un des membres de l'équipe de sécurité.
D'autre part, certains logiciels de courrier changent la fin des messages ce qui rompt la signature. Assurez-vous pour cela que votre logiciel ne fait aucun encodage ou décodage MIME, ou de conversion de taulation/espace.
Des coupables connus sont fetchmail (avec l'option mimedecode activée) et formail (pour procmail 3.14 uniquement).
Dès que l'Equipe Sécurité reçoit une notification d'un incident, un ou plusieurs membres l'inspecte et délibère si Debian/stable est vulnérable ou pas. Si votre système est vulnérable, un travail est entrepris pour résoudre le problème. Le responsable du paquet est également contacté s'il n'a pas déjà contacter l'Equipe Sécurité. Finalement, la solution est testée et de nouveaux paquets sont préparés qui sont ensuite compilés sur toutes les architectures stables et mis à disposition après coup. Après que toutes ces tâches soient terminées un "Debian Security Advisory (DSA)" est envoyé sur les listes de diffusions publiques.
L'analyse du temps que prend l'Equipe de Sécurité Debian pour envoyer un rapport et produire un paquet réparé à partir du moment où une vulnérabilité est connue, démontre qu'il faut un temps minimal avant que cette vulnérabilité ne soit réparée dans la distribution stable.
Un rapport published
in the debian-security mailinglist
montre que durant l'année 2001,
il fallait un temps moyen de 35 jours à l'Equipe de Sécurité Debian pour
sécuriser les vulnérabilités découvertes. Cependant, plus de 50% de ces
vulnérabilités ont été réparé dans un espace de dix jours, et plus de 15% de
celles-ci ont été réparé le jour même de la sortie du rapport.
Cependant, quand ils posent cette question les gens ont tendance à oublier que:
La réponse courte est: il n'y en a pas. Testing et unstable évoluent très rapidement et l'équipe de sécurité n'a pas les ressources nécessaires pour les supporter correctement. Si vous désirez un serveur stable et sécurisez nous vous encourageons fortement à rester sur une version stable.
Cependant, dans les faits, unstable est mis à jour très rapidement puisque les mises à jour de sécurité sont plus rapidement disponible en amont (Pour les autres versions, comme celles introduites dans la stable, il est nécessaire de faire un report).
A: Le but de security.debian.org est de mettre à disposition les mises à jour de sécurité aussi vite et facilement que possible. Les mirrors ajouteraient un niveau de complexité qui n'est pas nécessaire et qui provoquerait une certaine frustration en cas de non mise à jour.
A: Les informations de sécurité peuvent être envoyées à security@debian.org, qui est lu par tous les développeurs Debian. Si vous disposez d'informations sensible, utilisez team@security.debian.org qui n'est lu que par les membres de l'équipe de sécurité. Si vous le désirez, le mail peut être chiffré à l'aide de la clef de contact de la sécurité Debian(key ID 363CCD95).
Lorsque vous envoyez des messages à security@debian.org, ceux-ci sont envoyés aux mailing listes des développeurs (debian-private) à laquelle tous les développeurs Debian sont inscrits; tous les envois à cette liste sont tenus confidentiels (i.e. ne sont pas archivés sur le site public). Debian-security@lists.debian.org est une mailing liste publique, ouverte à tous ceux qui le désirent, et des archives sont disponible pour la recherche à partir du site Internet.
WNPP bug
et
proposer des logiciels que vous pensez utiles et qui ne sont pas encore
disponibles.
Linux Kernel
Security Audit Project
ou Linux
Security-Audit Project
accroît la sécurité de Debian GNU/Linux dès
lors que les contributions apportent, éventuellement, une aide supplémentaire.
Dans tous les cas, s'il vous plaît, passez en revue chaque problème avant de les rapporter à security@debian.org. Si vous êtes capable de fournir des rustines, cela accélérera le processus. Ne faites pas juste suivre le courrier de bugtraq étant donné qu'il a déjà été reçu. Fournir tout autre information est cependant toujours une bonne idée.
l'Equipe de Sécurité Debian se résume à cinq membres et deux secrétaires. l'Equipe Sécurité elle-même invite tout le monde à se joindre à l'équipe.
Non, l'équipe securité Debian ne vérifie pas tous les paquets et il n'existe pas de vérification automatique (lintian) afin de déceler de nouveaux paquets malveillants étant donné que ces vérifications sont plutôt impossible à détecter automatiquement. Les développeurs, toutefois, sont complètement responsables du logiciel qui est introduit dans Debian et aucun logiciel n'est introduit tant qu'il n'est pas signé par des développeurs habilités. Ceux-ci ont la responsabilité d'analyser le logiciel qu'ils maintiennent et la sécurité afférante. <--! Attente d'une meilleure traduction. Fait. jpg -->
Malheureusement non, l'Equipe Sécurité Debian ne peut pas gérer les deux versions stables (officieusement elle ne gère pas non plus la version unstable) et d'autres anciennes versions. Cependant, vous pouvez espérer des actualisations de la sécurité pour une période limitée juste après la sortie de la nouvelle distribution Debian.
Securing Debian Manual
2.8 14 febrero 2004Mon, 18 Nov 2002 23:13:42 +0100jfs@computer.org