Problème avec Fail2ban

Problème avec Fail2ban - Sécurité - Systèmes & Réseaux Pro

Marsh Posté le 20-12-2013 à 11:03:49    

J'ai un soucis avec un fail2ban sur un de mes dédies chez OVH.
Il ne fait pas son boulot (je ne reçoit aucun mail de ban SSH alors que sur mes autres dédiés c'est au moins 5 par  jours).
Je précise que l'envoi de mail fonctionne et que j'ai un autre dédié qui est, pour autant que je puisses le dire, identiques (machine prise à peu de temps d'écart, même version de Plesk et avec le même OS : Centos 6.5).
 
Premier truc, dans les logs de fail2ban j'ai énormément de :

Code :
  1. 2013-12-19 16:15:59,136 fail2ban.filter : DEBUG  Processing line with time:1387191041.0 and ip:91.121.162.124
  2. 2013-12-19 16:15:59,136 fail2ban.filter : DEBUG  Ignore line since time 1387191041.0 < 1387466159.14 - 600
  3. 2013-12-19 16:15:59,137 fail2ban.filter : WARNING Determined IP using DNS Reverse Lookup: ks360316.kimsufi.com = ['91.121.162.124']


Mais je ne sais pas ce que c'est, ni si ça a un rapport...
 
Et il s'est coupé ce matin avec :

Code :
  1. 2013-12-20 03:21:29,580 fail2ban.filter : DEBUG  Callback for Event: <Event dir=False mask=0x2 maskname=IN_MODIFY name='' path=/var/log/secure pathname=/var/log/secure wd=2 >
  2. 2013-12-20 03:21:29,581 fail2ban.filter.datedetector: DEBUG  Sorting the template list
  3. 2013-12-20 03:21:37,491 fail2ban.filter : DEBUG  Callback for Event: <Event dir=False mask=0x100 maskname=IN_CREATE name=logrotate_temp.0a1ReB path=/var/log pathname=/var/log/logrotate_temp.0a1ReB wd=1 >
  4. 2013-12-20 03:21:37,491 fail2ban.filter : DEBUG  Ignoring creation of /var/log/logrotate_temp.0a1ReB we do not monitor
  5. 2013-12-20 03:21:37,515 fail2ban.comm   : DEBUG  Command: ['ping']
  6. 2013-12-20 03:21:37,583 fail2ban.comm   : DEBUG  Command: ['stop', 'all']
  7. 2013-12-20 03:21:37,583 fail2ban.server : INFO   Stopping all jails
  8. 2013-12-20 03:21:37,583 fail2ban.server : DEBUG  Stopping jail ssh-iptables
  9. 2013-12-20 03:21:38,517 fail2ban.actions: DEBUG  Flush ban list
  10. 2013-12-20 03:21:38,517 fail2ban.actions: WARNING [ssh-iptables] Unban 222.175.114.134
  11. 2013-12-20 03:21:38,517 fail2ban.actions.action: DEBUG  iptables -n -L INPUT | grep -q 'fail2ban-SSH[ \t]'
  12. 2013-12-20 03:21:38,520 fail2ban.actions.action: DEBUG  iptables -n -L INPUT | grep -q 'fail2ban-SSH[ \t]' returned successfully
  13. 2013-12-20 03:21:38,520 fail2ban.actions.action: DEBUG  iptables -D fail2ban-SSH -s 222.175.114.134 -j DROP
  14. 2013-12-20 03:21:38,521 fail2ban.actions.action: DEBUG  iptables -D fail2ban-SSH -s 222.175.114.134 -j DROP returned successfully
  15. 2013-12-20 03:21:38,522 fail2ban.actions.action: DEBUG  Nothing to do
  16. 2013-12-20 03:21:38,522 fail2ban.actions: WARNING [ssh-iptables] Unban 61.147.116.58
  17. 2013-12-20 03:21:38,522 fail2ban.actions.action: DEBUG  iptables -n -L INPUT | grep -q 'fail2ban-SSH[ \t]'
  18. 2013-12-20 03:21:38,524 fail2ban.actions.action: DEBUG  iptables -n -L INPUT | grep -q 'fail2ban-SSH[ \t]' returned successfully
  19. 2013-12-20 03:21:38,524 fail2ban.actions.action: DEBUG  iptables -D fail2ban-SSH -s 61.147.116.58 -j DROP
  20. 2013-12-20 03:21:38,526 fail2ban.actions.action: DEBUG  iptables -D fail2ban-SSH -s 61.147.116.58 -j DROP returned successfully
  21. 2013-12-20 03:21:38,526 fail2ban.actions.action: DEBUG  Nothing to do
  22. 2013-12-20 03:21:38,526 fail2ban.actions.action: DEBUG  iptables -D INPUT -p tcp --dport ssh -j fail2ban-SSH
  23. iptables -F fail2ban-SSH
  24. iptables -X fail2ban-SSH
  25. 2013-12-20 03:21:38,529 fail2ban.actions.action: DEBUG  iptables -D INPUT -p tcp --dport ssh -j fail2ban-SSH
  26. iptables -F fail2ban-SSH
  27. iptables -X fail2ban-SSH returned successfully


On dirait un problème due au logrotate similaire à ça : https://github.com/fail2ban/fail2ban/issues/44
Mais je ne comprends pas la solution donné :

Citation :


Quick fix for this, for users, is to use
 
backend = gamin
 
to switch back to gamin for file change monitoring.


Et ça n'explique pas pourquoi j'ai ça sur ce serveur uniquement et pas sur l'autre !


Message édité par mechkurt le 20-12-2013 à 11:07:45
Reply

Marsh Posté le 20-12-2013 à 11:03:49   

Reply

Marsh Posté le 21-12-2013 à 17:06:45    

Truc bête qui m'est déjà arrivé : les timestamp dans tes logs sont-ils à l'heure ? (c'est à dire pas décalé d'une heure par exemple)
 
Ca arrive quand le service syslog est lancé, puis qu'on change la timezone de la machine sans le relancer, les logs restent sur l'ancien timezone, du coup fail2ban estime que la règle ne s'applique plus.
 
Je dis ça parce que les premiers logs que tu mentionnes ressemblent à ce type de problème.


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Reply

Marsh Posté le 23-12-2013 à 09:52:50    

J'ai reboot la machine "au cas ou" mais j'ai plus l'impression que c'est un problème de log-rotate (après c'est ptet lié).
 
Elle à recoupé dimanche à 3 H du matin donc je suis resté 24 H sans Fail2Ban, c'est reloud ce truc...


---------------
D3
Reply

Marsh Posté le 15-01-2014 à 08:33:22    

j'ai le même souci, as tu trouvé la solution ?

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed