Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 8 septembre 2023 Romain a écrit :

> Non l'IP en 10.200.2.73 ne me dit rien, chez moi c'est du 192.168, ce qu'il
> se passe entre mon range chez moi et l'IP OVH, je maîtrise rien, c'est OVH
> et/ou les différents liens qu'il possède.

Oui les IP 10.x.x.x et 192.168.x.x sont des IP privées qui ne sont pas
routées sur internet. Donc 10.200.2.73 est interne à OVH. Ca doit être
lui qui bug.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Non l'IP en 10.200.2.73 ne me dit rien, chez moi c'est du 192.168, ce qu'il
se passe entre mon range chez moi et l'IP OVH, je maîtrise rien, c'est OVH
et/ou les différents liens qu'il possède.
Merci pour le lien, je vais lire cela.

Le ven. 8 sept. 2023 à 09:14, NoSpam  a écrit :

>
> Le 08/09/2023 à 09:11, NoSpam a écrit :
>
> Bonjour
>
> J'ai trouvé cela
>
>
> https://community.ovh.com/t/proxmox-ip-failover-probleme-reseau-vers-orange/36874/13
>
> La 10.200.2.73 est une IP OVH
>
> Le 07/09/2023 à 23:38, Romain a écrit :
>
> Je confirme que quand ça tombe, c'est le serveur OVH qui ne parvient pas à
> envoyer la réponse à mon réseau.
>
> 35 9.862648672 IP_PUBLIQUE_MAISON → 54.38.38.159 ICMP 78 Echo (ping)
> request  id=0x4b30, seq=33150/32385, ttl=1
> 36 9.862704895 54.38.38.159 → IP_PUBLIQUE_MAISON ICMP 106 Destination
> unreachable (Port unreachable)
>
> MTR du serveur OVH vers chez moi :
> Start: 2023-09-07T23:30:08+0200
> HOST: rbx Loss%   Snt   Last   Avg  Best  Wrst
> StDev
>   1.|-- 54.38.38.252   0.0%100.6   0.5   0.3   0.7
> 0.1
>   2.|-- 10.162.250.98  0.0%100.9   0.5   0.4   0.9
> 0.1
>   3.|-- 10.72.52.320.0%100.5   0.5   0.4   0.7
> 0.1
>   4.|-- 10.73.17.420.0%100.2   0.2   0.1   0.3
> 0.0
>   5.|-- 10.95.64.152   0.0%101.1   1.2   1.1   1.5
> 0.1
>   6.|-- 54.36.50.226   0.0%104.4   4.4   4.2   4.7
> 0.2
>   7.|-- 10.200.2.730.0%10   78.0  11.6   4.1  78.0
>  23.4
>   8.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>
> Dubitatif: réseau interne OVH - Sortie OVH public - retour réseau interne
> de ???
>
> La 10.200.2.73 te dit quelque chose ?
>
>
> Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :
>
>> Le 7 septembre 2023 Thomas Trupel a écrit :
>>
>> > Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
>> > lancé sur rpi4 à la survenance du problème permettrait de détecter un
>> > éventuel problème de routage sur rpi4.
>>
>> Moi je pensais au bon vieux "route -n" mais on se refait pas :)
>> Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
>> bien aussi pour voir les devices connus dans le voisinage et qui devrait
>> être cohérent avec le routage.
>>
>>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Le 08/09/2023 à 09:11, NoSpam a écrit :


Bonjour


J'ai trouvé cela

https://community.ovh.com/t/proxmox-ip-failover-probleme-reseau-vers-orange/36874/13

La 10.200.2.73 est une IP OVH


Le 07/09/2023 à 23:38, Romain a écrit :
Je confirme que quand ça tombe, c'est le serveur OVH qui ne parvient 
pas à envoyer la réponse à mon réseau.


35 9.862648672 IP_PUBLIQUE_MAISON → 54.38.38.159 ICMP 78 Echo (ping) 
request  id=0x4b30, seq=33150/32385, ttl=1
36 9.862704895 54.38.38.159 → IP_PUBLIQUE_MAISON ICMP 106 Destination 
unreachable (Port unreachable)


MTR du serveur OVH vers chez moi :
Start: 2023-09-07T23:30:08+0200
HOST: rbx                         Loss%   Snt   Last   Avg  Best 
 Wrst StDev
  1.|-- 54.38.38.252               0.0%    10    0.6   0.5 0.3   0.7 
  0.1
  2.|-- 10.162.250.98              0.0%    10    0.9   0.5 0.4   0.9 
  0.1
  3.|-- 10.72.52.32                0.0%    10    0.5   0.5 0.4   0.7 
  0.1
  4.|-- 10.73.17.42                0.0%    10    0.2   0.2 0.1   0.3 
  0.0
  5.|-- 10.95.64.152               0.0%    10    1.1   1.2 1.1   1.5 
  0.1
  6.|-- 54.36.50.226               0.0%    10    4.4   4.4 4.2   4.7 
  0.2
  7.|-- 10.200.2.73                0.0%    10   78.0  11.6 4.1  78.0 
 23.4
  8.|-- ???                       100.0    10    0.0   0.0   0.0   
0.0   0.0


Dubitatif: réseau interne OVH - Sortie OVH public - retour réseau 
interne de ???


La 10.200.2.73 te dit quelque chose ?



Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :

Le 7 septembre 2023 Thomas Trupel a écrit :

> Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> lancé sur rpi4 à la survenance du problème permettrait de
détecter un
> éventuel problème de routage sur rpi4.

Moi je pensais au bon vieux "route -n" mais on se refait pas :)
Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut
être
bien aussi pour voir les devices connus dans le voisinage et qui
devrait
être cohérent avec le routage.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Bonjour

Le 07/09/2023 à 23:38, Romain a écrit :
Je confirme que quand ça tombe, c'est le serveur OVH qui ne parvient 
pas à envoyer la réponse à mon réseau.


35 9.862648672 IP_PUBLIQUE_MAISON → 54.38.38.159 ICMP 78 Echo (ping) 
request  id=0x4b30, seq=33150/32385, ttl=1
36 9.862704895 54.38.38.159 → IP_PUBLIQUE_MAISON ICMP 106 Destination 
unreachable (Port unreachable)


MTR du serveur OVH vers chez moi :
Start: 2023-09-07T23:30:08+0200
HOST: rbx                         Loss%   Snt   Last   Avg  Best  Wrst 
StDev

  1.|-- 54.38.38.252               0.0%    10    0.6   0.5 0.3   0.7   0.1
  2.|-- 10.162.250.98              0.0%    10    0.9   0.5 0.4   0.9   0.1
  3.|-- 10.72.52.32                0.0%    10    0.5   0.5 0.4   0.7   0.1
  4.|-- 10.73.17.42                0.0%    10    0.2   0.2 0.1   0.3   0.0
  5.|-- 10.95.64.152               0.0%    10    1.1   1.2 1.1   1.5   0.1
  6.|-- 54.36.50.226               0.0%    10    4.4   4.4 4.2   4.7   0.2
  7.|-- 10.200.2.73                0.0%    10   78.0  11.6 4.1  78.0  23.4
  8.|-- ???                       100.0    10    0.0   0.0 0.0   0.0   0.0


Dubitatif: réseau interne OVH - Sortie OVH public - retour réseau 
interne de ???


La 10.200.2.73 te dit quelque chose ?



Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :

Le 7 septembre 2023 Thomas Trupel a écrit :

> Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> lancé sur rpi4 à la survenance du problème permettrait de
détecter un
> éventuel problème de routage sur rpi4.

Moi je pensais au bon vieux "route -n" mais on se refait pas :)
Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
bien aussi pour voir les devices connus dans le voisinage et qui
devrait
être cohérent avec le routage.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Je confirme que quand ça tombe, c'est le serveur OVH qui ne parvient pas à
envoyer la réponse à mon réseau.

35 9.862648672 IP_PUBLIQUE_MAISON → 54.38.38.159 ICMP 78 Echo (ping)
request  id=0x4b30, seq=33150/32385, ttl=1
36 9.862704895 54.38.38.159 → IP_PUBLIQUE_MAISON ICMP 106 Destination
unreachable (Port unreachable)

MTR du serveur OVH vers chez moi :
Start: 2023-09-07T23:30:08+0200
HOST: rbx Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 54.38.38.252   0.0%100.6   0.5   0.3   0.7   0.1
  2.|-- 10.162.250.98  0.0%100.9   0.5   0.4   0.9   0.1
  3.|-- 10.72.52.320.0%100.5   0.5   0.4   0.7   0.1
  4.|-- 10.73.17.420.0%100.2   0.2   0.1   0.3   0.0
  5.|-- 10.95.64.152   0.0%101.1   1.2   1.1   1.5   0.1
  6.|-- 54.36.50.226   0.0%104.4   4.4   4.2   4.7   0.2
  7.|-- 10.200.2.730.0%10   78.0  11.6   4.1  78.0  23.4
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0

Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :

> Le 7 septembre 2023 Thomas Trupel a écrit :
>
> > Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> > lancé sur rpi4 à la survenance du problème permettrait de détecter un
> > éventuel problème de routage sur rpi4.
>
> Moi je pensais au bon vieux "route -n" mais on se refait pas :)
> Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
> bien aussi pour voir les devices connus dans le voisinage et qui devrait
> être cohérent avec le routage.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Thomas Trupel]

Bonjour Romain,

Pour compléter la réponse de Michel, un "ip route get 54.38.38.159" lancé sur 
rpi4 à la survenance du problème permettrait de détecter un éventuel problème 
de routage sur rpi4.

Cordialement,
Thomas

7 sept. 2023 12:55:53 Romain :

> Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le 
> serveur chez OVH.
> Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en 
> même temps, peut-être une correction de leur côté.
> A suivre.
> 
> Le jeu. 7 sept. 2023 à 12:37, Michel Verdier  a écrit :
>> Le 7 septembre 2023 Romain a écrit :
>> 
>>> Je n'en ai aucune idée, mais :
>>> - le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
>>> reproduire sur une IP Scaleway
>>> - depuis une VM hébergée sur un petit NUC branché au même switch que le
>>> RPI4, je ne reproduis pas le problème avec MTR
>>>
>>> J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne et
>>> déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
>>> complet.
>> 
>> Je vais essayer de clarifier. Tu es sur l'ip 192.168.0.2 (rpi4.home). Tu
>> fais un mtr vers l'ip 54.38.38.159. Celui qui marche aboutit bien sur
>> l'ip 54.38.38.159 (mail.borezo.info[http://mail.borezo.info]). Celui qui 
>> bloque aboutit sur l'ip
>> 192.168.0.2 (rpi4.home). Là le problème est sans doute un problème de
>> routage chez toi. Ce que confirmerait ton test avec le nuc.
>> Les erreurs rx checksum étaient bien sur ton serveur ou sur rpi4 ?
>> Regarde tes tables de routage sur rpi4 avant et pendant le problème pour
>> voir. Mais ça fait comme si rpi4 mettait la route vers 54.38.38.159 vers
>> lui-même au lieu de l'avoir vers ta box.
>> 

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Thomas Trupel a écrit :

> Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> lancé sur rpi4 à la survenance du problème permettrait de détecter un
> éventuel problème de routage sur rpi4.

Moi je pensais au bon vieux "route -n" mais on se refait pas :)
Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
bien aussi pour voir les devices connus dans le voisinage et qui devrait
être cohérent avec le routage.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Oui j'ai du full stack des deux côtés.

Le jeu. 7 sept. 2023 à 13:57, zithro  a écrit :

> On 07 Sep 2023 12:55, Romain wrote:
> > Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur
> le
> > serveur chez OVH.
> > Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
> > même temps, peut-être une correction de leur côté.
> > A suivre.
> >
>
> Rah ce top posting ...
>
> Pour info, si OVH utilise des IP privées sur son réseau interne, c'est
> normal qu'elles apparaissent dans les mtr.
> Comme ton DNS local (ou avahi, etc) connait cette adresse, il te
> l'affiche comme étant une machine locale.
>
> Les routeurs internes de certains FAIs et hébergeurs ont parfois des IPs
> RFC1918, voire APIPA (pour CG-NAT), afin d'économiser les IPv4 publiques.
>
> T'as une IPv4 full stack des deux côtés (chez toi et chez eux) ?
> D'après mes souvenirs ça peut poser des problèmes si ce n'est pas le cas.
>
> Autre piste, tu peux essayer des traceroutes avec les 3 protocoles :
> ICMP, UDP, TCP. Il y a parfois des différences.
>
>
> --
> ++
> zithro / Cyril
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[zithro]

On 07 Sep 2023 12:55, Romain wrote:

Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le
serveur chez OVH.
Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
même temps, peut-être une correction de leur côté.
A suivre.



Rah ce top posting ...

Pour info, si OVH utilise des IP privées sur son réseau interne, c'est 
normal qu'elles apparaissent dans les mtr.
Comme ton DNS local (ou avahi, etc) connait cette adresse, il te 
l'affiche comme étant une machine locale.


Les routeurs internes de certains FAIs et hébergeurs ont parfois des IPs 
RFC1918, voire APIPA (pour CG-NAT), afin d'économiser les IPv4 publiques.


T'as une IPv4 full stack des deux côtés (chez toi et chez eux) ?
D'après mes souvenirs ça peut poser des problèmes si ce n'est pas le cas.

Autre piste, tu peux essayer des traceroutes avec les 3 protocoles : 
ICMP, UDP, TCP. Il y a parfois des différences.



--
++
zithro / Cyril

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
> même temps, peut-être une correction de leur côté.

J'en doute quand même. Pour faire suite aux échanges sur debian-user, il
se peut que ce soit ta box et pas rpi4 qui soit en cause. Mais ton test
avec le nuc semble indiquer que c'est plutôt rpi4. L'idéal serait que tu
laisses le mtr périodique sur rpi4 mais aussi sur le nuc. Si les 2
tombent c'est ta box qui serait en cause. Si le nuc fonctionne c'est rpi4
en cause.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le
serveur chez OVH.
Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
même temps, peut-être une correction de leur côté.
A suivre.

Le jeu. 7 sept. 2023 à 12:37, Michel Verdier  a écrit :

> Le 7 septembre 2023 Romain a écrit :
>
> > Je n'en ai aucune idée, mais :
> > - le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
> > reproduire sur une IP Scaleway
> > - depuis une VM hébergée sur un petit NUC branché au même switch que le
> > RPI4, je ne reproduis pas le problème avec MTR
> >
> > J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne
> et
> > déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
> > complet.
>
> Je vais essayer de clarifier. Tu es sur l'ip 192.168.0.2 (rpi4.home). Tu
> fais un mtr vers l'ip 54.38.38.159. Celui qui marche aboutit bien sur
> l'ip 54.38.38.159 (mail.borezo.info). Celui qui bloque aboutit sur l'ip
> 192.168.0.2 (rpi4.home). Là le problème est sans doute un problème de
> routage chez toi. Ce que confirmerait ton test avec le nuc.
> Les erreurs rx checksum étaient bien sur ton serveur ou sur rpi4 ?
> Regarde tes tables de routage sur rpi4 avant et pendant le problème pour
> voir. Mais ça fait comme si rpi4 mettait la route vers 54.38.38.159 vers
> lui-même au lieu de l'avoir vers ta box.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> Je n'en ai aucune idée, mais :
> - le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
> reproduire sur une IP Scaleway
> - depuis une VM hébergée sur un petit NUC branché au même switch que le
> RPI4, je ne reproduis pas le problème avec MTR
>
> J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne et
> déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
> complet.

Je vais essayer de clarifier. Tu es sur l'ip 192.168.0.2 (rpi4.home). Tu
fais un mtr vers l'ip 54.38.38.159. Celui qui marche aboutit bien sur
l'ip 54.38.38.159 (mail.borezo.info). Celui qui bloque aboutit sur l'ip
192.168.0.2 (rpi4.home). Là le problème est sans doute un problème de
routage chez toi. Ce que confirmerait ton test avec le nuc.
Les erreurs rx checksum étaient bien sur ton serveur ou sur rpi4 ?
Regarde tes tables de routage sur rpi4 avant et pendant le problème pour
voir. Mais ça fait comme si rpi4 mettait la route vers 54.38.38.159 vers
lui-même au lieu de l'avoir vers ta box.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Je n'en ai aucune idée, mais :
- le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
reproduire sur une IP Scaleway
- depuis une VM hébergée sur un petit NUC branché au même switch que le
RPI4, je ne reproduis pas le problème avec MTR

J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne et
déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
complet.

Le jeu. 7 sept. 2023 à 11:53, Michel Verdier  a écrit :

> Le 7 septembre 2023 Romain a écrit :
>
> > └─# mtr -r 54.38.38.159 -4
> >  15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9
>  0.4
> >  12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.
>  0.0
>
> Je n'avais pas fait attention mais ton resolv change de mail.borezo.info
> en rpi4.home. Qu'est-ce qui change sur ton client pour provoquer ça ?
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Le 07/09/2023 à 11:47, Michel Verdier a écrit :

Le 7 septembre 2023 Romain a écrit :


Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?

L'option -n évite le dns mais ça n'apporte rien de plus.
Bein si, on aurait vu de suite une IP privée de rpi4.home, pas besoin de 
poser la question ...

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> └─# mtr -r 54.38.38.159 -4
>  15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9   0.4
>  12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.   0.0

Je n'avais pas fait attention mais ton resolv change de mail.borezo.info
en rpi4.home. Qu'est-ce qui change sur ton client pour provoquer ça ?

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
> compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
> mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?

L'option -n évite le dns mais ça n'apporte rien de plus.
Entre les 2 mtr on voit que le nombre de hop entre be103.rbx-g4-nc5.fr.eu
et ton serveur change. Peut-être pas du filtrage ddos mais un changement
de routage chez eux. Et ça en général ça indique un problème, donc chez
eux. Le mieux c'est de leur soumettre tes mtr. Avec les heures où ça
plante ils vont pouvoir faire le lien avec leurs logs.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

0
>>>  12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.
>>> 0.0
>>>
>>> Le mer. 6 sept. 2023 à 08:39, Romain  a écrit :
>>>
>>>> Bonjour la liste,
>>>>
>>>> J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça
>>>> puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
>>>>
>>>> Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi.
>>>> L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur)
>>>> fonctionne.
>>>>
>>>> Exemple cette nuit après un reboot du serveur la veille au soir :
>>>> 01h43-02h13 (30 minutes)
>>>> 02h26-03h26 (1 heure)
>>>> 03h28-05h28 (2 heures)
>>>> 05h55-? (pas encore débloqué)
>>>>
>>>> Problèmes :
>>>> - sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a
>>>> pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
>>>> - je n'en ai pas ajouté depuis l'installation du serveur, uniquement
>>>> apache (avec mod_security), PHP et MariaDB
>>>> - depuis l'IP de chez moi, cette nuit, les seules requêtes générées
>>>> étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les
>>>> minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais
>>>> retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien
>>>> entendu)
>>>>
>>>> Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping
>>>> retourne un "Destination Port Unreachable".
>>>>
>>>> Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR
>>>> (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier
>>>> par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en
>>>> rescue permet de récupérer le ping.
>>>>
>>>> Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12
>>>> quasiment vierge ? Je me tire les cheveux depuis quelques jours...
>>>>
>>>> Merci !
>>>>
>>>> Romain
>>>>
>>>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

└─# mtr -nr 54.38.38.159 -4
Start: 2023-09-07T08:17:12+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.10.0%101.1   0.9   0.5   1.3   0.3
  2.|-- 80.10.239.90.0%103.2   3.3   2.3   5.3   0.9
  3.|-- 193.253.80.138 0.0%104.5   4.0   2.2   6.0   1.2
  4.|-- 193.252.98.94  0.0%103.4   4.3   3.1  12.2   2.8
  5.|-- 193.252.98.101 0.0%103.5   3.4   2.9   3.6   0.2
  6.|-- 91.121.131.193 0.0%104.0  12.4   3.7  82.6  24.7
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- 192.168.0.2   90.0%10  3461. 3461. 3461. 3461.   0.0

Le jeu. 7 sept. 2023 à 10:17, Romain  a écrit :

> Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
> compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
> mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?
>
> Le jeu. 7 sept. 2023 à 09:54, NoSpam  a écrit :
>
>> rpi4.home c'est chez toi ? Avec le -n on aurait eu les IP ...
>> Le 07/09/2023 à 09:30, Romain a écrit :
>>
>> Ça s'est reproduit cette nuit, mais je n'ai pas pu investiguer avant mon
>> réveil, et pour l'instant ça ne bloque plus.
>>
>> Par curiosité je fais un MTR régulier, et j'ai eu un truc étrange.
>>
>> Un normal (rpi4 à la maison vers OVH) :
>> └─# mtr -r 54.38.38.159 -4
>> Start: 2023-09-07T07:14:15+
>> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
>> StDev
>>   1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1
>> 0.1
>>   2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5
>> 0.3
>>   3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3
>> 1.1
>>   4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6
>> 0.2
>>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.5   3.7   3.2   5.4
>> 0.6
>>   6.|-- be102.par-th2-pb1-nc5.fr.  0.0%10   25.9   9.6   3.7  31.7
>>  10.5
>>   7.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>   8.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>   9.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9
>> 4.2
>>  11.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  12.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  13.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  14.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9
>> 0.4
>>
>> Le même quelques minutes après (pas normal) :
>> └─# mtr -r 54.38.38.159 -4
>> Start: 2023-09-07T07:24:27+
>> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
>> StDev
>>   1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8
>> 0.6
>>   2.|-- 80.10.239.90.0%102.8   3.0   2.7   4.4
>> 0.5
>>   3.|-- ae102-0.ncidf103.rbci.ora  0.0%10   37.3   6.8   2.7  37.3
>>  10.7
>>   4.|-- ae51-0.nridf101.rbci.oran  0.0%103.5   3.5   3.1   4.6
>> 0.4
>>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4
>> 1.6
>>   6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1
>>  15.0
>>   7.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>   8.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>   9.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1
>> 1.7
>>  11.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.
>> 0.0
>>
>> Le mer. 6 sept. 2023 à 08:39, Romain  a écrit :
>>
>>> Bonjour la liste,
>>>
>>> J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse
>>> aider dans le diagnostic), passant de Debian 11 à Debian 12.
>>>
>>> Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi.
>>> L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur)
>>> 

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?

Le jeu. 7 sept. 2023 à 09:54, NoSpam  a écrit :

> rpi4.home c'est chez toi ? Avec le -n on aurait eu les IP ...
> Le 07/09/2023 à 09:30, Romain a écrit :
>
> Ça s'est reproduit cette nuit, mais je n'ai pas pu investiguer avant mon
> réveil, et pour l'instant ça ne bloque plus.
>
> Par curiosité je fais un MTR régulier, et j'ai eu un truc étrange.
>
> Un normal (rpi4 à la maison vers OVH) :
> └─# mtr -r 54.38.38.159 -4
> Start: 2023-09-07T07:14:15+
> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
> StDev
>   1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1
> 0.1
>   2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5
> 0.3
>   3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3
> 1.1
>   4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6
> 0.2
>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.5   3.7   3.2   5.4
> 0.6
>   6.|-- be102.par-th2-pb1-nc5.fr.  0.0%10   25.9   9.6   3.7  31.7
>  10.5
>   7.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   8.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   9.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9
> 4.2
>  11.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  12.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  13.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  14.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9
> 0.4
>
> Le même quelques minutes après (pas normal) :
> └─# mtr -r 54.38.38.159 -4
> Start: 2023-09-07T07:24:27+
> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
> StDev
>   1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8
> 0.6
>   2.|-- 80.10.239.90.0%102.8   3.0   2.7   4.4
> 0.5
>   3.|-- ae102-0.ncidf103.rbci.ora  0.0%10   37.3   6.8   2.7  37.3
>  10.7
>   4.|-- ae51-0.nridf101.rbci.oran  0.0%103.5   3.5   3.1   4.6
> 0.4
>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4
> 1.6
>   6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1
>  15.0
>   7.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   8.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   9.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1
> 1.7
>  11.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.
> 0.0
>
> Le mer. 6 sept. 2023 à 08:39, Romain  a écrit :
>
>> Bonjour la liste,
>>
>> J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse
>> aider dans le diagnostic), passant de Debian 11 à Debian 12.
>>
>> Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi.
>> L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur)
>> fonctionne.
>>
>> Exemple cette nuit après un reboot du serveur la veille au soir :
>> 01h43-02h13 (30 minutes)
>> 02h26-03h26 (1 heure)
>> 03h28-05h28 (2 heures)
>> 05h55-? (pas encore débloqué)
>>
>> Problèmes :
>> - sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas
>> d'outil de blocage pré-installé (pas de fail2ban par exemple)
>> - je n'en ai pas ajouté depuis l'installation du serveur, uniquement
>> apache (avec mod_security), PHP et MariaDB
>> - depuis l'IP de chez moi, cette nuit, les seules requêtes générées
>> étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les
>> minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais
>> retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien
>> entendu)
>>
>> Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping
>> retourne un "Destination Port Unreachable".
>>
>> Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR
>> (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier
>> par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en
>> rescue permet de récupérer le ping.
>>
>> Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12
>> quasiment vierge ? Je me tire les cheveux depuis quelques jours...
>>
>> Merci !
>>
>> Romain
>>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

rpi4.home c'est chez toi ? Avec le -n on aurait eu les IP ...

Le 07/09/2023 à 09:30, Romain a écrit :
Ça s'est reproduit cette nuit, mais je n'ai pas pu investiguer avant 
mon réveil, et pour l'instant ça ne bloque plus.


Par curiosité je fais un MTR régulier, et j'ai eu un truc étrange.

Un normal (rpi4 à la maison vers OVH) :
└─# mtr -r 54.38.38.159 -4
Start: 2023-09-07T07:14:15+
HOST: rpi4                        Loss%   Snt   Last   Avg  Best  Wrst 
StDev
  1.|-- livebox.home               0.0%    10    1.0   0.9   0.7   1.1 
  0.1

  2.|-- 80.10.239.9                0.0%    10    3.0   2.9 2.7   3.5   0.3
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%    10    3.3   3.4 2.2   6.3   1.1
  4.|-- ae51-0.nridf101.rbci.oran  0.0%    10    3.2   3.4 3.1   3.6   0.2
  5.|-- ae41-0.noidf001.rbci.oran  0.0%    10    3.5   3.7 3.2   5.4   0.6
  6.|-- be102.par-th2-pb1-nc5.fr <http://be102.par-th2-pb1-nc5.fr/>. 
 0.0%    10   25.9   9.6   3.7  31.7  10.5
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
 10.|-- be103.rbx-g4-nc5.fr.eu <http://be103.rbx-g4-nc5.fr.eu/>   0.0% 
   10    8.1   9.0   7.2  20.9   4.2
 11.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
 12.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
 13.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
 14.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
 15.|-- mail.borezo.info <http://mail.borezo.info/>         0.0%    10 
   6.9   7.2   6.7   7.9   0.4


Le même quelques minutes après (pas normal) :
└─# mtr -r 54.38.38.159 -4
Start: 2023-09-07T07:24:27+
HOST: rpi4                        Loss%   Snt   Last   Avg  Best  Wrst 
StDev
  1.|-- livebox.home               0.0%    10    0.9   1.1   0.7   2.8 
  0.6

  2.|-- 80.10.239.9                0.0%    10    2.8   3.0 2.7   4.4   0.5
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%    10   37.3   6.8 2.7  37.3  10.7
  4.|-- ae51-0.nridf101.rbci.oran  0.0%    10    3.5   3.5 3.1   4.6   0.4
  5.|-- ae41-0.noidf001.rbci.oran  0.0%    10    3.3   3.9 3.2   8.4   1.6
  6.|-- be102.par-th2-pb1-nc5.fr <http://be102.par-th2-pb1-nc5.fr/>. 
 0.0%    10    3.7  14.0   3.7  44.1  15.0
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
 10.|-- be103.rbx-g4-nc5.fr.eu <http://be103.rbx-g4-nc5.fr.eu/>   0.0% 
   10    7.5   8.4   7.1  12.1   1.7
 11.|-- ???                       100.0    10    0.0   0.0   0.0   0.0 
  0.0
 12.|-- rpi4.home                 90.0%    10  7955. 7955. 7955. 7955. 
  0.0


Le mer. 6 sept. 2023 à 08:39, Romain  a écrit :

Bonjour la liste,

J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça
puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.

Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez
moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le
même opérateur) fonctionne.

Exemple cette nuit après un reboot du serveur la veille au soir :
01h43-02h13 (30 minutes)
02h26-03h26 (1 heure)
03h28-05h28 (2 heures)
05h55-? (pas encore débloqué)

Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y
a pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur,
uniquement apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes
générées étaient celles de ma sonde Uptime Kuma, à savoir un ping
toutes les minutes, et une requête curl toutes les minutes vers
une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf
quand l'IP est bloquée, bien entendu)

Lorsque mon IP est bloquée, curl retourne un "Connection refused".
Ping retourne un "Destination Port Unreachable".

Dans les logs du serveur, je ne trouve aucune mention de mon IPv4.
MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai
fait vérifier par OVH et ce n'est pas un de leur équipement
réseau, et un redémarrage en rescue permet de récupérer le ping.

Avez-vous une idée de ce qui pourrait déclencher cela sur un
Debian 12 quasiment vierge ? Je me tire les cheveux depuis
quelques jours...

Merci !

Romain

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Ça s'est reproduit cette nuit, mais je n'ai pas pu investiguer avant mon
réveil, et pour l'instant ça ne bloque plus.

Par curiosité je fais un MTR régulier, et j'ai eu un truc étrange.

Un normal (rpi4 à la maison vers OVH) :
└─# mtr -r 54.38.38.159 -4
Start: 2023-09-07T07:14:15+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1   0.1
  2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5   0.3
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3   1.1
  4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6   0.2
  5.|-- ae41-0.noidf001.rbci.oran  0.0%103.5   3.7   3.2   5.4   0.6
  6.|-- be102.par-th2-pb1-nc5.fr.  0.0%10   25.9   9.6   3.7  31.7  10.5
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9   4.2
 11.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 12.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 13.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 14.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9   0.4

Le même quelques minutes après (pas normal) :
└─# mtr -r 54.38.38.159 -4
Start: 2023-09-07T07:24:27+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8   0.6
  2.|-- 80.10.239.90.0%102.8   3.0   2.7   4.4   0.5
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%10   37.3   6.8   2.7  37.3  10.7
  4.|-- ae51-0.nridf101.rbci.oran  0.0%103.5   3.5   3.1   4.6   0.4
  5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4   1.6
  6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1  15.0
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1   1.7
 11.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.   0.0

Le mer. 6 sept. 2023 à 08:39, Romain  a écrit :

> Bonjour la liste,
>
> J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse
> aider dans le diagnostic), passant de Debian 11 à Debian 12.
>
> Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi.
> L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur)
> fonctionne.
>
> Exemple cette nuit après un reboot du serveur la veille au soir :
> 01h43-02h13 (30 minutes)
> 02h26-03h26 (1 heure)
> 03h28-05h28 (2 heures)
> 05h55-? (pas encore débloqué)
>
> Problèmes :
> - sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas
> d'outil de blocage pré-installé (pas de fail2ban par exemple)
> - je n'en ai pas ajouté depuis l'installation du serveur, uniquement
> apache (avec mod_security), PHP et MariaDB
> - depuis l'IP de chez moi, cette nuit, les seules requêtes générées
> étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les
> minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais
> retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien
> entendu)
>
> Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping
> retourne un "Destination Port Unreachable".
>
> Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR
> (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier
> par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en
> rescue permet de récupérer le ping.
>
> Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12
> quasiment vierge ? Je me tire les cheveux depuis quelques jours...
>
> Merci !
>
> Romain
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 6 septembre 2023 Romain a écrit :

> La seule piste que j'ai (en attendant le prochain blocage et la collecte de
> mtr dans l'autre sens, tcpdump & co, c'est qu'avec ethtool, je vois un taux
> d'erreur qui augmente progressivement (rx_csum_offload_errors). De là à
> dire que ces erreurs sont générées par des paquets qui viennent de mon IP,
> et que ça entraîne un blocage invisible je ne sais où... Il y a déjà eu un
> changement de câble réseau, mais le problème reste. Le support OVH me dit
> que si ça continue en mode rescue il faudra changer la carte mère, sauf
> qu'en rescue il n'y aura pas les mêmes services de montés, et donc pas le
> même trafic pouvant être générateur d'erreurs.

Oui en général des erreurs checksum comme ça ça vient du matériel. Et
plutôt du serveur.
Le traffic tu peux peut-être le simuler, une erreur matériel sera
indépendante du contenu. Pour le port 80 tu as ab du paquet
apache2-utils qui le fait facilement. Tu devras peut-être faire varier la
taille du paquet.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

>
> Sinon est-ce que ta volumétrie est lourde car il peut y avoir un bridage
> de la bande passante sur ton serveur, et donc blocage si tu dépasses tes
> quotas.


Rien de lourd, sachant que c'est illimité chez OVH (le serveur à 500/500
Mbps unmetered), et puis en cas de quota ça serait bloqué partout, pas que
sur IPv4 et pas que sur mon IPv4.

La seule piste que j'ai (en attendant le prochain blocage et la collecte de
mtr dans l'autre sens, tcpdump & co, c'est qu'avec ethtool, je vois un taux
d'erreur qui augmente progressivement (rx_csum_offload_errors). De là à
dire que ces erreurs sont générées par des paquets qui viennent de mon IP,
et que ça entraîne un blocage invisible je ne sais où... Il y a déjà eu un
changement de câble réseau, mais le problème reste. Le support OVH me dit
que si ça continue en mode rescue il faudra changer la carte mère, sauf
qu'en rescue il n'y aura pas les mêmes services de montés, et donc pas le
même trafic pouvant être générateur d'erreurs.

Le mer. 6 sept. 2023 à 15:11, Michel Verdier  a écrit :

> Le 6 septembre 2023 Romain a écrit :
>
> > Il y a bien iptables par défaut, mais :
> >
> > # iptables -nL
> > Chain INPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain FORWARD (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain OUTPUT (policy ACCEPT)
> > target prot opt source   destination
>
> Ok. Donc reste le mtr à partir du serveur. L'option -n n'apportera rien
> de plus. Par contre tu peux peut-être faire un nmap en jouant avec
> certaines options. Je pense à -PN -PS --reason, les différents scans avec
> les options -s (et peut-être -sO), et bien sûr avec -v -v.
> Sinon est-ce que ta volumétrie est lourde car il peut y avoir un bridage
> de la bande passante sur ton serveur, et donc blocage si tu dépasses tes
> quotas.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 6 septembre 2023 Romain a écrit :

> Il y a bien iptables par défaut, mais :
>
> # iptables -nL
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination

Ok. Donc reste le mtr à partir du serveur. L'option -n n'apportera rien
de plus. Par contre tu peux peut-être faire un nmap en jouant avec
certaines options. Je pense à -PN -PS --reason, les différents scans avec
les options -s (et peut-être -sO), et bien sûr avec -v -v.
Sinon est-ce que ta volumétrie est lourde car il peut y avoir un bridage
de la bande passante sur ton serveur, et donc blocage si tu dépasses tes
quotas.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Il y a bien iptables par défaut, mais :

# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Le mer. 6 sept. 2023 à 11:19, Michel Verdier  a écrit :

> Le 6 septembre 2023 Romain a écrit :
>
> > J'insiste, les ports sont ouverts. Depuis une IP source différente (quand
> > la mienne est bloquée), ça fonctionne.
>
> Je reprends en français ça sera plus simple :)
> Tu n'as pas fail2ban, mais as-tu iptables ou nftables (ou autre chose) ?
> Il peut y avoir des règles qui provoquent ce comportement.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 6 septembre 2023 Romain a écrit :

> J'insiste, les ports sont ouverts. Depuis une IP source différente (quand
> la mienne est bloquée), ça fonctionne.

Je reprends en français ça sera plus simple :)
Tu n'as pas fail2ban, mais as-tu iptables ou nftables (ou autre chose) ?
Il peut y avoir des règles qui provoquent ce comportement.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Les ports SSH et HTTP sont bien ouverts.

Je testerai le mtr -n au prochain coup. Pas encore testé avec nc, je le
ferai.

La commande curl était la suivante :
└─# curl -v http://54.38.38.159
*   Trying 54.38.38.159:80...
* connect to 54.38.38.159 port 80 failed: Connection refused
* Failed to connect to 54.38.38.159 port 80 after 7 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 54.38.38.159 port 80 after 7 ms: Connection
refused

J'insiste, les ports sont ouverts. Depuis une IP source différente (quand
la mienne est bloquée), ça fonctionne.

Le mer. 6 sept. 2023 à 09:31, NoSpam  a écrit :

>
> Le 06/09/2023 à 09:13, Romain a écrit :
>
> Non c'est un blocage général semble-t-il (http, https, ssh, ping, ...).
>
> Port http non ouvert, port ssh inexistant sauf s'il écoute sur un autre
> port
>
>
> ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
>> ping et traceroute ...
>
>
> └─# mtr -r 54.38.38.159
>
> mtr -n 54.38.38.159
>
>
>
> tcpdump sur le port 80 avec enregistrement.
>>
>
> Côté serveur dédié OVH ou côté sonde Uptime Kuma ?
>
> Serveur bien sûr
>
> Au moment du blocage j'ai déjà tenté de reproduire des pings & curl vers
> l'IP de mon dédié sur lequel tournait tcpdump, aucune requête vu de mon IP
> à la maison.
>
> Je ne comprends pas cette phrase. As tu testé avec nc ?
>
> Quelle est la commande curl exécutée ?
>
>
> Le mer. 6 sept. 2023 à 09:00, NoSpam  a écrit :
>
>> Bonjour
>>
>> Le 06/09/2023 à 08:39, Romain a écrit :
>> > Bonjour la liste,
>> >
>> > J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça
>> > puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
>> >
>> > Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi.
>> > L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même
>> > opérateur) fonctionne.
>> >
>> > Exemple cette nuit après un reboot du serveur la veille au soir :
>> > 01h43-02h13 (30 minutes)
>> > 02h26-03h26 (1 heure)
>> > 03h28-05h28 (2 heures)
>> > 05h55-? (pas encore débloqué)
>> >
>> > Problèmes :
>> > - sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a
>> > pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
>> > - je n'en ai pas ajouté depuis l'installation du serveur, uniquement
>> > apache (avec mod_security), PHP et MariaDB
>> > - depuis l'IP de chez moi, cette nuit, les seules requêtes générées
>> > étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les
>> > minutes, et une requête curl toutes les minutes vers une URL qui n'a
>> > jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est
>> > bloquée, bien entendu)
>> >
>> > Lorsque mon IP est bloquée, curl retourne un "Connection refused".
>> > Ping retourne un "Destination Port Unreachable".
>> >
>> > Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR
>> > (-4) ne signale aucun problème pour joindre le serveur. J'ai fait
>> > vérifier par OVH et ce n'est pas un de leur équipement réseau, et un
>> > redémarrage en rescue permet de récupérer le ping.
>>
>> J'en déduis que le blocage est sur le port 80 ? Pour débloquer je
>> suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v  80
>>
>> ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
>> ping et traceroute ...
>>
>> >
>> > Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12
>> > quasiment vierge ? Je me tire les cheveux depuis quelques jours...
>> tcpdump sur le port 80 avec enregistrement.
>>
>>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Le 06/09/2023 à 09:13, Romain a écrit :

Non c'est un blocage général semble-t-il (http, https, ssh, ping, ...).

Port http non ouvert, port ssh inexistant sauf s'il écoute sur un autre port


ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
ping et traceroute ...


└─# mtr -r 54.38.38.159

mtr -n 54.38.38.159



tcpdump sur le port 80 avec enregistrement.

Côté serveur dédié OVH ou côté sonde Uptime Kuma ?

Serveur bien sûr
Au moment du blocage j'ai déjà tenté de reproduire des pings & curl 
vers l'IP de mon dédié sur lequel tournait tcpdump, aucune requête vu 
de mon IP à la maison.


Je ne comprends pas cette phrase. As tu testé avec nc ?

Quelle est la commande curl exécutée ?



Le mer. 6 sept. 2023 à 09:00, NoSpam  a écrit :

Bonjour

Le 06/09/2023 à 08:39, Romain a écrit :
> Bonjour la liste,
>
> J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça
> puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
>
> Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez
moi.
> L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même
> opérateur) fonctionne.
>
> Exemple cette nuit après un reboot du serveur la veille au soir :
> 01h43-02h13 (30 minutes)
> 02h26-03h26 (1 heure)
> 03h28-05h28 (2 heures)
> 05h55-? (pas encore débloqué)
>
> Problèmes :
> - sur le template Debian 12 d'OVH pour les serveurs dédiés, il
n'y a
    > pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
> - je n'en ai pas ajouté depuis l'installation du serveur,
uniquement
> apache (avec mod_security), PHP et MariaDB
> - depuis l'IP de chez moi, cette nuit, les seules requêtes générées
> étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les
> minutes, et une requête curl toutes les minutes vers une URL qui
n'a
> jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est
> bloquée, bien entendu)
>
> Lorsque mon IP est bloquée, curl retourne un "Connection refused".
> Ping retourne un "Destination Port Unreachable".
>
> Dans les logs du serveur, je ne trouve aucune mention de mon
IPv4. MTR
> (-4) ne signale aucun problème pour joindre le serveur. J'ai fait
> vérifier par OVH et ce n'est pas un de leur équipement réseau,
et un
> redémarrage en rescue permet de récupérer le ping.

J'en déduis que le blocage est sur le port 80 ? Pour débloquer je
suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v
 80

ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
ping et traceroute ...

>
> Avez-vous une idée de ce qui pourrait déclencher cela sur un
Debian 12
> quasiment vierge ? Je me tire les cheveux depuis quelques jours...
tcpdump sur le port 80 avec enregistrement.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Non c'est un blocage général semble-t-il (http, https, ssh, ping, ...).

ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
> ping et traceroute ...


└─# mtr -r 54.38.38.159
Start: 2023-09-01T07:39:01+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%100.7   0.8   0.6   1.0   0.1
  2.|-- 80.10.239.90.0%102.8   2.7   1.9   3.1   0.4
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.1   3.9   2.5  11.2   2.7
  4.|-- ae51-0.nridf101.rbci.oran  0.0%103.4   3.3   3.2   3.5   0.1
  5.|-- ae41-0.noidf001.rbci.oran  0.0%102.9   3.2   2.1   3.9   0.5
  6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.6  13.8   3.6  66.0  19.8
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.3   7.4   7.2   7.7   0.2
 11.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 12.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 13.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 14.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 15.|-- mail.borezo.info0.0%106.8   7.0   6.6   8.6
0.6

└─# ping 54.38.38.159
PING 54.38.38.159 (54.38.38.159) 56(84) bytes of data.
>From 54.38.38.159 icmp_seq=1 Destination Port Unreachable
>From 54.38.38.159 icmp_seq=2 Destination Port Unreachable
>From 54.38.38.159 icmp_seq=3 Destination Port Unreachable
>From 54.38.38.159 icmp_seq=4 Destination Port Unreachable

tcpdump sur le port 80 avec enregistrement.
>

Côté serveur dédié OVH ou côté sonde Uptime Kuma ? Au moment du blocage
j'ai déjà tenté de reproduire des pings & curl vers l'IP de mon dédié sur
lequel tournait tcpdump, aucune requête vu de mon IP à la maison.

Le mer. 6 sept. 2023 à 09:00, NoSpam  a écrit :

> Bonjour
>
> Le 06/09/2023 à 08:39, Romain a écrit :
> > Bonjour la liste,
> >
> > J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça
> > puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
> >
> > Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi.
> > L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même
> > opérateur) fonctionne.
> >
> > Exemple cette nuit après un reboot du serveur la veille au soir :
> > 01h43-02h13 (30 minutes)
> > 02h26-03h26 (1 heure)
> > 03h28-05h28 (2 heures)
> > 05h55-? (pas encore débloqué)
> >
> > Problèmes :
> > - sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a
> > pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
> > - je n'en ai pas ajouté depuis l'installation du serveur, uniquement
> > apache (avec mod_security), PHP et MariaDB
> > - depuis l'IP de chez moi, cette nuit, les seules requêtes générées
> > étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les
> > minutes, et une requête curl toutes les minutes vers une URL qui n'a
> > jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est
> > bloquée, bien entendu)
> >
> > Lorsque mon IP est bloquée, curl retourne un "Connection refused".
> > Ping retourne un "Destination Port Unreachable".
> >
> > Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR
> > (-4) ne signale aucun problème pour joindre le serveur. J'ai fait
> > vérifier par OVH et ce n'est pas un de leur équipement réseau, et un
> > redémarrage en rescue permet de récupérer le ping.
>
> J'en déduis que le blocage est sur le port 80 ? Pour débloquer je
> suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v  80
>
> ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
> ping et traceroute ...
>
> >
> > Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12
> > quasiment vierge ? Je me tire les cheveux depuis quelques jours...
> tcpdump sur le port 80 avec enregistrement.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Bonjour

Le 06/09/2023 à 08:39, Romain a écrit :

Bonjour la liste,

J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça 
puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.


Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. 
L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même 
opérateur) fonctionne.


Exemple cette nuit après un reboot du serveur la veille au soir :
01h43-02h13 (30 minutes)
02h26-03h26 (1 heure)
03h28-05h28 (2 heures)
05h55-? (pas encore débloqué)

Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a 
pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement 
apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées 
étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les 
minutes, et une requête curl toutes les minutes vers une URL qui n'a 
jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est 
bloquée, bien entendu)


Lorsque mon IP est bloquée, curl retourne un "Connection refused". 
Ping retourne un "Destination Port Unreachable".


Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR 
(-4) ne signale aucun problème pour joindre le serveur. J'ai fait 
vérifier par OVH et ce n'est pas un de leur équipement réseau, et un 
redémarrage en rescue permet de récupérer le ping.


J'en déduis que le blocage est sur le port 80 ? Pour débloquer je 
suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v  80


ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise 
ping et traceroute ...




Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 
quasiment vierge ? Je me tire les cheveux depuis quelques jours...

tcpdump sur le port 80 avec enregistrement.

Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Bonjour la liste,

J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse
aider dans le diagnostic), passant de Debian 11 à Debian 12.

Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi.
L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur)
fonctionne.

Exemple cette nuit après un reboot du serveur la veille au soir :
01h43-02h13 (30 minutes)
02h26-03h26 (1 heure)
03h28-05h28 (2 heures)
05h55-? (pas encore débloqué)

Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas
d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement apache
(avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées étaient
celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une
requête curl toutes les minutes vers une URL qui n'a jamais retourné autre
chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)

Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping
retourne un "Destination Port Unreachable".

Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4)
ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par
OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en
rescue permet de récupérer le ping.

Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12
quasiment vierge ? Je me tire les cheveux depuis quelques jours...

Merci !

Romain

Re: Montée en version vers Bullseye - Fail2ban KO

[BERTRAND Joël]

G2PC a écrit :
> Bonjour,
> 
> Votre montée en version vers Bullseye et avec Fail2ban ce passe t'elle
> tranquillement ?
> 
> De mon côté, j'observe que quelques règles ne fonctionnent plus, lié à
> la montée en version de Fail2ban.
> 
> Avez vous eu également cette problématique de règles Fail2ban à mettre à
> jour de votre côté ?
> 

BOnsoir,

Aucun problème de mon côté. En revanche, je suis en iptables-legacy
(parce que j'ai des tas de règles et que je n'ai pas le temps de passer
dans la nouvelle mouture).

Bien cordialement,

JKB

Montée en version vers Bullseye - Fail2ban KO

[G2PC]

Bonjour,

Votre montée en version vers Bullseye et avec Fail2ban ce passe t'elle
tranquillement ?

De mon côté, j'observe que quelques règles ne fonctionnent plus, lié à
la montée en version de Fail2ban.

Avez vous eu également cette problématique de règles Fail2ban à mettre à
jour de votre côté ?

Re: fail2ban regex

[G2PC]

> > Un outil de bannissement « définitif » pour ceux qui insistent
> > lourdement « multiban » répétés, basé sur l’analyse des logs de
> > Fail2ban. Vous pouvez le trouver sur l’URL suivante :
> >
> https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/
>
> >  Mais cela ne suffisant pas car les réseaux servant à beaucoup
> > d’attaques permettent le changement d’IP, nous ajoutons des règles
> > « ipset » nourries par des RBL qui bloquent même certains réseaux
> > connus pour leurs pratiques douteuses. La solution simple est basée
> > sur 3 ou 4 sites (https://blognote32.net/iptables-ip-blacklist/)
> > Vous pouvez aussi aller voir sur
> > https://iplists.firehol.org/#aboutCollapseThree…
>
>
>     Intéressant. Je note pour plus tard.
+1

Re: fail2ban regex

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Pierre Malard a écrit :
> Bonjour,

Bonjour,

> Je ne sais pas si cela correspond à ce que vous cherchez mais ici
> pour les serveurs sensibles nous nous appuyons en complément de
> Fail2ban qui ne banni que les IP de façon temporaires 2 ajouts :
> 
> Un outil de bannissement « définitif » pour ceux qui insistent
> lourdement « multiban » répétés, basé sur l’analyse des logs de
> Fail2ban. Vous pouvez le trouver sur l’URL suivante : 
> https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/
>
>  Mais cela ne suffisant pas car les réseaux servant à beaucoup
> d’attaques permettent le changement d’IP, nous ajoutons des règles
> « ipset » nourries par des RBL qui bloquent même certains réseaux
> connus pour leurs pratiques douteuses. La solution simple est basée
> sur 3 ou 4 sites (https://blognote32.net/iptables-ip-blacklist/) 
> Vous pouvez aussi aller voir sur
> https://iplists.firehol.org/#aboutCollapseThree…
> 

Intéressant. Je note pour plus tard.

Bien cordialement,

JKB
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAl6r2Q0ACgkQOAfo0lKQ
8+dImA//UlvrQCwLd6j3FCkyXd1p/bbXeyUGltac1A6s30m6BKe1w4LADAapglvY
kJpB+eAG8gG5li9+A4ixZlwF6v21mb8oL6PieaJ70R7ZLztvxjtp0gGPYnYpibie
ZRiB5Mz/EGO8ntYKpk45FtxcITh815ZVm05p5tcGzf0qusrAxRHdb5pTEstpd0ZY
iQdNi3uCETuqrwA3uxQ80lWtnoIeMbDl4YnCqD1owaInb0jyEg8J0kYvGSZvNDxE
EBRTY72Gr47eQisOo5rUUAbXMNGWVHtVqK1VWBU6lAWggEuFgEJqw+eYRykporJz
PEc78BIubRSsolafBQaOi9DaBBD9vJ5Nnv5C1s4IYhTnewFVi+eTuElu9ZvuTAEL
vTqcH7Tqd0o0KFh8cVzLKvnvw8gWyM7bXO+XJ2QxEndly3zIvGesGnubFtqHPAL+
8vaSYFxc6M9dqvqucpSRC9+ymv6D3hO/tc9UhWuqL5FO9CLnIECzPLIInA9XFxLq
l4oU1WaChZQmhd3vhaK8HLjJ1pzHZM3bn3KZcGO8PdShV+Ry+y5RPtWRktB2v9ds
EY5BtpHszSZ2juuK9SMo9bgLXCBIBGc3yBDNalLW9qVhnasCdBCSgGqhD1w/tku5
1ASZtXFFISitF/ekyh7Y9K4iYCpxdOxYsIqYxKKSRjNFtT/RVLM=
=nu0z
-END PGP SIGNATURE-

Re: fail2ban regex

[BERTRAND Joël]

Charles Plessy a écrit :
> Le Thu, Apr 30, 2020 at 12:01:36PM +0200, BERTRAND Joël a écrit :
>>
>>  Parce que le type est borné, que ça fait des jours que ça dure et que
>> l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
>> j'ai autre chose à faire que de surveiller /var/log/syslog.
> 
> Bonjour Joël,
> 
> as-tu essayé la cellule "récidive" de fail2ban ?
> 
> Amicalement,

Bonjour,

Oui, naturellement. Sauf que dans mon cas, ça ne fonctionne pas parce
que le filtre sur TLS ne fonctionne pas.

Aujourd'hui, mon filtre est le suivant :
_daemon = (?:courier)?(?:imapd?|pop3d?)-ssl?

failregex = ^%(__prefix_line)s.*ip=\[\], An unexpected TLS packet
was received.$

qui ne fonctionne pas. La partie failregex toute seule donne quelque
chose si je retire "^%(__prefix_line)s.*" :


fail2ban-regex /var/log/syslog "ip=\[\], An unexpected TLS packet
was received.$"
...
Lines: 73005 lines, 0 ignored, 6 matched, 72999 missed
[processed in 2.80 sec]

Mais fail2ban rajoute une en-tête :fail2ban-client get courier-tls failregex
The following regular expression are defined:
`- [0]:
ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$
et là, ça ne fonctionne plus.

Mais sans le retrait de ^%(__prefix_line)s.*, cela ne donne strictement
rien :

Root rayleigh:[/var/lib/iptables] > fail2ban-client get courier-tls
failregex
The following regular expression are defined:
`- [0]: ^(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)?(?:kernel: \[
*\d+\.\d+\]\s+)?(?:@vserver_\S+\s+)?(?:(?:(?:\[\d+\])?:\s+[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?|[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)\s+)?(?:\[ID
\d+
\S+\]\s+)?.*ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$
Root rayleigh:[/var/lib/iptables] > fail2ban-regex /var/log/syslog "[0]:
^(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)?(?:kernel: \[
*\d+\.\d+\]\s+)?(?:@vserver_\S+\s+)?(?:(?:(?:\[\d+\])?:\s+[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?|[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)\s+)?(?:\[ID
\d+
\S+\]\s+)?.*ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$"

Running tests
=

Use   failregex line : [0]: ^(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)...
Use log file : /var/log/syslog
Use encoding : UTF-8


Results
===

Failregex: 0 total

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [72942] {^LN-BEG}(?:DAY )?MON Day
%k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-

Lines: 72942 lines, 0 ignored, 0 matched, 72942 missed
[processed in 2.80 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all
72942 lines

Re: fail2ban regex

[Charles Plessy]

Le Thu, Apr 30, 2020 at 12:01:36PM +0200, BERTRAND Joël a écrit :
> 
>   Parce que le type est borné, que ça fait des jours que ça dure et que
> l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
> j'ai autre chose à faire que de surveiller /var/log/syslog.

Bonjour Joël,

as-tu essayé la cellule "récidive" de fail2ban ?

Amicalement,

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Re: fail2ban regex

[Pierre Malard]

Bonjour,

Je ne sais pas si cela correspond à ce que vous cherchez mais ici pour
les serveurs sensibles nous nous appuyons en complément de Fail2ban qui
ne banni que les IP de façon temporaires 2 ajouts :

Un outil de bannissement « définitif » pour ceux qui insistent lourdement
« multiban » répétés, basé sur l’analyse des logs de Fail2ban. Vous
pouvez le trouver sur l’URL suivante :

https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/

Mais cela ne suffisant pas car les réseaux servant à beaucoup d’attaques
permettent le changement d’IP, nous ajoutons des règles « ipset » nourries
par des RBL qui bloquent même certains réseaux connus pour leurs pratiques 
douteuses.
La solution simple est basée sur 3 ou 4 sites 
(https://blognote32.net/iptables-ip-blacklist/)
Vous pouvez aussi aller voir sur 
https://iplists.firehol.org/#aboutCollapseThree…

Cordialement


> Le 30 avr. 2020 à 12:01, BERTRAND Joël  a écrit :
> 
> Nisar JAGABAR a écrit :
>> 
>> Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te
>> permets de le faire, regarde la sortie de 'fail2ban-client --help' ou
>> son man :
>> bash# fail2ban-client set  banip 
>> 
>> Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un
>> bash# fail2ban-client status
>> 
>> Pour les IP déjà bannis sur un JAIL particulier :
>> bash# fail2ban-client status 
> 
>   Parce que le type est borné, que ça fait des jours que ça dure et que
> l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
> j'ai autre chose à faire que de surveiller /var/log/syslog.
> 
>   JKB
> 

--
Pierre Malard

  « on ne risque rien à livrer le secret professionnel car
 on ne livre pas la façon de s’en servir »
  Jean Cocteau - « Le secret professionnel » - 1922

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: fail2ban regex

[BERTRAND Joël]

Nisar JAGABAR a écrit :
> 
> Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te
> permets de le faire, regarde la sortie de 'fail2ban-client --help' ou
> son man :
> bash# fail2ban-client set  banip 
> 
> Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un
> bash# fail2ban-client status
> 
> Pour les IP déjà bannis sur un JAIL particulier :
> bash# fail2ban-client status 

Parce que le type est borné, que ça fait des jours que ça dure et que
l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
j'ai autre chose à faire que de surveiller /var/log/syslog.

JKB

Re: fail2ban regex

[Nisar JAGABAR]

Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te 
permets de le faire, regarde la sortie de 'fail2ban-client --help' ou 
son man :

bash# fail2ban-client set  banip 

Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un
bash# fail2ban-client status

Pour les IP déjà bannis sur un JAIL particulier :
bash# fail2ban-client status 


Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

Bonjour à tous,

Depuis plus de 48 heures, je subis une attaque sur l'un de mes serveurs
de mails en provenance de Russie. Les logs sont plein de ce genre de chose :

Apr 29 10:06:33 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 10:06:33 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]

Et ça défile à une vitesse délirante. Je tente donc de rajouter une
règle fail2ban mais elle ne fait rien.

J'ai rajouté courier-tls.conf:

[INCLUDES]
before = common.conf

[Definition]
_daemon = (imapd-ssl|pop3d-ssl)?
failregex = ^.*ip=\[\], An unexpected TLS packet was received.$
ignoreregex =
datepattern = {^LN-BEG}

J'ai naturellement modifié le fichier de configuration de fail2ban et
cette règle est chargée :

2020-04-29 10:05:04,148 fail2ban.server [1114037]: INFO
Reload jail 'courier-tls'
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
encoding: UTF-8
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
maxRetry: 5
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
findtime: 600
2020-04-29 10:05:04,148 fail2ban.actions[1114037]: INFO
banTime: 600

Mais elle ne fait rien. Si je la teste avec fail2ban-regex, elle semble
toutefois fonctionner. Où donc ai-je fait une boulette ?

Bien cordialement,

JKB



--
Nisar JAGABAR
 ,= ,-_-. =.
((_/)o o(\_))
 `-'(. .)`-'
 \_/

Re: fail2ban regex

[BERTRAND Joël]

Lorsque j'interroge directement la regex, j'obtiens ceci :

Root rayleigh:[/etc/fail2ban/filter.d] > fail2ban-client get courier-tls
failregex
The following regular expression are defined:
`- [0]:
^.*ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$

J'avoue que je ne sais pas interpréter.

Bien cordialement,

JKB

Re: fail2ban regex

[G2PC]

> Je n'en sais rien et c'est piégeux.

-> https://github.com/fail2ban/fail2ban/issues

Re: fail2ban regex

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 29/04/2020 à 11:39, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :
>>>> NoSpam a écrit :
>>>>> Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :
>>>>>>      Bonjour à tous,
>>>>> Bonjour
>>>>>
>>>>> la version de fail2ban prend t'elle en charge ipv6 (version minimum
>>>>> 0.10) ?
>>>> Oui : 0.10.2-2.1.
>>>>
>>>> Mais mon installation fail2ban traitait IPv6 depuis très longtemps
>>>> grâce à un petit patch bien senti ;-)
>>>>
>>>> Par ailleurs, l'adresse IP en question est une IPv4.
>>> Non, c'est une IPv6 (ipv4-mapped ipv6)
>>  Ben non. courier indique les adresses IPv4 comme ça. De toute façon, je
>> ne retrouve pas l'IP dans la chaîne correspondante de ip6tables.
> 
> Si si j'insiste ;)
> 
> https://en.wikipedia.org/wiki/IPv6
> 
> Hybrid dual-stack IPv6/IPv4 implementations recognize a special class of
> addresses, the IPv4-mapped IPv6 addresses. These addresses are typically
> written with a 96-bit prefix in the standard IPv6 format, and the
> remaining 32 bits written in the customary dot-decimal notation
> <https://en.wikipedia.org/wiki/Dot-decimal_notation> of IPv4.
> 
> Addresses in this group consist of an 80-bit prefix of zeros, the next
> 16 bits are ones, and the remaining, least-significant 32 bits contain
> the IPv4 address. For example, :::192.0.2.128 represents the IPv4
> address 192.0.2.128
> 
> J'utilise cette numérotation pour les règles firewall afin de pouvoir
> récupérer une connexion ipv6 si l'adresse global venait à défaillir.

Sauf que non. C'est juste un affichage par courier. La connexion est
une connexion réelle IPv4 et pas IPv4 mappée en IPv6.

Preuve :Apr 29 12:13:46 rayleigh pop3d-ssl: ip=[:::213.217.0.213],
An unexpected TLS packet was received.
Apr 29 12:13:46 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]
Apr 29 12:13:48 rayleigh pop3d-ssl: Connection, ip=[:::213.217.0.213]
Apr 29 12:13:48 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 12:13:48 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]
Apr 29 12:13:49 rayleigh pop3d-ssl: Connection, ip=[:::213.217.0.213]
Apr 29 12:13:49 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 12:13:49 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]
Apr 29 12:13:51 rayleigh pop3d-ssl: Connection, ip=[:::213.217.0.213]
Apr 29 12:13:51 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 12:13:51 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]

Et un coup de tcpdump :
12:13:41.213604 IP 213.217.0.213.47835 > rayleigh.systella.fr.pop3s:
Flags [.], ack 2478110317, win 258, length 0
12:13:41.214758 IP 213.217.0.213.47835 > rayleigh.systella.fr.pop3s:
Flags [P.], seq 0:43, ack 1, win 258, length 43
12:13:41.214812 IP rayleigh.systella.fr.pop3s > 213.217.0.213.47835:
Flags [.], ack 43, win 256, length 0
12:13:41.246767 IP rayleigh.systella.fr.pop3s > 213.217.0.213.47835:
Flags [P.], seq 1:8, ack 43, win 256, length 7
12:13:41.247583 IP rayleigh.systella.fr.pop3s > 213.217.0.213.47835:
Flags [R.], seq 8, ack 43, win 256, length 0

Maintenant, ne me demande pas pourquoi courier utilise cette notation,
je n'en sais rien et c'est piégeux.

JKB

Re: fail2ban regex

[BERTRAND Joël]

G2PC a écrit :
> 
>> J'ai naturellement modifié le fichier de configuration de fail2ban et
>> cette règle est chargée.
> 
> 
> Si ta règle match des résultats dans les logs, je suppose que la règle
> est correcte !
> Logique ?

Il me semble. Le doute que j'ai est sur

_daemon = (?:imapd-ssl|pop3d-ssl)

Les regex python sont vraiment des trucs cabalistiques.

> Par contre, personnellement, je me trompe peut être, j'ai peu confiance
> en la commande reload.
> 
> 
> Si tu redémarres totalement Fail2ban, que ce passerait t'il ?
> sudo service fail2ban restart
> 

J'ai essayé les deux, même motif, même punition.

> N'aurais tu pas, par hasard, une panne au démarrage, si tu consultais
> alors les logs en direct de Fail2ban, qui t'indiquerait que Fail2ban n'a
> pas redémarré, pour X ou Y raison ?
> tail -f -n 30 /var/log/fail2ban.log

Tout semble fonctionnel côté fail2ban, les logs donnent :

2020-04-29 12:09:45,750 fail2ban.jail   [1214575]: INFOJail
'sshd' started
2020-04-29 12:09:45,751 fail2ban.jail   [1214575]: INFOJail
'apache-auth' started
2020-04-29 12:09:45,751 fail2ban.jail   [1214575]: INFOJail
'roundcube-auth' started
2020-04-29 12:09:45,752 fail2ban.jail   [1214575]: INFOJail
'sendmail-auth' started
2020-04-29 12:09:45,753 fail2ban.jail   [1214575]: INFOJail
'sendmail-reject' started
2020-04-29 12:09:45,754 fail2ban.jail   [1214575]: INFOJail
'courier-auth' started
2020-04-29 12:09:45,755 fail2ban.jail   [1214575]: INFOJail
'mysqld-auth' started
2020-04-29 12:09:45,756 fail2ban.jail   [1214575]: INFOJail
'zoneminder' started
2020-04-29 12:09:45,757 fail2ban.jail   [1214575]: INFOJail
'courier-tls' started

> Si tu arrives à résoudre ce problème, j'aimerais bien pouvoir ajouter ta
> règle, à mon tutoriel, n'hésite pas à redonner la règle fonctionnelle,
> par la suite. ( Prison + Filtre )
> Installer et utiliser Fail2ban :
> https://wiki.visionduweb.fr/index.php?title=Installer_et_utiliser_Fail2ban

Si j'y arrive ;-)

JKB

Re: fail2ban regex

[NoSpam]

Le 29/04/2020 à 11:39, BERTRAND Joël a écrit :

NoSpam a écrit :

Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :

NoSpam a écrit :

Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

  Bonjour à tous,

Bonjour

la version de fail2ban prend t'elle en charge ipv6 (version minimum
0.10) ?

 Oui : 0.10.2-2.1.

 Mais mon installation fail2ban traitait IPv6 depuis très longtemps
grâce à un petit patch bien senti ;-)

 Par ailleurs, l'adresse IP en question est une IPv4.

Non, c'est une IPv6 (ipv4-mapped ipv6)

Ben non. courier indique les adresses IPv4 comme ça. De toute façon, je
ne retrouve pas l'IP dans la chaîne correspondante de ip6tables.


Si si j'insiste ;)

https://en.wikipedia.org/wiki/IPv6

Hybrid dual-stack IPv6/IPv4 implementations recognize a special class of 
addresses, the IPv4-mapped IPv6 addresses. These addresses are typically 
written with a 96-bit prefix in the standard IPv6 format, and the 
remaining 32 bits written in the customary dot-decimal notation 
<https://en.wikipedia.org/wiki/Dot-decimal_notation> of IPv4.


Addresses in this group consist of an 80-bit prefix of zeros, the next 
16 bits are ones, and the remaining, least-significant 32 bits contain 
the IPv4 address. For example, :::192.0.2.128 represents the IPv4 
address 192.0.2.128


J'utilise cette numérotation pour les règles firewall afin de pouvoir 
récupérer une connexion ipv6 si l'adresse global venait à défaillir.

Re: fail2ban regex

[G2PC]

> J'ai naturellement modifié le fichier de configuration de fail2ban et
> cette règle est chargée.


Si ta règle match des résultats dans les logs, je suppose que la règle
est correcte !
Logique ?

Par contre, personnellement, je me trompe peut être, j'ai peu confiance
en la commande reload.


Si tu redémarres totalement Fail2ban, que ce passerait t'il ?
sudo service fail2ban restart


N'aurais tu pas, par hasard, une panne au démarrage, si tu consultais
alors les logs en direct de Fail2ban, qui t'indiquerait que Fail2ban n'a
pas redémarré, pour X ou Y raison ?
tail -f -n 30 /var/log/fail2ban.log


Si tu arrives à résoudre ce problème, j'aimerais bien pouvoir ajouter ta
règle, à mon tutoriel, n'hésite pas à redonner la règle fonctionnelle,
par la suite. ( Prison + Filtre )
Installer et utiliser Fail2ban :
https://wiki.visionduweb.fr/index.php?title=Installer_et_utiliser_Fail2ban

Re: fail2ban regex

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :
>>>>  Bonjour à tous,
>>> Bonjour
>>>
>>> la version de fail2ban prend t'elle en charge ipv6 (version minimum
>>> 0.10) ?
>> Oui : 0.10.2-2.1.
>>
>> Mais mon installation fail2ban traitait IPv6 depuis très longtemps
>> grâce à un petit patch bien senti ;-)
>>
>> Par ailleurs, l'adresse IP en question est une IPv4.
> Non, c'est une IPv6 (ipv4-mapped ipv6)

Ben non. courier indique les adresses IPv4 comme ça. De toute façon, je
ne retrouve pas l'IP dans la chaîne correspondante de ip6tables.

JKB

Re: fail2ban regex

[NoSpam]

Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :

NoSpam a écrit :

Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

 Bonjour à tous,

Bonjour

la version de fail2ban prend t'elle en charge ipv6 (version minimum 0.10) ?

Oui : 0.10.2-2.1.

Mais mon installation fail2ban traitait IPv6 depuis très longtemps
grâce à un petit patch bien senti ;-)

Par ailleurs, l'adresse IP en question est une IPv4.

Non, c'est une IPv6 (ipv4-mapped ipv6)

Re: fail2ban regex

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :
>> Bonjour à tous,
> 
> Bonjour
> 
> la version de fail2ban prend t'elle en charge ipv6 (version minimum 0.10) ?

Oui : 0.10.2-2.1.

    Mais mon installation fail2ban traitait IPv6 depuis très longtemps
grâce à un petit patch bien senti ;-)

Par ailleurs, l'adresse IP en question est une IPv4.

JKB

Re: fail2ban regex

[NoSpam]

Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

Bonjour à tous,


Bonjour

la version de fail2ban prend t'elle en charge ipv6 (version minimum 0.10) ?



Depuis plus de 48 heures, je subis une attaque sur l'un de mes serveurs
de mails en provenance de Russie. Les logs sont plein de ce genre de chose :

Apr 29 10:06:33 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 10:06:33 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]

Et ça défile à une vitesse délirante. Je tente donc de rajouter une
règle fail2ban mais elle ne fait rien.

J'ai rajouté courier-tls.conf:

[INCLUDES]
before = common.conf

[Definition]
_daemon = (imapd-ssl|pop3d-ssl)?
failregex = ^.*ip=\[\], An unexpected TLS packet was received.$
ignoreregex =
datepattern = {^LN-BEG}

J'ai naturellement modifié le fichier de configuration de fail2ban et
cette règle est chargée :

2020-04-29 10:05:04,148 fail2ban.server [1114037]: INFO
Reload jail 'courier-tls'
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
encoding: UTF-8
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
maxRetry: 5
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
findtime: 600
2020-04-29 10:05:04,148 fail2ban.actions[1114037]: INFO
banTime: 600

Mais elle ne fait rien. Si je la teste avec fail2ban-regex, elle semble
toutefois fonctionner. Où donc ai-je fait une boulette ?

Bien cordialement,

JKB

fail2ban regex

[BERTRAND Joël]

Bonjour à tous,

Depuis plus de 48 heures, je subis une attaque sur l'un de mes serveurs
de mails en provenance de Russie. Les logs sont plein de ce genre de chose :

Apr 29 10:06:33 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 10:06:33 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]

Et ça défile à une vitesse délirante. Je tente donc de rajouter une
règle fail2ban mais elle ne fait rien.

J'ai rajouté courier-tls.conf:

[INCLUDES]
before = common.conf

[Definition]
_daemon = (imapd-ssl|pop3d-ssl)?
failregex = ^.*ip=\[\], An unexpected TLS packet was received.$
ignoreregex =
datepattern = {^LN-BEG}

J'ai naturellement modifié le fichier de configuration de fail2ban et
cette règle est chargée :

2020-04-29 10:05:04,148 fail2ban.server [1114037]: INFO
Reload jail 'courier-tls'
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
encoding: UTF-8
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
maxRetry: 5
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
findtime: 600
2020-04-29 10:05:04,148 fail2ban.actions[1114037]: INFO
banTime: 600

Mais elle ne fait rien. Si je la teste avec fail2ban-regex, elle semble
toutefois fonctionner. Où donc ai-je fait une boulette ?

Bien cordialement,

JKB

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Pierre Malard]

Ok, logique.

Regarde quand même le /var/log/syslog quand tu démarre Fail2Ban…

> Le 11 juil. 2019 à 19:11, Belaïd  a écrit :
> 
> Salut,
> 
> Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des 
> jails dans le même dossier ?  À ta place Je ferai ça dans 
> /etc/fail2ban/jail.d/
> 
> Le jeu. 11 juil. 2019 17:06, fab  <mailto:regnier@free.fr>> a écrit :
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

  « on ne risque rien à livrer le secret professionnel car
 on ne livre pas la façon de s’en servir »
  Jean Cocteau - « Le secret professionnel » - 1922

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Belaïd]

Salut,

Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des
jails dans le même dossier ?  À ta place Je ferai ça dans
/etc/fail2ban/jail.d/

Le jeu. 11 juil. 2019 17:06, fab  a écrit :

> salut la liste,
>
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
>
>
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
>
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
>
>
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
>
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
>
> /etc/hosts.allow sur les 2 serveurs sont les même.
>
> Bref, c'est tout pareil (à priori).
>
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
>
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
>
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
>
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
>
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
>
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
>
> merki,
>
> f.
>
>
>

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Pierre Malard]

Salut,

En supposant bien entendu que tu as installé le paquet Fail2Ban de Debian et 
pas un source venant du site du développeur…

Ça n’a peut-être rien à voir mais « Fail2Ban » préfère maintenant la 
déclaration des déclarations de taules (« jail ») dans un répertoire spécifique 
(« /etc/fail2ban/jail.d »). SI tu as déclaré une configuration dans le 
/etc/fail2ban/jail.local et qu’il en existe une spécifique à SSH dans le 
/etc/fail2ban/jail.d/, je ne sais pas lequel « aura raison ».

Une autre piste pour suivre le lancement de Fail2Ban c’est de suivre son 
lancement dans le fichier log /var/log/syslog. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement. C’est là que le lancement est suivit. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement.
À ce jeu, je me suis rendu compte que certains services n’écrivent pas par 
défaut leurs logs dans les fichiers déclarés par défaut dans Fail2Ban. Tout ça 
se trouve dans les fichiers « /etc/fail2ban/path-….conf ».

Sinon, pour savoir si Fail2Ban tourne, un simple :
# ps -ef | grep fail2ban
suffit.

> Le 11 juil. 2019 à 17:06, fab  a écrit :
> 
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour 
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
> Stopping all jails
> Jail 'sshd' stopped
> Exiting Fail2ban
> Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
> Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
> Creating new jail 'sshd'
> Jail 'sshd' uses pyinotify {}
> Initiated 'pyinotify' backend
> Set jail log file encoding to UTF-8
> Set maxRetry = 2
> Added logfile = /var/log/auth.log
> Set findtime = 600
> Set banTime = 600
> Set maxlines = 10
> Jail sshd is not a JournalFilter instance
> Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

À propos de nos chers économistes :
«Les habiles, dans notre siècle, se sont décernés a eux-mêmes la
qualification d’homme d’état. [...] ces politiques, ingénieux
a mettre aux fictions profitables un masque de nécessité.»
 Victor Hugo : “Les misérables”, La pléiade, Gallimard, P. 843

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

fail2ban : sshd jail ne fonctionne pas (encore)

[fab]

salut la liste,

Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour 
l'instant je n'ai paramétré qu'une seule prison sshd.



serveur A:
# cat defaults-debian.conf
[sshd]
port = 
enabled = true
maxretry = 2

serveur B:
# cat ../jail.local
[sshd]
port = 
enabled = true
maxretry = 2

Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.

Serveur A et B:
# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports  -j f2b-sshd
-A f2b-sshd -j RETURN


/var/log/fail2ban.log des Serveurs A et B sont identiques:

 Stopping all jails
 Jail 'sshd' stopped
 Exiting Fail2ban
 Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
 Connected to fail2ban persistent database
'/var/lib/fail2ban/fail2ban.sqlite3'
 Creating new jail 'sshd'
 Jail 'sshd' uses pyinotify {}
 Initiated 'pyinotify' backend
 Set jail log file encoding to UTF-8
 Set maxRetry = 2
 Added logfile = /var/log/auth.log
 Set findtime = 600
 Set banTime = 600
 Set maxlines = 10
 Jail sshd is not a JournalFilter instance
 Jail 'sshd' started

/etc/hosts.allow sur les 2 serveurs sont les même.

Bref, c'est tout pareil (à priori).

Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
de passe, fail2ban me bannit: OK.

Dans le auth.log du serveur B, j'ai :
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=11.22.33.44  user=toto
Failed password for toto from 11.22.33.44 port 40664 ssh2

Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.

Dans le auth.log du serveur A, j'ai :
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=11.22.33.44  user=toto
Failed password for toto from 11.22.33.44 port 41342 ssh2
Failed password for toto from 11.22.33.44 port 41342 ssh2
Failed password for toto from 11.22.33.44 port 41342 ssh2
Connection closed by 11.22.33.44 port 41342 [preauth]
PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
rhost=11.22.33.44  user=toto

Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.

Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!

merki,

f.

Re: Fail2ban et IMAP

[Sil]

Le 06/03/2019 à 08:16, Sil a écrit :

Bonjour la liste,

Depuis quelques jours quelqu'un essaie de trouver les mots de passe de 
mes comptes IMAP.


Extrait des log :
Mar  5 21:10:16 serveur authdaemond: pam_unix(imap:auth): 
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= 
user=toto


J'ai enfin trouvé une correspondance dans mail.log :

Mar 5 21:10:18 serveur imapd-ssl: LOGIN FAILED, method=PLAIN, 
ip=[:::109.105.195.250]


Par contre fail2ban ne voit rien car son filtre est le suivant :

failregex = ^%(__prefix_line)sLOGIN FAILED, user=.*, ip=\[\]$

J'ai donc créé un nouveau jail avec le filtre suivant :

failregex = ^%(__prefix_line)sLOGIN FAILED, method=.*, ip=\[\]$

Je vais attendre un peu pour voir si le gars se représente.

Silvère

Fail2ban et IMAP

[Sil]

Bonjour la liste,

Depuis quelques jours quelqu'un essaie de trouver les mots de passe de 
mes comptes IMAP.


Extrait des log :
Mar  5 21:10:16 serveur authdaemond: pam_unix(imap:auth): authentication 
failure; logname= uid=0 euid=0 tty= ruser= rhost= user=toto


Ces logs apparaissent dans auth.log et ne contiennent pas d'IP. Fail2ban 
est donc incapable de les détecter. Je ne vois rien dans mail.log, 
mail.warn et mail.err.

Avez-vous une idée pour pouvoir bloquer ces requêtes ?

Par avance merci.
Silvère Maugain

Re: fail2ban - destemail et adresses multiples

[Ph. Gras]

Le 17 mai 2016 à 10:15, Eric Degenetais <edegenet...@henix.fr> a écrit :

>> Je pense que ce n'est pas documenté, parce que ce n'est pas prévu
>> pour ça, on imagine mal un admin envoyer les résultats à son voisin.
> bonjour,
> moi j'imagine bien, par contre, un admin prendre des vacances, avoir
> une vie, toussa...donc il peut être intéressant qu'une ou plusieurs
> personnes agissant en backup reçoivent aussi les notifications.
> Une des solutions possibles indépendamment des possibilités de
> fail2ban lui-même serait de mettre en place une liste de diffusion et
> d'en enregistrer l'adresse.
> 
> cordialement
> 
> Eric
> 
Merkedanke a donné la réponse :

destemail = mac...@test.com bid...@test.com

Ph. Gras

Re: fail2ban - destemail et adresses multiples

[Eric Degenetais]

> Je pense que ce n'est pas documenté, parce que ce n'est pas prévu
> pour ça, on imagine mal un admin envoyer les résultats à son voisin.
bonjour,
moi j'imagine bien, par contre, un admin prendre des vacances, avoir
une vie, toussa...donc il peut être intéressant qu'une ou plusieurs
personnes agissant en backup reçoivent aussi les notifications.
Une des solutions possibles indépendamment des possibilités de
fail2ban lui-même serait de mettre en place une liste de diffusion et
d'en enregistrer l'adresse.

cordialement

Eric

Reu: areu : areu : fail2ban - destemail et adresses multiples

[merkedanke]

dîsons que nous soyons vendredi ... jour du troll ...
et ajoutons que je souhaîte répondre "public" ...

rtfm !
(j'exige faildebanne sinon deb_gnangnan supercon et pas cool hop 
microsoft et toc ... )



Quelqu'un sait si on peut spécifier plusieurs adresses mails derrière 
le paramètre destemail de fail2ban et comment le faire ?


1 _ d'une part je lis les liens que j'adresse, à défaut de tous les 
suivre ...
2 _ d'autre part, la réponse est effectivement donnée _ OUI, AJOUTEZ UN 
ESPACE ENTRE LES ADRESSSES.
3 _ en oûtre , évitez s.v.p. de parlez d'orthographe ou de français car 
, malheureusement , tout est permis vu qu'il s'agît d'une langue vivante 
et que la liberté/license faît partie de l'originalité de l'auteur (donc 
ne peut être retranscrît [ce qui est écrît par l'auteur], copié,transmis 
etc _propriété intellectiuelle_sans autorisation) et surtout qu'il est 
admis par l'académie française et les ministres de la culture qu'il 
s'agît d'une autre forme d'art (e.g rap, graffiti etc.).
4 _ de plus, je vous rappelle que toutes les formes sont admises 
anciennes, nouvelles et à venir ...
5 _ quant (quant à soi !_ voilà ce qui est sous-entendu de ce que je 
pense vraiment de votre post_{entre nous, vous vous fichez de notre 
fiole , ce n'est pas le s.a.v obligatoire de debian industrie !})

6 _ donc, vous ne maîtrisez pas les subtilités de la langue française.
7 _ on admettra qu'une langue soit transmise de la façon qu'il convient 
pour qu'une communication soit établie, qu'un contact, un lien soit créé 
... abc de la culture sur internet concernant la langue anglaise entre 
autre (sujet et non langue donc singulier) ... bref, on s'en tape (le 
style "sms" ne marche pas)!
8 _ donc , ce que vous lisez n'est jamais, en aucun cas, d'aucune 
manière le reflet de la langue mais un argôt/baragouin/pidgin ... christ 
!



En attente d'une suite favorable ?
C'est une plaisanterie ?
# oui, si vous avez lu le post référent, sinon non (sous-entendu : allez 
donc prendre rendez-vous avec laure herbert 37 ans sur une banquette 
arrière ...)



Et attention à l'orthographe

# donc , avez-vous déjà écrît un lîvre ?
# (moi, si )
# (houille ! que dalle prends ti _ laure, porte-en-t-elle ?)
# une dernière chose pour en finir : l'impératif n'est pas toléré (on 
n'est pas votre chien _ j'aîme bien le mien - Attention _ mise en garde 
_ ) ni dans la vie réel ni sur le net ...


Marrant le belge comme dîsait coluche...

Re: fail2ban - destemail et adresses multiples

[Ph. Gras]

Le 14 mai 2016 à 21:25, Jean-Marc  a écrit :

> Sat, 14 May 2016 15:14:13 +0200
> merkeda...@vmail.me écrivait :
> 
>> *
>> il manque un tag rtfm sur la liste ; avant toute demande, il est quant 
>> même souhaîtable de faire des recherches au préalable !
> 
> Aucun des liens ci-dessous ne donne une réponse à ma question.
> Aucun ne donne un exemple avec "destemail" et plusieurs adresses.
> 

Je pense que ce n'est pas documenté, parce que ce n'est pas prévu
pour ça, on imagine mal un admin envoyer les résultats à son voisin.

As-tu essayé des trucs comme ça ?

destemail = ad...@example.com, ad...@test.com
destemail = ad...@example.com ad...@test.com

Avec un peu de chance ça peut marcher, mais fallait le faire vendredi 13 ;-)

Bon courage,

Ph. Gras

Re: Re : fail2ban - destemail et adresses multiples

[Jean-Marc]

Sat, 14 May 2016 15:14:13 +0200
merkeda...@vmail.me écrivait :

> *
> il manque un tag rtfm sur la liste ; avant toute demande, il est quant 
> même souhaîtable de faire des recherches au préalable !

Aucun des liens ci-dessous ne donne une réponse à ma question.
Aucun ne donne un exemple avec "destemail" et plusieurs adresses.

Et attention à l'orthographe (pas d'accent circonflexe à "souhaitable" et 
"quand" dans ce genre d'usage s'écrit avec un "d", pas un "t").

> 
> En attente d'une suite favorable ?

C'est une plaisanterie ?

> 
> ******
> 
> https://help.ubuntu.com/community/Fail2ban
> 
> https://ubuntuforums.org/showthread.php?t=1698581
>   fail2ban doesn't send emails
> 
> https://www.maketecheasier.com/protect-ssh-server-with-fail2ban-ubuntu/
> 
> https://fedoraproject.org/wiki/Fail2ban_with_FirewallD
> 
> www.pontikis.net/blog/fail2ban-install-config-debian-wheezy
> Install and Config Fail2Ban in Debian 7 Wheezy - pontikis.net
> 
> www.linux-magazine.com › Intrusion Detec...
> Intrusion Detection with fail2ban » Linux Magazine
> 
> > spécifier plusieurs adresses mails derrière
> le paramètre destemail de fail2ban ?
> 
> on fait comme Aurore , de l'espace ...
> 


Jean-Marc <jean-m...@6jf.be>


pgpKnYmUoW2Cu.pgp
Description: PGP signature

Re : fail2ban - destemail et adresses multiples

[merkedanke]

*
il manque un tag rtfm sur la liste ; avant toute demande, il est quant 
même souhaîtable de faire des recherches au préalable !


En attente d'une suite favorable ?

**

https://help.ubuntu.com/community/Fail2ban

https://ubuntuforums.org/showthread.php?t=1698581
 fail2ban doesn't send emails

https://www.maketecheasier.com/protect-ssh-server-with-fail2ban-ubuntu/

https://fedoraproject.org/wiki/Fail2ban_with_FirewallD

www.pontikis.net/blog/fail2ban-install-config-debian-wheezy
Install and Config Fail2Ban in Debian 7 Wheezy - pontikis.net

www.linux-magazine.com › Intrusion Detec...
Intrusion Detection with fail2ban » Linux Magazine


spécifier plusieurs adresses mails derrière

le paramètre destemail de fail2ban ?

on fait comme Aurore , de l'espace ...

fail2ban - destemail et adresses multiples

[Jean-Marc]

salut la liste,

Je sèche un peu.

Quelqu'un sait si on peut spécifier plusieurs adresses mails derrière
le paramètre destemail de fail2ban et comment le faire ?

Merci.

Jean-Marc <jean-m...@6jf.be>


pgp_3BinMPajV.pgp
Description: PGP signature

Re: Fail2ban

[Philippe Gras]

Le 1 déc. 2015 à 17:40, Jean-Jacques Doti <b...@doti.fr> a écrit :

> Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :
>> Bonjour,
>> 
>> J'avais lancé un help sur ce sujet et modifié
>> jail.conf et fail.local
>> 
>> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
>> (tentatives de connexions sur des comptes mail) :
>> 
>> "authentication failure; logname= uid=0 euid=0 tty=dovecot
>> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
>> 
>> Une personne qui n'est pas le propriétaire du mail,
>> tente de se connecter 66 fois alors que le "maxretry=3"
>> 
>> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
>> (je l'avais bien relancé).
>> 
>> André
>> 
> Salut,
> 
> En fait, le soucis se situe directement dans la façon dont fail2ban 
> fonctionne.
> Le principe est que fail2ban scrute des fichiers de logs à la recherche de 
> certaines chaînes de caractères. Pour dovecot, c'est le fichier 
> /var/log/mail.log qui est examiné (cf /etc/fail2ban/jail.conf section 
> [dovecot]). La chaîne "authentication failure" est normalement bien repérée 
> et l'adresse IP du client récupérée (cf /etc/fail2ban/filter.d/dovecot.conf). 
> Cette adresse IP es bloquée (via iptables) si elle apparaît plus d'un 
> certains nombre de fois pendant un certain laps de temps (par défaut 3 
> apparitions en 600 secondes).
> Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
> authentication failure; logname= uid=0 euid=0 tty=dovecot 
> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
> c'est à dire avec une seule ligne indiquant de nombreux échecs 
> d'authentification (il s'agit peut-être du nombre d'echec au cours d'une même 
> connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une seule 
> tentative (une seule ligne) et l'IP du client n'est pas immédiatement bloquée.
> 
> Je ne vois pas trop comment changer ce comportement facilement.
> Il doit être possible d'arriver à quelque chose d'accpetable en indiquant 
> "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et en modifiant 
> ou en ajoutant un filtre fai2ban spécifique (les tentatives 
> d'authentification sont alors toutes loggées, mais le format est différent de 
> ce que fail2ban recherche en standard avec la configuration Debian).
> 
> J'espère que je n'ai pas été trop confus dans mes explications et je suis 
> désolé de ne pas pouvoir fournir une solution clé en main…
> 
> A+
> Jean-Jacques
> 
Ah, ouais :-( C'est pas glop comme fonctionnement !

Dans ce cas, on peut mettre le 'maxretry' à 0, comme

ça l'IP est bannie après une première série de fails.

Re: Fail2ban

[Philippe Gras]

Le 1 déc. 2015 à 17:53, Jean-Jacques Doti <b...@doti.fr> a écrit :

> Le 01/12/2015 17:50, Philippe Gras a écrit :
>> Le 1 déc. 2015 à 17:40, Jean-Jacques Doti <b...@doti.fr> a écrit :
>> 
>>> Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :
>>>> Bonjour,
>>>> 
>>>> J'avais lancé un help sur ce sujet et modifié
>>>> jail.conf et fail.local
>>>> 
>>>> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
>>>> (tentatives de connexions sur des comptes mail) :
>>>> 
>>>> "authentication failure; logname= uid=0 euid=0 tty=dovecot
>>>> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
>>>> 
>>>> Une personne qui n'est pas le propriétaire du mail,
>>>> tente de se connecter 66 fois alors que le "maxretry=3"
>>>> 
>>>> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
>>>> (je l'avais bien relancé).
>>>> 
>>>> André
>>>> 
>>> Salut,
>>> 
>>> En fait, le soucis se situe directement dans la façon dont fail2ban 
>>> fonctionne.
>>> Le principe est que fail2ban scrute des fichiers de logs à la recherche de 
>>> certaines chaînes de caractères. Pour dovecot, c'est le fichier 
>>> /var/log/mail.log qui est examiné (cf /etc/fail2ban/jail.conf section 
>>> [dovecot]). La chaîne "authentication failure" est normalement bien repérée 
>>> et l'adresse IP du client récupérée (cf 
>>> /etc/fail2ban/filter.d/dovecot.conf). Cette adresse IP es bloquée (via 
>>> iptables) si elle apparaît plus d'un certains nombre de fois pendant un 
>>> certain laps de temps (par défaut 3 apparitions en 600 secondes).
>>> Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
>>> authentication failure; logname= uid=0 euid=0 tty=dovecot 
>>> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
>>> c'est à dire avec une seule ligne indiquant de nombreux échecs 
>>> d'authentification (il s'agit peut-être du nombre d'echec au cours d'une 
>>> même connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une 
>>> seule tentative (une seule ligne) et l'IP du client n'est pas immédiatement 
>>> bloquée.
>>> 
>>> Je ne vois pas trop comment changer ce comportement facilement.
>>> Il doit être possible d'arriver à quelque chose d'accpetable en indiquant 
>>> "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et en modifiant 
>>> ou en ajoutant un filtre fai2ban spécifique (les tentatives 
>>> d'authentification sont alors toutes loggées, mais le format est différent 
>>> de ce que fail2ban recherche en standard avec la configuration Debian).
>>> 
>>> J'espère que je n'ai pas été trop confus dans mes explications et je suis 
>>> désolé de ne pas pouvoir fournir une solution clé en main…
>>> 
>>> A+
>>> Jean-Jacques
>>> 
>> Ah, ouais :-( C'est pas glop comme fonctionnement !
>> 
>> Dans ce cas, on peut mettre le 'maxretry' à 0, comme
>> 
>> ça l'IP est bannie après une première série de fails.
>> 
> Oui mais non !
> Tu ne veux pas forcément bannir l'utilisateur qui paramètre sa connexion (sur 
> une nouvelle machine ou un nouveau smartphone) et qui fait une faute de 
> frappe lors de la saisie du mot de passe…
> 
> 
Sans doute, mais tu ne paramètres pas ta connexion tous les jours sur un 
nouveau bidule…

Le cas échéant, il vaut mieux penser à modifier sa règle 5 min. Pas pratique 
j'en conviens ;-)

mais une mauvaise solution est parfois meilleure que pas de solution du tout !

Re: Fail2ban

[Jean-Jacques Doti]

Le 01/12/2015 17:50, Philippe Gras a écrit :

Le 1 déc. 2015 à 17:40, Jean-Jacques Doti <b...@doti.fr> a écrit :


Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :

Bonjour,

J'avais lancé un help sur ce sujet et modifié
jail.conf et fail.local

Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
(tentatives de connexions sur des comptes mail) :

"authentication failure; logname= uid=0 euid=0 tty=dovecot
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"

Une personne qui n'est pas le propriétaire du mail,
tente de se connecter 66 fois alors que le "maxretry=3"

Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
(je l'avais bien relancé).

André


Salut,

En fait, le soucis se situe directement dans la façon dont fail2ban fonctionne.
Le principe est que fail2ban scrute des fichiers de logs à la recherche de certaines 
chaînes de caractères. Pour dovecot, c'est le fichier /var/log/mail.log qui est examiné 
(cf /etc/fail2ban/jail.conf section [dovecot]). La chaîne "authentication 
failure" est normalement bien repérée et l'adresse IP du client récupérée (cf 
/etc/fail2ban/filter.d/dovecot.conf). Cette adresse IP es bloquée (via iptables) si elle 
apparaît plus d'un certains nombre de fois pendant un certain laps de temps (par défaut 3 
apparitions en 600 secondes).
Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
authentication failure; logname= uid=0 euid=0 tty=dovecot 
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
c'est à dire avec une seule ligne indiquant de nombreux échecs 
d'authentification (il s'agit peut-être du nombre d'echec au cours d'une même 
connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une seule 
tentative (une seule ligne) et l'IP du client n'est pas immédiatement bloquée.

Je ne vois pas trop comment changer ce comportement facilement.
Il doit être possible d'arriver à quelque chose d'accpetable en indiquant 
"auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et en modifiant ou 
en ajoutant un filtre fai2ban spécifique (les tentatives d'authentification sont alors 
toutes loggées, mais le format est différent de ce que fail2ban recherche en standard 
avec la configuration Debian).

J'espère que je n'ai pas été trop confus dans mes explications et je suis 
désolé de ne pas pouvoir fournir une solution clé en main…

A+
Jean-Jacques


Ah, ouais :-( C'est pas glop comme fonctionnement !

Dans ce cas, on peut mettre le 'maxretry' à 0, comme

ça l'IP est bannie après une première série de fails.


Oui mais non !
Tu ne veux pas forcément bannir l'utilisateur qui paramètre sa connexion 
(sur une nouvelle machine ou un nouveau smartphone) et qui fait une 
faute de frappe lors de la saisie du mot de passe…

Re: Fail2ban

[Philippe Gras]

Le 1 déc. 2015 à 18:57, andre_deb...@numericable.fr a écrit :

>> et  en modifiant ou en ajoutant un filtre fail2ban spécifique 
>> (les tentatives d'authentification sont alors toutes loggées, 
>> mais le format est  différent de ce que fail2ban recherche :
> 
>> J'espère que je n'ai pas été trop confus dans mes explications et je 
>> suis désolé de ne pas pouvoir fournir une solution clé en main…
>> A+  Jean-Jacques 
> 
> Merci, pas confus mais pas d'infos sur :
> "comment ajouter un filtre fail2ban spécifique" :-)

Ce n'est pas super compliqué, en fait. Il n'existe pas de tuto parce que
chaque nouveau filtre est spécifique à des besoins personnels.

Personnellement, j'ai procédé comme suit.

D'abord, je me suis fait envoyer les bans par mail (une option à ajouter
qui est décrite dans le haut du fichier jail.{conf | local})

J'ai été regarder mes logs litigieux et j'ai créé une regex dessus.

Puis, j'ai mv un filtre lambda.conf en avotboncoeur.conf

J'ai remplacé sa regex par la mienne et je l'ai testée :

/usr/bin/fail2ban-regex /var/log/nginx/monfichier.access.log 
/etc/fail2ban/filter.d/nginx-login.conf

J'y ai été contraint, parce que je n'ai pas trouvé de filtre sympa sur nginx
et j'ai pas mal d'exploits sur Wordpress.

> 
> La crainte est qu'un jour une intrusion découvre
> le mot de passe d'un compte mail.

C'est clair que ça vaut le coup de se creuser la cervelle pour trouver une
+/- bonne solution avec un maximum d'efficacité.

> 
> Bonne  soirée.
> 
> André
> 

Re: Fail2ban

[andre_debian]

On Tuesday 01 December 2015 17:40:24 Jean-Jacques Doti wrote:
[cut]
> Je ne vois pas trop comment changer ce comportement facilement.
> Il doit être possible d'arriver à quelque chose d'accpetable en 
> indiquant "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf  :

Fait.

> et  en modifiant ou en ajoutant un filtre fail2ban spécifique 
> (les tentatives d'authentification sont alors toutes loggées, 
> mais le format est  différent de ce que fail2ban recherche :

> J'espère que je n'ai pas été trop confus dans mes explications et je 
> suis désolé de ne pas pouvoir fournir une solution clé en main…
> A+  Jean-Jacques 

Merci, pas confus mais pas d'infos sur :
"comment ajouter un filtre fail2ban spécifique" :-)

La crainte est qu'un jour une intrusion découvre
le mot de passe d'un compte mail.

Bonne  soirée.

André

Re: Fail2ban

[Philippe Gras]

Le 1 déc. 2015 à 15:56, andre_deb...@numericable.fr a écrit :

> On Tuesday 01 December 2015 14:28:18 Philippe Gras wrote:
>> Le 1 déc. 2015 à 14:17, andre_deb...@numericable.fr a écrit :
>>> J'avais lancé un help sur ce sujet et modifié
>>> jail.conf et fail.local
>>> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
>>> (tentatives de connexions sur des comptes mail) :
>>> "authentication failure; logname= uid=0 euid=0 tty=dovecot 
>>> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
>>> Une personne qui n'est pas le propriétaire du mail,
>>> tente de se connecter 66 fois alors que le "maxretry=3"
>>> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
>>> (je l'avais bien relancé).
> 
>> Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ? :
> 
> Les IP intrusives changent d'un jour à l'autre.

Bon, ben alors c'est normal. Quand tu auras banni toutes les IP du pirate ça
va se tasser, mais ça prend évidemment plusieurs jours

> 
>> La période de ban peut être augmentée (> 1 mois c'est bien) :
> 
> Quelle est la ligne à ajouter/ configurer dans les fichiers jail.conf 
> et .local ?

bantime = nombre de secondes en nombre entier
> 
>> Sinon, les requêtes peuvent avoir été envoyées en même temps, et en
>> masse, c'est une technique utilisée pour passer les filtres fail2ban :
> 
> Comment contourner la technique des ? :
> "requêtes envoyées en même temps et en masse".

À ma connaissance ce n'est pas possible. Par contre tu peux filtrer le nombre
de connections simultanées sur ton serveur ou avec iptables.
> 
> André
> 
> 

Re: Fail2ban

[andre_debian]

On Tuesday 01 December 2015 14:28:18 Philippe Gras wrote:
> Le 1 déc. 2015 à 14:17, andre_deb...@numericable.fr a écrit :
> > J'avais lancé un help sur ce sujet et modifié
> > jail.conf et fail.local
> > Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
> > (tentatives de connexions sur des comptes mail) :
> > "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> > ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
> > Une personne qui n'est pas le propriétaire du mail,
> > tente de se connecter 66 fois alors que le "maxretry=3"
> > Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
> > (je l'avais bien relancé).

> Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ? :

Les IP intrusives changent d'un jour à l'autre.

> La période de ban peut être augmentée (> 1 mois c'est bien) :

Quelle est la ligne à ajouter/ configurer dans les fichiers jail.conf 
et .local ?

> Sinon, les requêtes peuvent avoir été envoyées en même temps, et en
> masse, c'est une technique utilisée pour passer les filtres fail2ban :

Comment contourner la technique des ? :
"requêtes envoyées en même temps et en masse".

André

Re: Fail2ban

[andre_debian]

Bonjour,
 
J'avais lancé un help sur ce sujet et modifié jail.conf et jail.local
 
Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
(tentatives de connexions sur des comptes mail) :
 
"authentication failure; logname= uid=0 euid=0 tty=dovecot 
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
 
Une personne qui n'est pas le propriétaire du mail,
tente de se connecter 66 fois alors que le "maxretry=3"
 
Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
(je l'avais bien relancé).
 
André
 

Re: Fail2ban

[Philippe Gras]

Le 1 déc. 2015 à 14:17, andre_deb...@numericable.fr a écrit :

> Bonjour,
> 
> J'avais lancé un help sur ce sujet et modifié
> jail.conf et fail.local
> 
> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
> (tentatives de connexions sur des comptes mail) :
> 
> "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"

Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ?

La période de ban peut être augmentée (> 1 mois c'est bien ;-))

Sinon, les requêtes peuvent avoir été envoyées en même temps, et en

masse, c'est une technique utilisée pour passer les filtres fail2ban.
> 
> Une personne qui n'est pas le propriétaire du mail,
> tente de se connecter 66 fois alors que le "maxretry=3"
> 
> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
> (je l'avais bien relancé).
> 
> André
> 

Re: Fail2ban

[Bernard Schoenacker]

Le Tue, 1 Dec 2015 14:17:43 +0100,
andre_deb...@numericable.fr a écrit :

> Bonjour,
> 
> J'avais lancé un help sur ce sujet et modifié
> jail.conf et fail.local
> 
> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
> (tentatives de connexions sur des comptes mail) :
> 
> "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
> 
> Une personne qui n'est pas le propriétaire du mail,
> tente de se connecter 66 fois alors que le "maxretry=3"
> 
> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
> (je l'avais bien relancé).
> 
> André
> 

bonjour,


serait il possible de comparer avec cet exemple :

http://wiki.dovecot.org/HowTo/Fail2Ban

ensuite, serait il possible de donner la version de dovecot installée ?


et de lire ceci : /usr/share/doc/fail2ban/run-rootless.txt



slt
bernard

Re: Fail2ban

[Bernard Schoenacker]

Le Tue, 1 Dec 2015 14:43:12 +0100,
Bernard Schoenacker <bernard.schoenac...@free.fr> a écrit :

> Le Tue, 1 Dec 2015 14:17:43 +0100,
> andre_deb...@numericable.fr a écrit :
> 
> > Bonjour,
> > 
> > J'avais lancé un help sur ce sujet et modifié
> > jail.conf et fail.local
> > 
> > Malgré, j'ai toujours ce type de message dans mon logwatch
> > quotidien, (tentatives de connexions sur des comptes mail) :
> > 
> > "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> > ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
> > 
> > Une personne qui n'est pas le propriétaire du mail,
> > tente de se connecter 66 fois alors que le "maxretry=3"
> > 
> > Ici, fail2ban ne joue pas son rôle, il reste insensible à ses
> > configs. (je l'avais bien relancé).
> > 
> > André
> >   
> 
> bonjour,
> 
> 
> serait il possible de comparer avec cet exemple :
> 
> http://wiki.dovecot.org/HowTo/Fail2Ban
> 
> ensuite, serait il possible de donner la version de dovecot
> installée ?
> 
> 
> et de lire ceci : /usr/share/doc/fail2ban/run-rootless.txt
> 
> 
> 
> slt
> bernard
> 

bonjour,

j'ai oublié un lien :

http://www.fail2ban.org/wiki/index.php/Talk:Dovecot

slt
bernard

Fail2ban

[andre_debian]

Bonjour,

J'avais lancé un help sur ce sujet et modifié
jail.conf et fail.local

Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
(tentatives de connexions sur des comptes mail) :

"authentication failure; logname= uid=0 euid=0 tty=dovecot 
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"

Une personne qui n'est pas le propriétaire du mail,
tente de se connecter 66 fois alors que le "maxretry=3"

Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
(je l'avais bien relancé).

André

Re: Fail2ban

[Jean-Jacques Doti]

Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :

Bonjour,

J'avais lancé un help sur ce sujet et modifié
jail.conf et fail.local

Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
(tentatives de connexions sur des comptes mail) :

"authentication failure; logname= uid=0 euid=0 tty=dovecot
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"

Une personne qui n'est pas le propriétaire du mail,
tente de se connecter 66 fois alors que le "maxretry=3"

Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
(je l'avais bien relancé).

André


Salut,

En fait, le soucis se situe directement dans la façon dont fail2ban 
fonctionne.
Le principe est que fail2ban scrute des fichiers de logs à la recherche 
de certaines chaînes de caractères. Pour dovecot, c'est le fichier 
/var/log/mail.log qui est examiné (cf /etc/fail2ban/jail.conf section 
[dovecot]). La chaîne "authentication failure" est normalement bien 
repérée et l'adresse IP du client récupérée (cf 
/etc/fail2ban/filter.d/dovecot.conf). Cette adresse IP es bloquée (via 
iptables) si elle apparaît plus d'un certains nombre de fois pendant un 
certain laps de temps (par défaut 3 apparitions en 600 secondes).

Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
authentication failure; logname= uid=0 euid=0 tty=dovecot 
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
c'est à dire avec une seule ligne indiquant de nombreux échecs 
d'authentification (il s'agit peut-être du nombre d'echec au cours d'une 
même connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une 
seule tentative (une seule ligne) et l'IP du client n'est pas 
immédiatement bloquée.


Je ne vois pas trop comment changer ce comportement facilement.
Il doit être possible d'arriver à quelque chose d'accpetable en 
indiquant "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et 
en modifiant ou en ajoutant un filtre fai2ban spécifique (les tentatives 
d'authentification sont alors toutes loggées, mais le format est 
différent de ce que fail2ban recherche en standard avec la configuration 
Debian).


J'espère que je n'ai pas été trop confus dans mes explications et je 
suis désolé de ne pas pouvoir fournir une solution clé en main…


A+
Jean-Jacques

Re: [HS][up!] fail2ban

[Jacques Lav!gnotte.]

Le 18/02/2015 00:11, Philippe Gras a écrit :

 Bon, alors j'ai trouvé :
 http://serverfault.com/questions/448779/have-fail2ban-send-notification-to-banned-party

Et comme bien souvent le 'banned-party' n'accepte pas les e-mails le MTA
de ta machine se retrouve pendant 5 jours à essayer d'envoyer.

Peut etre une FBI :(

 Je ne pense pas que ça fonctionne sous les tropiques, mais dans les pays
 civilisés peut-
 être que oui.

Tu peux préciser ta pensée sur cette dichotomie ?

J.

-- 
GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http://weusepgp.info/

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54e45ae1.9070...@lavignotte.org

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 18 févr. 15 à 10:26, Jacques Lav!gnotte. a écrit :


Le 18/02/2015 00:11, Philippe Gras a écrit :


Bon, alors j'ai trouvé :
http://serverfault.com/questions/448779/have-fail2ban-send- 
notification-to-banned-party


Et comme bien souvent le 'banned-party' n'accepte pas les e-mails  
le MTA

de ta machine se retrouve pendant 5 jours à essayer d'envoyer.


Ça m'est arrivé 1 fois en Chine effectivement, et ce n'était pas un  
mail automatique.




Peut etre une FBI :(

Je ne pense pas que ça fonctionne sous les tropiques, mais dans  
les pays

civilisés peut-
être que oui.


Tu peux préciser ta pensée sur cette dichotomie ?


C'est nécessaire ?


J.

--
GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http:// 
weusepgp.info/


--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54e45ae1.9070...@lavignotte.org



--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/91bb8245-473e-4cf0-af41-bb0857eea...@worldonline.fr

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 3 févr. 15 à 20:04, Laurent Lesage a écrit :

La dernière version que j'ai installée (0.8.14) utilise le REJECT.  
J'ai des sites en 0.8.4 où c'était encore DROP.

Donc, l'évolution va dans le sens de ce post.

On 03/02/15 12:01, Philippe Gras wrote:


Le 3 févr. 15 à 08:37, BERTRAND Joël a écrit :


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…


Bon, alors j'ai trouvé :
http://serverfault.com/questions/448779/have-fail2ban-send- 
notification-to-banned-party


Il suffit d'ajouter une ligne à action dans les jails de jail.local :-)

Je ne pense pas que ça fonctionne sous les tropiques, mais dans les  
pays civilisés peut-

être que oui.





--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54d07ad5.6080...@systella.fr





--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54d11bb1.6060...@2lconsult.be

Re: [HS][up!] fail2ban

[Vincent Lefevre]

On 2015-02-17 13:11:11 +0100, Philippe Gras wrote:
 Le 17 févr. 15 à 12:59, Vincent Lefevre a écrit :
 On 2015-02-16 16:04:23 +0100, Philippe Gras wrote:
 Le 16 févr. 15 à 15:09, Vincent Lefevre a écrit :
 En même temps, cela permet de repérer les adresses IP en question.
 
 Ouais, mais qu'est-ce que tu veux prendre comme mesures avec des IP
 situées
 en Russie ou en Chine ? C'est comme si elles étaient sur la planète Mars
 !
 
 Je les bannis de manière permanente (en fait, le sous-réseau entier).
 
 Tu veux dire toute la plage ? Avec un paramètre de géolocalisation ?

Toute la plage (en général), pas de géolocalisation: je remarque
qu'il y a plusieurs adresses IP bannies similaires (même préfixe)
qui reviennent, puis je fais un whois sur l'une d'elle, ce qui me
donne un sous-réseau, je m'aperçois que ces adresses appartiennent
toutes à ce sous-réseau, et je bannis de manière permanente.

 Sinon, j'ai trouvé un truc marrant hier soir :
 http://www.wikigento.com/securite/tarpit-iptables-les-armes-fatales-anti-ddos/

Donc si je comprends bien, au lieu de faire un DROP ou un REJECT
avec fail2ban, on pourrait appliquer un Tarpit?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217142253.gc4...@xvii.vinc17.org

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 17 févr. 15 à 15:22, Vincent Lefevre a écrit :


On 2015-02-17 13:11:11 +0100, Philippe Gras wrote:

Le 17 févr. 15 à 12:59, Vincent Lefevre a écrit :

On 2015-02-16 16:04:23 +0100, Philippe Gras wrote:

Le 16 févr. 15 à 15:09, Vincent Lefevre a écrit :

En même temps, cela permet de repérer les adresses IP en question.


Ouais, mais qu'est-ce que tu veux prendre comme mesures avec des IP
situées
en Russie ou en Chine ? C'est comme si elles étaient sur la  
planète Mars

!


Je les bannis de manière permanente (en fait, le sous-réseau  
entier).


Tu veux dire toute la plage ? Avec un paramètre de géolocalisation ?


Toute la plage (en général), pas de géolocalisation: je remarque
qu'il y a plusieurs adresses IP bannies similaires (même préfixe)
qui reviennent, puis je fais un whois sur l'une d'elle, ce qui me
donne un sous-réseau, je m'aperçois que ces adresses appartiennent
toutes à ce sous-réseau, et je bannis de manière permanente.


OK. Je faisais ça avant d'avoir installé fail2ban. Trop de  
maintenance à mon goût :-)



Sinon, j'ai trouvé un truc marrant hier soir :
http://www.wikigento.com/securite/tarpit-iptables-les-armes- 
fatales-anti-ddos/


Donc si je comprends bien, au lieu de faire un DROP ou un REJECT
avec fail2ban, on pourrait appliquer un Tarpit?


Oui, mais j'ai l'impression qu'il s'agit d'une instruction  
hétérodoxe, à installer chez soi.




--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/ 
blog/

Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150217142253.gc4...@xvii.vinc17.org




--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/84bcfb80-3bd4-4d7b-b3ed-220db1fb2...@worldonline.fr

Re: [HS][up!] fail2ban

[Vincent Lefevre]

On 2015-02-17 15:22:54 +0100, Vincent Lefevre wrote:
 On 2015-02-17 13:11:11 +0100, Philippe Gras wrote:
  Sinon, j'ai trouvé un truc marrant hier soir :
  http://www.wikigento.com/securite/tarpit-iptables-les-armes-fatales-anti-ddos/
 
 Donc si je comprends bien, au lieu de faire un DROP ou un REJECT
 avec fail2ban, on pourrait appliquer un Tarpit?

À ce propos, avec Google, j'ai trouvé ça:

  http://blog.nicolargo.com/2012/03/bannir-les-bannis-avec-fail2ban.html

En bonus, nous allons également voir comment pourrir la bande
passante de la machine effectuant l'attaque en utilisant la règle
de drop de type tarpitting de IpTable.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217142551.gd4...@xvii.vinc17.org

Re: [HS][up!] fail2ban

[Vincent Lefevre]

On 2015-02-16 16:04:23 +0100, Philippe Gras wrote:
 Le 16 févr. 15 à 15:09, Vincent Lefevre a écrit :
 En même temps, cela permet de repérer les adresses IP en question.
 
 Ouais, mais qu'est-ce que tu veux prendre comme mesures avec des IP situées
 en Russie ou en Chine ? C'est comme si elles étaient sur la planète Mars !

Je les bannis de manière permanente (en fait, le sous-réseau entier).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217115959.ga4...@xvii.vinc17.org

Re: [HS][up!] fail2ban

[Jean-Michel OLTRA]

Bonjour,


Le mardi 17 février 2015, Philippe Gras a écrit...


 Donc si je comprends bien, au lieu de faire un DROP ou un REJECT
 avec fail2ban, on pourrait appliquer un Tarpit?

 Oui, mais j'ai l'impression qu'il s'agit d'une instruction hétérodoxe, à
 installer chez soi.

Ce n'est pas vraiment compliqué. Installer xtables-addons-common et
xtables-addons-dkms qui s'occupera de tout. Puis TARPIT'er les
méchants !

Tu peux en parallèle utiliser les fonctionnalités d'ipset et de ses
listes pour faire des blacklist (ou whitelist) plus ou moins dynamiques.

C'est très efficace. Fail2ban, ou un autre hids (comme Ossec) peut
remplir les listes et iptables s'occuper du reste, ce qui concentre la
riposte en un seul point.

-- 
jm

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217212838.GD2850@espinasse

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 17 févr. 15 à 12:59, Vincent Lefevre a écrit :


On 2015-02-16 16:04:23 +0100, Philippe Gras wrote:

Le 16 févr. 15 à 15:09, Vincent Lefevre a écrit :

En même temps, cela permet de repérer les adresses IP en question.


Ouais, mais qu'est-ce que tu veux prendre comme mesures avec des  
IP situées
en Russie ou en Chine ? C'est comme si elles étaient sur la  
planète Mars !


Je les bannis de manière permanente (en fait, le sous-réseau entier).


Tu veux dire toute la plage ? Avec un paramètre de géolocalisation ?

Sinon, j'ai trouvé un truc marrant hier soir :
http://www.wikigento.com/securite/tarpit-iptables-les-armes-fatales- 
anti-ddos/


Je ne sais pas si c'est de série dans Iptables.


--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/ 
blog/

Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150217115959.ga4...@xvii.vinc17.org




--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/84d5904b-83cc-48ea-988e-6287ac90e...@worldonline.fr

Re: [HS][up!] fail2ban

[Vincent Lefevre]

On 2015-02-16 14:38:47 +0100, Philippe Gras wrote:
 Le 16 févr. 15 à 14:18, Vincent Lefevre a écrit :
 D'un autre côté, faire un DROP embête plus l'attaquant, qui va perdre
 son temps à faire des requêtes qui n'aboutiront pas. Mais...
 
 Non, le DROP n'embête pas plus l'attaquant que ça. Tu loues un VPN à
 la journée, la semaine ou au mois et t'as un abonnement identique pour
 X, Y ou Z Ko de trafic, dans une certaine limite évidemment.

Ce n'est pas le trafic qui est important ici. Quand on fait un DROP,
le ssh qui a été lancé reste actif sur la machine cliente pendant un
certain temps, alors qu'avec un REJECT, le ssh termine immédiatement.
Donc avec des DROP, l'attaquant peut donc faire moins de tentatives
s'il passe son temps à tomber sur des DROP (même s'il fait des ssh
en parallèle, le parallélisme a ses limites).

[...]
 Le fait d'avoir changé le DROP en REJECT m'a permis d'en décourager
 beaucoup, en seulement quelques jours. Je suis en train de généraliser
 l'option sur tous mes filtres.
 
 Avec  le DROP quand tu lèves le ban, tu vois les mêmes IP réapparaître.
 
 On a vraiment l'impression que les mecs ne récupèrent pas les données
 de leurs bots, c'est n'importe quoi !

En même temps, cela permet de repérer les adresses IP en question.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216140954.ga27...@xvii.vinc17.org

Re: [HS][up!] fail2ban

[Vincent Lefevre]

On 2015-02-15 12:22:34 +0100, Philippe Gras wrote:
 Le 15 févr. 15 à 12:08, BERTRAND Joël a écrit :
 
 Philippe Gras a écrit :
 
 Le 14 févr. 15 à 20:50, BERTRAND Joël a écrit :
 
 Philippe Gras a écrit :
 OKAAAYY !
 
 Le 14 févr. 15 à 20:04, BERTRAND Joël a écrit :
 
 Philippe Gras a écrit :
 Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas
 très bien
 compris la façon dont ça se passe et pourquoi ça décourage
 l'attaquant.
 
 Parce que lorsque tu fais un DROP, l'attaquant ne sait pas si
 le
 port est ouvert (et saturé) ou fermé, ou s'il y a même une machine
 sur
 cette adresse. Il réessaye jusqu'à ce que quelqu'un lui réponde.
 Avec
 un REJECT, tu dis immédiatement merdre à l'attaquant et il passe à
 autre chose.
 
 Cela fonctionne pour l'instant parce que les réseaux zombie
 veulent passer inaperçus. Donc si une machine est un peu protégée,
 ils
 passent à une autre.
 
 Bon, j'ai pigé maintenant :-) Mais pour passer inaperçus, tu…
 repasseras
 ;-)
 
 La boîte noire n'est jamais une solution quand on parle de
 sécurité.
 
 La boîte noire ? Que veux-tu dire par-là ?
 
  Que faire croire qu'il n'y a aucune machine qui répond sur cette adresse
 IP n'est pas la solution. Rejeter le paquet signifie j'ai bien vu ta
 tentative et je t'emmerde.

D'un autre côté, faire un DROP embête plus l'attaquant, qui va perdre
son temps à faire des requêtes qui n'aboutiront pas. Mais...

 Oui, tu as 1.000.000 fois raison ! Il y a un module pour envoyer des
 réclamations abuse
 
 dans fail2ban. J'aimerais bien l'activer aussi, mais je n'ai pas trouvé
 comment faire.

un abuse serait peut-être mieux. Ceci dit, je ne sais pas si
les principaux FAI concernés (en général chinois) prendraient
des mesures. Pour info, j'ai ceci dans mon /etc/hosts.deny:

# Permanent SSH ban due to many attempts (according to fail2ban)
# CHINANET-ZJ-HU (CN)
sshd: 61.174.48.0/21
# HEETHAI-HK (CN)
sshd: 103.41.124.0/24
# CHINANET-ZJ-SX (CN)
sshd: 115.231.216.0/21
# CHINANET-ZJ-HU (CN)
sshd: 122.225.96.0/19
# CHINANET-JS (CN)
sshd: 218.2.0.0/16
# UNICOM-JL (CN)
sshd: 222.160.0.0/14

 Quand elles aboutissent chez des gens sérieux perchant dans des pays
 sérieux, l'effet
 
 rafraîchissant est garanti. Je reçois plein de pourriels de chez OVH en ce
 moment, et je
 
 sais qu'en les dénonçant, ils vont cesser leur petit jeu débile.
 
 Les mecs ont déjà usé 3 IP pour me faire ch… et je suppose qu'ils en ont
 d'autres. Si je

J'ai déjà blacklisté plus de 500 adresses IP de chez OVH (toutes
provenant de sous-réseaux propageant le même modèle de spam: quand
j'en vois un, je me dis que ça vient de chez OVH, et effectivement).

 pouvais leur faire suspendre leur abonnement, ça me ferait bien plaisir :-).

Ce n'est pas ça qui va gêner les spammeurs. Tant qu'il n'y a pas de
grosse conséquence financière...

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216131856.ga17...@xvii.vinc17.org

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 16 févr. 15 à 14:18, Vincent Lefevre a écrit :


On 2015-02-15 12:22:34 +0100, Philippe Gras wrote:

Le 15 févr. 15 à 12:08, BERTRAND Joël a écrit :


Philippe Gras a écrit :


Le 14 févr. 15 à 20:50, BERTRAND Joël a écrit :


Philippe Gras a écrit :

OKAAAYY !

Le 14 févr. 15 à 20:04, BERTRAND Joël a écrit :


Philippe Gras a écrit :
Apparemment, ça a l'air super efficace :-) Par contre je  
n'ai pas

très bien
compris la façon dont ça se passe et pourquoi ça décourage
l'attaquant.


   Parce que lorsque tu fais un DROP, l'attaquant ne sait pas si
le
port est ouvert (et saturé) ou fermé, ou s'il y a même une  
machine

sur
cette adresse. Il réessaye jusqu'à ce que quelqu'un lui réponde.
Avec
un REJECT, tu dis immédiatement merdre à l'attaquant et il  
passe à

autre chose.

   Cela fonctionne pour l'instant parce que les réseaux zombie
veulent passer inaperçus. Donc si une machine est un peu  
protégée,

ils
passent à une autre.


Bon, j'ai pigé maintenant :-) Mais pour passer inaperçus, tu…
repasseras
;-)


   La boîte noire n'est jamais une solution quand on parle de
sécurité.


La boîte noire ? Que veux-tu dire par-là ?


	Que faire croire qu'il n'y a aucune machine qui répond sur cette  
adresse
IP n'est pas la solution. Rejeter le paquet signifie j'ai bien  
vu ta

tentative et je t'emmerde.


D'un autre côté, faire un DROP embête plus l'attaquant, qui va perdre
son temps à faire des requêtes qui n'aboutiront pas. Mais...


Non, le DROP n'embête pas plus l'attaquant que ça. Tu loues un VPN à
la journée, la semaine ou au mois et t'as un abonnement identique pour
X, Y ou Z Ko de trafic, dans une certaine limite évidemment.

Le plus galère dans la sécurité, ce n'est pas le plus dangereux. On a en
effet 2 types d'attaquants :
Les script kiddies, qui te bouffent un max de ressources, mais ne te  
font

pas réellement de dégâts.
Les vrais pirates, qui savent infiltrer un serveur incognito.

Il faut bien se dire que fail2ban te permet de bloquer les premiers,  
et de

sauver ainsi énormément de ressources. Pour les autres…

Le fait d'avoir changé le DROP en REJECT m'a permis d'en décourager
beaucoup, en seulement quelques jours. Je suis en train de généraliser
l'option sur tous mes filtres.

Avec  le DROP quand tu lèves le ban, tu vois les mêmes IP réapparaître.

On a vraiment l'impression que les mecs ne récupèrent pas les données
de leurs bots, c'est n'importe quoi !




Oui, tu as 1.000.000 fois raison ! Il y a un module pour envoyer des
réclamations abuse

dans fail2ban. J'aimerais bien l'activer aussi, mais je n'ai pas  
trouvé

comment faire.


un abuse serait peut-être mieux. Ceci dit, je ne sais pas si
les principaux FAI concernés (en général chinois) prendraient
des mesures. Pour info, j'ai ceci dans mon /etc/hosts.deny:

# Permanent SSH ban due to many attempts (according to fail2ban)
# CHINANET-ZJ-HU (CN)
sshd: 61.174.48.0/21
# HEETHAI-HK (CN)
sshd: 103.41.124.0/24
# CHINANET-ZJ-SX (CN)
sshd: 115.231.216.0/21
# CHINANET-ZJ-HU (CN)
sshd: 122.225.96.0/19
# CHINANET-JS (CN)
sshd: 218.2.0.0/16
# UNICOM-JL (CN)
sshd: 222.160.0.0/14


Quand elles aboutissent chez des gens sérieux perchant dans des pays
sérieux, l'effet

rafraîchissant est garanti. Je reçois plein de pourriels de chez  
OVH en ce

moment, et je

sais qu'en les dénonçant, ils vont cesser leur petit jeu débile.

Les mecs ont déjà usé 3 IP pour me faire ch… et je suppose qu'ils  
en ont

d'autres. Si je


J'ai déjà blacklisté plus de 500 adresses IP de chez OVH (toutes
provenant de sous-réseaux propageant le même modèle de spam: quand
j'en vois un, je me dis que ça vient de chez OVH, et effectivement).

pouvais leur faire suspendre leur abonnement, ça me ferait bien  
plaisir :-).


Ce n'est pas ça qui va gêner les spammeurs. Tant qu'il n'y a pas de
grosse conséquence financière...

--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/ 
blog/

Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150216131856.ga17...@xvii.vinc17.org




--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/7fb7b0b6-d9d1-44a0-aa71-a5b2449cc...@worldonline.fr

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 16 févr. 15 à 15:09, Vincent Lefevre a écrit :


On 2015-02-16 14:38:47 +0100, Philippe Gras wrote:

Le 16 févr. 15 à 14:18, Vincent Lefevre a écrit :
D'un autre côté, faire un DROP embête plus l'attaquant, qui va  
perdre

son temps à faire des requêtes qui n'aboutiront pas. Mais...


Non, le DROP n'embête pas plus l'attaquant que ça. Tu loues un VPN à
la journée, la semaine ou au mois et t'as un abonnement identique  
pour

X, Y ou Z Ko de trafic, dans une certaine limite évidemment.


Ce n'est pas le trafic qui est important ici. Quand on fait un DROP,
le ssh qui a été lancé reste actif sur la machine cliente pendant un
certain temps, alors qu'avec un REJECT, le ssh termine immédiatement.
Donc avec des DROP, l'attaquant peut donc faire moins de tentatives
s'il passe son temps à tomber sur des DROP (même s'il fait des ssh
en parallèle, le parallélisme a ses limites).


C'est vrai dans le principe, mais dans la pratique ça revient au  
même… Avec
la différence que ce dialogue établi entre le serveur et le bot  
semble avoir un

effet sur la persistance des attaques.

Le problème avec cette assertion, c'est qu'il faudrait installer un  
robot sur son
serveur pour se spammer soi-même afin de vérifier l'efficacité du  
DROP et du
REJECT, ça représente une charge de travail que je n'ai pas envie  
d'assumer.


Je suppose que les bots sont livrés à l'origine de telle façon qu'ils  
s'arrêtent au

moment où ils reçoivent un message ICMP. Ça me semble cohérent… mais je
ne peux pas le certifier !

Toujours est-il que j'observe de meilleurs résultats avec le REJECT !



[...]

Le fait d'avoir changé le DROP en REJECT m'a permis d'en décourager
beaucoup, en seulement quelques jours. Je suis en train de  
généraliser

l'option sur tous mes filtres.

Avec  le DROP quand tu lèves le ban, tu vois les mêmes IP  
réapparaître.


On a vraiment l'impression que les mecs ne récupèrent pas les données
de leurs bots, c'est n'importe quoi !


En même temps, cela permet de repérer les adresses IP en question.


Ouais, mais qu'est-ce que tu veux prendre comme mesures avec des IP  
situées
en Russie ou en Chine ? C'est comme si elles étaient sur la planète  
Mars !


Les gouvernements pourraient facilement limiter le spam et le  
piratage, avec les
fournisseurs d'accès nationaux. Mais comme il y a un gros bizness  
derrière c'est

complètement hors de question…


--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/ 
blog/

Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150216140954.ga27...@xvii.vinc17.org




--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2e33e366-60e1-4957-bfd7-b78af6760...@worldonline.fr

Re: [HS][up!] fail2ban

[BERTRAND Joël]

Philippe Gras a écrit :


Le 14 févr. 15 à 20:50, BERTRAND Joël a écrit :


Philippe Gras a écrit :

OKAAAYY !

Le 14 févr. 15 à 20:04, BERTRAND Joël a écrit :


Philippe Gras a écrit :

Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas
très bien
compris la façon dont ça se passe et pourquoi ça décourage
l'attaquant.


Parce que lorsque tu fais un DROP, l'attaquant ne sait pas si le
port est ouvert (et saturé) ou fermé, ou s'il y a même une machine sur
cette adresse. Il réessaye jusqu'à ce que quelqu'un lui réponde. Avec
un REJECT, tu dis immédiatement merdre à l'attaquant et il passe à
autre chose.

Cela fonctionne pour l'instant parce que les réseaux zombie
veulent passer inaperçus. Donc si une machine est un peu protégée, ils
passent à une autre.


Bon, j'ai pigé maintenant :-) Mais pour passer inaperçus, tu… repasseras
;-)


La boîte noire n'est jamais une solution quand on parle de sécurité.


La boîte noire ? Que veux-tu dire par-là ?


	Que faire croire qu'il n'y a aucune machine qui répond sur cette 
adresse IP n'est pas la solution. Rejeter le paquet signifie j'ai bien 
vu ta tentative et je t'emmerde.


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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54e07e23.70...@systella.fr

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 15 févr. 15 à 12:08, BERTRAND Joël a écrit :


Philippe Gras a écrit :


Le 14 févr. 15 à 20:50, BERTRAND Joël a écrit :


Philippe Gras a écrit :

OKAAAYY !

Le 14 févr. 15 à 20:04, BERTRAND Joël a écrit :


Philippe Gras a écrit :

Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas
très bien
compris la façon dont ça se passe et pourquoi ça décourage
l'attaquant.


Parce que lorsque tu fais un DROP, l'attaquant ne sait pas  
si le
port est ouvert (et saturé) ou fermé, ou s'il y a même une  
machine sur
cette adresse. Il réessaye jusqu'à ce que quelqu'un lui  
réponde. Avec

un REJECT, tu dis immédiatement merdre à l'attaquant et il passe à
autre chose.

Cela fonctionne pour l'instant parce que les réseaux zombie
veulent passer inaperçus. Donc si une machine est un peu  
protégée, ils

passent à une autre.


Bon, j'ai pigé maintenant :-) Mais pour passer inaperçus, tu…  
repasseras

;-)


La boîte noire n'est jamais une solution quand on parle de  
sécurité.


La boîte noire ? Que veux-tu dire par-là ?


	Que faire croire qu'il n'y a aucune machine qui répond sur cette  
adresse IP n'est pas la solution. Rejeter le paquet signifie j'ai  
bien vu ta tentative et je t'emmerde.


Oui, tu as 1.000.000 fois raison ! Il y a un module pour envoyer des  
réclamations abuse


dans fail2ban. J'aimerais bien l'activer aussi, mais je n'ai pas  
trouvé comment faire.


Quand elles aboutissent chez des gens sérieux perchant dans des pays  
sérieux, l'effet


rafraîchissant est garanti. Je reçois plein de pourriels de chez OVH  
en ce moment, et je


sais qu'en les dénonçant, ils vont cesser leur petit jeu débile.

Les mecs ont déjà usé 3 IP pour me faire ch… et je suppose qu'ils en  
ont d'autres. Si je


pouvais leur faire suspendre leur abonnement, ça me ferait bien  
plaisir :-).




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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54e07e23.70...@systella.fr



--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/711da1f0-3ce1-4e7e-8044-b6eaeec88...@worldonline.fr

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 2 févr. 15 à 15:48, BERTRAND Joël a écrit :


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...


Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas  
très bien

compris la façon dont ça se passe et pourquoi ça décourage l'attaquant.

Ph. Gras


Cordialement,

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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/44671fd3-4714-40d3-a00c-d4b378c03...@worldonline.fr

Re: [HS][up!] fail2ban

[BERTRAND Joël]

Philippe Gras a écrit :

Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas très bien
compris la façon dont ça se passe et pourquoi ça décourage l'attaquant.


	Parce que lorsque tu fais un DROP, l'attaquant ne sait pas si le port 
est ouvert (et saturé) ou fermé, ou s'il y a même une machine sur cette 
adresse. Il réessaye jusqu'à ce que quelqu'un lui réponde. Avec un 
REJECT, tu dis immédiatement merdre à l'attaquant et il passe à autre chose.


	Cela fonctionne pour l'instant parce que les réseaux zombie veulent 
passer inaperçus. Donc si une machine est un peu protégée, ils passent à 
une autre.


Cordialement,

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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54df9c4f.5040...@systella.fr

Re: [HS][up!] fail2ban

[Philippe Gras]

OKAAAYY !

Le 14 févr. 15 à 20:04, BERTRAND Joël a écrit :


Philippe Gras a écrit :
Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas  
très bien
compris la façon dont ça se passe et pourquoi ça décourage  
l'attaquant.


	Parce que lorsque tu fais un DROP, l'attaquant ne sait pas si le  
port est ouvert (et saturé) ou fermé, ou s'il y a même une machine  
sur cette adresse. Il réessaye jusqu'à ce que quelqu'un lui  
réponde. Avec un REJECT, tu dis immédiatement merdre à l'attaquant  
et il passe à autre chose.


	Cela fonctionne pour l'instant parce que les réseaux zombie  
veulent passer inaperçus. Donc si une machine est un peu protégée,  
ils passent à une autre.


Bon, j'ai pigé maintenant :-) Mais pour passer inaperçus, tu…  
repasseras ;-)


Cordialement,

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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54df9c4f.5040...@systella.fr



--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/b151b725-78bb-46f3-a579-2332bf78c...@worldonline.fr

Re: [HS][up!] fail2ban

[BERTRAND Joël]

Philippe Gras a écrit :

OKAAAYY !

Le 14 févr. 15 à 20:04, BERTRAND Joël a écrit :


Philippe Gras a écrit :

Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas
très bien
compris la façon dont ça se passe et pourquoi ça décourage l'attaquant.


Parce que lorsque tu fais un DROP, l'attaquant ne sait pas si le
port est ouvert (et saturé) ou fermé, ou s'il y a même une machine sur
cette adresse. Il réessaye jusqu'à ce que quelqu'un lui réponde. Avec
un REJECT, tu dis immédiatement merdre à l'attaquant et il passe à
autre chose.

Cela fonctionne pour l'instant parce que les réseaux zombie
veulent passer inaperçus. Donc si une machine est un peu protégée, ils
passent à une autre.


Bon, j'ai pigé maintenant :-) Mais pour passer inaperçus, tu… repasseras
;-)


La boîte noire n'est jamais une solution quand on parle de sécurité.

--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54dfa6ec.6060...@systella.fr

Re: [HS][up!] fail2ban

[Philippe Gras]

Le 14 févr. 15 à 20:50, BERTRAND Joël a écrit :


Philippe Gras a écrit :

OKAAAYY !

Le 14 févr. 15 à 20:04, BERTRAND Joël a écrit :


Philippe Gras a écrit :

Apparemment, ça a l'air super efficace :-) Par contre je n'ai pas
très bien
compris la façon dont ça se passe et pourquoi ça décourage  
l'attaquant.


Parce que lorsque tu fais un DROP, l'attaquant ne sait pas si le
port est ouvert (et saturé) ou fermé, ou s'il y a même une  
machine sur
cette adresse. Il réessaye jusqu'à ce que quelqu'un lui réponde.  
Avec

un REJECT, tu dis immédiatement merdre à l'attaquant et il passe à
autre chose.

Cela fonctionne pour l'instant parce que les réseaux zombie
veulent passer inaperçus. Donc si une machine est un peu  
protégée, ils

passent à une autre.


Bon, j'ai pigé maintenant :-) Mais pour passer inaperçus, tu…  
repasseras

;-)


La boîte noire n'est jamais une solution quand on parle de sécurité.


La boîte noire ? Que veux-tu dire par-là ?


--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54dfa6ec.6060...@systella.fr



--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/f17e761f-424d-4132-8b8c-384d32542...@worldonline.fr

Re: [fail2ban][Argh!] bidouiller les fichiers système

[Sébastien NOBILI]

Bonjour,

Le mardi 10 février 2015 à 23:45, Philippe Gras a écrit :
 Ma question, au fait ? Je redoute de modifier des trucs à l'arrache dans les
 fichiers système, alors je préfère demander…

Elle n'est pas très claire ta question…

Je suppose que tu veux savoir si c'est propre de modifier directement les
fichiers d'un paquet (par exemple sous « /usr »).

Non, ce n'est pas propre.

Maintenant, est-ce que c'est grave ?

Pas forcément.

Si ta modification n'entraîne pas de faille au niveau de la sécurité, alors ce
n'est pas dramatique de le faire.

Par contre, quand le paquet sera mis à jour, tu perdras ta modification (et il y
a de grandes chances que tu l'aies oubliée d'ici-là et que tu te trouves donc
avec un paquet qui ne fonctionne pas comme tu le voudrais sans bien comprendre
pourquoi).

Quelle solution plus propre ?

Télécharger le paquet source, patcher le code et regénérer le paquet avec tes
modifications.

Ça résout le problème de modification directe dans « /usr », mais pas le
problème de la mise-à-jour qui viendrait écraser tes modifications.

Pour résoudre le problème de la mise-à-jour, « apt-src » est une bonne réponse.

Seb

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150211092248.ga13...@sebian.nob900.homeip.net

Re: [fail2ban][Argh!] bidouiller les fichiers système

[Sébastien NOBILI]

Merci de ne pas me répondre directement, je suis abonné à la liste.

Le mercredi 11 février 2015 à 11:30, judith a écrit :
 Je vais parler tout les distrib que j'utilise.  mais dans le principe,
 ça reste identique. Pour installer Foremost, vous devez activer les
 dépôts Universe et entrer la ligne de commande suivante (ou passer par
 Synaptic) :

Universe ??? C'est de l'Ubuntu ça… Ici c'est Debian et chez Debian, « foremost »
est dans main, donc rien à faire d'autre que :

 apt-get install foremost

Seb

-- 
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150211104408.gc13...@sebian.nob900.homeip.net

Re: [fail2ban][Argh!] bidouiller les fichiers système

[Philippe Gras]

Le 11 févr. 15 à 11:44, Sébastien NOBILI a écrit :



Merci de ne pas me répondre directement, je suis abonné à la liste.

Le mercredi 11 février 2015 à 11:30, judith a écrit :
Je vais parler tout les distrib que j'utilise.  mais dans le  
principe,

ça reste identique. Pour installer Foremost, vous devez activer les
dépôts Universe et entrer la ligne de commande suivante (ou passer  
par

Synaptic) :


Universe ??? C'est de l'Ubuntu ça… Ici c'est Debian et chez Debian,  
« foremost »

est dans main, donc rien à faire d'autre que :


apt-get install foremost


J'avais fait apt-get install fail2ban. J'ai eu tort ?



Seb

--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150211104408.gc13...@sebian.nob900.homeip.net




--
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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/b7baa858-de73-4d02-b189-c1d2a7831...@worldonline.fr