Je suis nul. Je n’y comprends rien de rien
Est qu’il y aurait quelqu’un qui pourrait me sortir de ce merdier… contre rémunération ?
a ce stade là, j’aurais tendance à soupconné que le site a été l’objet d’un piratage à un moment avec un malware en arrière plan. Autrement dit ce ne serait pas SPIP en lui meme qui fait tourner le process, mais plutot un truc derrier
J’aurais donc tendance à préconiser d’utiliser spip-contrib-outils / spip_cleaner · GitLab OU BIEN si c’est trop compliqué d’utiliser pour toi ce script
- Sauvegarde de la BASE, du dossier IMG et du dossier plugins
- Effacement de tout SPIP
- Reinstallation
- Laisser pendant quelques temps voir si cela sature encore.
- Si pas le cas, finir la reinstallation
a. Reimport de la base
b. Reimport du dossier IMG par étape en n’y mettabt que les fichiers legitimes
c. Reinstallation des plugins depuis l’espace de SPIP
Pour vous cet identifiant signifie quelque chose ? c’est votre identifiant O2Switch ? (ça ressemble à un identifiant O2S)
Cette IP 167.71.55.227 (Digital Ocean Francfort) semble pas très clean non plus bien que dans votre cas on dirait que c’est elle la cible, je pencherai aussi pour un site piraté avec un malware qui tente d’établir une connexion à 167.71.55.227, cette IP étant signalée comme abusive, il n’est pas impossible que le malware tente une connexion avec une IP qui a entre temps été nettoyée, d’ou les échecs.
ChapGPT:
Ces appels systèmes montrent qu’un programme tente de se connecter à un serveur via une socket TCP/IP à l’adresse 167.71.55.227 sur le port 6667, mais la connexion est refusée. Ensuite, plusieurs tentatives d’opérations qui sont inappropriées pour une socket (comme ioctl et lseek) échouent logiquement.
Le fait que votre site fasse ce genre de tentative de connexion vers l’extérieur semble indiquer qu’il y a un programme qui essaye de faire ça et je ne pense pas que ce soit Spip …
Et l’analyse par ChaptGPT du log Spip est intéressante, vu qu’il ne sait pas que c’est Spip … je me demande s’il a tout juste, la conclusion donne des pistes mais je ne sais pas si ces erreurs Spip ont à voir avec les process évoqués par O2S, par essence le log Spip ne voit que ses propres erreurs et problèmes:
Ce journal semble provenir d’un serveur ou d’une application web (peut-être sous un système CMS comme SPIP, vu la structure des erreurs et des chemins de cache). Voici une analyse détaillée de chaque ligne :
2024-09-09 21:40:44 104.168.171.139 (pid 1839742) :Pub:!INFO: form ecrire_auteur:email_nobot rempli: sonic@busihelp.xyz
- Un utilisateur (probablement avec l’adresse IP 104.168.171.139) a rempli un formulaire (potentiellement un formulaire de contact ou d’inscription) où le champ d’email sonic@busihelp.xyz a été utilisé. Le préfixe
email_nobotpourrait indiquer une protection anti-bot (comme un captcha).
2024-09-09 23:14:53 35.91.190.215 (pid 2082813) :Pub:ERREUR: creation tmp/cache/calcul/60/
- Une erreur survient lors de la création du répertoire
tmp/cache/calcul/60/, nécessaire pour le système de cache. L’adresse IP associée à cette action est 35.91.190.215. Cela pourrait être causé par des permissions incorrectes sur le dossier ou un problème de capacité du serveur.
2024-09-09 23:14:55 109.234.160.100 (pid 2082817) :Pub:!INFO: Collision avec le paquet <spip-contrib-extensions/territoires_stat-c5e87-territoires_stat-1.1.0.zip / Connexion · GitLab 1> du depot <11>
- Un message d’information indique une collision avec un paquet lors d’une tentative de gestion de l’extension territoires_stat (probablement une extension SPIP). La collision pourrait signifier que plusieurs processus essaient de manipuler ce fichier simultanément, ou qu’il y a un conflit de version dans le dépôt GitLab.
2024-09-10 01:54:42 20.120.134.35 (pid 2609915) :Pub:ERREUR: creation tmp/cache/calcul/b5/
- Nouvelle erreur liée à la création d’un dossier cache, ici
tmp/cache/calcul/b5/, associée à l’adresse IP 20.120.134.35. Cela peut aussi être un problème de droits ou de disponibilité du stockage.
2024-09-10 02:29:36 104.247.184.230 (pid 2724568) :Pub:ERREUR: creation tmp/cache/calcul/db/
- Erreur similaire avec un autre dossier cache
db/pour l’IP 104.247.184.230.
2024-09-10 02:29:37 104.247.184.230 (pid 2724568) :Pub:ERREUR: creation tmp/cache/calcul/aa/
- Encore une erreur pour la création d’un répertoire cache
aa/.
2024-09-10 02:29:37 104.247.184.230 (pid 2724584) :Pub:ERREUR: creation tmp/cache/calcul/c3/
- Nouvelle erreur sur le cache
c3/.
2024-09-10 02:29:38 104.247.184.230 (pid 2724635) :Pub:ERREUR: creation tmp/cache/calcul/13/
- Erreur cache sur
13/.
2024-09-10 02:29:38 104.247.184.230 (pid 2724635) :Pub:ERREUR: creation tmp/cache/calcul/98/
- Erreur cache sur
98/.
2024-09-10 02:38:10 104.248.83.242 (pid 2752540) :Pub:ERREUR: queue_close_job car _JQ_PENDING depuis +180s : Array
- Ce message d’erreur signale un problème avec une file d’attente de tâches (
queue_close_job) qui n’a pas été traitée depuis plus de 180 secondes. Cela pourrait indiquer un blocage dans l’exécution d’une tâche ou un problème de gestion des files d’attente.
Résumé :
Le journal montre des problèmes récurrents avec la création de répertoires de cache, probablement dus à des permissions incorrectes, un manque de place ou des problèmes de configuration du serveur. Il y a aussi un conflit lié à une extension SPIP, ainsi qu’un souci avec la file d’attente de tâches. Il serait recommandé de vérifier les droits d’accès aux dossiers de cache et la configuration des extensions.
Je repose la question, et demande aussi à ton hébergeur de vérifier que la machine est saine.
J’ai eu le cas sur un serveur cet après midi :
- les mêmes
connect(3, {sa_family=AF_INET, sin_port=htons(6667), sin_addr=inet_addr(« 167.71.55.227 »)}, 16) = -1 ECONNREFUSED (Connection refused)lancées par/usr/sbin/client - le site de l’user concerné était propre (pas de trace de rootkit ou de fichiers malicieux)
- une analyse avec clamav a remonté des fichiers pas propres dans
/dev/shmcf
/dev/shm/.ICE-Unix/.dev/libprocesshider.so: Unix.Malware.Libprocesshider-10030016-0 FOUND
/dev/shm/.ICE-Unix/.dev/crond: Multios.Coinminer.Miner-6781728-2 FOUND
/dev/shm/.ICE-Unix/dev.jpg.2: Multios.Coinminer.Miner-6781728-2 FOUND
/dev/shm/.ICE-Unix/dev.jpg.1: Multios.Coinminer.Miner-6781728-2 FOUND
/dev/shm/.ICE-Unix/dev.jpg: Multios.Coinminer.Miner-6781728-2 FOUND
Après nettoyage des fichiers infectés et kill des process /usr/sbin/client pour l’user concerné, je n’en ai plus observé depuis.
Bref, il faut demander à ton hébergeur de faire son travail d’analyse sur la machine qui héberge ton site 
Je n’ai rien pu faire mais ce matin, miracle, le site remarche ! Jusqu’à quand ? Mystère…
Message de o2swish : « Votre hébergement contient un CMS SPIP.
Ce dernier rencontre actuellement beaucoup de soucis sur des génération de process en boucle.
Je vous invite à contacter SPIP à ce sujet. »
C’est vrai ça ?
À notre connaissance, non, mais ton hébergeur pourra certainement nous en dire plus et s’il a observé ça sur plusieurs SPIP afin qu’on investigue sur la question.
167.71.55.227 quelqu’un sait si c’est une IP interne de SPIP ?
Nope, à ma connaissance on n’a rien chez DigitalOcean, et cette IP semble bien douteuse d’après ce lien LevelBlue - Open Threat Exchange
Bonjour,
Souci similaire, chez o2Switch.
Réponse de l’hébergeur :
Bonjour,
En complément de la réponse de mon collègue.
Vos processus liés à SPIP s’accumulent en boucle jusqu’à atteindre saturation complète de l’hébergement.
Une fois saturé, les processus PHP ne peuvent plus fonctionner, c’est pour cela que votre phpinfo ne répond pas.
Voici les processus en question :
2922970 20 0 31440 6892 2260 S 0,0 0,0 0:16.89 /usr/sbin/client
2922974 20 0 31336 6892 2256 S 0,0 0,0 0:17.95 /usr/sbin/client
2925066 20 0 31332 6968 2340 S 0,0 0,0 0:18.07 /usr/sbin/client
2925070 20 0 31368 6948 2328 S 0,0 0,0 0:18.35 /usr/sbin/client
2927787 20 0 31440 6728 2096 S 0,0 0,0 0:18.22 /usr/sbin/client
2927791 20 0 31336 6892 2256 S 0,0 0,0 0:18.30 /usr/sbin/client
2928095 20 0 31332 6840 2212 S 0,0 0,0 0:17.85 /usr/sbin/client
2928098 20 0 31340 6852 2212 S 0,0 0,0 0:18.90 /usr/sbin/client
2931840 20 0 31444 6788 2148 S 0,0 0,0 0:18.36 /usr/sbin/client
2931845 20 0 31336 6700 2084 S 0,0 0,0 0:17.36 /usr/sbin/client
2945441 20 0 31332 6840 2216 S 0,0 0,0 0:17.87 /usr/sbin/client
2945444 20 0 31332 6840 2220 S 0,0 0,0 0:18.42 /usr/sbin/client
2945470 20 0 31444 6760 2128 S 0,0 0,0 0:17.83 /usr/sbin/client
2945473 20 0 31440 6984 2348 S 0,0 0,0 0:16.65 /usr/sbin/client
3448324 20 0 31336 6980 2348 S 0,0 0,0 0:14.92 /usr/sbin/client
3448327 20 0 31336 6844 2212 S 0,0 0,0 0:14.73 /usr/sbin/client
3451119 20 0 31444 6680 2044 S 0,0 0,0 0:14.97 /usr/sbin/client
Je peux les kill, mais ils reviennent systématiquement.
Lorsque je fais un strace d’un des processus voici ce que j’ai :
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
ioctl(3, TCGETS, 0x7ffee8084cc0) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ioctl(3, TCGETS, 0x7ffee8084cc0) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(6667), sin_addr=inet_addr(« 167.71.55.227 »)}, 16) = -1 ECONNREFUSED (Connection refused)
close(3)
SPIP semble faire une requête vers un serveur externe ayant comme IP 167.71.55.227.
IP qui semble provenir de Digital Ocean lorsque l’on regarde le Whois : Whois Lookup Captcha
Il faudrait voir avec SPIP si cela leur parle directement.
Oui, je leur ai envoyé le lien vers ton message.
Merci
Réponse de l’hébergeur :
Oui nous sommes au courant et nous avons été contacté par plusieurs personnes utilisant SPIP et ayant exactement le même problème que vous.
Non, je n’ai rien en global sur le serveur, les autres comptes d’hébergement n’utilisant pas SPIP n’ont aucun problème et aucun process de ce type de lancé.
C’est uniquement lié aux comptes d’hébergement utilisant le CMS SPIP.
Il doit y avoir une faille / quelque chose au sein de SPIP qui génère ces processus malheureusement.
A notre niveau, difficile d’avoir plus d’éléments.
En regardant le détail des processus, la seule chose que je vois est l’IP que je vous ai fourni.
J’ai également dans le doute vérifié comme le post forum dans /dev/shm et je n’ai aucun processus du même type de mon côté.
À propos de O2Switch, j’avais envisagé basculer chez eux mes sites hébergés chez gandi, car depuis son rachat, les prix ont augmenté et surtout les prestations fournies par Gandi ont été diminuées (disparition des emails inclus par exemple, pas cool).
Mais O2Switch a été également racheté, et par la même boîte que Gandi (TWS) cf https://www.opportunites-digitales.com/le-groupe-tws-acquiert-le-fournisseur-francais-dhebergement-web-o2switch
Il m’a donc semblé assez probable que les nouveaux propriétaires de O2Switch appliquent prochainement la même politique de rentabilisation max de leur investissement et que les prix augmentent et que les prestations fournies diminuent…
Apparamment ça ne s’est pas passé que pour Gandi, mais aussi pour d’autres services hébergeurs acheté par TWS (cf Gandi fusionne avec Total Webhosting Solutions (TWS) qui devient Your.Online, et cela inquiète - Next )
Attention donc !
Merci pour cette info JLuc, je ne savais pas.
Du coup, je m’adresse ici aux développeurs de Spip, quelle solution avons-nous concernant le problème évoqué dans ce fil ? Comment trouver l’origine de ce problème ?
Avez-vous des pistes ?
S’il faut ajouter un fichier pour test, dites-le moi, je le mettrai en place chez o2switch.
J’ai deux sites Spip chez eux et les deux ont déjà été touchés (simultanément par le passé, et ce jour un seul sur les deux).
moi ce qui m’étonne c’est que personne n’a de problème sur ca en dehors de o2switch… mais je ne sais vraiment pas comment tracer ce genre de chose
Je suis d’accord, je viens d’ailleurs de leur écrire que sur la douzaine de sites Spip que j’ai réalisée, seuls les deux hébergés chez eux sont concernés.
Une hypothèse sinon pourrait provenir d’une faille dans Spip mais qui ne serait exploitable que chez eux.
Ou bien les autres hébergeurs bloquent ces requêtes externes préservant les ressources et invisibilisant le problème (mes autres sites sont chez Nuxit ou OVH).
Une autre idée, la version de PHP. Je suis ici en 7.4.33. Je vais passer sur la branche 8. Mais chez les autres hébergeurs, la plupart sont également sur la branche 7.
Même problème par ici, seulement sur les SPIP hébergés chez O2s
Tout semblable à vos posts, IP suspecte aussi. J’ai beau tout cleaner de mon côté ! Ca ne fonctionne qu’après avoir KILL les process et rapidement c’est de nouveau saturé (24 à 48h).
Un test à faire serait de déplacer ce site vers un autre hébergeur ou même simplement une autre instance de O2S pour voir si le problème déménage avec le site ou s’il reste sur l’instance concernée …
Mais ça c’est pas forcément simple avec O2S, il n’y a pas de moyen simple de migrer un domaine d’une instance à une autre surtout si il y a du mail avec, en gros il faut sauvegarder, détruire, puis re-créer sur une autre instance. Perso c’est ce qui fait que je sépare « mail » de « site » et que je migre peu à peu tous les sites que j’avais chez eux vers mes serveurs (entre mes serveurs migrer un site c’est en gros 2 clics et 2 infos à saisir, en général pas plus de 5 à 10 min, plus le DNS bien sûr).