Sécurisez votre déploiement SSH avec l'authentification à deux facteurs WiKID

Sécurisez votre déploiement SSH avec l’authentification à deux facteurs WiKID

SSH offre un canal hautement sécurisé pour l’administration à distance des serveurs. Cependant, si vous faites face à un audit pour des exigences réglementaires ou commerciales, telles que le PCI Visa/Mastercard, vous devez être conscient de certaines lacunes potentielles liées à l’authentification qui peuvent causer des maux de tête lors d’un audit. Par exemple :

Il n’y a aucun moyen de contrôler quels utilisateurs ont une autorisation par clé publique
Il n’y a aucun moyen d’imposer la complexité des phrases de passe (ou même d’être sûr qu’une est utilisée)
Il n’y a aucun moyen d’expirer une clé publique

Dans ce document, nous allons démontrer comment combiner l’authentification à deux facteurs de WiKID avec un serveur passerelle SSH avec des clés privées hébergées pour créer une solution d’accès à distance hautement sécurisée, auditable et facile à utiliser. Le système d’authentification forte WiKID est une solution d’authentification à deux facteurs commerciale/open source. Tout d’abord, nous allons configurer un domaine sur le serveur WiKID, puis ajouter les serveurs en tant que clients réseau au serveur WiKID, et enfin configurer la boîte de passerelle et les serveurs cibles - dans notre cas, des serveurs Fedora Core 6.

Ajouter un domaine au serveur WiKID

Créer un domaine

Créer un client réseau

Après avoir enregistré les informations du domaine, cliquez sur l’onglet Client Réseau et Créer un Nouveau Client Réseau. Entrez un nom pour ce client et l’adresse IP de la passerelle SSH sur le réseau interne. Sélectionnez Radius comme protocole et le domaine que vous avez créé ci-dessus comme domaine.

Créer un client réseau

Cliquez sur Ajouter pour accéder à la page suivante et entrez le secret partagé pour Radius.

Créer un client réseau 2

Vous devrez répéter ce processus pour chaque serveur de votre réseau.

Configurer la passerelle SSH

Maintenant, nous allons configurer la passerelle SSH centrale. Cette boîte Linux est la passerelle/proxy vers tous les serveurs de production de la ferme. Elle doit être verrouillée avec aucun logiciel ou service superflu en cours d’exécution. Elle doit avoir une interface externe pour les connexions entrantes et une interface interne pour les connexions internes. Tout d’abord, nous allons configurer la boîte de passerelle pour utiliser WiKID pour l’authentification forte des utilisateurs SSH. Modifiez votre fichier /etc/pam.d/sshd comme suit :

#%PAM-1.0   
auth       sufficient   /lib/security/pam_radius_auth.so   
auth       include      system-auth   
account    required     pam_nologin.so   
account    include      system-auth   
password   include      system-auth   
session    include      system-auth   
session    required     pam_loginuid.so

Ajoutez votre serveur WiKID au fichier /etc/raddb/server, en utilisant l’adresse IP interne du serveur WiKID et le secret partagé que vous avez entré dans la page de création du client réseau :

# server[:port] shared_secret      timeout (s)   
127.0.0.1       secret             1   
xxx.xxx.xxx.xx  wikidserver_secret 3

Ajoutons également un peu de sécurité à la configuration SSH ici. Ouvrez votre /etc/ssh/sshd_config (pas le fichier ssh_config à proximité). Ajoutez ces options de configuration :

#Protocol 2,1   
#Vérifiez que seul le protocole 2 est autorisé :   
Protocol 2   
#Interdire la connexion root :   
PermitRootLogin no   
#Interdire les comptes sans mots de passe :   
PermitEmptyPasswords no

Si vous souhaitez changer le port, vous le pouvez. Cela n’arrêtera pas un attaquant, mais cela pourrait réduire les événements de journal causés par des script kiddies. Cette boîte de passerelle est maintenant configurée pour utiliser des mots de passe à usage unique WiKID pour l’authentification SSH. Tous les utilisateurs doivent être enregistrés auprès du serveur WiKID et personne ne peut se connecter en tant que root. Avant de quitter cette boîte, nous allons faire quelque chose d’un peu différent - nous allons faire en sorte que les utilisateurs créent leur clé privée RSA sur la passerelle. Une fois que chaque utilisateur est connecté à la boîte avec WiKID, demandez-leur de créer leurs clés :

ssh-keygen -t rsa

À mon avis, les phrases de passe pour ces clés sont redondantes. Elles sont là uniquement pour créer une fonctionnalité de connexion unique dans la ferme de serveurs. Évidemment, vous devez être prudent pour vous assurer que les utilisateurs n’ont pas accès à d’autres clés.

Configurer les serveurs cibles

Évidemment, nous configurons ces serveurs pour n’accepter que les demandes SSH entrantes de la passerelle. Nous faisons cela en restreignant l’accès sur le port 22 à nos adresses internes. Modifiez /etc/sysconfig/iptables et ajoutez ou modifiez la ligne pour SSH sur le port 22 :

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT

Il y a de fortes chances que vous puissiez utiliser la configuration standard pour sshd_config, qui permet l’authentification par clé publique. Donc, nous avons terminé !

Conclusion

SSH à distance est maintenant extrêmement sécurisé. Aucun utilisateur ne peut accéder à la ferme de serveurs sans d’abord obtenir un code d’accès à usage unique du serveur WiKID. Les deux facteurs d’authentification sont la possession du jeton WiKID (et de sa clé cryptographique) et la connaissance du PIN. Comme le PIN est validé sur le serveur WiKID, il est très facile de désactiver un utilisateur. Tout est enregistré et tout auditeur devrait être très satisfait.

De plus, vous pourriez exiger un code d’accès à usage unique WiKID pour l’accès root sur les machines internes. Il suffit de créer un nouveau domaine pour su et de modifier /etc/pam.d/su en conséquence. Cela vous permettra également de diviser les serveurs en différents groupes pour la gestion. Par exemple, si vous avez un ensemble de serveurs pour les RH auxquels seuls certains administrateurs ont accès root, ils peuvent être configurés pour un domaine WiKID spécifique - permettant un contrôle d’accès granulaire et une authentification forte. Obtenez plus d’informations sur l’authentification à deux facteurs sur le site Web de WiKID.