Cet article va vous exposer quelques trucs et astuces permettant d’améliorer le niveau de sécurité d’un serveur SSH. Ces astuces s’appuient sur l’implémentation la plus répandue du protocole SSH, OpenSSH. Ceci n’est pas un tutoriel dans le sens où toutes ces astuces ne peuvent être « activées » sur un même serveur SSH.
Les fichiers de Configuration d’OpenSSH
Pour rappel, OpenSSH possède un certain nombre de fichiers de configuration:
- /etc/ssh/sshd_config : fichier de configuration du serveur SSH,
- /etc/ssh/ssh_config : fichier de configuration du client SSH,
- ~/.ssh/ : répertoire contenant la configuration ssh propre à l’utilisateur, référencé par ~,
- ~/.ssh/authorized_keys : Liste des clés publiques (RSA et DSA) pouvant être utilisées pour se connecter à ce compte,
- /etc/hosts.allow et /etc/hosts.deny : la white list et la black list d’OpenSSH.
Ces fichiers seront cités dans la suite de l’article, sans faire référence à leur chemin complet.
Petit point à propos des mécanismes de chiffrement RSA et DSA.
Régulierement est posée la question de savoir qui du protocole RSA ou DSA est le plus sécurisé. La réponse est simple. A un dimensionnement de clés raisonnable, les deux protocoles offriront un niveau de sécurité équivalent. L’ANSSI (Agence Nationale de la sécurité des systèmes d’information) recommande aujourd’hui d’utiliser des clés de 2048bits (cf. Recommandations sur le dimensionnement des clés).
Cependant, ssh-keygen, l’outil de génération de clés d’OpenSSH ne permet pas de générer des clés DSA de 2048 bits (tout du moins dans la version d’OpenSSH 5.1p1 disponible sous Ubuntu Jaunty). Vous pouvez cependant la générer avec openssl et l’utiliser avec openssh.
Génération d’un clé DSA avec OpenSSL :
Génération de la clé privée
openssl dsaparam -noout -out ~/.ssh/id_dsa -genkey 2048
openssl dsa -in ~/.ssh/id_dsa -des3 -out ~/.ssh/id_dsa
Génération de la clé publique :
openssl dsa -in ~/.ssh/id_dsa -pubout -out ~/.ssh/id_dsa.pub
Règles et recommandations :
Renforcement de l’authentification
Un précédent article dans ce blog montre que les utilisateurs, en négligeant les risques liés au choix et au dimensionnement de leurs méthodes d’authentification sont souvent le maillon faible d’un système d’information.
Afin d’endiguer ce phénomène, voici quelques règles simples qui permettront de renforcer l’authentification des utilisateurs sur des serveurs SSH. Les clés de configuration listées sont à insérer/contrôler dans le fichier sshd_config.
- Ne pas autoriser de mots de passe vides :
PermitEmptyPasswords no
- Ne pas donner d’accès root à l’équipement :
PermitRootLogin no *
- Modifier le MOTD visualisé par les utilisateurs afin de les informer des risques encourus :
Banner <chemin de la nouvelle bannière>
- Ajouter un timeout à vos connexions afin que les utilisateurs ne laissent pas des shells ouverts indéfiniment :
ClientAliveInterval 300
ClientAliveCountMax 0
- Forcer les utilisateurs à avoir des mots de passe forts **
- Privilégier l’authentification par clé publique et désactiver l’authentification par mot de passe :
PasswordAuthentication No
- Mettre en place une authentification forte / bi-facteur.
* En règle générale, il est recommandé pour deux raisons d’éviter de donner l’accès à des comptes génériques :
- le nom d’utilisateur est connu de tous (une information sur deux est disponible!),
- il est impossible pour un administrateur du SI de savoir qui a fait quoi. Il est préférable de s’authentifier d’abord à l’aide d’un compte nominatif, puis de prendre les privilèges nécessaires (les logs système permettront de savoir quel utilisateur a pris quels droits à un instant T).
** Cette réflexion va bien au-delà du simple renforcement de l’authentification sur des serveurs SSH et doit être prise à un niveau global dans l’administration d’un système d’information.
Renforcement de l’accès au serveur SSH
- La première règle de sécurité est évidente : un démon SSH inutilisé est un démon SSH de trop.
- Vérifier que les serveurs SSH ne supportent que la version 2 du protocole, la première version étant désormais ancienne et faillée comme un OS de Microsoft. Pour cela, vérifier que votre sshd_config possède l’entrée suivante :
« Protocol 2″
- Limiter les comptes autorisés à se connecter via SSH en utilisant les clés AllowUsers et DenyUsers.
AllowUsers john
n’autorisera que l’utilisateur john à se connecter à la machine
DenyUsers mysql
n’autorisera pas l’utilisateur mysql.
Ceci est particulièrement utile dans le cadre de machines disposant de compte générique (base de données …)
- Paramétrer les firewalls pour limiter l’accès à vos services (dans un monde parfait, l’accès SSH est limité à votre LAN)
- Changer le port de connexion, limiter les adresses de binding
ListenAddress 192.168.1.5
Port 300
- Renforcer votre serveur SSH contre les attaques brute-force en utilisant des systèmes tels que DenyHosts ou fail2ban
- Désactiver l’authentification par mot de passe. Ceci vous protégera efficacement des attaques par force brute
- Enfin, si l’authentification par mot de passe est nécessaire, privilégier l’authentification « keyboard-interactive ». Ceci également afin de vous protéger des attaques par force brute.
Modifier votre sshd_config de la manière suivante:
PasswordAuthentication no
ChallengeResponseAuthentication yes
DenyHosts : Mettre à jour votre hosts.deny
DenyHosts est un démon, écrit en python qui scrute le /var/log/auth.log pour détecter les échecs d’authentification. Si un nombre (configurable) de tentatives échouées est atteint, l’ip source est alors blacklistée dans le hosts.deny du système. DenyHosts implémente également un mécanisme de purge. Un court article ici (en anglais) montre une configuration simple pour DenyHosts.
Authentification Bi-Facteur avec OpenSSH
Une des authentifications bi-facteur la plus simple à mettre en oeuvre est une authentification password / clé publique + OTP (one-time password).
Pour debian la marche à suivre est la suivante :
apt-get install libpam-opie opie-server
Ensuite dans /etc/pam.d/ssh, ajouter l’entrée pam_opie :
auth required pam_env.so envfile=/etc/default/locale
auth required pam_opie.so
Le fichier de configuration du serveur ssh doit avoir une authentification positionnée à :
ChallengeResponseAuthentication yes
PasswordAuthentication no
Il reste à initialiser le serveur OTP :
opiepasswd -c
Rentrer la passphrase qui permettra de générer les OTP. Il ne reste plus qu’à déployer des calculatrices OTP sur les postes clients (paquet opie-client). La procédure d’authentification sera alors la suivante :
jack@bauer:~$ ssh login@device
otp-md5 492 ne9401 ext, Response:
Password:
...
Contribution d’Olivier Hervieu pour TechnoAddict
Tags:
ANSSI,
DenyHosts,
DSA,
Fail2ban,
OpenSSL,
OPIE,
RSA,
sécurité,
SSH
Planet-libre, Securite Informatique
ANSSI, DenyHosts, DSA, Fail2ban, OpenSSL, OPIE, RSA, sécurité, SSH
