Sécuriser SSH, c’est pas bien compliqué

doc_openssh_logo_2Vous le savez peut être déjà, une faille semble avoir été trouvé dans SSH. Pour ceux qui n’ont jamais fait d’administration système, le protocole SSH est le protocole utilisé pour administrer les serveurs Linux/BSD ainsi que de très nombreux équipements réseau. Qui dit faille SSH dit accès total aux machines disposant de ce service. Pour vous rassurer, la faille semble ne toucher que les versions les plus vieilles d’OpenSSH. Vous qui disposez d’une Debian, vous êtes à l’aise car vous savez que Debian a un cycle de release assez rapide. Vous qui croyiez être à l’aise sur votre RHEL (Red Hat Entreprise Linux) ou CentOS et la stabilité qu’un cycle de release lent, vous devez être plus stressé et vous avez bien raison ! Cependant, elle semble peu crédible et basée sur de très nombreuses hallucinations suppositions.

Constat

Tout le monde le sait, le SSH est probablement le protocole le plus sensible sur une machine ou un équipement voire sur Internet. Il semble cependant régner un climat de confiance excessive autour de ce protocole. Dans le même temps, d’autres protocoles sont ultra surveillés comme c’est le cas pour HTTP ou DNS alors qu’ils sont moins sensibles. Je pense que dire que SSH est le protocole le plus sensible n’est pas une exagération trop importante. Certes le protocole DNS est ultra critique, mais une faille sur le protocole SSH permettra la modification des zones DNS présentes sur la machine. Une faille SSH permettra de prendre la main sur les routeurs et de modifier les informations BGP et ainsi de suite.

Bloquer les accès

La plus simple des parades à toutes les failles éventuelles sur SSH est de bloquer l’accès à ce dernier. Bien sur, si vous bloquez l’accès complètement, vous ne pourrez plus administrer vos machines mais il y a tout de même des solutions. Il est indispensable de ne pas autoriser la terre entière à accéder à votre serveur SSH. On ne peut pas considérer le service SSH sécurisé si il est accessible par la terre entière. Vous pouvez mettre une règle de filtrage permettant de n’autoriser que l’IP de votre connexion Internet. Si vous avez une connexion avec IP dynamique, vous pouvez utiliser OpenVPN pour accéder à votre zone de serveurs et n’autorisez la connexion qu’à partir du serveur VPN. Si vous êtes une société avec un minimum de moyens, mettez en place un tunnel MPLS jusqu’à votre datacentre.

L’accès en root, c’est mal…

Il est également peu raisonnable d’autoriser les accès SSH directement en root. Si vous donnez le mot de passe root à tous les utilisateurs de la machine, il sera plus difficile de leur en interdire l’accès par la suite. Ceci est d’autant plus grave si votre serveur SSH est accessible par tout le monde. De plus, un accès avec un compte utilisateur permet d’éviter que tout le monde puisse faire rm -Rf / par erreur. Une exception existe à cette règle, si votre filtrage au niveau du réseau est suffisament efficace et que vous avez la possibilité de supprimer l’accès en supprimant l’accès au VPN, il est possible d’accéder directement en root aux serveurs.