Denyhosts vs fail2ban vs iptables - le meilleur moyen d'empêcher les ouvertures de session par force brute?
J'installe un serveur LAMP et je dois empêcher SSH/FTP/etc. les tentatives de connexion par force brute échouent. J'ai vu de nombreuses recommandations pour les denyhosts et fail2ban, mais peu de comparaisons des deux. J'ai également lu qu'une règle IPTables peut remplir la même fonction.
Pourquoi devrais-je choisir l'une de ces méthodes plutôt qu'une autre? Comment les utilisateurs de serverfault gèrent-ils ce problème?
IIRC, DenyHosts ne surveillera que votre service SSH. Si vous en avez également besoin pour protéger d'autres services, Fail2ban est certainement un meilleur choix. Il est configurable pour regarder presque tous les services si vous souhaitez modifier sa configuration, mais cela ne devrait pas être nécessaire car les nouvelles versions de Fail2ban incluent des ensembles de règles qui conviennent à de nombreux démons de serveurs populaires. L'utilisation de fail2ban sur une simple limite de débit iptables a l'avantage de bloquer complètement un attaquant pendant une durée spécifiée, au lieu de simplement réduire la vitesse à laquelle il peut marteler votre serveur. J'ai utilisé fail2ban avec d'excellents résultats sur un certain nombre de serveurs de production et je n'ai jamais vu l'un de ces serveurs violé par une attaque par force brute depuis que j'ai commencé à l'utiliser.
meilleure façon d'empêcher les ouvertures de session par force brute?
Ne les laissez pas accéder à votre machine en premier lieu! Il existe de nombreuses façons d'arrêter les tentatives de force brute avant qu'elles n'atteignent votre hôte, ou même au niveau SSH.
Cela dit, protéger votre système d'exploitation avec quelque chose comme fail2ban est une excellente idée. Fail2ban est légèrement différent de DenyHosts, bien qu'ils jouent dans le même espace. Fail2ban utilise iptables.
http://en.wikipedia.org/wiki/Fail2ban
Fail2ban est similaire à DenyHosts ... mais contrairement à DenyHosts qui se concentre sur SSH, fail2ban peut être configuré pour surveiller tout service qui écrit des tentatives de connexion dans un fichier journal, et au lieu d'utiliser /etc/hosts.deny uniquement pour bloquer les adresses IP/hôtes , fail2ban peut utiliser Netfilter/iptables et TCP Wrappers /etc/hosts.deny.
Il existe un certain nombre de techniques de sécurité importantes que vous devez envisager pour empêcher les connexions par force brute:
SSH:
- Ne pas autoriser root à se connecter
- Ne pas autoriser les mots de passe ssh (utiliser l'authentification par clé privée)
- N'écoutez pas sur toutes les interfaces
- Créez une interface réseau pour SSH (par exemple eth1), qui est différente de l'interface à partir de laquelle vous servez les demandes (par exemple eth0)
- N'utilisez pas de noms d'utilisateur courants
- Utiliser une liste d'autorisation et autoriser uniquement les utilisateurs qui nécessitent un accès SSH
- Si vous avez besoin d'un accès Internet ... Restreignez l'accès à un ensemble fini d'adresses IP. Une IP statique est idéale, mais le verrouiller à x.x.0.0/16 est meilleur que 0.0.0.0/0
- Si possible, trouvez un moyen de vous connecter sans accès à Internet, de cette façon, vous pouvez refuser tout le trafic Internet pour SSH (par exemple, avec AWS, vous pouvez obtenir une connexion directe qui contourne Internet, elle s'appelle Direct Connect)
- Utilisez un logiciel comme fail2ban pour attraper toutes les attaques par force brute
- Assurez-vous que le système d'exploitation est toujours à jour, en particulier les packages de sécurité et ssh
Application:
- Assurez-vous que votre application est toujours à jour, en particulier les packages de sécurité
- Verrouillez les pages "admin" de votre application. La plupart des conseils ci-dessus s'appliquent également à la zone d'administration de votre application.
- Mot de passe Protégez votre zone d'administration, quelque chose comme htpasswd pour la console Web projettera toutes les vulnérabilités sous-jacentes des applications et créera une barrière supplémentaire à l'entrée
- Verrouillez les autorisations de fichier. Les "dossiers de téléchargement" sont connus pour être des points d'entrée de toutes sortes de choses désagréables.
- Pensez à placer votre application derrière un réseau privé et à exposer uniquement votre équilibreur de charge frontal et un jumpbox (il s'agit d'une configuration typique dans AWS à l'aide de VPC)
NE AUTRE EXCELLENTE FAÇON DE PROTÉGER SSH (Je l'utilise depuis une décennie ou mieux) consiste à utiliser nativement les bibliothèques récentes dans iptables (en fonction de votre distribution).
Fondamentalement, il peut être utilisé comme un détournement de port intégré aux iptables. Cela vous évitera de nombreux maux de tête. Tant que vous pouvez vous connecter à TCP (Telnet est un moyen. J'ai également utilisé des clients SSH et les ai pointés vers le port. Tout ce qui fera une connexion TCP à un numéro de port spécifié. Je vous regarde PuTTY!) client initiant la connexion ssh, vous pouvez l'utiliser.
Vous trouverez ci-dessous un exemple dans lequel iptables ouvrira le port 22 à votre hôte lorsque vous vous connecterez de votre hôte au serveur sur le port 4103. Vous pouvez ensuite utiliser un telnet sur le port 4102 ou 4104 pour fermer l'ouverture de sed. La raison pour les deux 4102 et 4104 est de garder une simple analyse TCP de l'ouverture 22. Seule une connexion TCP (Telnet) au port 4103 vous permettra d'entrer.
Prendre plaisir!
Oh et je préfère Fail2Ban. Plus de flexibilité et j'aime que l'interdiction se produise dans iptables plutôt que dans tcpwrappers.
SSH PORTKNOCKING
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP
J'utilise des règles iptables pour limiter les nouvelles connexions à partir de la même adresse IP (SSH principalement, mais cela fonctionnerait également très bien pour FTP). L'avantage, à mon avis, par rapport à "fail2ban" et à d'autres outils de ce type est que la route iptables se produit totalement en mode noyau et ne repose sur aucun outil en mode utilisateur pour analyser/analyser les fichiers journaux.
Des centaines de connexions ssh ont échoué
Si vous pouvez le faire, limiter les adresses sources pouvant accéder aux protocoles en question aidera évidemment aussi.
Avec SSH, vous devriez vraiment utiliser l'authentification par certificat et ne pas accepter les mots de passe de toute façon.
Une autre différence entre Fail2ban et Denyhosts est que Denyhosts peut partager la liste de blocage avec d'autres utilisateurs Denyhosts. Avec Fail2ban, vous ne pouvez bloquer que les adresses IP que votre serveur a vues auparavant - avec Denyhosts, une tentative de force brute peut même ne jamais arriver sur votre serveur, si quelqu'un d'autre l'a vu, et la liste de blocage est téléchargée sur votre serveur avant l'attaquant arrive à votre ordinateur.
Une autre différence est que Fail2ban utilise iptables, tandis que Denyhosts utilise tcpwrappers. D'autres ont déjà mentionné cette différence, mais il y a quelques notes annexes qui méritent d'être mentionnées.
iptables est limité dans le nombre d'adresses IP que vous pouvez bloquer efficacement. C'est probablement l'une des raisons pour lesquelles Fail2ban n'a pas de mécanisme pour partager les listes de blocage.
Un autre effet est que lorsque iptables est remplacé par nftables, Fail2ban cessera probablement de fonctionner ou devra être réécrit. Denyhosts continuera probablement à fonctionner.
Les deux ont donc des avantages et des inconvénients. J'aime les deux; pour moi, j'utilise Denyhosts parce que d'habitude je veux seulement protéger SSH, et j'aime partager la liste de blocage.
Une chose à noter sur Fail2Ban est qu'il semble utiliser environ 10 Mo de mémoire en plus que DenyHosts. Donc, si vous êtes sur un VPS de 128 Mo, vous voudrez peut-être examiner cela. De plus, fail2ban prêt à l'emploi est uniquement configuré sur SSH, ce qui signifie que sans modification de la configuration - DenyHosts fait la même chose avec moins de mémoire.
denyhosts est pour ssh. fail2ban est plus complet (HTTP, FTP, etc.). Les deux utilisent des iptables dans les coulisses.
Au lieu de jouer avec des iptables fastidieuses ou avec une configuration fail2ban, pourquoi ne pas laisser la communauté ouverte faire tout le travail pour vous et utiliser CSF/LFD à la place? Je peux le recommander fortement par-dessus toutes les autres options mentionnées. Voir http://configserver.com/cp/csf.html pour ce qu'il peut faire pour vos serveurs. CSF ne nécessite pas de panneau de contrôle, il offre une interface utilisateur simple elle-même, pour ceux qui ne veulent pas le faire par Shell. Et c'est beaucoup de scripts Perl non-résidents fiables et stables.
fail2ban ne semble pas avoir de mécanisme pour reconnaître une connexion ssh réussie et réinitialiser son nombre d'échecs.
Le filtre standard pour sshd (au moins sur mon installation debian), enregistre un nombre d'échecs pour chaque clé ssh que le client présente et que le serveur rejette. Certains utilisateurs présentent de nombreuses clés à chaque connexion et sont régulièrement verrouillés, même si leurs connexions ont réussi une fois que quelques clés ont été passées.
À la suite de ce qui précède, je pense actuellement à m'éloigner de fail2ban. À cet égard, au moins, denyhosts est mieux. Cependant, ce n'est apparemment plus une bonne option, et n'est plus pris en charge dans les versions plus récentes de debian (quelques discussions sur https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with- fail2ban-for-debian / )
Je n'ai pas de bonne solution ici.
En fait, je pense que denyHost est capable d'empêcher de nombreux autres services en plus du service sshd. Dans son fichier de configuration - /etc/denyhosts.conf, il y a quelques lignes de code dites:
# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg. sshd: 127.0.0.1 # will block sshd logins from 127.0.0.1
#
# To block all services for the offending Host:
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE = sshd
donc si nous définissons BLOCK_SERVICE variable devant être ALL comme ci-dessus, nous pouvons regarder notre service ssh.
Denyhosts version 3.0: chaque fois qu'une adresse IP apparaît dans un fichier journal, Denyhosts ouvre le fichier hosts.deny et lit le tout pour correspondre à l'adresse. À chaque fois. Rien n'est mis en cache dans la mémoire. Si vous avez un énorme fichier hosts.deny et êtes soumis à de nombreuses sondes (de nombreuses entrées de fichier journal), Denyhosts devient un porc de CPU lisant et relisant le fichier hosts.deny pour chaque adresse IP qui apparaît. Pas bon.
Si vous activez la prise en charge d'iptables, Denyhosts créera d'énormes listes lentes d'adresses IP bloquées. Denyhosts n'utilise pas d'ipset ou de nftables pour créer des cartes IP efficaces.