Je suis en train de mettre en place un serveur LAMP et j'ai besoin d'empêcher les tentatives de connexion par force brute SSH/FTP/etc. de réussir. J'ai vu de nombreuses recommandations pour denyhosts et fail2ban, mais peu de comparaisons entre les deux. J'ai également lu qu'une règle IPTables peut remplir la même fonction.
Pourquoi choisirais-je une de ces méthodes plutôt qu'une autre ? Comment les gens sur serverfault gèrent-ils ce problème ?
Une chose à noter à propos de Fail2Ban est qu'il semble utiliser environ 10 Mo de mémoire de plus que DenyHosts. Donc, si vous êtes sur un VPS de 128 Mo, vous devriez peut-être vous pencher sur cette question. De plus, Fail2Ban n'est configuré qu'en SSH, ce qui signifie qu'en l'absence de modification de la configuration, DenyHosts fait la même chose avec moins de mémoire.
Denyhosts version 3.0 : Chaque fois qu'une adresse IP apparaît dans un fichier journal, Denyhosts ouvre le fichier hosts.deny et le lit en entier pour faire correspondre l'adresse. A chaque fois. Rien n'est mis en cache en mémoire. Si vous avez un énorme fichier hosts.deny et que vous êtes soumis à de nombreuses sondes (beaucoup d'entrées dans le fichier journal), Denyhosts devient un gros consommateur de CPU en lisant et relisant le fichier hosts.deny pour chaque adresse IP qui apparaît. Ce n'est pas bon.
Si vous activez le support iptables, Denyhosts créera des listes énormes et lentes d'adresses IP bloquées. Denyhosts n'utilise pas ipset ou nftables pour créer des cartes IP efficaces.
Au lieu de s'embêter avec une configuration fastidieuse d'iptables ou de fail2ban, pourquoi ne pas laisser la communauté ouverte faire tout le travail pour vous, et utiliser CSF/LFD à la place ? Je peux fortement le recommander au-dessus de 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 lui-même une interface utilisateur simple, pour ceux qui ne veulent pas le faire par Shell. Et c'est beaucoup de perl-scripting non-résident stable et fiable.
Fail2ban ne semble pas avoir de mécanisme pour reconnaître une connexion ssh réussie et réinitialiser son compte d'échecs.
Le filtre standard de sshd (du moins sur mon installation debian), compte les é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 se retrouvent régulièrement bloqués, bien que leurs connexions aient réussi une fois que quelques clés ont été passées en revue.
En conséquence de ce qui précède, j'envisage actuellement de m'éloigner de fail2ban. À cet égard au moins, denyhosts est meilleur. Cependant, ce n'est apparemment plus une bonne option, et elle n'est plus supportée dans les versions plus récentes de Debian (quelques discussions à https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-fail2ban-for-debian/ )
Je n'ai pas de bonne solution ici.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
