Product SiteDocumentation Site

Chapitre 5. Sécurisation des services du système

5.1. Sécurisation de SSH
5.1.1. Chrooter SSH
5.1.2. Clients SSH
5.1.3. Interdire les transferts de fichiers
5.1.4. Restriction d'accès au seul transfert de fichiers
5.2. Sécurisation de Squid
5.3. Sécurisation de FTP
5.4. Sécurisation de l'accès au système X Window
5.4.1. Vérifiez le gestionnaire d'affichage
5.5. Sécurisation de l'accès à l'impression (le problème lpd et lprng)
5.6. Sécurisation du service de courrier
5.6.1. Configurer un Nullmailer
5.6.2. Fournir un accès sécurisé aux boîtes à lettres
5.6.3. Réception du courrier de manière sûre
5.7. Sécurisation de BIND
5.7.1. Configuration de BIND pour éviter de mauvaises utilisations
5.7.2. Changer l'utilisateur de BIND
5.7.3. Chrooter le serveur de domaine
5.8. Sécurisation d'Apache
5.8.1. Désactiver la publication de contenu sur le web par les utilisateurs
5.8.2. Permissions des fichiers de journalisation
5.8.3. Fichiers web publiés
5.9. Sécurisation de finger
5.10. Paranoïa généralisée du suid et du chroot
5.10.1. Créer des environnements chrooté automatiquement
5.11. Paranoïa généralisée du mot de passe en texte clair
5.12. Désactivation du NIS
5.13. Sécurisation des services RPC
5.13.1. Désactivation des services RPC
5.13.2. Limiter l'accès aux services RPC
5.14. Ajouter des capacités au pare-feu
5.14.1. Protéger le système local avec un pare-feu
5.14.2. Utiliser un pare-feu pour protéger d'autres systèmes
5.14.3. Mettre en place un pare-feu
Les services présents sur un système peuvent être sécurisés de deux façons :
  • les rendre accessibles uniquement aux points d'accès (interfaces) nécessaires ;
  • les configurer correctement ainsi seuls les utilisateurs habilités pourront les utiliser.
Restreindre les services pour qu'ils ne soient accessibles que depuis un endroit bien spécifique peut être fait au niveau du noyau (pare-feu), configurez les services pour écouter uniquement sur une interface définie (certains services ne fournissent peut-être pas cette fonctionnalité) ou utilisez tout autre méthode, par exemple le correctif vserver pour Linux (2.4.16) peut être utilisé pour forcer les processus à n'utiliser qu'une interface.
Concernant les services lancés par inetd (telnet, ftp, finger, pop3, etc.), il est à noter que inetd peut être configuré pour que les services n'écoutent que sur une interface précise (en utilisant la syntaxe service@ip), mais c'est une fonctionnalité non documentée. L'un de ses remplaçants, le métadémon xinetd, inclut une option bind pour faire cela. Consultez ixnetd.conf(5)
service nntp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = news
        group           = news
        server          = /usr/bin/env
        server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
        bind            = 127.0.0.1
}
Les paragraphes suivants détaillent comment déterminer les services qui peuvent être configurés correctement en fonction de leur utilisation.

5.1. Sécurisation de SSH

Si vous utilisez toujours TELNET au lieu de SSH, vous devriez prendre une pause dans la lecture de ce manuel pour remédier à cela. SSH devrait être utilisé pour toutes les connexions distantes à la place de TELNET. À une époque où il est facile de scruter le trafic Internet et d'obtenir les mots de passe en clair, vous devriez utiliser uniquement les protocoles qui utilisent la cryptographie. Par conséquent, effectuez maintenant un apt-get install ssh sur le système.
Encourager tous les utilisateurs du système à utiliser SSH au lieu de TELNET, ou mieux encore, désinstallez telnet/telnetd. De plus, vous devriez éviter de vous connecter au système en utilisant SSH en tant que superutilisateur et préférer l'utilisation de méthodes alternatives pour devenir superutilisateur comme su ou sudo. Enfin, le fichier sshd_config, dans /etc/ssh, devrait être modifié comme suit pour accroître la sécurité.
  • Ne faîtes écouter SSH que sur une interface donnée, juste au cas où vous en ayez plus d'une (et ne voulez pas que SSH y soit disponible) ou si vous ajoutez, dans le futur, une nouvelle carte réseau (et ne voulez pas de connexions SSH dessus).
  • Essayez autant que possible de ne pas autoriser de connexion en tant que superutilisateur. Si quelqu'un veut devenir superutilisateur par SSH, deux connexions sont maintenant nécessaires et le mot de passe du superutilisateur ne peut être attaqué par force brute par SSH.
  • Port 666 ou ListenAddress 192.168.0.1:666 change le port d'écoute, ainsi l'intrus ne peut être complètement sûr de l'exécution d'un démon sshd (soyez prévenus, c'est de la sécurité par l'obscurité).
  • PermitEmptyPasswords no Les mots de passe vides sont un affront au système de sécurité.
  • Autorise seulement certains utilisateurs à avoir accès par SSH à cette machine. user@host peut également être utilisé pour n'autoriser l'accès qu'à un utilisateur donné depuis un hôte donné.
  • Autorise seulement certains membres de groupes à avoir accès par SSH à cette machine. AllowGroups et AllowUsers ont des directives équivalentes pour interdire l'accès à la machine. Sans surprise elles s'appellent « DenyUsers » et « DenyGroups ».
  • Il vous appartient complètement de décider ce que vous voulez faire. Il est plus sûr d'autoriser l'accès à la machine uniquement aux utilisateurs avec des clefs SSH placées dans le fichier ~/.ssh/authorized_keys. Si c'est ce que vous voulez, positionnez cette option à « no ».
  • Désactiver toute forme d'autorisation dont vous n'avez pas réellement besoin  si vous n'utilisez pas, par exemple, RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication ou RhostsAuthentication, vous devriez les désactiver même s'ils le sont déjà par défaut (consultez la page de manuel sshd_config(5)).
  • Désactiver le protocole version 1, car il a des défauts de conception qui facilitent le piratage de mots de passe. Pour obtenir de plus amples renseignements, consultez http://earthops.net/ssh-timing.pdf ou le http://xforce.iss.net/static/6449.php.
  • Ajouter une bannière (elle sera récupérée du fichier) pour les utilisateurs se connectant au serveur SSH. Dans certains pays, envoyer un avertissement avant l'accès à un système donné avertissant des accès non autorisés ou du suivi des utilisateurs devrait être ajouté pour avoir une protection légale.
Vous pouvez également restreindre l'accès au serveur ssh en utilisant pam_listfile ou pam_wheel dans le fichier de contrôle PAM. Par exemple, vous pourriez bloquer tous les utilisateurs qui ne sont pas dans /etc/loginusers en ajoutant cette ligne à /etc/pam.d/ssh :
auth required pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers
Pour finir, soyez conscient que ces directives proviennent d'un fichier de configuration OpenSSH. Actuellement, trois démons SSH sont couramment utilisés, ssh1, ssh2, et OpenSSH par les gens d'OpenBSD. ssh1 était le premier démon SSH disponible et est toujours le plus couramment utilisé (il y a même des rumeurs à propos d'un portage pour Windows). ssh2 a beaucoup d'avantages par rapport à ssh1 sauf qu'il est diffusé sous une licence non libre. OpenSSH est un démon SSH complètement libre, qui gère à la fois ssh1 et ssh2. OpenSSH est la version installée sur Debian quand le paquet ssh est choisi.
You can read more information on how to set up SSH with PAM support in the http://lists.debian.org/debian-security/2001/11/msg00395.html.

5.1.1. Chrooter SSH

OpenSSH ne fournit pas de moyen à l'heure actuelle pour chrooter automatiquement les utilisateurs lors de la connexion (la version commerciale fournit cette fonctionnalité). Cependant, il existe un projet ayant pour but de fournir cette fonctionnalité pour OpenSSH également, consultez http://chrootssh.sourceforge.net, il n'est cependant pas empaqueté pour Debian actuellement. Vous pourriez cependant utiliser le module pam_chroot module comme décrit dans Section 4.11.15, « Restriction des utilisateurs ».
Dans Section B.7, « Environnement de chroot pour SSH », vous pouvez trouver plusieurs options pour créer un environnement chroot pour SSH.

5.1.2. Clients SSH

Si vous utilisez un client SSH pour se connecter au serveur SSH, vous devez vous assurer qu'il prend en charge les mêmes protocoles que ceux utilisés sur le serveur. Par exemple, si vous utilisez le paquet mindterm, il ne prend en charge que le protocole version 1. Cependant, le serveur sshd est, par défaut, configuré pour n'accepter que la version 2 (pour des raisons de sécurité).

5.1.3. Interdire les transferts de fichiers

Si vous ne voulez pas que les utilisateurs transfèrent des fichiers depuis et vers le serveur ssh, vous devez restreindre l'accès au sftp-server et l'accès scp. Vous pouvez restreindre sftp-server en configurant le bon Subsystem dans /etc/ssh/sshd_config.
Vous pouvez aussi cloisonner les utilisateurs dans un chroot (en utilisant libpam-chroot de telle sorte que même si le transfert de fichiers est autorisé, ils soient limités à un environnement qui ne contient aucun fichier système.

5.1.4. Restriction d'accès au seul transfert de fichiers

Vous pourriez restreindre l'accès aux utilisateurs pour leur permettre seulement le transfert de fichiers sans interpréteur de commandes interactif. Pour faire cela, vous pouvez :
  • soit interdire les connexions d'utilisateurs au serveur SSH (comme décrit ci-dessus par le fichier de configuration ou par la configuration PAM) ;
  • soit donner aux utilisateurs un interpréteur de commandes restreint comme scponly ou rssh. Ces interpréteurs de commandes restreignent les commandes disponibles pour les utilisateurs afin de ne pas leur donner de droits d'exécution à distance.