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.
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)).
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.
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 ».
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.
