Alors j'ai peut être trouvé le souci avec mod_evasive et fail2ban.
J'ai un des disques de mon RAID5 qui répondait très lentement (voir "retour unité de stockage ata1 "), du coup comme il y avait un temps de réponse un peu trop long il partait en erreur et donc fail2ban finissait par bannir les ip... Et comme les ip qui sont en liste blanche ne sont pas bannis, voilà la raison du pourquoi ce n'était pas le cas avec.
retour unité de stockage ata1 :
Jan 26 06:44:30 xxxxxxx kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40000 action 0x6 frozen
Jan 26 06:44:30 xxxxxxx kernel: ata1: SError: { CommWake }
Jan 26 06:44:30 xxxxxxx kernel: ata1.00: failed command: FLUSH CACHE EXT
Jan 26 06:44:30 xxxxxxx kernel: ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 13#012 res 40/00:46:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
Jan 26 06:44:30 xxxxxxx kernel: ata1.00: status: { DRDY }
Jan 26 06:44:30 xxxxxxx kernel: ata1: hard resetting link
Jan 26 06:44:35 xxxxxxx kernel: ata1: found unknown device (class 0)
Jan 26 06:44:40 xxxxxxx kernel: ata1: softreset failed (device not ready)
Jan 26 06:44:40 xxxxxxx kernel: ata1: hard resetting link
Jan 26 06:44:45 xxxxxxx kernel: ata1: found unknown device (class 0)
Jan 26 06:44:50 xxxxxxx kernel: ata1: softreset failed (device not ready)
Jan 26 06:44:50 xxxxxxx kernel: ata1: hard resetting link
Jan 26 06:44:55 xxxxxxx kernel: ata1: found unknown device (class 0)
Jan 26 06:45:00 xxxxxxx kernel: ata1: link is slow to respond, please be patient (ready=0)
Jan 26 06:45:25 xxxxxxx kernel: ata1: softreset failed (device not ready)
Jan 26 06:45:25 xxxxxxx kernel: ata1: limiting SATA link speed to 3.0 Gbps
Jan 26 06:45:25 xxxxxxx kernel: ata1: hard resetting link
Jan 26 06:45:25 xxxxxxx kernel: ata1: SATA link down (SStatus 0 SControl 320)
Jan 26 06:45:26 xxxxxxx kernel: ata1: hard resetting link
Jan 26 06:45:35 xxxxxxx kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Jan 26 06:45:35 xxxxxxx kernel: ata1.00: configured for UDMA/133
Jan 26 06:45:35 xxxxxxx kernel: ata1.00: retrying FLUSH 0xea Emask 0x4
Jan 26 06:45:35 xxxxxxx kernel: ata1: EH complete
Donc je suis bon pour des sauvegardes et soit :
- Un remplacement des câbles SATA
- Un remplacement de l'unité de stockage problématique. A voir laquelle (faudrait que je mette un marquage pour savoir le numéro à remplacer... pas simple dans mon petit boîtier ITX du coup :-P ).
Donc on peut dire que c'est résolu... En partie vu que mod_evasive est souvent très agressif...
Pour l'autre avec mod_security cela semble être lié aussi.
mod_security3 plante avec le fichier de configuration des règles du CRS sur la dernière partie :
#
# -- [[ End of setup ]] --------------------------------------------------------
#
# The CRS checks the tx.crs_setup_version variable to ensure that the setup
# has been loaded. If you are not planning to use this setup template,
# you must manually set the tx.crs_setup_version variable before including
# the CRS rules/* files.
#
# The variable is a numerical representation of the CRS version number.
# E.g., v3.0.0 is represented as 300.
#
SecAction \
"id:900990,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_setup_version=334"
Comme il est obligatoire d'avoir le mod_security par défaut, A voir si il ne faut pas simplement supprimer cette partie...