Antoine Benkemoun

09 Juil, 2009

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

Posté par Antoine dans la catégorie Libre|Réseau|Sécurité

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.

6 Commentaires to "Sécuriser SSH, c’est pas bien compliqué"

1 | Julien

juillet 10th, 2009 at 10 h 24 min

Avatar

JAMAIS D’ACCES EN ROOT VIA SSH!!!! QUELQUE SOIT LA RAISON !!!! ON PEUT TOUJOURS FAIRE SU APRES !!! BORDEL !!!
Et sinon de façon plus construite:
# Sudo existe et il y a une raison. Si il faut donner des privileges root on le fait via le fichier /etc/sudoers. Et là on peut controler les permissions utilisateurs.
# Deuxième point le bruteforcing existe et en entrant PermitRootLogin à No on bloque l’accès à root via ssh.
Ainsi on bloque le bruteforce directement au niveau du compte. Et ceci car les comptes les plus utilisés pour le bruteforce sont root,admin,guest,test et user.

2 | admin

juillet 10th, 2009 at 10 h 28 min

Avatar

Je suis entièrement d’accord avec toi.

L’accès en root peut être autorisé si la machine n’est pas accessible du net… Dans le cas où le port n’est accessible qu’à partir d’un réseau local d’administration, ca ne me choque pas d’autoriser le SSH en root. Après rien n’empêche de mettre fail2ban pour éviter un bruteforce venant de l’intérieur… Cependant, à partir du moment où l’attaque vient du réseau d’administration, ce ne sont plus des problèmes technologiques qu’il faut résoudre mais humains…

C’est plus simple de donner un utilisateur. Cependant, une solution type NIS ou TACACS (pour les équipements réseau) est bien plus efficace.

3 | Ludo

juillet 10th, 2009 at 20 h 48 min

Avatar

@julien

Je ne suis pas d’accord avec tout ce que tu as dit pour différentes raisons.

1) « Ne pas autoriser la connexion en root par SSH »

Pourquoi donc ?

Pour éviter le brute-force ? Installe Fail2Ban ! Tu peux le mettre en mode parano et blacklister à jamais toute IP ayant raté sa connexion en rot.

Tu crains pour la sécurité de ton mot de passe ? N’autorise que les connexions par clé publique. Le nombre de clé différentes est tellement énorme (surtout avec une clé de 4096 octets) que tout bruteforce est inconcevable.

2) « Sudo est utile »

Ah ? Et pour quelle raison ?
Pour faire court, utiliser sudo pour passer en root revient à supprimer la protection du mot de passe root.
Après, « rm -rf / » est bloquer depuis longtemps, mais lancer des commandes hasardeuses en root ne peut de toute façon pas etre empeché.

4 | admin

juillet 10th, 2009 at 22 h 04 min

Avatar

@Ludo

Par rapport à fail2ban, si cet outil a une utilité c’est que le réseau est mal conçu. Il ne doit pas être possible au monde entier de faire des tentatives de bruteforce. A partir du moment où c’est le cas, j’estime qu’il y a un problème. Il existe des masses de moyens de sécurisation (OpenVPN, Filtrage, Liaisons dédiées, IPsec, …) donc il n’y a quasiment aucune raison que le service SSH soit ouvert à des plages d’IP publiques (une poignée d’IP éventuellement).

Pour moi, l’authentification par clé est une mauvaise solution. Les clés ca a tendance à se démultiplier avec les systèmes d’authentification par clés partagées… Un bon mot de passe ca suffit amplement.

5 | Maxime DERCHE

juillet 11th, 2009 at 15 h 03 min

Avatar

Deux petites remarques :
* d’une part, la rumeur n’a *jamais* concerné OpenSSH, mais portable-OpenSSH, ce qui est *très* différent ;
* d’autre part, concernant le sentiment de sécurité qui règne à propos du protocole SSH, je dirais qu’en fait c’est faux, mais qu’il y a clairement un sentiment de sécurité à propos de la suite logicielle OpenSSH.

OpenSSH est une suite logicielle développée par une partie de l’équipe de développement d’OpenBSD, pour OpenBSD. Il existe également une version modifiée d’OpenSSH, nommée portable-OpenSSH, maintenue par la même équipe, destinée aux autres systèmes (GNU/Linux, etc.), et ne bénéficiant donc pas forcément du même niveau de sécurité que le « vrai » OpenSSH.

Et puis bon, le fait qu’il soit si simple de sécuriser (portable-)OpenSSH découle du fait qu’il est développé chez OpenBSD (vous savez, l’OS qui publie une version tous les six mois, à date fixe ?)…

Cordialement,
Maxime

6 | admin

juillet 12th, 2009 at 11 h 45 min

Avatar

Ah merci pour ces précisions Maxime mais les sources que je cite ne mentionnent qu’OpenSSH donc d’où l’erreur dans mon article.

Ajoutez votre commentaire

A propos de ce blog

Ce blog a pour objectif de partager des informations avec tous les internautes. Comme indiqué dans le titre, je traiterais de différrents sujets gravitant autour de la sécurité informatique, de la virtualisation, de la l'administration système et du réseau.