Sécuriser les serveurs Linux: iptables vs fail2ban

Je voudrais choisir le cerveau de la communauté concernant la sécurité du serveur Linux, en particulier en ce qui concerne les attaques par force brute et l'utilisation de fail2ban vs iptables personnalisés .

Il y a quelques questions similaires, mais aucune d'entre elles n'aborde le sujet à ma satisfaction. En bref, j'essaie de déterminer la meilleure solution pour sécuriser les serveurs Linux exposés à Internet (exécutant les services habituels, ssh, web, mail), contre les attaques par force brute.

J'ai une bonne gestion de la sécurité du serveur, c'est-à-dire verrouiller ssh en n'autorisant pas les connexions root ou par mot de passe, changer le port par défaut, s'assurer que le logiciel est à jour, vérifier les fichiers journaux, autoriser uniquement certains hôtes à accéder au serveur et utiliser la sécurité des outils d'audit tels que Lynis ( https://cisofy.com/lynis/ ), pour la conformité générale de la sécurité, donc cette question ne concerne pas nécessairement cela, bien que les commentaires et les conseils soient toujours les bienvenus .

Ma question est quelle solution dois-je utiliser (fail2ban ou iptables), et comment dois-je la configurer, ou dois-je utiliser une combinaison des deux pour se protéger contre les attaques par force brute?

Il y a une réponse intéressante concernant le sujet ( Denyhosts vs fail2ban vs iptables - le meilleur moyen d'empêcher les ouvertures de session par force brute? ). La réponse la plus intéressante pour moi était personnellement ( https://serverfault.com/a/128964 ), et que le routage iptables se produit dans le noyau par opposition à fail2ban qui utilise des outils en mode utilisateur pour analyser les fichiers journaux. Fail2ban utilise bien sûr iptables, mais il doit toujours analyser les fichiers journaux et faire correspondre un modèle jusqu'à ce qu'il exécute une action.

Est-il alors logique d'utiliser iptables et d'utiliser une limitation de débit ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ) pour supprimer les demandes d'une IP pendant une période de temps qui fait trop de tentatives de connexion pendant une période spécifique quel que soit le protocole auquel il tentait de se connecter? Si c'est le cas, alors il y a quelques réflexions intéressantes sur l'utilisation de la suppression contre le rejet pour ces paquets ici ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), des réflexions à ce sujet?

Fail2ban permet une configuration personnalisée sous la forme de la possibilité d'écrire des « règles » personnalisées pour les services qui pourraient ne pas être traités dans la configuration par défaut. Il est facile à installer et à configurer et est puissant, mais pourrait-il être exagéré si tout ce que j'essaie de réaliser est de « bloquer » une IP du serveur s'ils effectuent 2 tentatives d'accès infructueuses sur n'importe quel service / protocole sur une quantité x de temps?

Le but ici est d'ouvrir des rapports journaliers de surveillance et de ne pas avoir à parcourir les pages des tentatives de connexion au serveur.

Merci de prendre le temps.

dois-je utiliser fail2ban ou iptables?

Vous utilisez fail2ban en plus d' une solution de pare-feu, pour étendre à la demande ces règles de pare-feu existantes avec des règles pour bloquer les adresses IP spécifiques des systèmes qui effectuent des actions indésirables sur des services par ailleurs publics. Ils travaillent de concert.

Simplifié: un pare-feu ne voit que les connexions et les paquets réseau et peut comprendre les modèles qui s'y trouvent, mais il n'a pas la connaissance du niveau d'application pour distinguer les demandes souhaitées et valides des demandes malveillantes, malformées et indésirables. Par exemple, votre pare-feu ne peut pas faire la différence entre un tas de demandes d'API HTTP et un certain nombre de tentatives de connexion incorrectes causées par une devinette de mot de passe par force brute sur votre page d'administration Wordpress, pour le pare-feu, elles ne sont toutes les deux que des connexions TCP au port 80 ou 443.

Fail2ban est une approche générique et extensible pour fournir ce niveau d’application à votre pare-feu, quoique quelque peu indirectement.
Les applications enregistrent et enregistrent fréquemment les demandes malveillantes, mal formées et indésirables en tant que telles, mais elles ont rarement la capacité native d'empêcher de nouveaux abus. Bien qu'il soit légèrement découplé, Fail2ban peut alors agir sur ces événements malveillants enregistrés et limiter les dommages et empêcher d'autres abus, généralement en reconfigurant dynamiquement votre pare-feu pour refuser tout accès supplémentaire. En d'autres termes, Fail2ban donne à vos applications existantes, sans les modifier, les moyens de repousser les abus.

Une méthode différente pour fournir aux pare-feu des informations au niveau de l'application consisterait à utiliser un système de détection / prévention des intrusions .

Par exemple, un serveur Web est un service public commun et dans votre pare-feu, les ports TCP 80 et 443 sont ouverts pour Internet en général.
En règle générale, vous n'avez pas de limitation de débit sur les ports HTTP / HTTPS car plusieurs utilisateurs valides peuvent avoir une seule origine lorsqu'ils se trouvent par exemple derrière une passerelle NAT ou un proxy Web.

Lorsque vous détectez des actions indésirables et / ou malveillantes envers votre serveur Web, vous utilisez fail2ban pour automatiser le blocage d'un tel délinquant (soit les bloquer complètement, soit en verrouillant uniquement leur accès aux ports 80 et 443).

D'un autre côté, l'accès SSH n'est pas un service public, mais si vous n'êtes pas en mesure de restreindre l'accès SSH dans votre pare-feu aux seules plages d'adresses IP répertoriées en liste blanche, les connexions entrantes à limitation de débit sont un moyen de ralentir la brute - forcer les attaques. Mais votre pare-feu ne peut toujours pas faire la distinction entre l'utilisateur Bob se connectant avec succès 5 fois car il exécute des playbooks ansible et 5 tentatives infructueuses de connexion en tant que root par un bot.

dois-je utiliser fail2ban ou iptables?

Cela revient un peu à demander "devrais-je utiliser une ceinture de sécurité ou une voiture?".

Tout d'abord, rappelez-vous que fail2ban n'est vraiment qu'un outil pour détecter automatiquement les entrées récurrentes dans les fichiers texte et exécuter une commande lorsque celles-ci atteignent un seuil spécifié.

Nous l'utilisons souvent pour bloquer les hôtes qui violent une politique, comme en témoignent les entrées de journal récurrentes qui indiquent une violation de politique, mais ce n'est pas la seule raison pour laquelle vous pouvez l'utiliser.

Vous pouvez utiliser fail2ban pour ajouter (et supprimer) des règles iptables à la demande. Vous pouvez également ajouter et supprimer des règles iptables à la main, ou vous pouvez utiliser fail2ban pour faire quelque chose de complètement différent en réponse. C'est tout sur la façon dont vous le configurez.

Vous devez avoir un pare-feu général en place, que vous exécutiez fail2ban ou non. Un tel pare-feu serait, par exemple, pour bloquer le trafic (entrant ou sortant) dont vous savez qu'il ne sera jamais légitime. Par exemple, ce serveur de base de données a-t-il vraiment besoin de gérer les connexions entrantes sur le port 25 de tout Internet?

En plus de cela, avoir fail2ban répondre aux violations de politique en coupant les IP offensantes pendant un certain temps ne fera pas grand-chose pour sécuriser votre serveur en soi (un bon exploit ne doit traverser votre pare-feu qu'une seule fois) mais il le fera réduire le niveau de bruit sur votre système, y compris, mais sans s'y limiter, dans les journaux système. La manière la plus simple de le faire est de faire exécuter fail2ban iptables pour configurer le noyau afin qu'il supprime les paquets pendant un certain temps. Si vous pouvez reconfigurer votre pare-feu de périmètre au lieu de simplement le pare-feu hôte, alors tant mieux.

En d'autres termes, dans la mesure où ils peuvent être facilement séparés en premier lieu, vous voulez les deux.

cela pourrait-il être exagéré si tout ce que j'essaie de réaliser est de «bloquer» une adresse IP du serveur s'ils effectuent 2 tentatives d'accès infructueuses sur n'importe quel service / protocole sur une période de temps?

C'est exactement le cas d'utilisation que fail2ban est conçu pour résoudre. Utiliser un outil pour l'usage auquel il est destiné n'est presque jamais exagéré.

Le but ici est d'ouvrir des rapports journaliers de surveillance et de ne pas avoir à parcourir les pages des tentatives de connexion au serveur.

Un côté, pas directement lié à votre question: chaque fois que vous filtrez les journaux pour examen, réfléchissez à ce que vous ferez à propos d'une entrée particulière. Si tout ce que vous allez faire à propos d'une entrée est de dire "meh" et de continuer, alors vous voudrez probablement la filtrer. Assurez-vous d'enregistrer les journaux complets pour examen si cela est nécessaire, mais insérez uniquement dans votre flux de travail de surveillance normal les éléments avec lesquels vous allez faire quelque chose lorsqu'il apparaît. Si vous configurez fail2ban pour bloquer un hôte après quelques tentatives de connexion infructueuses, il est fort probable que vous n'aurez pas besoin de les examiner manuellement et de les supprimer de vos notifications de surveillance. Si un utilisateur légitime se plaint de la perte d'accès, il vous suffit de retirer les journaux complets et d'y jeter un œil.

J'ai résolu la même question il y a quelques années. J'ai décidé d'utiliser iptables avec un module récent en raison des performances et de la configuration facile. J'ai dû protéger beaucoup de conteneurs virtuels sur les hôtes. N'oubliez pas de ne pas ouvrir de vecteur DOS avec vos règles. Utilisez également l'ipset pour faire correspondre les listes de réseaux ou les listes d'adresses IP dans les règles. Je l'utilise pour les listes blanches. Tous les réseaux d'un pays dans une liste sont parfaits pour un réglage fin. Et il est très facile de protéger un autre service avec le même ensemble de règles uniquement en ajoutant un port de plus à faire correspondre. Je n'aime donc pas changer avec fail2ban mais peut-être que quelqu'un avec d'autres besoins sera content avec fail2ban.

Voici un exemple:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

La sortie de vos messages de journalisation peut être combinée avec fail2ban. Vous pouvez également l'utiliser pour les règles INPUT.