Le blog de llaumgui - fail2ban

Les Dedibox seraient elles plus victimes d'attaques ?

llaumgui — Wed, 12 Sep 2007 23:56:00 +0200

Que ce soit professionnel ou personnel : je gère, à la louche, un parc de 15 serveurs dédiés.
Si je mets de côté les serveurs sous Windows qui sont à eux seuls, à la fois une aberration et une faille de sécurité; je dois m'occuper d'une bonne dizaine de serveurs Linux. Ces serveurs sont variés et tournent sous des Debian Sarge et Etch, des CentOS 5 ou Fedora 5. On peut localiser ce parc par 8 serveurs chez Ikoula et 2 Dedibox.

Après avoir décrit le parc, je vais décrire mes habitudes. Comme je suis conscient que tout le monde il est pas beau et que tout le monde il est pas gentils; j'ai pris l'habitude d'installer fail2ban et logwatch sur mes serveurs.
Le premiers détecte les tentatives d'intrusions par brute force et bloque, pendant une durée X, l'IP de toute personne ayant tenté par 3 fois et sans succès, de se connecter sur un serveur.
Le second est une tâche planifiée qui m'envoie un rapport journalier sur les serveurs.

Maintenant que le décor est planté, ma constatation : Les attaques par brute force ou par tentative d'exploitation de faille CMS ou de forums^[1] sur mes 2 Dedibox sont largement supérieures à celles de mes serveurs chez Ikoula voir même supérieures à l'ensemble de toutes les autres machines.

J'ai ouvert un topic sur le sujet chez Dedibox-news et l'explication qu'il m'a été faite me parait à la fois effrayante et réaliste : à 29€ HT, Dedibox démocratise le dédié et n'importe quel clampin peu s'offrir une box sans aucune compétence en administration. Bilan, les IPs Dedibox auraient une réputation plus facile...

^[1] Erreur 404 représentant des URLs typiques de script répendu tel que phpMyAdmin, joomla ou autres.

fail2ban et l'erreur "Please check the format and your locale settings."

llaumgui — Wed, 25 Apr 2007 22:44:00 +0200

J'avais déjà parlé de fail2ban dans un précédent billet, hors depuis quelque temps, je ne reçoit plus de mail d'alerte de la part de ce scripts... Arrêterait-on de forcer les accès SSH de Borsalino ?
C'est donc en contrôlant les logs (/etc/log/fail2ban.log), que je tombe sur près de 45.000 entrées.

root@borsalino ~> wc -l /var/log/fail2ban.log

45 751 /var/log/fail2ban.log

Un petit cat et je me rends compte d'une ligne récurante :

ERROR: time data did not match format: data=Mar 21 10:00:50 fmt=%b %d %H:%M:%S

ERROR: Please check the format and your locale settings.

Après recherche sur le wiki de fail2ban, et la lecture de la faq, il s'avère que ce message vient d'un bug (#1457620) introduit dans la version 0.6.1, fixé (0.6.2) et du à l'expression régulière en charge de l'analyse des logs.

En effet mon système étant en français (fr_FR), fail2ban s'attend à trouver des logs (/var/log/secure) avec des dates françaises, ce qui n'est pas le cas... Pour cela, comme indiqué dans la faq, il suffit de renseigner la ligne locale dans le fichier de configuration (/etc/fail2ban.conf) :

# Option:  locale

# Notes.:  global (cannot be redefined per section) locale to use for

#          timestamp pattern matching by changing LC_TIME for

#          fail2ban process. Empty entry sets locale to default one

#          (usually specified by LC_ALL environment variable).

# Values:  LOCALE  Default:

#

locale = en_US

Protéger les accès SSH avec fail2ban

llaumgui — Mon, 13 Nov 2006 19:45:00 +0100

Après l'attaque de ce week-end et après une lecture des logs d'accès ssh, je me suis décidé à mettre en place une gestion automatique des bannissements d'IPs.

L'idée est simple : bannir les IPs qui tentent de passer le compte root en "Brut de force".
Il est évident que l'accès root n'est pas autorisé en ssh (PermitRootLogin no) tout comme les mots de passe (PasswordAuthentication no), et que de telles attaques ne peuvent pas aboutir, mais c'est pour le principe ;-).

root@borsalino ~> cat /var/log/secure.1 | grep "Failed password for root" --count

1812

Sur les conseils de Titax, je me suis penché sur fail2ban, mais à la différence de la méthode proposée par Thierry, j'ai préféré utiliser le dépôts dries.

Si vous ne l'avais pas installé, vous en trouverez la config ici.

Pour installer fail2ban :

root@borsalino ~> yum --enablerepo=dries install fail2ban

Une fois le service installé, il faut le configurer, ça ce passe dans /etc/fail2ban.conf, le fichier et très bien documenté vous pourrez y régler le nombre de tentative, la durée du bannissement, les services concernés (ssh mais possibilité de le mettre en place pour apache), et l'envoi de mail lors d'un bannissement.

Ensuite, pour activer le service :

root@borsalino ~> /sbin/chkconfig --add fail2ban

root@borsalino ~> /sbin/service fail2ban start