SSH

Date Auteur/auteure Catégories
21/03/2015 Janiko Sécurisation

Le plus important : oublier telnet

Ce principe est facile à comprendre et à retenir : il ne faut jamais plus utiliser telnet, ni rlogin ni rsh !

Si ces utilitaires ont eu leur heure de gloire, il faut totalement les proscrire de tout serveur (et de toute machine) reliée à internet. En effet, tous les flux circulent en clair, y compris le couple login/mot de passe. Ça n’est pas très grave pour un réseau purement interne, mais dès qu’une machine est visible de l’extérieur, il faut supprimer ces commandes (si c’est possible) et les interdire via votre pare-feu. Pas de question à se poser !

SSH = Secure Shell

Comme son nom l’indique, SSH est un outil qui permet d’avoir accès à un shell de manière sécurisée sur une machine distante. Enfin, sécurisée, c’est vrai mais faut faire attention.

SSH désigne à la fois l’outil qui permet de se connecter mais aussi la norme utilisée pour réaliser cette communication.

Chiffrement

SSH est chiffré : tout ce que vous ferez une fois connecté n’apparaîtra pas en clair. Si rien n’est impossible, un pirate aura cependant beaucoup de difficulté à déchiffrer ce flux, et tout ce qui complique la vie d’un pirate est bon à prendre.

Sécurisation de SSH

Protocole V1

Comme tout n’est pas parfait du premier coup, il faut savoir qu’il existe 2 versions majeures de protocole SSH : la v1 et la v2. Logique, mais hélas la v1 souffre de quelques problèmes qui la rendent fragile et sensible à certaines attaques.
Conséquence : N’autorisez que la version 2 du protocole.

Comment se limiter à la v2 (sur le serveur)

C’est tout simplement un paramètre de SSH. Pour cela, il suffit d’éditer /etc/ssh/sshd_config, et décommenter la ligne Protocol en ne laissant que 2.

La fichier doit donc contenir quelque chose qui ressemble à :

... 
Compression yes 
Protocol 2 
RSAAuthentication yes 
...

Attention au piège !

Il y a un piège ? Oui, dans certaines conditions : il faut faire attention côté client. Si vous êtes sous Windows, vous utilisez certainement PuTTY pour vos connexions SSH. Or si vous ne spécifiez pas de rester uniquement en version 2 de SSH, le serveur pourrait demander à passer en version 1, vulnérable, en indiquant qu’il ne connaît que celle là. Et PuTTY acceptera, si vous ne spécifiez pas 2 only.

Or dans le cas d’une attaque man-in-the-middle, le fraudeur aura tout intérêt à tenter de passer par la version la moins sécurisée de SSH ! Ce genre de crypto downgrade attack est également utilisé dans le cas de Freak.

Interdire l’accès à root ?

Il existe plusieurs façons de le faire. Mais d’abord, pourquoi le ferait-on ? Et bien parce que si vous interdisez l’accès à root, vous serez obligé de faire du su ou du sudo pour lancer des commandes d’administration. Donc un 2e mot de passe à saisir, donc à deviner. Donc double difficulté pour l’attaquant.

Ca n’est pas un impératif absolu, si vous avez un mot de passe suffisamment fort. Cela dit, on n’est jamais trop prudent.

Changer de port

Les ports (tcp ou udp) les plus utilisés et les plus courants sont répertoriés1 et donc, pour des questions de commodité évidente, sont connus de tous. On parle même de well-known ports pour les les ports allant de 0 à 1023 (ports systèmes). Il est ainsi facile de savoir quel port utiliser pour un service donné, et cela empêche également que deux services se marchent sur les pieds en utilisant le même.
Il ne s’agit toutefois que d’une recommandation : libre à vous d’utiliser un port habituellement attribué à un autre service ou de modifier le numéro de port habituel d’un service.

Cela peut être une bonne pratique sur des services attaqués par force brute, comme SSH : le port 22 (celui de SSH habituellement) est probablement le premier et le plus attaqué. Donc autant ne pas faciliter la tâche aux attaquants est positionner le service SSH (sshd sur Linux) sur un autre port, afin de rendre inopérante les attaques automatiques.

En général ça se passe dans le fichier /etc/ssh/sshd_config, dans les toutes premières lignes :

# The strategy used for options in the default sshd_config shipped with 
# OpenSSH is to specify options with their default value where 
# possible, but leave them commented.  Uncommented options change a 
# default value. 
Port 4567

Limiter l’accès à SSH

Vous pouvez aussi limiter l’accès à SSH via le pare-feu, en n’autorisant que certaines adresses IP. C’est plus sûr, mais ça n’est pas toujours pratique, si vous avez besoin d’accéder à votre machine depuis un endroit inhabituel ou si l’adresse IP de votre connexion internet n’est pas fixe (ce qui arrive avec les connexions par fibre).

Autres articles