Afin d’améliorer la sécurité de mon installe bluemind j’aurais voulu activer fail2ban pour bloquer les user après plusieurs tentative de connections échouée. malheureusement je ne trouve l’ip des users que dans les log de nginx et les échec de connections dans core.log.
J’ai également cherché la possibilité de faire un développement complémentaire mais je ne vois pas quelle point d’extension me permettrai d’y arriver.
Y a t’il un autre fichier de log qui rassemblerai les échec de connections avec l’ip ?
sinon prévoyez vous un système du style désactivation du user après x tentative ? ou bien y a t’il un point d’extension qui me permettrai d’agir après une tentative érronée ?
Il n’y a pas de log actuellement qui regroupe ces informations. Il faut passer par une étape de consolidation des logs. Nous prenons en compte ceci, il serait intéressant d’avoir l’IP réelle lors d’un l’authentification.
Avec le point d’extension net.bluemind.core.authenticationservice il doit-être possible d’ajouter un plugin d’authentification qui se place en dernier et ne serait donc atteint que si tout les autres plugins refusent de valider l’authentification proposée. En faisant un autre point d’extension de ce type, se placant en tout premier on peut ajouter des régles pour refuser directement l’authentification.
Par exemple, le dernier compte et stocke pour chaque login le nombre d’echec, le premier refuse si ce nombre dépasse un certain niveau et retourne DoAuthStatus.UNKNOWN sinon.
J’ai enfin pris le temps de regarder un peux au système d’authentification.
La piste que vous m’aviez proposé ne semble pas réalisable, en effet on ne peux pas placer de service d’authentification en dernier étant donné que le service DatabaseAuthenticationService est ajouté en dernier après le chargement des plugins.
me reste plus qu’a attendre une mise a jour éventuel qui rajouterai l’ip dans les log en cas d’échec.
Le problème de l’IP est qu’on n’aura pas forcément l’IP du client si on est derrière des reverses proxy plus ou moins bien configurés par exemple, mais ça reste quelque chose de simple à mettre en oeuvre.
Nous allons aussi discuter de la pertinence de modifier le chargement des plugins d’authentification afin de pouvoir éventuellement en ajouter après celui de validation sur la base.
Ha mon sens il serait plus simple d’ajouter ce control d’échec d’authentification au niveaux du databaseAuthentificatioservce directement. (d’autre système d’authentification telle que ldap/ad peuvent déjà gérer ce genre de problématique).
Il faudrait dés lors prévoir une possibilité de “déverrouiller” un user or interface web (via une commande système).
Quelque soit la solution ces a mon avis un problème important le user admin étant défini et fixe, les api public, il est facile de mettre en place une attaque par brut force pour hacker une installation.
bonjour,
en lisant le post je me demandais si les logs de nginx ne peuvent pas fournir la solution.
en fait à chaque connexion ratée, le code de retour de la requete “POST /webmail/bluemind_sso_security HTTP/1.1” est 200 sinon elle est 302
Cela ne conviendrait il pas pour configurer fail2ban, sachant que l’adresse ip est préente dans le fichier access.log ?
(si mes souvenirs sont bons, fail2ban peut prendre en considération le nombre d’échecs dans un temps donné pour une adresse IP)
Bonsoir,
J’ai fait quelque test mais malheureusement ton idée ne fonctionne pas dans tout les cas. Je ne sait pas se qui influe sur le status code mais j’ai eu des code 200 lors d’authentification réussi.
De plus cette approche permettrai uniquement de contrôler l’accès dans le cas d’authentification via l’interface web, or si quelqu’un tante un piratage il passerai plus facilement via les API/service.
En fait tu peux parfaitement bloquer le compte et gérer les attaques brute force avec un plugin. Par contre il faut te brancher sur 2 points d’extension :
...]
public class Fail2Ban implements IAuthenticationServiceFactory,
IAuthenticationService, ILoginValidationListener {
private static final Logger logger = LoggerFactory
.getLogger(Fail2Ban.class);
private final Cache<String, AtomicInteger> trials;
public Fail2Ban() {
trials = CacheBuilder.newBuilder()
.expireAfterAccess(20, TimeUnit.SECONDS).build();
}
@Override
public void loginValidated(IAuthenticationService iAuthenticationService,
String userLogin, Domain bmDomain, String password) {
trials.invalidate(userLogin + "@" + bmDomain.getName());
}
@Override
public DoAuthStatus doAuth(String userLogin, Domain domain, String password) {
String latd = userLogin + "@" + domain.getName();
AtomicInteger authCount = trials.getIfPresent(latd);
if (authCount == null) {
logger.info("First attempt for {}", latd);
trials.put(latd, new AtomicInteger(1));
return DoAuthStatus.UNKNOWN;
} else {
int val = authCount.incrementAndGet();
if (val > 3) {
logger.warn(
"Too many ({}) attempts for {}. Wait 20sec to retry",
val, latd);
return DoAuthStatus.NO;
} else {
logger.info("** Attempt {} for {}", val, latd);
return DoAuthStatus.UNKNOWN;
}
}
}
...]
}
Chaque tentative d’authent incrémente un compteur par utilisateur dont la valeur est conservé 20sec (le 20, TimeUnit.SECONDS dans le code). Ces 20sec sont réarmées à chaque fois qu’une nouvelle authen est essayée. Si on ne tente plus pendant 20sec, ça se ré-initialize et les tentatives sont à nouveau prises en compte.
Si mon petit projet intéresse quelqu’un je l’ai mis sur un projet GIT : https://github.com/pumdum/BM-Fail2Ban
J’ai juste apporté quelque modif a la proposition de tcataldo. j’essayerai dans le futur de pouvoir réinitialisé le compteur pour un utilisateur manuellement (sinon il suffit de redémarrer bm).
Si mon petit projet intéresse quelqu’un je l’ai mis sur un projet GIT : https://github.com/pumdum/BM-Fail2Ban
J’ai juste apporté quelque modif a la proposition de tcataldo. j’essayerai dans le futur de pouvoir réinitialisé le compteur pour un utilisateur manuellement (sinon il suffit de redémarrer bm).[/quote]
Merci beaucoup ! Rien n’est fait actuellement, mais nous prévoyons de mettre en avant les contributions et projets annexes à Blue Mind.
Si nous avons démarré ce chantier, avec la mise à disposition de l’outil de traduction en ligne, intégré directement avec modération, à la plateforme d’intégration continue.
Cela nous a permis aussi de publier les règles de contribution (partage de la propriété) pour permettre à Blue Mind d’utiliser les contributions (celles qui sont effectuées sur le logiciel lui-même) y compris commercialement, et de protéger les auteurs au niveau de la responsabilité.
Prochaine étape, mettre en avant les contributions existantes.
