Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec --reject-with icmp-port-unreachable
Si je comprends bien, tu aurais le même problème que moi si tu
attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout
bénef :-P
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Philippe Gras a écrit :
Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec --reject-with icmp-port-unreachable
Si je comprends bien, tu aurais le même problème que moi si tu
attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout
bénef :-P
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54CF9615.3030100@systella.fr
Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec --reject-with icmp-port-unreachable
Si je comprends bien, tu aurais le même problème que moi si tu
attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout
bénef :-P
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue…
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Si je comprends bien, tu aurais le même problème que moi si tu attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout bénef :-P
Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un REJECT,
ce n'est pas la même chose finalement ?
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue…
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Si je comprends bien, tu aurais le même problème que moi si tu attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout bénef :-P
Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un REJECT,
ce n'est pas la même chose finalement ?
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue…
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Si je comprends bien, tu aurais le même problème que moi si tu attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout bénef :-P
Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un REJECT,
ce n'est pas la même chose finalement ?
Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Si je comprends bien, tu aurais le même problème que moi si tu
attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus,
lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout
bénef :-P
Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un
REJECT,
ce n'est pas la même chose finalement ?
Non, ce n'est pas la même chose. DROP, le paquet de l'émetteur
tombe dans un trou noir et la connexion tombe par un timeout côté
émetteur. Avec un REJECT, j'informe explicitement l'émetteur que le
port est fermé en coupant la communication de mon côté. Si
l'émetteur n'est pas trop idiot, il passe à autre chose.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Si je comprends bien, tu aurais le même problème que moi si tu
attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus,
lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout
bénef :-P
Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un
REJECT,
ce n'est pas la même chose finalement ?
Non, ce n'est pas la même chose. DROP, le paquet de l'émetteur
tombe dans un trou noir et la connexion tombe par un timeout côté
émetteur. Avec un REJECT, j'informe explicitement l'émetteur que le
port est fermé en coupant la communication de mon côté. Si
l'émetteur n'est pas trop idiot, il passe à autre chose.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54CF9C1D.7040600@systella.fr
Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Si je comprends bien, tu aurais le même problème que moi si tu
attendais
que la connexion se fermât
Oui j'ai eu ce genre de problème par le passé. En plus,
lorsqu'on
parle au zombie, il passe à autre chose plus vite, c'est tout
bénef :-P
Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un
REJECT,
ce n'est pas la même chose finalement ?
Non, ce n'est pas la même chose. DROP, le paquet de l'émetteur
tombe dans un trou noir et la connexion tombe par un timeout côté
émetteur. Avec un REJECT, j'informe explicitement l'émetteur que le
port est fermé en coupant la communication de mon côté. Si
l'émetteur n'est pas trop idiot, il passe à autre chose.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue…
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie chez moi ?
(… et d'autres sur la liste éventuellement aussi, parce que ça a l'air
trop cool)
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue…
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie chez moi ?
(… et d'autres sur la liste éventuellement aussi, parce que ça a l'air
trop cool)
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue…
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien senti, je
n'attends pas que la connexion se ferme d'elle même en DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie chez moi ?
(… et d'autres sur la liste éventuellement aussi, parce que ça a l'air
trop cool)
Philippe Gras a écrit :
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits
(casser un
mot de passe en testant des milliers de combinaisons
possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien
senti, je
n'attends pas que la connexion se ferme d'elle même en
DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie
chez moi ?
( et d'autres sur la liste éventuellement aussi, parce que ça a
l'air
trop cool)
Si tu le dis... Elle n'a rien d'extraordinaire.
Dans jail.conf, j'ai un :
banaction = iptables46-multiport <- ipv4 _et_ ipv6
et dans action.d/iptables-common.conf un :
blocktype = REJECT --reject-with icmp-port-unreachable
Le reste ressemble assez à une configuration par défaut. Encore
une fois, je n'ai pas suivi les évolutions de la configuration par
défaut et je ne sais pas comment est configuré un fail2ban récent
out of the box.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Philippe Gras a écrit :
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Je rencontre un problème sur les tentatives d'exploits
(casser un
mot de passe en testant des milliers de combinaisons
possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien
senti, je
n'attends pas que la connexion se ferme d'elle même en
DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie
chez moi ?
( et d'autres sur la liste éventuellement aussi, parce que ça a
l'air
trop cool)
Si tu le dis... Elle n'a rien d'extraordinaire.
Dans jail.conf, j'ai un :
banaction = iptables46-multiport <- ipv4 _et_ ipv6
et dans action.d/iptables-common.conf un :
blocktype = REJECT --reject-with icmp-port-unreachable
Le reste ressemble assez à une configuration par défaut. Encore
une fois, je n'ai pas suivi les évolutions de la configuration par
défaut et je ne sais pas comment est configuré un fail2ban récent
out of the box.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54CFA91C.70404@systella.fr
Philippe Gras a écrit :
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits
(casser un
mot de passe en testant des milliers de combinaisons
possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien
senti, je
n'attends pas que la connexion se ferme d'elle même en
DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie
chez moi ?
( et d'autres sur la liste éventuellement aussi, parce que ça a
l'air
trop cool)
Si tu le dis... Elle n'a rien d'extraordinaire.
Dans jail.conf, j'ai un :
banaction = iptables46-multiport <- ipv4 _et_ ipv6
et dans action.d/iptables-common.conf un :
blocktype = REJECT --reject-with icmp-port-unreachable
Le reste ressemble assez à une configuration par défaut. Encore
une fois, je n'ai pas suivi les évolutions de la configuration par
défaut et je ne sais pas comment est configuré un fail2ban récent
out of the box.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Philippe Gras a écrit :
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits
(casser un
mot de passe en testant des milliers de combinaisons
possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien
senti, je
n'attends pas que la connexion se ferme d'elle même en
DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie
chez moi ?
( et d'autres sur la liste éventuellement aussi, parce que ça a
l'air
trop cool)
Si tu le dis... Elle n'a rien d'extraordinaire.
Dans jail.conf, j'ai un :
banaction = iptables46-multiport <- ipv4 _et_ ipv6
et dans action.d/iptables-common.conf un :
blocktype = REJECT --reject-with icmp-port-unreachable
Le reste ressemble assez à une configuration par défaut. Encore
une fois, je n'ai pas suivi les évolutions de la configuration par
défaut et je ne sais pas comment est configuré un fail2ban récent
out of the box.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Philippe Gras a écrit :
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :
Philippe Gras a écrit :
Je rencontre un problème sur les tentatives d'exploits
(casser un
mot de passe en testant des milliers de combinaisons
possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien
senti, je
n'attends pas que la connexion se ferme d'elle même en
DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie
chez moi ?
( et d'autres sur la liste éventuellement aussi, parce que ça a
l'air
trop cool)
Si tu le dis... Elle n'a rien d'extraordinaire.
Dans jail.conf, j'ai un :
banaction = iptables46-multiport <- ipv4 _et_ ipv6
et dans action.d/iptables-common.conf un :
blocktype = REJECT --reject-with icmp-port-unreachable
Le reste ressemble assez à une configuration par défaut. Encore
une fois, je n'ai pas suivi les évolutions de la configuration par
défaut et je ne sais pas comment est configuré un fail2ban récent
out of the box.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54CFA91C.70404@systella.fr
Philippe Gras a écrit :
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit :Philippe Gras a écrit :
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit :Philippe Gras a écrit :Je rencontre un problème sur les tentatives d'exploits
(casser un
mot de passe en testant des milliers de combinaisons
possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de
plus de
50 machines et la cible récidive fonctionne parfaitement. En
revanche,
je ferme autoritairement la connexion avec un ICMP bien
senti, je
n'attends pas que la connexion se ferme d'elle même en
DROPant le
paquet. Ça aide un peu...
Ah, OK ! Peux-tu expliquer comment tu "fermes autoritairement la
connexion avec un ICMP bien senti" ?
Au lieu de garder la configuration par défaut (d'il y a très
longtemps, je n'ai pas vérifié si cette configuration avait changé
récemment) qui installe un DROP, mes règles installent un REJET
avec
--reject-with icmp-port-unreachable
Tu veux parler de la configuration de fail2ban, c'est ça ?
Oui.
Ça t'ennuierait de communiquer ta conf. perso, que je la recopie
chez moi ?
( et d'autres sur la liste éventuellement aussi, parce que ça a
l'air
trop cool)
Si tu le dis... Elle n'a rien d'extraordinaire.
Dans jail.conf, j'ai un :
banaction = iptables46-multiport <- ipv4 _et_ ipv6
et dans action.d/iptables-common.conf un :
blocktype = REJECT --reject-with icmp-port-unreachable
Le reste ressemble assez à une configuration par défaut. Encore
une fois, je n'ai pas suivi les évolutions de la configuration par
défaut et je ne sais pas comment est configuré un fail2ban récent
out of the box.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-blocktype.conf
as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-blocktype.conf
as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-blocktype.conf
Philippe Gras a écrit :as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/
iptables-blocktype.conf
Non. Mon fail2ban est un fail2ban d'origine contrôlée patché pour
qu'il surveille aussi IPv6. Je n'ai pas cherché à le modifier.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Philippe Gras a écrit :
as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/
iptables-blocktype.conf
Non. Mon fail2ban est un fail2ban d'origine contrôlée patché pour
qu'il surveille aussi IPv6. Je n'ai pas cherché à le modifier.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54D07AD5.6080108@systella.fr
Philippe Gras a écrit :as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/
iptables-blocktype.conf
Non. Mon fail2ban est un fail2ban d'origine contrôlée patché pour
qu'il surveille aussi IPv6. Je n'ai pas cherché à le modifier.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 3 févr. 15 à 08:37, BERTRAND Joël a écrit :Philippe Gras a écrit :as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-blocktype.conf
Non. Mon fail2ban est un fail2ban d'origine contrôlée patché pour
qu'il surveille aussi IPv6. Je n'ai pas cherché à le modifier.
JKB
Il existe un système analogue dans la version que j'ai téléchargée à
Noël, mais qui fait un
DROP au lieu du REJECT.
C'est sur ce fichier :
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-xt_recent-echo.conf
On voit bien le <blocktype> sur ce fichier du dépôt Github.
Dans l'un et l'autre cas, il suffit de mettre banaction =
iptables-xt_recent-echo dans jail.local,
sur tel ou tel filtre.
Comme ce REJECT m'a bien plu, j'ai copié iptables-blocktype.conf et
j'ai créé un clone avec
iptables-xt_recent-echo.local, qui reprend le blocktype.
J'ai rechargé fail2ban et ça a l'air de bien se passer. Mais je ne
peux pas encore le confirmer,
n'ayant pas subi d'exploit hier.
J'ai vu aussi qu'il existait un système pour formuler une réclamation
au registrar :
https://github.com/sergejmueller/fail2ban/blob/master/action.d/complain.conf
Le fichier existe aussi dans ma version de fail2ban. Si quelqu'un
connaît la procédure pour le
faire fonctionner…
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 3 févr. 15 à 08:37, BERTRAND Joël a écrit :
Philippe Gras a écrit :
as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-blocktype.conf
Non. Mon fail2ban est un fail2ban d'origine contrôlée patché pour
qu'il surveille aussi IPv6. Je n'ai pas cherché à le modifier.
JKB
Il existe un système analogue dans la version que j'ai téléchargée à
Noël, mais qui fait un
DROP au lieu du REJECT.
C'est sur ce fichier :
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-xt_recent-echo.conf
On voit bien le <blocktype> sur ce fichier du dépôt Github.
Dans l'un et l'autre cas, il suffit de mettre banaction =
iptables-xt_recent-echo dans jail.local,
sur tel ou tel filtre.
Comme ce REJECT m'a bien plu, j'ai copié iptables-blocktype.conf et
j'ai créé un clone avec
iptables-xt_recent-echo.local, qui reprend le blocktype.
J'ai rechargé fail2ban et ça a l'air de bien se passer. Mais je ne
peux pas encore le confirmer,
n'ayant pas subi d'exploit hier.
J'ai vu aussi qu'il existait un système pour formuler une réclamation
au registrar :
https://github.com/sergejmueller/fail2ban/blob/master/action.d/complain.conf
Le fichier existe aussi dans ma version de fail2ban. Si quelqu'un
connaît la procédure pour le
faire fonctionner…
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54D07AD5.6080108@systella.fr
Le 3 févr. 15 à 08:37, BERTRAND Joël a écrit :Philippe Gras a écrit :as-tu aussi un fichier iptables-blocktype.conf dans action.d ?
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-blocktype.conf
Non. Mon fail2ban est un fail2ban d'origine contrôlée patché pour
qu'il surveille aussi IPv6. Je n'ai pas cherché à le modifier.
JKB
Il existe un système analogue dans la version que j'ai téléchargée à
Noël, mais qui fait un
DROP au lieu du REJECT.
C'est sur ce fichier :
https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-xt_recent-echo.conf
On voit bien le <blocktype> sur ce fichier du dépôt Github.
Dans l'un et l'autre cas, il suffit de mettre banaction =
iptables-xt_recent-echo dans jail.local,
sur tel ou tel filtre.
Comme ce REJECT m'a bien plu, j'ai copié iptables-blocktype.conf et
j'ai créé un clone avec
iptables-xt_recent-echo.local, qui reprend le blocktype.
J'ai rechargé fail2ban et ça a l'air de bien se passer. Mais je ne
peux pas encore le confirmer,
n'ayant pas subi d'exploit hier.
J'ai vu aussi qu'il existait un système pour formuler une réclamation
au registrar :
https://github.com/sergejmueller/fail2ban/blob/master/action.d/complain.conf
Le fichier existe aussi dans ma version de fail2ban. Si quelqu'un
connaît la procédure pour le
faire fonctionner…
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Philippe Gras a écrit :Pardon de remonter ce sujet.
As-tu réussi à stopper ces attaques avec fail2ban, finalement ?
Oui, ça s'est calmé, mais il y a eu une quinzaine de jours assez
folkloriques.Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus
de 50 machines et la cible récidive fonctionne parfaitement. En
revanche, je ferme autoritairement la connexion avec un ICMP bien
senti, je n'attends pas que la connexion se ferme d'elle même en
DROPant le paquet. Ça aide un peu...
Cordialement,
JKB
Philippe Gras a écrit :
Pardon de remonter ce sujet.
As-tu réussi à stopper ces attaques avec fail2ban, finalement ?
Oui, ça s'est calmé, mais il y a eu une quinzaine de jours assez
folkloriques.
Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus
de 50 machines et la cible récidive fonctionne parfaitement. En
revanche, je ferme autoritairement la connexion avec un ICMP bien
senti, je n'attends pas que la connexion se ferme d'elle même en
DROPant le paquet. Ça aide un peu...
Cordialement,
JKB
Philippe Gras a écrit :Pardon de remonter ce sujet.
As-tu réussi à stopper ces attaques avec fail2ban, finalement ?
Oui, ça s'est calmé, mais il y a eu une quinzaine de jours assez
folkloriques.Je rencontre un problème sur les tentatives d'exploits (casser un
mot de passe en testant des milliers de combinaisons possibles).
Chez moi, fail2ban bannit bien les IP, mais l'attaque continue
Chez moi aussi, ça fait ça, mais comme les attaquants sont
décorrélés, pas de problème. J'ai eu des queues de bannis de plus
de 50 machines et la cible récidive fonctionne parfaitement. En
revanche, je ferme autoritairement la connexion avec un ICMP bien
senti, je n'attends pas que la connexion se ferme d'elle même en
DROPant le paquet. Ça aide un peu...
Cordialement,
JKB