Comment protéger SSH avec Fail2Ban sur Ubuntu 14.04
Introduction
Bien que la connexion à votre serveur via SSH puisse être très sécurisée, le démon SSH lui-même est un service qui doit être exposé à Internet pour fonctionner correctement. Cela comporte un certain risque inhérent et crée un vecteur d'attaque pour les agresseurs potentiels.
Tout service exposé au réseau est une cible potentielle de cette manière. Si vous prêtez attention aux journaux d'application pour ces services, vous verrez souvent des tentatives de connexion répétées et systématiques qui représentent des attaques par force brute de la part des utilisateurs et des bots.
Un service appelé fail2ban peut atténuer ce problème en créant des règles qui peuvent modifier automatiquement la configuration de votre pare-feu iptables en fonction d'un nombre prédéfini de tentatives de connexion infructueuses. Cela permettra à votre serveur de répondre aux tentatives d'accès illégitimes sans intervention de votre part.
Dans ce guide, nous expliquerons comment installer et utiliser fail2ban sur un serveur Ubuntu 14.04.
Installer Fail2Ban sur Ubuntu 14.04
Le processus d'installation de cet outil est simple car l'équipe de packaging d'Ubuntu maintient un package dans les référentiels par défaut.
Tout d'abord, nous devons mettre à jour notre index de package local, puis nous pouvons utiliser apt pour télécharger et installer le package :
sudo apt-get update sudo apt-get install fail2ban
Comme vous pouvez le voir, l'installation est triviale. Nous pouvons maintenant commencer à configurer l'utilitaire pour notre propre usage.
Configurez Fail2Ban avec vos paramètres de service
Le service fail2ban conserve ses fichiers de configuration dans le répertoire /etc/fail2ban. Il existe un fichier avec des valeurs par défaut appelé jail.conf.
Étant donné que ce fichier peut être modifié par des mises à niveau de packages, nous ne devons pas modifier ce fichier sur place, mais plutôt le copier afin que nous puissions apporter nos modifications en toute sécurité. Pour que ces deux fichiers fonctionnent ensemble avec succès, il est préférable d'inclure uniquement les paramètres que vous souhaitez remplacer dans le fichier jail.local. Toutes les options par défaut seront extraites du fichier jail.conf.
Même si nous ne devrions inclure que les écarts par rapport à la valeur par défaut dans le fichier jail.local, il est plus facile de créer un fichier jail.local basé sur le fichier jail.conf existant. Nous allons donc copier ce fichier, avec le contenu commenté, comme base du fichier jail.local. Vous pouvez le faire en tapant :
awk '{ printf "# "; print; }' /etc/fail2ban/jail.conf | sudo tee /etc/fail2ban/jail.local
Une fois le fichier copié, nous pouvons ouvrir le fichier d'origine jail.conf pour voir comment les choses sont configurées par défaut
sudo nano /etc/fail2ban/jail.conf
Dans ce fichier, il y a quelques paramètres que vous souhaiterez peut-être ajuster. Les paramètres situés sous la section [DEFAULT] seront appliqués à tous les services activés pour fail2ban qui ne sont pas remplacés dans la propre section du service.
/etc/fail2ban/jail.conf
[DEFAULT] . . . ignoreip = 127.0.0.1/8 . . .
Le paramètre ignoreip configure les adresses source ignorées par fail2ban. Par défaut, il est configuré pour n'interdire aucun trafic provenant de la machine locale. Vous pouvez ajouter des adresses supplémentaires à ignorer en ajoutant une section [DEFAULT] avec un paramètre ignoreip en dessous au fichier jail.local. Vous pouvez ajouter des adresses supplémentaires en les ajoutant à la fin de la directive, séparées par un espace.
/etc/fail2ban/jail.conf
[DEFAULT] . . . bantime = 600 . . .
Le paramètre bantime définit la durée pendant laquelle un client sera banni lorsqu'il n'a pas réussi à s'authentifier correctement. Ceci est mesuré en secondes. Par défaut, il est défini sur 600 secondes ou 10 minutes.
/etc/fail2ban/jail.conf
[DEFAULT] . . . findtime = 600 maxretry = 3 . . .
Les deux paramètres suivants auxquels vous voulez prêter attention sont findtime et maxretry. Ceux-ci travaillent ensemble pour établir les conditions dans lesquelles un client s'avère être un utilisateur illégitime qui devrait être interdit.
La variable maxretry définit le nombre d'essais qu'un client doit s'authentifier dans une fenêtre de temps définie par findtime, avant d'être banni. Avec les paramètres par défaut, le service fail2ban bannira un client qui tente sans succès de se connecter 3 fois dans une fenêtre de 10 minutes.
/etc/fail2ban/jail.conf
[DEFAULT] . . . destemail = root@localhost sendername = Fail2Ban mta = sendmail . . .
Vous voudrez évaluer les paramètres destemail, sendername et mta si vous souhaitez configurer des alertes par e-mail. Le paramètre destemail définit l'adresse e-mail qui doit recevoir les messages d'interdiction. Le sendername définit la valeur du champ "De" dans l'e-mail. Le paramètre mta configure le service de messagerie qui sera utilisé pour envoyer le courrier. Encore une fois, ajoutez-les au fichier jail.local, sous l'en-tête [DEFAULT] et définissez les valeurs appropriées si vous souhaitez les ajuster.
/etc/fail2ban/jail.conf
[DEFAULT] . . . action = $(action_)s . . .
Ce paramètre configure l'action que fail2ban prend lorsqu'il veut instituer une interdiction. La valeur action_ est définie dans le fichier peu avant ce paramètre. L'action par défaut consiste simplement à configurer le pare-feu pour rejeter le trafic de l'hôte incriminé jusqu'à ce que le délai d'interdiction soit écoulé.
Si vous souhaitez configurer des alertes par e-mail, ajoutez ou décommentez l'élément action au fichier jail.local et changez sa valeur de action_ à action_mw. Si vous souhaitez que l'e-mail inclue les lignes de journal pertinentes, vous pouvez le remplacer par action_mwl. Assurez-vous que les paramètres de messagerie appropriés sont configurés si vous choisissez d'utiliser les alertes par e-mail.
Paramètres de prison individuels
Enfin, nous arrivons à la partie du fichier de configuration qui traite des services individuels. Ceux-ci sont spécifiés par les en-têtes de section, comme [ssh].
Chacune de ces sections peut être activée en décommentant l'en-tête dans jail.local et en changeant la ligne enabled pour qu'elle soit "true" :
/etc/fail2ban/jail.local
[jail_to_enable] . . . enabled = true . . .
Par défaut, le service SSH est activé et tous les autres sont désactivés.
Ces sections fonctionnent en utilisant les valeurs définies dans la section [DEFAULT] comme base et en les modifiant si nécessaire. Si vous souhaitez remplacer des valeurs, vous pouvez le faire en ajoutant la section du service approprié à jail.local et en modifiant ses valeurs.
Certains autres paramètres définis ici sont le filter qui sera utilisé pour décider si une ligne dans un journal indique un échec d'authentification et le logpath qui indique à fail2ban où se trouvent les journaux de ce service particulier. situé.
La valeur filter est en fait une référence à un fichier situé dans le répertoire /etc/fail2ban/filter.d, avec son extension .conf supprimée. Ces fichiers contiennent les expressions régulières qui déterminent si une ligne du journal est une tentative d'authentification ayant échoué. Nous ne couvrirons pas ces fichiers en profondeur dans ce guide, car ils sont assez complexes et les paramètres prédéfinis correspondent bien aux lignes appropriées.
Cependant, vous pouvez voir quels types de filtres sont disponibles en consultant ce répertoire :
ls /etc/fail2ban/filter.d
Si vous voyez un fichier qui semble être lié à un service que vous utilisez, vous devez l'ouvrir avec un éditeur de texte. La plupart des fichiers sont assez bien commentés et vous devriez au moins être en mesure de dire contre quel type de condition le script a été conçu pour se prémunir. La plupart de ces filtres ont des sections appropriées (désactivées) dans le fichier jail.conf que nous pouvons activer dans le fichier jail.local si vous le souhaitez.
Par exemple, imaginez que nous servons un site Web en utilisant Nginx et réalisez qu'une partie protégée par mot de passe de notre site est victime de tentatives de connexion. Nous pouvons dire à fail2ban d'utiliser le fichier nginx-http-auth.conf pour vérifier cette condition dans le fichier /var/log/nginx/error.log.
Ceci est en fait déjà configuré dans une section appelée [nginx-http-auth] dans notre fichier /etc/fail2ban/jail.conf. Nous aurions juste besoin de décommenter la section dans le fichier jail.local et d'inverser le paramètre enabled pour protéger notre service :
/etc/fail2ban/jail.local
. . . [nginx-http-auth] enabled = true . . .
Si vous l'activez, vous devrez redémarrer votre service fail2ban pour vous assurer que vos règles sont correctement construites.
Mettre tous ensemble
Maintenant que vous comprenez l'idée de base derrière fail2ban, passons en revue une configuration de base.
Nous allons configurer une politique d'interdiction automatique pour SSH et Nginx, comme nous l'avons décrit ci-dessus. Nous voulons que fail2ban nous envoie un e-mail lorsqu'une adresse IP est interdite.
Tout d'abord, installons tous les logiciels pertinents.
Si vous ne l'avez pas déjà, vous aurez besoin de nginx, car nous allons surveiller ses journaux, et vous aurez besoin de sendmail pour nous envoyer des notifications. Nous allons également saisir iptables-persistent pour permettre au serveur de configurer automatiquement nos règles de pare-feu au démarrage. Ceux-ci peuvent être acquis à partir des référentiels par défaut d'Ubuntu :
sudo apt-get update sudo apt-get install nginx sendmail iptables-persistent
Arrêtez le service fail2ban pendant un moment afin que nous puissions établir un pare-feu de base sans les règles qu'il ajoute :
sudo service fail2ban stop
Établir un pare-feu de base
Lorsque cela est terminé, nous devrions implémenter un pare-feu par défaut. Vous pouvez apprendre comment configurer un pare-feu iptables sur Ubuntu 14.04 ici. Nous allons simplement créer un pare-feu de base pour ce guide.
Nous allons lui dire d'autoriser les connexions établies, le trafic généré par le serveur lui-même, le trafic destiné à nos ports SSH et serveur Web. Nous supprimerons tout autre trafic. Nous pouvons configurer ce pare-feu de base en tapant :
sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT sudo iptables -A INPUT -j DROP
Ces commandes implémenteront la politique ci-dessus. Nous pouvons voir nos règles de pare-feu actuelles en tapant :
sudo iptables -S
Output-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP
Vous pouvez enregistrer les pare-feux afin qu'ils survivent à un redémarrage en tapant :
sudo dpkg-reconfigure iptables-persistent
Ensuite, vous pouvez redémarrer fail2ban pour implémenter les règles d'encapsulation :
sudo service fail2ban start
Nous pouvons voir nos règles de pare-feu actuelles en tapant :
sudo iptables -S
Output-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-ssh -j RETURN
Nous avons notre politique par défaut pour chacune de nos chaînes, puis les cinq règles de base que nous avons établies. En rouge, nous avons également la structure par défaut mise en place par fail2ban puisqu'il implémente déjà les politiques d'interdiction SSH par défaut. Ceux-ci peuvent ou non apparaître au début, car parfois fail2ban n'ajoute pas la structure jusqu'à ce que la première interdiction soit mise en œuvre.
Réglage de la configuration Fail2ban
Maintenant, nous devons configurer fail2ban en utilisant les paramètres que nous aimerions. Ouvrez le fichier jail.local :
sudo nano /etc/fail2ban/jail.local
Nous pouvons définir une durée d'interdiction plus sévère ici. Recherchez et décommentez l'en-tête [DEFAULT]. Sous l'en-tête par défaut, modifiez le paramètre bantime afin que notre service bannisse les clients pendant une demi-heure :
/etc/fail2ban/jail.local
[DEFAULT] . . . bantime = 1800 . . .
Nous devons également configurer nos informations d'e-mail d'alerte. Tout d'abord, recherchez le paramètre destemail, qui devrait également figurer sous l'en-tête [DEFAULT]. Entrez l'adresse e-mail que vous souhaitez utiliser pour collecter ces messages :
/etc/fail2ban/jail.local
[DEFAULT] . . . destemail = [email protected] . . .
Vous pouvez régler le sendername sur autre chose si vous le souhaitez. Il est cependant utile d'avoir une valeur qui peut être facilement filtrée à l'aide de votre service de messagerie, sinon votre boîte de réception habituelle pourrait être inondée d'alertes s'il y a beaucoup de tentatives d'interruption à partir de divers endroits.
En descendant, nous devons ajuster le paramètre action à l'une des actions qui nous envoie un e-mail. Les choix sont entre action_mw qui institue l'interdiction et nous envoie ensuite un rapport "whois" sur l'hôte incriminé, ou action_mwl qui fait ce qui précède, mais envoie également par e-mail les lignes de journal pertinentes.
Nous allons choisir action_mwl car les lignes de journal nous aideront à résoudre les problèmes et à recueillir plus d'informations en cas de problème :
/etc/fail2ban/jail.local
[DEFAULT] . . . action = %(action_mwl)s . . .
Passant à notre section SSH, si nous voulons ajuster le nombre de tentatives infructueuses qui doivent être autorisées avant qu'une interdiction ne soit établie, vous pouvez modifier l'entrée maxretry. Si vous utilisez un port autre que "22", vous devrez ajuster le paramètre port de manière appropriée. Comme nous l'avons déjà dit, ce service est déjà activé, nous n'avons donc pas besoin de le modifier.
Ensuite, recherchez la section nginx-http-auth. Décommentez l'en-tête et changez le paramètre enabled pour lire "true".
/etc/fail2ban/jail.local
. . . [nginx-http-auth] enabled = true . . .
Cela devrait être tout ce que vous avez à faire dans cette section, sauf si votre serveur Web fonctionne sur des ports non standard ou si vous avez déplacé le chemin du journal des erreurs par défaut.
Redémarrage du service Fail2ban
Lorsque vous avez terminé, enregistrez et fermez le fichier.
Maintenant, démarrez ou redémarrez votre service fail2ban. Parfois, il est préférable d'arrêter complètement le service, puis de le redémarrer :
sudo service fail2ban stop
Maintenant, nous pouvons le redémarrer en tapant :
sudo service fail2ban start
Le remplissage de toutes vos règles de pare-feu peut prendre quelques instants. Parfois, les règles ne sont pas ajoutées tant que la première interdiction de ce type n'est pas instituée. Cependant, après un certain temps, vous pouvez vérifier les nouvelles règles en tapant :
sudo iptables -S
Output-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -j RETURN
Les lignes en rouge sont celles que nos politiques fail2ban ont créées. À l'heure actuelle, ils dirigent simplement le trafic vers de nouvelles chaînes presque vides, puis laissent le trafic revenir directement dans la chaîne INPUT.
Cependant, ces nouvelles chaînes sont celles où les règles d'interdiction seront ajoutées.
Tester les politiques d'interdiction
À partir d'un autre serveur, qui n'aura pas besoin de se connecter à votre serveur fail2ban, nous pouvons tester les règles en faisant bannir notre deuxième serveur.
Après vous être connecté à votre deuxième serveur, essayez de vous connecter en SSH au serveur fail2ban. Vous pouvez essayer de vous connecter en utilisant un nom inexistant par exemple :
ssh blah@fail2ban_server_IP
Entrez des caractères aléatoires dans l'invite de mot de passe. Répétez cela plusieurs fois. À un moment donné, le serveur fail2ban cessera de répondre avec le message Permission denied. Cela signale que votre deuxième serveur a été banni du serveur fail2ban.
Sur votre serveur fail2ban, vous pouvez voir la nouvelle règle en vérifiant à nouveau nos iptables :
sudo iptables -S
Output-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -s 203.0.113.14/32 -j REJECT --reject-with icmp-port-unreachable -A fail2ban-ssh -j RETURN
Comme vous pouvez le voir dans la ligne en surbrillance, nous avons une nouvelle règle dans notre configuration qui rejette le trafic vers le port SSH provenant de l'adresse IP de notre deuxième serveur. Vous devriez également avoir reçu un e-mail concernant l'interdiction du compte que vous avez configuré.
Conclusion
Vous devriez maintenant être en mesure de configurer certaines politiques d'interdiction de base pour vos services. Fail2ban est très facile à configurer et constitue un excellent moyen de protéger tout type de service utilisant l'authentification.
Si vous souhaitez en savoir plus sur le fonctionnement de fail2ban, vous pouvez consulter notre didacticiel sur comment fonctionnent les règles et les fichiers fail2ban.
Pour plus d'informations sur l'utilisation de fail2ban pour protéger d'autres services, essayez ces liens :
