De l’intérêt de fail2ban

Zargos · Juillet 28, 2021, 3:43pm

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.

anon96191775 · Juillet 28, 2021, 3:38pm

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.

Zargos · Juillet 28, 2021, 3:50pm

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).

Clochette · Juillet 28, 2021, 4:49pm

Non je bloque temporairement, afin que le curieux passe à autre chose.

anon96191775 · Juillet 29, 2021, 9:50am

2 messages ont été scindés en un nouveau sujet : Pare-feu Nanopi R4S et FriendlyWrt

anon96191775 · Juillet 29, 2021, 9:52am

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 :

Pare-feu Nanopi R4S et FriendlyWrt

anon70622873 · Juillet 30, 2021, 8:30am

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.

anon96191775 · Juillet 30, 2021, 7:29am

Ç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.

yatta · Juillet 30, 2021, 10:28am

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.

anon96191775 · Juillet 30, 2021, 10:53am

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…

anon70622873 · Juillet 30, 2021, 11:03am

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é.

Clochette · Juillet 30, 2021, 11:59am

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.

anon96191775 · Juillet 30, 2021, 4:57pm

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.

yatta · Juillet 31, 2021, 8:39am

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.

Zargos · Juillet 31, 2021, 8:58am

Non ce n’est pas la réponse. Relire le post de Bruno ou de Clochette plus haut.

anon96191775 · Juillet 31, 2021, 9:05am

Pour l’instant ce qui ressort de ce fil c’est que fail2ban n’est ni nécessaire, ni même utile pour sécuriser des services.

Il peut apparemment servir à améliorer la lisibilité des logs sur le serveur, et aider à nourrir des bases de données d’IP au comportement suspect. Mais ça n’est pas de la sécurisation de quoi que ce soit.

La simplicité de mise en place n’apporte rien ici. Google Chrome aussi c’est simple à installer, heureusement personne ne conseille aux débutants de l’installer sur leurs serveurs pour les sécuriser.

yatta · Juillet 31, 2021, 10:35am

ici, je lis

diminuer la probabilité de réussite d’une attaque par force brute ;

pour faire simple on va repartir de la source :

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs – too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, courier, ssh, etc).
Fail2Ban is able to reduce the rate of incorrect authentications attempts however it cannot eliminate the risk that weak authentication presents. Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services.

au final, on fait quoi de ces IPs ? si c’est juste pour les stocker, l’intérêt est plus que limité.

anon70622873 · Juillet 31, 2021, 10:50am

J’ai précisé par la suite et c’est important :

Et la doc de fail2ban que tu indiques, dit la même chose que moi.

Par exemple pour un service SSH/SFTP correctement configuré, accessible uniquement par clés ou par mots de passe très solides, fail2ban est tout à fait superflu sauf si on veut envoyer des signalements sur les IP qui tentent des connexions.

Pour l’envoi des IP à des services tiers je disais :

Cela contribue à la désactivation des machines compromises qui font des tentatives de connexion (si le service abuse concerné est efficace) et donc globalement à avoir un Internet un tout petit peu plus sûr.
Les services cités utilisent ces bases de données pour fournir des listes noires (RBL ou DNSBL) qui peuvent ensuite être utilisées comme moyen de filtrage pour les service hébergés. C’est particulièrement utile, par exemple, pour un serveur de courrier.

Mediaf · Août 3, 2021, 8:51am

Comme vous le dites vous-même :
« recommandés aux débutants comme une première étape dans la sécurisation d’un serveur. »
Pour sécuriser un serveur, il faut bien commencer par quelque chose, avant de passer à autre chose.
J’utilise Fail2ban sur tous mes serveurs depuis plus de 15 ans. Il m’a été extrêmement utile à une époque où je n’avais qu’un serveur « multitâches » : serveur web, mysql, dns, e-mail, ftp, ssh, etc… Car il bloquait rapidement toutes les activités malveillantes, limitait le volume des logs à une époque où les disque durs courants n’atteignaient pas les 100 Go.
Et avant la diffusion de fail2ban, j’ai moi-même subi un rootkit suite à une attaque brute force sur un serveur de production que fail2ban aurait certainement évité, s’il avait existé… Mais j’étais moi-même débutant à l’époque.
Autre chose, à propos des ip identifiées qui sont « libérées » au bout de quelques heures, il y a la détection des récidives qui les bloque durablement.

anon96191775 · Août 3, 2021, 9:14am

Oui, il faut bien commencer par quelque chose, mais par quelque chose d’utile sinon c’est contre-productif et forme juste à de mauvaises pratiques.

Pourtant de ce que je vois des retours dans ce fil, fail2ban ne bloque pas les activités malveillantes. Et encore moins toutes les activités malveillantes.

Si tu as des exemples concrets de menaces qui auraient réellement pu aboutir mais ont été déjouées par fail2ban, ça m’aiderait à nuancer mon opinion