Le 09/10/07, Sébastien Renard <[EMAIL PROTECTED]> a écrit : > > Le mardi 9 octobre 2007, Cyril Mougel a écrit: > > Autre solution mettre le port ssh sur un autre port que le 22. Tu > > verras cela sera radical. Plus d'attaque par brute force. > > C'est en effet radicale. Une autre solution, qui permet de dormir > tranquille > est d'ajouter la directive AllowUSers avec uniquement un user. > Certes les attaques polluent toujours les logs, mais il n'y a pas besoin > de > s'inquiéter pour la solidité des mots de passe de chacun des users. > > Une solution encore plus efficace mais contraignante : n'autoriser le > login > que par clef. Il ne faut pas perdre les clefs dans ce cas et les avoir > toujours sur soi pour pouvoir se logguer.. > > A+ > -- > Sébastien >
Encore une autre solution, le daemon Fail2ban, qui surveille en permanence auth.log pour détecter ce genre d'attaques et paramétrer automatiquement iptables pour bloquer les adresses ip d'où elles proviennent. On peut paramétrer Fail2ban de manière à ce qu'il bloque une adresse pendant «x» secondes, s'il a detecté «y» tentatives de connexion venant de celle-ci dans les «z» dernières secondes. A priori, il suffirait de bloquer l'adresse pendant un quart d'heure pour que les bots abandonnent et partent à l'attaque d'une autre machine. J'ai trouvé un billet sur un blog qui explique ça plutôt bien : http://jujuseb.com/dotclear/?2006/04/18/6-fail2ban-contre-l-attaque-par-brute-force Sécuritairement, Miklos :)
_________________________________ Linux mailing list [email protected] http://lists.parinux.org/mailman/listinfo/linux
