12.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, consultez les
http://www.cert.org/stats/cert_stats.html ou générez des statistiques en utilisant la
http://nvd.nist.gov/statistics.cfm (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.
Rappelez-vous également que certaines failles signalées concernant Debian ne s'appliquent qu'à la branche
unstable (c'est-à-dire non publiée).
12.1.1.1. Debian est-elle mieux sécurisée que d'autres distributions Linux (comme Red Hat, SuSE, etc.) ?
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
http://www.cert.org/advisories/CA-2000-17.html 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
http://www.cert.org. 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.
12.1.1.2. De nombreux bogues Debian sont dans Bugtraq, cela la rend-elle plus vulnérable ?
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).
12.1.1.3. Debian possède-t-elle une certification relative à 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.
12.1.1.4. Existe-t-il un programme de durcissement pour Debian ?
Oui.
http://bastille-linux.sourceforge.net/, orienté à la base vers certaines distributions Linux (Red Hat et Mandrake), cela fonctionne actuellement aussi 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.
12.1.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.). 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 ?
12.1.1.6. Comment mieux sécuriser le service XYZ dans Debian ?
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).
12.1.1.7. Comment supprimer toutes les informations de version pour les services ?
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.
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.
12.1.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é, 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.
12.1.1.9. Pourquoi certains fichiers journaux ou fichiers de configuration sont-ils lisibles par tous les utilisateurs, est-ce que c'est sûr ?
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.
12.1.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 le système, vous pouvez les renforcer en 750. Pour les utilisateurs, veuillez lire
Section 4.11.19.1, « Limiter l'accès aux informations d'autres utilisateurs ».
12.1.1.11. Après l'installation de grsec ou d'un pare-feu, j'ai commencé à recevoir beaucoup de messages de console ! Comment les supprimer ?
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
dmseg(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=""
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 */
12.1.1.12. Les utilisateurs et les groupes du système d'exploitation
12.1.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 (identifiant utilisateur (UID) < 99 comme décrit dans la
http://www.debian.org/doc/debian-policy/ 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
(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.
12.1.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 des fichiers password et group, vous pouvez essayez de récupérer de ce problème en utilisant update-passwd (consultez update-passwd(8)).
12.1.1.12.3. Quelle est la différence entre les groupes adm et staff ?
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.
12.1.1.13. Pourquoi y a-t-il un nouveau groupe à chaque ajout de 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'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.
12.1.1.14. Questions concernant les services et les ports ouverts
12.1.1.14.1. Pourquoi tous les services sont-ils activés lors de l'installation ?
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
Section 3.5.1, « Désactivation de services démon » 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.
12.1.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 (consultez
Section 3.5.1, « Désactivation de services démon »), soit retirer le paquet en utilisant
equivs.
12.1.1.14.3. Pourquoi le port 111 est-il 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 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
Section 5.13, « Sécurisation des services RPC ».
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).
12.1.1.14.4. À quoi sert identd (port 113) ?
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
http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html). 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
http://logi.cc/linux/reject_or_deny.php3).
12.1.1.14.5. Des services utilisent les ports 1 et 6, quels sont ces services et comment les enlever ?
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.
12.1.1.14.6. Le port XYZ est ouvert, puis-je le fermer ?
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
Section 3.5.2, « Désactivation d'inetd ou de ses services ») 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).
12.1.1.14.7. Est-ce que la suppression de services de /etc/services va aider à sécuriser la 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) 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
Section 3.5.1, « Désactivation de services démon ».
12.1.1.15. Problèmes courants de sécurité
12.1.1.15.1. J'ai perdu mon mot de passe et je ne peux plus accéder au système !
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é).
12.1.1.16. Comment mettre en place un service pour les utilisateurs sans leur donner un compte avec invite de commande ?
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
Section 4.11.1, « Authentification utilisateur: PAM ») 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".
