Forum Linux.général Protection bruteforce OpenLDAP

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
0
27
mai
2016

Salut à toi, moustachu du LDAP,

Sais-tu comment protéger un serveur OpenLDAP des attaques par dictionnaire ou par brute force.

Autrement dit, existe-il un moyen :
- d'interdire les requètes pendant un certain temps au bout de plusieurs erreurs ?
- de limiter la fréquence des requètes ?

Merci d'avance,

Librement

  • # fail2ban ?

    Posté par  (site web personnel) . Évalué à 4.

    Tout est dans le titre.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: fail2ban ?

      Posté par  (site web personnel) . Évalué à 1.

      Oui, fail2ban peut faire le boulot par contre je crois que je dois m'attendre à une baisse de performance parce qu'il génère beaucoup d'I/O.

      • [^] # Re: fail2ban ?

        Posté par  . Évalué à 4.

        Oui, fail2ban peut faire le boulot par contre je crois que je dois m'attendre à une baisse de performance parce qu'il génère beaucoup d'I/O.

        fail2ban va bloquer (avec le firewall iptables) une IP
        sur un motif pris dans les logs, par exemple les erreurs d'authentification

        donc il ne genere pas d'I/O hormis reecrire les regles iptables et les executer.

        ou alors je n'ai pas compris la question.

        • [^] # Re: fail2ban ?

          Posté par  (site web personnel) . Évalué à 3.

          • des I/O pour lire les logs. C'est probablement là que peuvent résider les coûts, s'il faut lire toutes les secondes ces derniers. Mais, si c'est bien fait et que les informations sont correctement envoyées à fail2an, ça doit aller. Sans savoir comment les logs sont transmis, je n'ai jamais remarqué de sur-activité lié à fail2ban sur mes machines.

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: fail2ban ?

      Posté par  . Évalué à 3.

      Fail2ban, ça peut être un peu délicat.

      Si ton LDAP est utilisé par une application (au hasard un serveur Web), tu risques de bloquer l'IP du serveur Web à cause d'un utilisateur (ou d'un hacker) qui tape plusieurs fois un mauvais mot de passe… et donc plus personne ne pourrait s'authentifier.

      Peut-être que ppolicy pourrait (au moins partiellement) répondre au besoin?

      • [^] # Re: fail2ban ?

        Posté par  (site web personnel) . Évalué à 2.

        Ah oui, ça c'est un gros problème effectivement.
        Si pour un utilisateur qui ne sais pas taper son mot de passe (et j'en ai !) ça me bloque tout le serveur "client LDAP" ça risque de poser problème.

        Je vais regarder ppolicy qui a l'air plus adapté à mon besoin.
        En effet derrière ma question, il y avait aussi plus globalement la politique des mots de passe (durée de vie, historique, blocage du brute force).

        Merci à toi

        • [^] # Re: fail2ban ?

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          En effet le module ppolicy est fait pour ça. Il va gérer plusieurs choses :
          - Contrôle lors de l'authentification : blocage de compte en cas d'authentifications ratées, expiration du mot de passe, réinitialisation forcée
          - Contrôle lors du changement de mot de passe : taille, présence dans un historique, robustesse, etc

          Concernant ta question initiale, tu peux configurer ppolicy pour bloquer un compte après par exemple 5 authentifications ratées dans un intervalle de 60 secondes, pour une durée de 10 minutes. Tout cela est paramétrable. Et tu peux associer des politiques différentes à des comptes différents.

      • [^] # Re: fail2ban ?

        Posté par  . Évalué à 5.

        Dans des configurations comme cela, il faut mettre le serveur web en whitelist pour fail2ban et activer un fail2ban du côté du serveur web.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.