Si une telle attaque a très peu de chance de passer avec les mesures de sécurité qui vont bien, il n’empêche qu’elle consomme les ressources du serveur (bande passante notamment).
Encore une fois, c’est pas la panacée en terme de sécurité. Ça ne veut pas dire pour autant que le ratio bénéfices/coût est nul.
Bonjour,
Je suis tout à fait d’accord avec les remarques faites sur ce outil.
Je ne considère pas fail2ban comme un outil de sécurité a proprement parler. Il sert effectivement à :
Cela a donc son intérêt pour des services où l’on est obligé de laisser un accès par mot de passe, surtout si le mot de passe est géré par l’utilisateur final et est susceptible d’être faible. Ce qui est le cas de certains sites web ou de serveurs de courriels par exemple.
Par contre ce n’est en rien une protection absolue. Le cas des botnets a été évoqué, mais il faut aussi bien comprendre que fail2ban agit après coup. Une IP n’est bloquée qu’après un certains nombre de tentatives et après analyse des logs.
En outre fail2ban consomme lui aussi des ressources.
Penser être protégé (faux sentiment de sécurité) parce que l’on a installé fail2ban et plus ou moins bien configuré un pare-feu est une erreur assez courante. On peut d’ailleurs le voir dans un fil récent de ce forum.
En effet, pour l’instant mon hypothèse est qu’une fois qu’on fait entrer le faux sentiment de sécurité dans l’équation, le rapport bénéfices/risques est négatif 
En effet, c’est un cas d’utilisation qui se défend, même si mon serveur mail (dont tous les comptes n’utilisent probablement pas des mots de passe très forts) semble s’en être sorti sans depuis des années.
Idem d’ailleurs pour les serveurs Web de type WordPress/PrestaShop/Drupal dont j’ai eu la charge quand je bossais en administration système pour des agences de développement Web gérant aussi l’hébergement des sites.
C’est en partie à cause de ces expériences que je commence à douter de la réalité de ce type de menace.
C’est bien ce qui m’a fait ouvrir ce fil. Je me demande si j’ai loupé un intérêt de fail2ban pour la sécurité des serveurs, ou s’il est conseillé à tort pour remplir un rôle dont il est incapable. La question pourrait d’ailleurs s’élargir aux pare-feux, je suis parti sur fail2ban parce qu’il semble être l’interface de configuration automatique de pare-feu la plus conseillée sur nos forums.
Je vois très souvent fai2ban présenté comme un composant essentiel de la sécurité d’un serveur public, à installer sans se poser de question. Mais je constate aussi que cette mise en avant semble surtout faite par des personnes avec peu d’expérience en administration système, alors que quand j’en cause avec des collègues expérimentés il est souvent soit inconnu, soit inutilisé.
Avec pas loin de 1.5Go de log par semaine sur plusieurs serveurs virtuels je dirais pas la même.
Sans doute que ton IP et ton domaine n’intéresse pas trop pour l’instant (touche du bois ).
Je vais quand même pas bannir la moitié de la planète pour conserver des logs de taille raisonnable.
Maintenant Fail2ban je l’installe systématiquement avec les jails adéquat, mais ce n’est clairement pas le seul éléments que j’installe pour sécuriser un serveur.
Pour avoir eu à m’occuper (et c’est toujours d’actualité actuellement) des serveurs de mails avec des comptes imap qui régulièrement sont testés (aps une journée sans plusieurs centaines de tentatives).
C’est dernier temps je travaille avec du haproxy en amont pour filtrer et restreindre les accès, malgré tout je conserver comme base de mon industrialisation fail2ban, ça ne peux pas faire de mal …
Bien entendu et c’est malheureusement le cas lorsque l’on regarde des tutoriels expliquant la sécurisation d’un serveur sur pas mal de Blog.
Pour rappel : l’infogérance d’un serveur/service est un métier et cela s’apprend facilement mais cela ne s’improvise pas.
Je suis dans le même ordre de grandeur sur mes services. Je ne dis pas que les attaques n’existent pas, mais bien que la menace est au mieux exagérée
Mes IPs sont scannées en permanence, on attaque mes services tout au long de la journée (surtout le mail apparemment), mais malgré tout ça rien ne passe.
De ce que je vois des attaques, c’est surtout des trucs qui visent des relais mail ouverts ou des WordPress configurés avec les pieds. Et pour ça la réponse n’est sûrement pas fail2ban, mais de faire appel à quelqu’un de compétent pour repenser la configuration des services.
En fait je pense que la plupart des attaques que je vois passer visent surtout des machines sans administrateur, oubliées depuis longtemps sur un coin de réseau sans aucune forme de maintenance. Pour celles-ci fail2ban ne fera pas de miracle. Et pour les autres (les machines correctement administrées), je continue à penser qu’il n’apporte pas de bénéfice mesurable.
Je ne comprends pas : ce n’est pas justement ce que fail2ban se propose de faire ?
Vu le niveau de compétences de pas mal de professionnels que j’ai croisé au cours de mes activités, je confirme que ce n’est pas difficile de faire mieux que ce qui est attendu dans l’industrie 
Mais pour autant, ça ne s’improvise pas en effet.
12 clients de mon entreprise ont fait l’objet de ce type d’attaque plus quelques autres (types d’attaque NDLR). la réalité de ces attaques est bien réelle. Sans parler d’environ près d’une demi douzaine, et peut etre plus, d’entreprise du CAC40 ou affiliées qui ont l’objet de ransomware depuis 2019, dont Gefco, SOPRA-STERIA par exemple.
l’attaque par force brute, c’est le bas de gamme des attaque; c’est le modèle bourrin; ce qui n’enlève rien à une parie de son efficacité.
c’est une bonne solution, car en plus, HAPROXY travaille en layer7 et layer 4 ce qui permet même d’être en frontal de serveur SSH, messagerie, etc…
et même dans le métier, ce n’est pas une sinécure 
Mais concernant le volume de logs, faire un serveur de gestion de ces logs peut être un plus (un SOC/SIEM par exemple). Ce n’est pas facile à faire, mais les retours peuvent être intéressant, sur la visibilité d’une part, et d’autre part, à partir de ça de savoir ce qu’il faut envisager comme actions et solutions.
oui il y en a, et qui fonctionne sur des comptes de messagerie par exemple, ou des applicatifs exposés sur internet (entre autre des applicatifs dans lesquels les devs ont oublié de retirer les comptes de tests avec des mots de passe minables, c’est du vécu sur ce dernier cas).
en termes de volume avec le DDOS, les attaques par forces brutes sont les plus nombreuses.
Tu veux dire qu’ils ont été la cible d’attaques par force brute, ou qu’ils ont subi des brèches de sécurité suite à des attaques de ce type ?
Je ne doute pas de l’existence des attaques, j’en vois tous les jours dans mes logs
Mais comme je disais un peu plus haut je cherche des retours d’expérience qui montreraient qu’il arrive à ces attaques de réussir sur autre chose que des serveurs abandonnés sans aucune forme de maintenance.
personnellement je suis en train de tout revoir chez moi, j’utilise un IDS, un ELK pour centraliser tous les logs et notifications afin de pouvoir une visibilité la plus dénuées de faux positifs possibles, que ce soit au niveau système, applicatif, IPv4 et IPv6 (les systèmes sur IPv6 sont actuellement plus fragiles que IPv4, non pas à cause du protocole en lui-même mais de la façon dont il est utilisé utilisation).
Toutes les machines ont un parefeu de base dont la configuration utilise les mêmes règles de conception (pas de ruleset), dont les logs remontent tous au même endroit.
j’ai ma propre PKI pour les accès qui ne sont pas universel (i.e.: dont des gens que je ne connais peuvent être utilisateurs potentiels).
tous les accès HTTP/HTTPS passent toutes par un HAPROXy, SSH est en passe de l’etre aussi. et bientot la mise en place d’un proxy pour la sortie sur internet.
je cherche à mettre en place un moyen de tracer les accès web au niveau applicatif (quelle application pour quel flux).
Non je bloque temporairement, afin que le curieux passe à autre chose.
J’ai déplacé la question de @Alphoso dans un fil dédié pour qu’elle ne se retrouve pas mélangée au reste de la discussion :
J’ai vu par le passé au moins deux attaques réussies sur des comptes de courrier électronique par force brute. Dans les deux cas les mots de passes était extrêmement basiques et présents dans les dictionnaires courants utilisés par les scripts kiddies. Les logs montraient qu’ils avaient été trouvés après seulement quelques dizaines de tentatives.
Fail2ban aurait sans doute pu ralentir le processus, mais ces comptes auraient fini par être compromis. La seule politique de sécurité viable à ce niveau est de forcer une complexité minimale des mots de passe, voire la double authentification.
À l’heure actuelle je vois plutôt ce type de tentatives sur les comptes courriels :
Jul 29 01:40:33 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<fynbar@example.com>, method=PLAIN, rip=210.61.47.79, lip=*.*.*.*, TLS: Connection closed, session=<G7nogjfIdKzSPS9P>
Jul 29 02:12:13 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<christiana@example.com>, method=PLAIN, rip=122.53.139.111, lip=*.*.*.*, TLS: Connection closed, session=<Yosc9DfI2tV6NYtv>
Jul 29 02:53:11 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 9 secs): user=<christiana@example.com>, method=PLAIN, rip=205.240.77.231, lip=*.*.*.*, TLS, session=<zyVxhjjIWYDN8E3n>
Jul 29 02:53:30 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 4 secs): user=<christiana@example.com>, method=PLAIN, rip=184.179.216.135, lip=*.*.*.*, TLS, session=<lsTWhzjI3Ze4s9iH>
Jul 29 06:04:38 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<fynbar@example.com>, method=PLAIN, rip=123.63.30.201, lip=*.*.*.*, TLS: Connection closed, session=<vIpWMzvIvaR7Px7J>
Jul 29 06:21:58 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<christiana@example.com>, method=PLAIN, rip=200.146.227.146, lip=*.*.*.*, TLS: Connection closed, session=<miNTcTvIuqzIkuOS>
Jul 29 06:39:37 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<christiana@example.com>, method=PLAIN, rip=129.126.101.198, lip=*.*.*.*, TLS: Connection closed, session=<5C5vsDvIAuqBfmXG>
Jul 29 07:39:39 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<fynbar@example.com>, method=PLAIN, rip=196.70.252.2, lip=*.*.*.*, TLS: Connection closed, session=<BMYhhzzIUbfERvwC>
Jul 29 08:06:01 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<christiana@example.com>, method=PLAIN, rip=220.66.155.2, lip=*.*.*.*, TLS, session=<gJdp5TzI8EPcQpsC>
Jul 29 08:52:58 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<christiana@example.com>, method=PLAIN, rip=129.205.106.123, lip=*.*.*.*, TLS: Connection closed, session=<I0JNjT3IdLOBzWp7>
Jul 29 09:22:08 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<christiana@example.com>, method=PLAIN, rip=177.43.251.153, lip=*.*.*.*, TLS: Connection closed, session=<hxGn9T3IsKSxK/uZ>
Jul 29 15:20:24 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 5 secs): user=<fynbar@example.com>, method=PLAIN, rip=187.50.136.210, lip=*.*.*.*, TLS: Connection closed, session=<QSfo9kLI+bO7MojS>
Jul 29 19:55:26 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<fynbar@example.com>, method=PLAIN, rip=200.146.227.146, lip=*.*.*.*, TLS: Connection closed, session=<zyN5zkbI9KXIkuOS>
Jul 29 20:27:58 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<christiana@example.com>, method=PLAIN, rip=200.205.134.107, lip=*.*.*.*, TLS, session=<Yt7TQkfI/cvIzYZr>
Jul 29 21:35:57 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<fynbar@example.com>, method=PLAIN, rip=139.198.121.63, lip=*.*.*.*, TLS: Connection closed, session=<P3n0NUjIw7qLxnk/>
Jul 29 21:48:51 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 4 secs): user=<christiana@example.com>, method=PLAIN, rip=212.98.122.91, lip=*.*.*.*, TLS: Connection closed, session=<7RUsZEjIK9XUYnpb>
Jul 29 22:03:05 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<christiana@example.com>, method=PLAIN, rip=143.59.208.91, lip=*.*.*.*, TLS: Connection closed, session=<fc76lkjIPISPO9Bb>
Jul 29 22:44:35 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<fynbar@example.com>, method=PLAIN, rip=220.66.155.2, lip=*.*.*.*, TLS, session=<gkJaK0nIMBTcQpsC>
Jul 29 23:11:16 ks10 dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<christiana@example.com>, method=PLAIN, rip=181.176.172.162, lip=*.*.*.*, TLS, session=<MKjViknIX3S1sKyi>
On voit que les IP sources sont différentes et les nouvelles tentatives provenant des mêmes IP se produisent plusieurs heures après. Elles passeront donc sous le radar d’un fail2ban configuré avec des délais raisonnables.
Je continue à utiliser fail2ban pour un ou deux services (et surtout pour transmettre les IP aux bases de données) mais on peut effectivement parfaitement s’en passer si les services sont correctement sécurisés avec une bonne politique de mots de passe.
Ça correspond aussi à ce que je vois chez moi dans les logs de la plupart de mes services. Et en effet ça fait partie des raisons de mes doutes initiaux au sujet de fail2ban.
fail2ban ne fait pas plus qu’il n’est censé faire.
si tu penses qu’il ne sert à rien, ne l’installe pas.
de la me même manière, tu peux aussi ne pas mettre de ceinture de sécurité dans une voiture. Après tout, si tu n’as pas d’accident elle ne sert à rien.
C’est déjà ce que je fais, mais comme je vois pas mal de monde le recommander je cherche à comprendre dans quel cadre il est utilisé sérieusement, et pourquoi il est autant recommandé aux débutants en administration système alors qu’il semble majoritairement ignoré par les administrateurs plus expérimentés.
Cette comparaison est d’un niveau de mauvaise foi que je trouve surprenant…
Et ce qu’il est censé faire a été expliqué plus haut.
Il vaut mieux éviter ce genre d’analogie foireuse. La sécurité d’un passager d’une voiture n’a strictement rien à voir avec la sécurité d’un service informatique. Le port de la ceinture de sécurité minimise les dégâts corporels en cas d’accident. Fail2ban ne protège de rien en cas d’accident (intrusion).
D’ailleurs fail2ban ne protège pas des intrusions. Il diminue la probabilité de succès d’une attaque par force brute menée par une IP unique sur un service accessible avec un mot de passe faible.
Et c’est typiquement ce genre d’argument fondé sur une fausse analogie qui maintient l’utilisateur dans l’illusion de la sécurité.
Exactement, c’est pourquoi lorsque je le mets en place c’est avant tout pour alléger les logs de connexion et éviter de polluer mes logs de connexion SQL, SMTP, FTP, SSH, etc
Maintenant sa mise ne place est industrialisé, je ne perds donc pas de temps pour le mettre ne place c’est pourquoi je le déploie systématiquement.
C’est pour l’instant le cas d’utilisation le plus justifié que j’ai pu voir proposé. Mais dans ce cas ce n’est « que » un outil de confort pour l’administration des machines, pas un outil lié à la sécurité. Plus ou moins comparable à l’utilisation de ports non-standards pour les services ouverts à l’extérieur.
Je n’ai bien sûr aucun souci avec ce genre d’outil, mais c’est une très mauvaise chose dans ce cas qu’il soit autant recommandés aux débutants comme une première étape dans la sécurisation d’un serveur.
En quoi ça serait une mauvaise chose ? est-ce que je devrais désinstaller fail2ban ?
Le premier article que je trouve " Fail2ban is the answer to protect services from brute force and other automated attacks."
Si quelqu’un raconte n’importe quoi sur un forum ou ailleurs, l’outil n’est pas à remettre en question.
sur le fond, le plus important est de savoir ce qu’il est nécessaire de mettre en place pour protéger ses services.
certains outils sont plus ou moins facile à mettre en place.
de ce point de vue, fail2ban n’est pas complexe à mettre en place.
a partir de là, il y a encore du chemin pour sécuriser son environnement.
Non ce n’est pas la réponse. Relire le post de Bruno ou de Clochette plus haut.