Le blog de llaumgui

Linux en général, Fedora en particulier...

 

Aller au contenu | Aller au menu | Aller à la recherche

Balise - fail2ban

Fil des billets - Fil des commentaires

mercredi 12 septembre 2007

Par llaumgui - le mercredi 12 septembre 2007, 23:56 - Linux

 

Les Dedibox seraient elles plus victimes d'attaques ?

7 commentaires

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.

mercredi 25 avril 2007

Par llaumgui - le mercredi 25 avril 2007, 22:44 - Linux

 

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

aucun commentaire

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

lundi 13 novembre 2006

Par llaumgui - le lundi 13 novembre 2006, 19:45 - Linux

 

Protéger les accès SSH avec fail2ban

aucun commentaire

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

Lire la suite...