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

Rétroéclairage qui se rallume à chaque démarrage

[Jérémy Prego]

Bonjour,

Je suis sous Debian testing à jour, avec un del G5 15 5587 qui dispose 
d'un clavier Rétroéclairé. Le problème que je rencontre, c'est que ce 
maudit rétroéclairage ce rallume à chaque démarrage, même si je le 
désactive jusqu'à dans l'UEFI.


J'aimerai trouver une solution pour me débarrasser définitivement de ce 
rétroéclairage et ne plus qu'il se rallume à tout bout de champ, et 
surtout que linux respecte le choix que j'ai mis dans le bios. si ça 
peut aider, j'utilise mate comme bureau avec lightdm comme gestionnaire 
de session.


Pour info, actuellement j'utilise des "hacks" pour l'éteindre,  mais si 
on pouvais corriger le problème à la source, ça m'arrangerai  :)


merci pour vos suggestions, si vous en avez

Jerem

Re : Re: Re : Re: Re : Re : Re : Re : FFMPEG ?

[benoit]

Le vendredi 1 septembre 2023 à 09:00, ptilou  a écrit :


> Le samedi 19 août 2023 à 17:30:03 UTC+2, benoit a écrit :
>
> > Petite astuce, pour cataloguer digikam ou darktable est super, mais si on 
> > veux juste visionner des RAW au format fermé de Nikon (NEF) avec une 
> > visionneuse libre, légère et rapide, geeqie fait très bien le taf.
> > https://packages.debian.org/bookworm/geeqie
> >
> > --
> > Benoît
> >
> > Envoyé avec la messagerie sécurisée Proton Mail.
> >
> > --- Original Message ---
> > Le vendredi 18 août 2023 à 15:21, Norbert Ponce norber...@wanadoo.fr a 
> > écrit :
> >
> > > Lorsque je recherche ufraw sur synaptic il me sélectionne darktable, et
> > > quand je tente d'ouvrir un raw nikon dans gimp, celui-ci me demande
> > > d'installer darktable.
> > > Donc le remplacement est acté. Je suis encore en Bullseye.
> > >
> > > Le 17/08/2023 à 07:14, nicolas...@gmail.com a écrit :
> > >
> > > > On 16/08/2023 21:20:41, didier gaumet wrote:
> > > >
> > > > > tu ne dois pas avoir nettoyé ton cache depuis au moins quatre ans ;-)
> > > > > ufraw a bien été retiré de testing et unstable il y a quatre ans:
> > > > > https://tracker.debian.org/pkg/ufraw
> > > > > Il est installé et comme il est en conflit avec personne, il est 
> > > > > toujours là.
> > > > > C’est pour ça.
> > > >
> > > > nicolas patrois : pts noir asocial
>
>
> Il n'y a pas d'avantage a utiliser le format RAW, sauf a achete des mass 
> storages !

Sauf si on veut fait du post-traitement non destructif, sur une image venant 
d'un capteur d'appareil photo.

Benoît

Re: [HS] Depuis la canicule le BIOS me tarabuste : résolu (du moins pour l'instant)

[plapla]

Le 07/09/2023 à 11:57, ajh-valmer a écrit :

On Wednesday 06 September 2023 18:25:50 mauriceplapla wrote:

Le 06/09/2023 à 18:02, ajh-valmer a écrit :
Depuis les grosses chaleurs, 



d'après la principale fonction de cette pile, qui est de garder l'heure
de la machine, en cas d'éteignage (oui je sais: néologisme!) 



en cas d'éteignage :

Pourquoi ce néologisme ? : en cas d'extinction :-)
Oui toutes mes confuses, je n'ai pas retrouvé le mot en écrivant ma 
réponse !

Accessoirement je poste avec le pseudo à moi que j'ai sur la liste ! ;)
Je suis étonné que mon précédent post soit passé...


Je pense que c'est la pile qui s'est déchargée pendant mon absence,
avec la chaleur.
En redémarrant, en reconfigurant le BIOS, date, heure, reconnaissance
des disques, le boot  ne m'affiche plus d'erreurs, du moins pour l'instant...
Si c'est la pile qui est déchargée, elle ne va pas tarder à redéconner, 
enfin les paramètres risquent de sauter à la prochaine extinction. Sur 
un reboot sans éteindre ça tiendra peut-être, mais il vaut mieux la 
changer, ça se trouve facilement, si c'est le même modèle que je vois 
sur des tours. Sur des (certains) portables, elle est souvent emballée 
dans un plastique thermomoulé, avec des fois les électrodes du câble du 
connecteur soudées sur la pile, un peu plus compliqué, mais faisable.


Bonne journée.


Cordialement.

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: [HS] Depuis la canicule le BIOS me tarabuste

[ajh-valmer]

On Wednesday 06 September 2023 19:31:32 Haricophile wrote:
> Le Wed, 6 Sep 2023 18:25:50 +0200,
> mauriceplapla  a écrit :
> Quand on a un bios UEFI, il faut parfois configurer sur quoi on boot
> (Debian). Je suis trop nul pour savoir de mémoire à quoi correspond
> Ctrl+i
C'est 

J'ai mis le bios en mode "legacy",
ça ne semble pas poser de problèmes.

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: [HS] Depuis la canicule le BIOS me tarabuste : résolu (du moins pour l'instant)

[ajh-valmer]

On Wednesday 06 September 2023 18:25:50 mauriceplapla wrote:
> Le 06/09/2023 à 18:02, ajh-valmer a écrit :
> > Depuis les grosses chaleurs, lorsque je boote mon ordinateur,
> > je tombe sur une demande du BIOS me demandant de faire ,
> > alors le menu GRUB apparait.
> > Avant, non, le menu GRUB apparaissait immédiatement.
> > S'agit-il de la pile ronde électrique qui supporte mal la chaleur ?

> d'après la principale fonction de cette pile, qui est de garder l'heure 
> de la machine, en cas d'éteignage (oui je sais: néologisme!) il faudrait 
> savoir si le BIOS t'en dit plus pour être sûr de bien cerner le problème.
> Sinon c'est une autre histoire, je laisse des gens compétents donner 
> leur avis.  mes 0.02€

> en cas d'éteignage :
Pourquoi ce néologisme ? : en cas d'extinction :-)

Je pense que c'est la pile qui s'est déchargée pendant mon absence,
avec la chaleur.
En redémarrant, en reconfigurant le BIOS, date, heure, reconnaissance
des disques, le boot  ne m'affiche plus d'erreurs, du moins pour l'instant...

Bonne journée.

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]

J'arrive à reproduire avec des IP OVH, mais pas avec des IP Scaleway. Ca
sent le filtrage côté OVH.

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

> └─# 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)
 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 

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

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