Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

fail2ban : soucis dans le script de base

3 réponses
Avatar
Michel Grentzinger
Bonjour,

Je rencontre un probl=C3=A8me avec fail2ban.
Lors de tentatives d'acc=C3=A8s ill=C3=A9gales en ssh, les logs de fail2ban=
m'indique=20
qu'il bannit bien l'adresse concern=C3=A9e :
2007-08-24 14:51:41,163 fail2ban.actions.action: DEBUG iptables -L INPUT |=
=20
grep -q fail2ban-ssh returned successfully
2007-08-24 14:51:41,164 fail2ban.actions.action: DEBUG iptables -I=20
fail2ban-ssh 1 -s 217.22.55.50 -j DROP
2007-08-24 14:51:41,172 fail2ban.actions.action: DEBUG iptables -I=20
fail2ban-ssh 1 -s 217.22.55.50 -j DROP returned successfully

Mais lorsque je v=C3=A9rifie avec iptables -L -n, j'ai ceci :
[root@kayak]:~ # iptables -L INPUT -n | grep fail2ban
fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

Or cette r=C3=A8gle est initialis=C3=A9e au d=C3=A9marrage de fail2ban (via=
init.d/fail2ban).=20
Je suppose qu'il faut en fait modifier la r=C3=A8gle existante plut=C3=B4t =
que de tenter=20
d'en ajouter une nouvelle ?

Quelqu'un a-t-il eu le m=C3=AAme soucis ?=20

=2D-=20
Michel Grentzinger
OpenPGP key ID : B2BAFAFA
Available on http://www.keyserver.net

3 réponses

Avatar
Pascal Hambourg
Salut,

Michel Grentzinger a écrit :

Je rencontre un problème avec fail2ban.
Lors de tentatives d'accès illégales en ssh, les logs de fail2ban m'indique
qu'il bannit bien l'adresse concernée :
2007-08-24 14:51:41,163 fail2ban.actions.action: DEBUG iptables -L INPUT |
grep -q fail2ban-ssh returned successfully
2007-08-24 14:51:41,164 fail2ban.actions.action: DEBUG iptables -I
fail2ban-ssh 1 -s 217.22.55.50 -j DROP
2007-08-24 14:51:41,172 fail2ban.actions.action: DEBUG iptables -I
fail2ban-ssh 1 -s 217.22.55.50 -j DROP returned successfully

Mais lorsque je vérifie avec iptables -L -n, j'ai ceci :
[]:~ # iptables -L INPUT -n | grep fail2ban
fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22



AMA il faudrait plutôt vérifier dans la chaîne utilisateur fail2ban-ssh,
parce que d'après ce que je lis plus haut c'est là que les règles sont
ajoutées par fail2ban.

# iptables -nL fail2ban-ssh


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Michel Grentzinger
Le vendredi 24 août 2007 15:15, Pascal Hambourg a écrit :
> Mais lorsque je vérifie avec iptables -L -n, j'ai ceci :
> []:~ # iptables -L INPUT -n | grep fail2ban
> fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 tcp
> dpt:22

AMA il faudrait plutôt vérifier dans la chaîne utilisateur fail2ban -ssh,
parce que d'après ce que je lis plus haut c'est là que les règles s ont
ajoutées par fail2ban.

# iptables -nL fail2ban-ssh



Oui, c'était une partie du problème ! Mais le "bannissage" ne fonctionn ait pas
non plus !
En fait, c'est lié au bogue n°407561 (
http://bugs.debian.org/cgi-bin/bugreport.cgi?)
une vérification était faite avec la résolution inverse ce qui prenna it
beaucoup de temps car j'ai un script iptables un peu long.

Pour ceux que ça interresse, il faut modifier :
[]:~ # diff -u /etc/fail2ban/action.d/iptables.conf*
--- /etc/fail2ban/action.d/iptables.conf 2007-08-24 15:06:27.00000 0000
+0200
+++ /etc/fail2ban/action.d/iptables.conf-FIRST 2007-08-24 15:05:23.0000000 00
+0200
@@ -27,7 +27,7 @@
# Notes.: command executed once before each fwban command
# Values: CMD
#
-actioncheck = iptables -L INPUT -n | grep -q fail2ban-<name>
+actioncheck = iptables -L INPUT | grep -q fail2ban-<name>

Et après tout fonctionne !

Ce bogue ne mériterait-il pas une mise à jour dans stable à la procha ine
révision ?

--
Michel Grentzinger
OpenPGP key ID : B2BAFAFA
Available on http://www.keyserver.net
Avatar
mouss
Michel Grentzinger wrote:
Le vendredi 24 août 2007 15:15, Pascal Hambourg a écrit :
Mais lorsque je vérifie avec iptables -L -n, j'ai ceci :
[]:~ # iptables -L INPUT -n | grep fail2ban
fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 tcp
dpt:22


AMA il faudrait plutôt vérifier dans la chaîne utilisateur fail2ban-ssh,
parce que d'après ce que je lis plus haut c'est là que les règles sont
ajoutées par fail2ban.

# iptables -nL fail2ban-ssh



Oui, c'était une partie du problème ! Mais le "bannissage" ne fonctionnait pas
non plus !
En fait, c'est lié au bogue n°407561 (
http://bugs.debian.org/cgi-bin/bugreport.cgi?)
une vérification était faite avec la résolution inverse ce qui prennait
beaucoup de temps car j'ai un script iptables un peu long.

Pour ceux que ça interresse, il faut modifier :
[]:~ # diff -u /etc/fail2ban/action.d/iptables.conf*
--- /etc/fail2ban/action.d/iptables.conf 2007-08-24 15:06:27.000000000
+0200
+++ /etc/fail2ban/action.d/iptables.conf-FIRST 2007-08-24 15:05:23.000000000
+0200
@@ -27,7 +27,7 @@
# Notes.: command executed once before each fwban command
# Values: CMD
#
-actioncheck = iptables -L INPUT -n | grep -q fail2ban-<name>
+actioncheck = iptables -L INPUT | grep -q fail2ban-<name>

Et après tout fonctionne !

Ce bogue ne mériterait-il pas une mise à jour dans stable à la prochaine
révision ?





euh. pourquoi faire des requetes dns?

Au fait. il faut etre sur de lancer une version recente de fail2ban. Il
avait un enorme bug:
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6302
http://www.mail-archive.com//msg01806.html

pour vérifier, il suffit de tenter un login en tant que
"taratata from 1.2.3.4"
et voir si 1.2.3.4 ne se retrouve pas bloqué.

ça donne pas beaucoup confiance tout ça...




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact