À l’air des ransomware (ou rançongiciels), virus injectés par des attaques automatiques et ciblées, dont l’objectif est de prendre en otage les données personnelles ou critiques d’une entreprise, Fail2ban est un outil indispensable pour sécuriser les serveurs de son réseau.

Surveillance automatique des logs et blocage des IP pirates

Le but de Fail2ban est de surveiller les fichiers de logs de différents programmes et services d’un serveur et, selon une configuration pré-établie, définir des règles de parefeu pour bannir sur une période les adresses IP qui se connecterait anormalement souvent ou tenterait d’utiliser des failles pour s’introduire dans le système.

Outils utilisés

• fail2ban

Exemple de surveillance des accès SSH

Un cas d’utilisation classique mais important, est la surveillance des accès SSH d’un serveur Linux. L’accès SSH est très largement utilisé pour accéder et administrer un serveur Linux sur internet, que ce soit un serveur web, un serveur de sauvegarde ou autre. Le protocole SSH est le moyen sécurisé de contrôler un serveur en donnant accès à un terminal. Mais comme tout programme, des failles peuvent exister, ou des mots de passe cassé, notamment par brut force.

Pour l’exemple, j’ai commandé un VPS classique sous Debian chez OVHCloud, le serveur est immédiatement mis à disposition avec simplement le système installé et un accès SSH dont le mot de passe root est envoyé par mail. Je l’ai commandé un soir vers 22h, et l’ai laissé tel quel toute la nuit jusqu’au lendemain matin.

À peine mis en service, le serveur SSH est détecté et scanné par des pirates

D’après le log /var/log/auth.log on peut voir le démarrage du serveur SSH à 22h11, heure à laquelle j’ai commandé le VPS, puis des déconnexions d’IP dès 22h23 :

On aurait pu imaginer dans un premier temps que ces deux connexions provenait des serveurs d’OVH pour un contrôle quelconque lié à la livraison du serveur, mais en recherchant le whois de ces adresses, il s’est avéré que non. L’une des adresses est originaire de l’Equateur, l’autre provient des USA. À partir de là, on peut facilement en déduire que ce sont deux machines zombie servant de robots scanneurs qui ont détecté le serveur SSH sur le port TCP 22, le port par défaut de SSH.

Après quoi, toute la nuit, les scans style brut force n’ont pas cessé, notamment sur des accès par défaut (utilisateurs « test », « oracle, « admin », etc) :

Ici, l’adresse IP provient de Singapour.

Bien entendu, le premier réflexe est de modifier le port TCP utilisé par le serveur SSH comme expliqué dans un autre de mes articles : Sécuriser un serveur Linux. Dans cet exemple, j’ai choisi le port 11331 qui ne correspond à rien, cela a tout de suite stoppé les scans :

Efficace à court terme, mais insuffisant sur le long terme. Les scans de pirates ne s’arrêtent pas au seul port TCP 22, il faut admettre que ce sont les 65535 ports TCP qui finissent par être scannés, d’autant plus si un pirate cible spécifiquement le serveur. Une fois découvert, le nouveau port utilisé est de nouveau testé en boucle.

Même avec un port SSH modifié, le serveur fini par être de nouveau détecté et scanné par des pirates

Voici une courbe issue de Zabbix (voir un de mes articles à propos de Zabbix) représentant le nombre d’adresses IP bannies d’un serveur, c’est donc le nombre d’adresses IP qui tentent de scanner le serveur SSH, pourtant défini sur un port bien au delà des 10000 :

Dans cet exemple, c’est en moyenne 240 machines zombies différentes qui tentent de se connecter en SSH sur ce serveur. C’est impressionnant, même effrayant. On peut imaginer le nombre de possibilité d’identification testés sur des serveurs non sécurisés.

Changer le port SSH à chaque fois que l’on détecte des scans serait pénible à la longue, avec le risque de ne plus savoir quel port on utilise pour accéder au serveur. La solution est Fail2ban.

(Dans le cas ci-dessus, fail2ban ou non, il est conseillé de rechanger le port SSH utilisé, étant donné que celui-ci est connu et scanné par des pirates)

Installation

Selon la distribution utilisée, Fail2ban est certainement disponible dans le gestionnaire de paquet correspondant. Par exemple, sur un système basé sur Debian, la commande d’installation est la suivante :

# apt-get install fail2ban

À noter que Fail2ban nécessite Python, il sera automatiquement installé par le gestionnaire de paquet si besoin.

Configuration

Par défaut, les fichiers de configuration se trouvent dans /etc/fail2ban et sont organisés comme suit :

• fail2ban.conf : Paramètres généraux de fonctionnement de Fail2ban.
• filter.d/ : Description d’entrée de log des différents services utilisables dans Fail2ban.
• actions.d/ : Définition des différentes commandes (blocage d’IP, etc) exécutables par Fail2ban.
• jail.conf : Configurations par défaut de contrôles des logs des principaux services (SSH, HTTP/Apache, certains CMS, etc).
• jail.d : Configurations spécifiques de contrôles des logs.
• path*.conf : Définition des chemins par défaut des logs des principaux services.

Pour activer la surveillance SSH, éditez un nouveau fichier dans le répertoire jail.d :

# vi /etc/fail2ban/jail.d/sshd.conf

Puis ajoutez simplement les lignes suivantes :

[sshd]
enabled = true
maxretry = 5
findtime  = 30m
bantime  = 1440m
port = 11331

La section [sshd] complète les paramètres de surveillance sshd prédéfinis dans jail.conf. Les paramètres définis sont les suivants :

• enabled : Active la surveillance du serveur SSHD.
• maxretry : Nombre de tentative de connexion maximum après lesquels l’IP source est bloquée.
• findtime : Période pendant laquelle le nombre de tentative d’une IP source est comptabilisé.
• bantime : Temps de blocage de l’IP source.
• port : Port SSH à bloquer.

Dans cet exemple, 5 essais maximum sont tolérés par période de 30 minutes, après quoi une IP est bannie pendant 1440 minutes (soit 24 heures). Fail2ban a besoin de savoir sur quel port le serveur SSH est configuré pour le bloquer aux IP attaquantes. Dans cet exemple, comme vu plus haut dans l’article, le port est le 11331.

Démarrage de Fail2ban

La procédure suivante utilise systemd (système par défaut sur Debian à partir de la version 8).

Chargement de la configuration :

# systemctl daemon-reload

Démarrage du service Fail2ban :

# systemctl start fail2ban

Interactions avec Fail2ban

Vérifier l’état de Fail2ban :

# fail2ban-client status

Résultat :

Status
|- Number of jail:      1
`- Jail list:   sshd

Vérifier l’état des contrôles des accès SSH (exécuter sur un serveur régulièrement scanné) :

# fail2ban-client status sshd

Résultat :

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     8907
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 202
   |- Total banned:     2614
   `- Banned IP list:   71.73.5.169 222.92.116.40 138.197.200.16 121.204.148.63
59.152.237.118 159.203.188.141 152.136.183.147 193.112.74.169 211.253.129.225
111.229.193.164 179.108.19.214 182.61.49.107 ...

Pour afficher les paramètres existants, il suffit d’exécuter la commande fail2ban-client sans paramètre.

Il est possible de vérifier les paramètres de surveillance, débloquer une adresse IP, redéfinir un paramètre de surveillance, etc.

Stratégie de sécurité

En général, Fail2ban doit être configuré pour surveiller tous les services utilisés sur un serveur. Fail2ban possède déjà les configurations de lecture de log des principaux services utilisés sur les serveurs Linux, mais il est possible de les compléter selon les besoins.

Les ports TCP 80 et 443 pour le Web sont extrêmement scannés sur internet.

Les services « publiques », tel que les serveur web, mails, ftp, etc, la surveillance est importante car les ports utilisés ne peuvent être changés, au risque de ne plus être accessibles, ce qui n’est pas le but de ces services. Ils sont donc d’autant plus facilement repérables par les pirates et scannés en masse. Le serveur web, port TCP 80, est extrêmement scanné sur internet et mérite une surveillance accrue.

Par exemple, si un portail web est accessible sur un serveur, il est primordiale de loguer les tentatives d’identification de sorte à les surveiller par Fail2ban. La plupart des CMS (WordPress, Drupal, etc) ont déjà une configuration pré établie dans Fail2ban.

En espérant que cette démonstration vous aura été intéressante, il existe sur ce blog une catégorie nommée « Fail2ban » dans laquelle je placerai les articles décrivant d’autres exemples ou technologie en lien avec Fail2ban.

N’hésitez pas à me contacter via la page Me contacter pour de plus amples informations ou demande quelconque.