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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
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 :
[root@kayak]:~ # 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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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
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 ?
Le vendredi 24 août 2007 15:15, Pascal Hambourg a écrit :
> Mais lorsque je vérifie 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
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?bug=407561)
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 :
[root@kayak]:~ # 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
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 ?
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 ?
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
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 :
[root@kayak]:~ # 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?bug@7561)
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 :
[root@kayak]:~ # 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/ubuntu-motu@lists.ubuntu.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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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 ?
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