Pourquoi protéger son port SSH

 

Lorsqu'on dispose d'un serveur avec une adresse IP publique celui-ci devient vulnérable. De nos jours, des nombreux serveurs scannent en continu les adresse IP dans le monde afin d'y trouver une faille et pouvoir en profiter. L'objectif de cet article est de montrer comment sécuriser son serveur SSH.

Si vous gérez votre propre serveur, vous possédez forcement une connexion SSH pour y accéder à distance.
Le protocole SSH (Secure Shell) est conçu pour assurer une connexion sécurisée au serveur. SSH a été développé dans le souci de remplacer l'ancien protocole Telnet et d'autres protocoles d'accès à distance non sécurisés, qui envoient des informations, notamment des mots de passe, en clair, permettant de les découvrir en analysant le trafic.

Les deux versions principales du protocole sont SSH1 et SSH2. Le protocole SSH est principalement utilisé dans les systèmes d'exploitation Linux, Unix et Windows. Le chiffrement utilisé par SSH est destiné à garantir la confidentialité et l'intégrité des données transmises sur un réseau non sécurisé tel qu'Internet.

L'attaque par brute force est une des plus connues. Les attaques par "force brute" sont utilisées sur les bases de données de mots de passe. Celles-ci impliquent l'utilisation de combinaisons successives de caractères alphanumériques de différentes longueurs. Ils sont généralement efficaces contre les mots de passe faciles à deviner de 6 à 7 caractères.
Les attaques par dictionnaire sont similaires aux attaques par force brute, mais les mots du dictionnaire, leurs combinaisons et les caractères alphanumériques sont utilisés pour briser le mot de passe.

 

Pour les besoins de cet article nous avons utilisé ce projet : SSH-LOG-INFLUX qui nous permets de visualiser les attaques de type brute force sur notre serveur SSH.
Nous avons laissé ce service tourner durant 5 jours et le résultat fait froid dans le dos.

Pendant cette période nous avons reçu 31 781 attaques de type brute force. Comme vous pouvez le voir sur le graphique ci dessous les attaques viennent des 4 coins du monde mais majoritairement d'Asie.

 

 

 

Configuration serveur OpenSSH

Voici nos astuces pour rendre son serveur OpenSSH moins vulnérable aux attaques. Nous avons suivi les recommandations de l'ANSSI pour rédiger cet article. Toutes les modifications se font dans /etc/sshd/sshd_config.

En 2006, le protocole SSH a été mis à jour de la version 1 à la version 2. Il s'agissait d'une mise à niveau importante. Il y a eu tellement de changements et d'améliorations, en particulier autour du chiffrement et de la sécurité, que la version 2 n'est pas rétrocompatible avec la version 1. Pour empêcher les connexions des clients de la version 1, vous pouvez stipuler que votre ordinateur n'acceptera que les connexions des clients de la version 2. OpenSSH 6.9/6.9p1 (2015-07-01) est la première version qui n'utilise plus la v1.

Vous pouvez tester si votre serveur accepte le protocole avec la version 1 avec la commande suivante :

ssh -1 VOTRE_IP

 

Si vous n'obtenez pas ce résultat: SSH protocol v.1 is no longer supported.

Il faut rajouter la ligne suivante dans le fichier de configuration de SSH :

Protocol 2

 

Pour les connexions SSH, rendez un utilisateur avec le moins de droits possible mais avec un mot de passe aussi complexe que possible. On désactive donc la connexion via l'utilisateur root.

PermitRootLogin no

 

On peut restreindre l'accès SSH uniquement à l'utilisateur spécifié et en bloquer certains:

AllowUsers user_1 user_2
DenyUsers user_10 user_11

 

Si des groupes ont été crée minutieusement préalablement on peut utiliser les lignes suivantes:

AllowGroups example
DenyGroups root

 

Ensuite, c'est génial si vous changez le port sur lequel les connexions SSH sont établies, évitant ainsi plus de 50% des attaques automatiques par force brute.

Port 10666

 

Si le serveur possède plusieurs cartes réseau avec plusieurs adresses IP, il est judicieux de spécifier une adresse (de préférence interne, si possible) où les connexions SSH seront prises en charge:

ListenAddress 192.168.1.1

 

Réduisez le délai de connexion. Dans la configuration par défaut, le serveur SSH attend 2 minutes pour entrer un nom d'utilisateur et un mot de passe. Il est conseillé de réduire cet intervalle. 30 secondes suffisent.

LoginGraceTime 30

 

Désactiver les mots de passe vides:

PermitEmptyPasswords no

 

La redirection X11 doit être désactivée par défaut:

X11Forwarding no

 

Pluggable Authentication Modules (modules d’authentification enfichables, en abrégé PAM) est un mécanisme permettant d’intégrer différents schémas d’authentification de bas niveau dans une API de haut niveau, permettant de ce fait de rendre indépendants du schéma les logiciels réclamant une authentification. (source: Wikipedia)
Il faut désactiver cette fonctionnalité:

UsePAM no

 

Vos clés SSH peuvent utiliser l'un des algorithmes suivants:

🚨 DSA: il est dangereux et même plus pris en charge depuis OpenSSH version 7, vous devez le mettre à niveau!
⚠️ RSA: Cela dépend de la taille de la clé. S'il a une longueur de 3072 ou 4096 bits, alors tout va bien. La longueur de 1024 bits est même considérée comme dangereuse.
✅ Ed25519: C'est l'algorithme de clé publique le plus recommandé disponible aujourd'hui!

Autoriser uniquement l'utilisation des clés ed25519:

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

 

Pour prendre en compte les modifications:

systemctl restart sshd.service

 

Pour voir votre configuration:

sshd -T

 

Voici comment générer une clé ed25519 sur votre machine:

ssh-keygen -t ed25519

 

 

Améliorer la sécurité de votre serveur avec fail2ban

Bien que l'utilisation d'un pare-feu réduise le risque, il est nécessaire de contrôler l'accès protégé par mot de passe une trop de demandes de connexion ont échoué en cas d'attaques par force brute ou Bruteforce

L'outil fail2ban vous permet de surveiller l'activité de certains services, tels que les journaux SSH ou Apache. Lorsqu'un nombre excessif d'échecs d'authentification fail2ban générera une règle IPTables, cette règle visera à autoriser les connexions susceptibles d'être une adresse IP d'attaquant pendant une période spécifiée.

Installation fail2ban :

apt-get update && sudo apt-get upgrade
apt install fail2ban
systemctl enable fail2ban

Le service Fail2ban conserve les fichiers de configuration dans le répertoire /etc/fail2ban. Vous y trouverez un fichier avec des valeurs par défaut appelé jail.conf. Étant donné que ce fichier sera réécrit par les mises à jour du package, il ne sera pas nécessaire de le modifier. Au lieu de cela, nous allons écrire un nouveau fichier appelé jail.local. Toutes les valeurs définies dans jail.local seront remplacées par celles de jail.conf.

Le fichier jail.conf contient une section [DEFAULT], suivie de sections pour les services individuels. jail.local peut remplacer n'importe laquelle de ces valeurs. De plus, les fichiers /etc/fail2ban/jail.d/ peuvent être utilisés pour remplacer les paramètres des deux fichiers.

Ouvrez le fichier /etc/fail2ban/jail.local et collez :

[DEFAULT]

[sshd]
enabled = true
banaction = iptables-multiport
port    = ssh
maxretry = 3
bantime = 864000
logpath = %(sshd_log)s

[sshlongterm]
port      = ssh
logpath   = %(sshd_log)s
banaction = iptables-multiport
maxretry  = 10
findtime  = 259200
bantime   = 6084000
enabled   = true
filter    = sshd

 

Redémarrer fail2ban pour prendre en compte la nouvelle configuration:

systemctl restart fail2ban

 

Vous pouvez résoudre les problèmes en vérifiant les journaux fail2ban du dernier démarrage:

journalctl -b -u fail2ban

 

Utilisez fail2ban-client pour interroger l'intégralité de l'état de fail2ban-server ou tout espace individuel:

fail2ban-client status
fail2ban-client status jail_name

 

Le service fail2ban a de nombreuses autres configurations possibles. Y compris la configuration de l'envoi d'e-mails, la possibilité de regrouper l'envoi d'e-mails après un nombre défini d'interdictions. Pour configurer différentes options nous vous invitons à consulter le site officiel fail2ban.

 

Résultats

On a laissé tourner la configuration de fail2ban tourner pendant 1 journée. Durant cette journée il a banni 448 IP. Désormais notre serveur reçois moins d'attaque mais reste vulnérable. L'utilisation d'un firewall en collaboration avec fail2ban, ce qui sera l'objet d'un futur article.