Je pense avoir compris ce qui se passe.
Sur mon serveur Stretch, j’ai à la fois des ligne « WARNING » et des lignes « NOTICE » dans les logs fail2ban. Avec les lignes « WARNING » le n° IP des bannissement est le 7ème champ. Par contre, dans les lignes « NOTICE », c’est le 8ème…

Si je pars du principe que tu test les lignes WARNING, je propose de les extraire du log avant de lancer le script :
# grep ‘ WARNING ‘ /var/log/fail2ban > [Fichier temporaire]
# ./ban-them.py -v -s [Fichier temporaire]

Cela permet également de jumeler la recherche des IP bannies dans les 2 derniers fichiers de log. On peut lancer ça dans le cron :
0 * * * * (cat /var/log/fail2ban{,.1} > /chemin/vers/le/script/fail2ban.log && /chemin/vers/le/script/ban-them -s /chemin/vers/le/script/fail2ban.log)

A+

Voici la forme des lignes générée par le script « sort-fail2ban-log.sh » avec les champs 6 et 8 :
./sort-fail2ban-log.sh /var/log/fail2ban.log
3 [sshd]
3 [recidive]
2 [ssh-iptables-ipset6]

Je pensais que c’était bon, ben non, voilà ce que ça donne :
# ./ban-them.py -v
iptables v1.6.0: host/network `Ban’ not found
Try `iptables -h’ or ‘iptables –help’ for more information.
Traceback (most recent call last):
File « ./ban-them.py », line 171, in
main(sys.argv[1:])
File « ./ban-them.py », line 163, in main
ipt_result = subprocess.check_output([« /sbin/iptables », « -A », « ban-them », « -s », row[1], « -j », « DROP »])
File « /usr/lib/python3.5/subprocess.py », line 316, in check_output
**kwargs).stdout
File « /usr/lib/python3.5/subprocess.py », line 398, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command ‘[‘/sbin/iptables’, ‘-A’, ‘ban-them’, ‘-s’, ‘Ban’, ‘-j’, ‘DROP’]’ returned non-zero exit status 2

Voici le genre de lignes contenue à l’exécution de ta commande :
./sort-fail2ban-log.sh /var/log/fail2ban.log
105 NOTICE Ban

Et voici un exemple de contenu du log :
…
2017-06-22 21:07:01,976 fail2ban.actions [790]: NOTICE [sshd] Ban
2017-06-22 21:07:01,988 fail2ban.filter [790]: INFO [recidive] Found
2017-06-22 21:07:09,227 fail2ban.actions [790]: NOTICE [sshd] Unban
…
2017-06-23 00:46:01,901 fail2ban.actions [790]: NOTICE [recidive] [NNN.NNN.NNN.NNN]
…
2017-06-23 00:46:35,732 fail2ban.actions [766]: NOTICE [recidive] Ban [NNN.NNN.NNN.NNN]
…

Visiblement il y a eu un décalage dans l’ordre du log. J’ai pris les champs 6 et 8 à la place des champs 5 et 7 et tout est rentré dans l’ordre.

Merci

Bonjour Piotr58,

Merci pour ton commentaire.

La ligne qui pose problème est celle qui ajoute les adresses IP à bannir à IPTables. Il semblerait dans ton cas qu’une donnée autre qu’une adresse IP a été transmise à la commande (« Ban » dans l’erreur que tu as fourni).

Peux-tu exécuter la commande suivante depuis le répertoire où tu as installé mon script : ./sort-fail2ban-log.sh /var/log/fail2ban.log

Le résultat devrait être une suite de lignes du genre « 15 [ssh] une_adresse_ip ». Si le résultat n’est pas celui-là, je pense que Debian a modifié les logs de Fail2ban dans Debian 9. Dans ce cas, peux-tu me transmettre un extrait des logs de /var/log/fail2ban.log ? Je verrai ensuite comment il faut adapter mon script.

C’est vraiment bien mais voici ce que j’ai avec Debian 9 stretch :
# ./ban-them.py -v
iptables v1.6.0: host/network `Ban’ not found
Try `iptables -h’ or ‘iptables –help’ for more information.
Traceback (most recent call last):
File « ./ban-them.py », line 170, in
main(sys.argv[1:])
File « ./ban-them.py », line 162, in main
ipt_result = subprocess.check_output([« /sbin/iptables », « -A », « ban-them », « -s », row[1], « -j », « DROP »])
File « /usr/lib/python3.5/subprocess.py », line 316, in check_output
**kwargs).stdout
File « /usr/lib/python3.5/subprocess.py », line 398, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command ‘[‘/sbin/iptables’, ‘-A’, ‘ban-them’, ‘-s’, ‘Ban’, ‘-j’, ‘DROP’]’ returned non-zero exit status 2

Avec Jessie, ça fonctionne bien semble t’il. Où est l’erreur ? Une idée ?

Merci Martial 🙂