504 Délai d'attente de la passerelle

Général
, , ,
#21

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/shm cf
/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 :slight_smile:

#22

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 ?

#23

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

#24

167.71.55.227 quelqu’un sait si c’est une IP interne de SPIP ?

#25

Nope, à ma connaissance on n’a rien chez DigitalOcean, et cette IP semble bien douteuse d’après ce lien LevelBlue - Open Threat Exchange

#26

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.

#27

Voir mon message plus haut ↑ 504 Délai d'attente de la passerelle - #21 par b_b

#28

Oui, je leur ai envoyé le lien vers ton message.

Merci

#29

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

#30

À 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 !

#31

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

#32

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

#33

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.

#34

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

#35

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

#36

Nous avons donc tous ce problème chez O2switch et donc Cpanel visiblement ?
Personne d’autre sous Cpanel, hors O2switch ?

C’est très étrange car cela se produit donc sur plusieurs serveurs différents chez O2. Une faille couplée Cpanel / SPIP serait visible ailleurs que chez O2 ! D’autres hébergeurs utilisent Cpanel !

Pour les fichiers à chercher dans /dev/shm , O2 a regardé et rien côté serveur en global.

Donc : SPIP / O2switch / Cpanel / même effet de saturation des processus (même messages) / même IP incriminée 167.71.55.227 (??)

#37

J’apporte quelques précisions à ce que je disais plus haut. Pour le contexte, j’ai eu à gérer le problème dans le cadre de mon activité bénévole chez un hébergeur associatif.

Chez nous, certains SPIP pas à jour ont servi de vecteur pour déposer des rootkits sur l’espace de l’adhérent⋅e concerné⋅e. Une fois le rootkit en place, tout est possible : dépôt de fichier, lancement de commandes avec l’user du compte concernée, etc. Ainsi, il est possible que l’attaquant⋅e pose de quoi lancer des process, que ces process soient « masquées » car le fichier qui les lancent a ensuite été supprimé, mais ils restent en RAM.

En résume, il faut :

  1. couper l’accès au site concerné
  2. tuer tous les process suspects
  3. lancer une analyse de la machine avec clamav ou autre et virer les éléments suspects (travail à la charge de l’hébergeur)
  4. analyser en profondeur le site concerné et le réinstaller au propre, j’ai publié une note à ce sujet par ici Nettoyer un site SPIP piraté - Le labo (travail à la charge des personnes qui maintiennent le site)
  5. réactiver l’accès au site une fois qu’on est certain que tout est propre
3 « J'aime »
#38

Je m’occupe d’un site avec cPannel chez un hébergeur à La Réunion. Pas de problème particulier.

1 « J'aime »
#39

Message o2Switch :

Oui pas de soucis, nous regardons en parallèle de notre côté si nous voyons quelque chose.
Mais si c’était global au serveur, les autres sites hors SPIP hébergés chez nous auraient le même problème.
Pour le coup, toutes les personnes qui nous contactent avec ce problème sont toutes sur des serveurs physiques différent et utilisent toutes SPIP.

A tout hasard, vos autres sites chez d’autres hébergeurs utilisent cPanel ?

Car c’est potentiellement une faille sur SPIP exploitable uniquement avec cPanel même si cela me semble étrange.

Il me semble que par le passé un problème similaire était survenu sur les sites SPIP et un patch côté SPIP avait été déployé pour corriger car il s’agissait effectivement d’un piratage global au CMS.

Mes sites Spip qui ne sont pas chez o2Switch ne disposent pas de cPanel effectivement.

#40

J’ai exactement le même problème en ce moment chez Alwaysdata.

Des process /usr/sbin/client (c’est un faux nom, le process se cache ailleurs) qui apparaissent régulièrement, des trucs écrits dans /tmp, voir des crontab installées.