Beau scan de vulnérabilité

Aujourd'hui un "pirate" a battu le score précédent (#1400 hits) avec 1667 hits.
Une panoplie complète des "chaînes d'URL" les plus recherchées :

  • 616 hits contenant la chaine ".env" !
  • 280 hits contenant la chaiîne "config"
  • 142 hits contenant la chaîne ".php"
  • 68 hits contenant la chaîne "secret"
  • 41 hits contenant la chaîne "credential"
  • 40 hits contenant la chaine "wp-"
  • 36 hits contenant la chaîne ".git"
  • 30 hits contenant la chaine ".sql"

Et pas mal d'autres "trucs" moins connus ...


 

Changement de box internet

Aujourd'hui j'ai changé ma vieille "box", qui avait déja quelques années, pour le "dernier cri" et en la paramétrant j'ai d'abord complètement "zappé" la création d'une "DMZ", ce qui a "coupé" l'accès à ce site !
C'est ici la machine à la quelle doivent être envoyées les communication entrantes sur l'adresse fournie par le FAI.
Je ne me suis rendu compte de cet "oubli" qu'en examinant les statistiques de ce site qui marquaient un "stop" complet à une certaine heure ... il m'a fallu plusieurs minutes pour me souvenir de ce nécessaire paramétrage de DMZ.
Comme quoi on ne pense pas toujours à tout ...

Par contre les téléphones se sont connectés sans aucune difficulté (Iphone 7,13 et 15).

Une autre surprise : j'ai une petite station météo, qui date de quelques années, consultable sur Internet connectée au WIFI mais, impossible à connecter car le mot de passe réseau est toujours refusé. J'ai tenté plusieurs "bricolages" sans aucun succès ...

Il semble que les appareils anciens peuvent avoir du mal à se connecter au nouveau système s'il ne disposent que de la bande 2.4GHz ce qui semble être le cas de ma petite météo personelle ... mais la console semble permettre de "suspendre" la bande 5GHz pour 5 minutes ce qui devrait permettre à ce device récalcitrant de se connecter ... à auivre.

Par contre la partie WI-FI de la box semble bien plus rapide que ma "vieille" box, depuis mon portable le téléchargement des mises à jour de Debian s'effectue à nettement plus de 20Mo/seconde alors qu'avec l'ancienne box c'était de 10 à 15 Mo/seconde.

Origine scans : sous reseaux

J'enregistre depuis le 25 janvier 2025 dans une petite base tous les "méchants" qui font des scans de ports, au moins 4 ports bloqués sur une journée, et après quelques temps j'ai eu envie de voir un peu le contenu de cette table qui contient (juin 2026) à peine moins de 6000 rangs.

Ma première envie a été de voir la répartition de ces méchants scanneurs sur le réseau, ici je suis descendu aux réseaux /24 et voici le premier résultat pour les sous_réseaux /24 qui contiennent au moins 50 scanneurs.

+----------------------------------------+----------+
| 69.5.169.*                             |      248 |
| 198.235.24.*                           |      181 |
| 147.185.132.*                          |      151 |
| 205.210.31.*                           |      147 |
| 193.163.125.*                          |      145 |
| 162.216.150.*                          |       94 |
| 35.203.210.*                           |       89 |
| 147.185.133.*                          |       87 |
| 162.216.149.*                          |       82 |
| 35.203.211.*                           |       82 |
| 66.132.172.*                           |       74 |
| 216.25.89.*                            |       70 |
| 66.132.186.*                           |       67 |
| 162.142.125.*                          |       66 |
| 193.176.31.*                           |       60 |
| 81.19.216.*                            |       56 |
| 185.223.235.*                          |       55 |
| 31.14.254.*                            |       55 |
| 89.21.67.*                             |       54 |
| 5.226.140.*                            |       53 |
| 85.217.140.*                           |       53 |
| 167.94.138.*                           |       53 |
+----------------------------------------+----------+
Pas mal pour le premier qui remplit, sur ma modeste machine, plus de 97% de son sous-réseau, mais c'est un groupe de recherches sur Internet ...
Le deuxième, le troisième et le quatrième appartiennent à Paloaltonetworks qui est un groupe de services sur internet ...
Tous ne sont donc pas de vrais "méchants" ?
Pourr le cinquième la plupart des adresses sont affublées de scores importants sur AbuseIPDB.com, ce sont donc probablement réellement de vilains méchants, "So they really are nasty villains." pour les anglophones, bien que certains autres subnets semblent aussi appartenir à des entités qui effectuent des recherches ou commercialisent des solutions de sécurité ...

 

Sauvegarde d'une base Clickhouse

Il est important de sauvegarder une base de données ! 
Clickhouse est, là aussi, un peu spé&cial par rapport à d'autres bases, il faut :

  • Créer un fichier descriptif de l'espace disque à utiliser et l'autoriser.
    Ici ce fichier est créé sur un disque externe "monté à la demande" sur /BAIES/NVMX dans lequel un répertoire SV_CLICK est créé avec autrisation d'écriture pour le user "clickhouse".
cd /BAIES/NVMX
ls -al SV_CLICK
drwxrwxr--  3 jpp  clickhouse  4096 mai   31 13:03 SV_CLICK

Le fichier descriptif est ici construit comme suit :

<clickhouse>
    <storage_configuration>
        <disks>
            <backups>
                <type>local</type>
		<path>/BAIES/NVMX/SV_CLICK/</path>
            </backups>
        </disks>
    </storage_configuration>
    <backups>
        <allowed_disk>backups</allowed_disk>
	<allowed_path>/BAIES/NVMX/SV_CLICK/</allowed_path>
    </backups>
</clickhouse>

Il faut ensuite, bien sûr, redémarrer Clickhouse pour activer ces paramètres.

  • Pour effectuer le backup de la base entière il suffit alors de l'ordre "SQL" suivant :
BACKUP DATABASE local_ntopng TO Disk('backups','SV_local');

L'exécution de cet ordre crée un repertoire SV_local dans le répertoire de backup et y effectue la sauvegarde de la base, le résultat est contenu dans la strucrute de fichiers suivante :

drwxr-x--- 4 clickhouse clickhouse   4096 mai   31 13:04 .
drwxrwxr-- 3 jpp        clickhouse   4096 mai   31 13:03 ..
-rw-r----- 1 clickhouse clickhouse 268752 mai   31 13:04 .backup
drwxr-x--- 3 clickhouse clickhouse   4096 mai   31 13:03 data
drwxr-x--- 3 clickhouse clickhouse   4096 mai   31 13:03 metadata

Les données sont contenues dans le répertoire "data" avec un répertoire par table et une structure de fichiers extrêmement complexe ...

 

Linux 7.0

Ca y est, la version 7 de Linux est disponible sur Debian, d'abord la 7.0.4 puis la 7.0.7.
J'ai commencé par installer la 7.0.4 sur un portable qui a déjà quelques années mais 8 threads et 16Go de mémoire ... Cà fonctionne parfaitement, le passage en 7.0.7 est déjà fait et la machine tourne très bien, y compris la video.

Un autre essai sur une machine virtuelle (après une bonne sauvegarde de la MV) le passage en 7.0.4 n'a révélé aucun problème et cette MV fonctionne bien, d'ailleurs c'est celle sur laquelle "tourne" ce site.
Le passage d'un "petit" PC (core I5 5ème génération avec video Intel Iris) n'a posé aucun problème et la machine fonctionne très bien et madame est parfaitement satisfaite..

Après ces premiers tests je viens de passer ces deux machines en 7.0.9 ...puis 7.0.10  et tout a l'air de se passer très bien, aucune plainte ! Et maintenant le 7.0.12, puis 7.0.13 qui sont passés ... comme une lettre à la poste.

Par contre j'ai un problème avec une autre machine (core I7 6éme génération + Nvidia GK710) car les pilotes propriétaires refusent de compiler avec des versions supérieures à 6.12.57, Nvidia n'assure pas le support des pilotes "anciens" et délaisse Linux, voir ici.

Il va falloir que je change de carte video si je veux suivre les versions de Linux avec cette machine ...

Si quelqu'un connaît une carte video simple qui fonctionne avec les drivers standards de Linux, 6 et 7 je suis intéressé et prêt à recevoir votre message !

 

Nvidia : plus de support Linux

J'utilise des cartes vidéo Nvidia depuis très longtemps mais les dernières versions des drivers ne compilent plus pour des Kernels > 6.12.57 sur mes machines Debian. J'ai donc envoyé un message au support technique. Ils m'ont répondu très gentiment qu'ils n'assuraient pas de suppport technique pour Linux ... ci dessous copie de leur courrier.

Bonjour Jean-Paul, 
  
Merci d'avoir contacté le service clientèle NVIDIA. Mon nom est Raluca et je suis ici 
pour vous porter assistance. 

Merci d'avoir porté à notre attention les difficultés que vous rencontrez, 
mais rassurez-vous, on est là pour vous aider.

Nous vous informons que nous n’assurons pas de support technique pour
 les environnements Linux. De ce fait, nous ne sommes malheureusement 
 pas en mesure de vous accompagner sur cette problématique.

Nous vous invitons à consulter le forum suivant, où vous pourrez trouver 
des informations complémentaires ainsi que des échanges avec la communauté 
susceptible de vous aider:

https://forums.developer.nvidia.com/c/gpu-graphics/linux/148

Merci pour votre compréhension et patience.  
  
Je vous souhaite une bonne journée! 

Cordialement, 
Raluca
Service Clientèle NVIDIA

Je vais, bien sûr, essayer le forum et surtout me tourner vers AMD bien qu'il ne fournissent pas de drivers pour Debain mais seulement pour RHEL et Ubuntu.

Gros scanneur

Aujourd'hui l'analyse des scans de ports m'a donné un nouveau record sur une journée :

23339 ports scannés entre 10:30 et 12:47 soit environ 170 ports par minute et plus de 1/3 des ports existants, par l'IP 45.142.193.185 basée en Hollande.

Le précédent record était d'environ 16000 seulement !

 

 

 

Redis-server blocage programme utilisateur

Janvier 2026.
J'ai rencontré un petit problème lors de l'éxécution d'un couple de programmes en Python dont l'un "passe" des données à l'autre par l'intermédiaire de "redis". Le problème était un arrêt intempestif du programme recevant les données ce qui entrainait le blocage du programme émetteur.
Après analyse des logs j'ai trouvé des messages d'erreur dans redis.log conseillant d'ajouter :

"vm.overcommit_memory = 1"

dans /etc/sysctl.d en donnant en référence : https://github.com/jemalloc/jemalloc/issues/1328 mais cette page est devenue inaccessible ...

J'ai donc ajouté "vm.overcommit_memory = 1" dans un fichier /etc/sysctl.d/redis.conf et après un petit coup de :
 "sysctl --load=redis.conf

et redémarré redis ... depuis mes deux programmes fonctionnent normalement.

Et ... cela n'a pas duré et j'ai toujours des plantages "aléatoires" lors de l'exécution, sans solution pour l'instant alors que sur une autre machine tout fonctionne normalement ... et je ne vois aucune différence entre les versions des programmes, aussi bien Python que Redis.

Mars 2026.
Après quelques temps il n'y a plus de blocage "aléatoire" et tout semble tourner rond ...

Sécurité disques RAID 1 (miroir)

Après avoir fait un petit voyage à Taïwan et en Corée pour les fêtes de fin d'année je suis quand même revenu …

Et j’ai redémarré mes machines qui ont bénéficié de plus de 3 semaines de repos, mais sur trois machines à la maison une seule a redémarré correctement, celle de madame, mais le pont vers Internet étant HS elle ne permettait pas grand-chose d’utile.
La machine qui sert de pont vers Internet, et qui héberge ce site, a refusé obstinément de démarrer.
En démarrant sur une clef USB j’ai pu constater des dégâts importants : sur 4 disques 2 étaient HS, en principe ces disques sont montés deux par deux en miroir ce qui jusqu’ici m’avait toujours permis de récupérer les données sur le disque « survivant ». Le système, lui aussi sur des disques en miroir (2 x NVME de 1To), n’avait absolument pas souffert et les volumes LVM contenant des machines virtuelles étaient accessibles.
Mais là, les disques « survivants » s’il étaient lisibles ne disposaient pas de la totalité des données, sur une base de données suivie depuis presque 10 ans je n’ai récupéré que les années de 2016 à 2018 ! Le disque qui contenait les sauvegardes était carrément illisible !
J’ai donc du monter de nouveaux disques, recréer les bases de données et les fichiers annexes mais certaines sauvegardes ne se sont pas restaurées complètement et quelques databases MariaDB étaient très incomplètes … et j’ai du les reconstituer en partie à partir de copies faites sur une autre machine pour tester Clickhouse. Cela prend beaucoup de temps mais j’ai fini par remettre le tout en état mais avec une perte d’une partie de l’historique des archives issues de Apache/modsec ou des archives de Suricata.

Au niveau de la base de données elle-même un certain nombre d’utilisateurs étaient absents ou incomplets … je n’arrive pas à comprendre ce phénomène.

J’ai tout de suite commencé la mise en place de sauvegardes des bases de données avec recopie immédiate sur un autre système afin de prendre moins de risques sur les historiques.

Une autre machine avait perdu sa configuration, suspectant un problème avec la pile de maintien j’ai laissé la machine branchée et elle a démarré gentiment le lendemain et fonctionne fort bien, c’est elle qui conservait la copie de certaines données dans une base Clickhouse.

En ce qui concerne les disques « en miroir » j’avais toujours pu récupérer les données sur le disque survivant, même en milieu professionnel. La seule différence ici que j’ai utilisé LVM, le Physical Volume est déclaré sur le miroir et les partitions ne sont pas physiques comme « autrefois » mais juste des Logical Volumes … il va falloir que je réalise quelques tests de reprise en l’absence d’un disque.

openai robot curieux

Aujourd'hui en analysant les logs de Apache j'ai trouvé un robot OpenAI marquant comme "Referer" https://community.letsencrypt.org et tentant d'accéder à l'Url "/.well-known/acme-challenge/6iKOg35diTyM8rvagvtu3dzO_i1gu75DvMF75dMoC50".

Ce robot chercherait-il à récupérer des informations sur le certificat correspondant ?

Par défaut j'ai bloqué ce type de comportement.