Re: [HS] Depuis la canicule le BIOS me tarabuste
Le Wed, 6 Sep 2023 18:25:50 +0200, mauriceplapla a écrit : > > Hello à tous, > > > > 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 ? > > > > Merci. Les réaction chimiques sont plus réactives à la chaleur, ça accélère l'auto-décharge, mais parfois les piles se déchargent quand on les utilise... Sinon pour info, quand on manipule les piles boutons non encapsulées, c'est bon de ne pas utiliser les doigts, la sueur est acide et peut causer des mauvais contacts avec le temps. On peut généraliser ça à tous les contacts. L'été il y a aussi parfois des orages, et les «pêches» sur le réseau électrique peuvent avoir une influence et induire des erreurs. Vérifie les paramètres et sauve les. 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 > Salut, > 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€ C'est facile de vérifier si l'horloge reste à l'heure ou se remet au réglage épochien d'usine. Je ne sais pas si les 2c sont mérités, en plus je fais mes transactions en bon choco. Amicalement
Re: [HS] Depuis la canicule le BIOS me tarabuste
Le 06/09/2023 à 18:02, ajh-valmer a écrit : Hello à tous, 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 ? Merci. Salut, 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€
Re: Debian 12 - Blocage IPv4 sans fail2ban & co
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.
[HS] Depuis la canicule le BIOS me tarabuste
Hello à tous, 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 ? Merci.
Re: Debian 12 - Blocage IPv4 sans fail2ban & co
> > 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
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
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
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
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
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
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
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
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
