Site Web indisponible Ce site est actuellement suspendu. Les informations ont été transmises à son administrateur.
... / Site Web indisponible Ce ...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

Site Web indisponible Ce site est actuellement suspendu. Les informations ont été transmises à son administrateur.

by
Steph

Bonjour,

Depuis dimanche, OVH a bloqué les sites de mon hébergement parce qu'il consommait trop de ressources.

Depuis, toutes les requêtes vers n'importe quelle page du site sont interceptées et le contenu remplacé par une page qui indique que le site est suspendu.

Après création de ticket, appel téléphonique, escalade du problème, on m'a renvoyé une liste de fichiers avec cette explication 

il est crucial de nettoyer ou de supprimer tous les fichiers malveillants détectés

 
Dès réception du message et après que OVH ait au moins rétabli la possibilité de me connecter en ftp, j'ai téléchargé ces fichiers pour analyse, et je les ai supprimés du site.

Ensuite le message spécifiait une procédure à suivre:

Une fois ces manipulations effectuées, vous pourrez réouvrir votre hébergement en suivant ce guide : https://help.ovhcloud.com/csm/fr-web-hosting-403-forbidden-diagnosis?id=kb_article_view&sysparm_article=KB0052605#etape-3-reactiver-votre-hebergement-web_1

J'ai effectué la procédure point par point et après le chmod l'état du site dans OVH Manager est revenu à 

Etat du service: Actif

Mais depuis, aucun changement; les sites sur cet hébergement restent avec la page de site suspendu.

Après avoir attendu, j'ai remonté les infos dans le ticket.

Toujours sans réponse ce matin, je me décide à téléphoner à nouveau, et après cet appel un message dans le ticket m'informe que:

Je fais suite à notre échange téléphonique de ce jour. Votre demande a été remontée en interne. Une réponse vous sera apportée dans les plus brefs délais.

Depuis, plus aucune nouvelle et les sites sont toujours inaccessibles...

J'ai tenté de trouver des infos sur le forum, mais sans succès. Est-ce que d'autres personnes ont été confrontées au même problème? Que puis-je faire à mon niveau pour rétablir la situation?

Exemples de sites impactés:
https://www.gaudry.be/
https://www.loadcontrolcenter.com/

Et pour info, après analyse des fichiers malveillants, il s'agit principalement de fichiers html en cache, sans script, dont le code est parfaitement sain. Je suspecte que c'est le nombre d'appels énorme vers ces fichiers et le nombre important de liens internes qui pointent vers eux qui a fait croire à l'analyste d'OVH que ces fichiers étaient malicieux (il s'agit principalement de pages d'acteurs, ou de voix de séries de manga qui comportent des centaines d'épisodes, donc chaque page d'épisode pointe bien normalement vers les pages d'infos sur les acteurs qui y interprètent un rôle). 


10 Replies ( Latest reply on 2025-10-30 10:42:33 by
fritz2cat 🇧🇪 🇪🇺
)

Bonjour,

Seul le support peut vous réouvrir dans ces circonstances mais ils ne le feront pas car vos scans présentent toujours des malwares dans un dossier www/old

Je vous invite pour gagner du temps à nettoyer cela.

--

Bruno B.
Team Lead hébergements mutualisés

rm -r www/old/

voilà c'est fait.

Mais je suis extrêmement mécontent de la prise en charge car sans votre réaction sur ce forum je n'ai aucune réponse à mon ticket et je pouvais encore attendre des années comme ça.

Ceci étant, il faudra vraiment que l'on m'explique ce que vous identifiez comme malware...

Suites de la saga:

Heureusement que Bruno B. m'a informé dans ce fil de discussions qu'il y avait encore des fichiers considérés par OVH comme malwares, car aucun retour d'infos.


J'ai été contraint de sonner à nouveau au service technique et la personne qui a pris en charge le dossier m'a enfin expliqué clairement la situation et a enfin compris la problématique

Je suis tout à fait d'accord avec lui sur la nécessité d'effectuer un scan afin d'identifier d'éventuels malwares après nettoyage pour rouvrir le site. 
Ce qui est inadmissible dans le cas que je viens de rencontrer, c'est qu'après le scan, je n'aie eu aucun retour dans le ticket... Je pouvais encore attendre des années en pensant que OVH était occupé à débloquer la situation, puisque de mon côté j'avais supprimé tous les fichiers que l'on m'avait indiqué et je pensais que c'était OK (de plus, dans le panneau de l'hébergement du manager, tout était à présent vert).

Donc à présent on m'a affirmé que cette situation ne se représenterait plus et que je serai informé du résultat du scan s'il détecte encore des fichiers qu'il considère comme malware.

Bonjour @Steph 

Pour éviter ces petits soucis et permettre une restauration rapide :

 

Les sauvegardes chez OVH de votre site ne sont pas éternelles.

Extrait de mon guide : T - Restauration OVH de votre site à une date antérieure

Chez OVH, la restauration de votre hébergement ne permet de remonter qu’au maximum à deux semaines.

Si le piratage de votre site remonte à 3 semaines, vous êtes foutu et obliger de tout supprimer et reconstruire complètement votre site.

Chez OVH, la restauration de votre base de données ne permet de remonter qu’au maximum à deux mois

Penser à faire une sauvegarde Hébergement et Base de données sur votre PC une fois par mois.
Voir dans mon guide le paragraphe : Ua - Sauvegarde complète de votre site sur votre PC

Et pour une restauration rapide :

Voir dans mon guide le paragraphe : Ub - Restauration complète de votre site depuis votre PC

 

Merci pour la réponse Gaston, 

mais ici ce n'est absolument pas un problème de backup, mais bien du fait que le site soit mis dans un statut désactivé et que je n'ai toujours pas de feedback du scan. Donc OVH désactive le site (certainement à cause d'une mauvaise interprétation qui considère de manière erronée des fichiers comme étant malwares), et que les sites soient totalement inaccessibles pendant ce temps. Le problème perdure depuis dimanche. Et aucun retour dans le ticket.

Bonjour @Steph 

Je comprends tes doutes.

Mais ces doutes pourraient être levés très rapidement.

Deux cas :

  1.  Site OK. Donc regarde sur ton PC où se trouvent les fichiers défectueux.
  2. Site NOK : Le problème serait alors chez OVH.



     

Bonjour @ Gaston  

Je me permet de corriger quelques éléments qui pourraient induire en erreur de futurs lecteurs de ce fil : 

Les sauvegardes ne sont pas la solution systématique, pour deux raisons, la première est que la restauration d'une sauvegarde peut pour certain engendrer une perte des données modifiées précieuses entre la sauvegarde et le moment de la restauration, cela doit être fait en maîtrise des causes et conséquences.

La seconde est que nous constatons que nombre de services contaminés le sont par la présence de malwares anciens historiquement non exploités et que l'on voit ressurgir ces derniers temps, dans ce cas la restauration de la sauvegarde ne règle en rien le problème, car elle contient ce qui doit être nettoyé.

Le plus important dans ces circonstances est de nettoyer l'ensemble de l'hébergement des fichiers malicieux, ET le plus important, de corriger les failles de sécurité en procédant aux mises à jour nécessaires qui logiquement devraient être faites de manière régulières. Sans correction de ces failles, un hébergement "nettoyé" sera réinfecté sous quelques heures / jours, et sera donc de nouveau détecté par nos outils.

Je communiquerai sous peu sur ces outils qui évoluent très fortement en ce moment afin d'expliquer le pourquoi, le comment et les impacts pour tous.

Notre mission est de maintenir le service de qualité pour tous et nous travaillons au quotidien dans ce sens.

--

Bruno B.
Team Lead & Responsable des operations Infrastructures hébergements mutualisés

Bonjour à tous,

Pour faire le point

  1. Restaurer une sauvegarde quand des fichiers contiennent des malwares est en effet dangereux et que je qualifierais presque de stupide car ça ne fait que remettre la situation dans son état critique au lieu d'améliorer les choses. Avec ce comportement les malwares sont encore présents.
  2. Le scan d'OVH est une chose nécessaire, et encore plus sur des environnements mutualisés car du code malicieux n'affecte pas seulement l'hébergement fautif, mais en plus les hébergements dont les ressources sont partagées. Je trouve très positif que le scan d'OVH soit en place.
  3. Le seul point que j'incrimine dans la situation présente au niveau du scan, est le manque de communication... Je n'ai eu aucun retour sur mon ticket après le scan qui a été effectué après que j'aie supprimé les fichiers que l'on m'avait signalé. 
    De plus, le message sur le site stipule: Les informations ont été transmises à son administrateur. => j'ai vérifié à de nombreuses reprises et je suis formel, j'ai reçu des mails pour les dépassements de ressources, jamais (ni dans les spams) sur le scan, les résultats du scan, ou le fait que le site ait été bloqué par OVH (si je ne travaillais pas quotidiennement sur les sites, je n'airais donc pas eu connaissance du fait qu'il ne s'affichait plus).
    Dernier exemple sur la communication: ce matin le site est enfin revenu à la normale, mais toujours aucun retour dans le ticket..
    A cause de cette situation, et des différents intervenants (malgré certaines personnes bienveillantes qui ont fait ce qu'elles ont pu chez OVH), l'hébergement est encore une fois resté totalement inaccessible pendant plusieurs jours, affectant les différents sites, dont un qui ne comporte qu'une page en html.

Au niveau des backups et du code

Et pour répondre à Gaston au niveau des backups, je travaille depuis 20 ans sur le site principal avec un système de versionning du code (auparavant subversion et depuis plus de dix ans git), donc je ne n'ai aucune crainte de perdre le code de base. Par contre, le site travaille avec de nombreux media de type image (la partie sur la photographie, les db, livres et films...) et ces images ne sont pas dans git et je dois faire un backup manuel. Ce sont ces derniers fichiers téléversés que je devais récupérer en ftp en cas de problème.

Quand du code est commité, Jenkins le publie automatiquement sur le serveur d'acceptation sans intervention de ma part, et ce serveur me permet de voir si tout va bien, et de lancer automatiquement les tests de qualité du code avec SonarQube et d'effectuer tous les tests unitaires. C'est seulement quand le résultat de ces tests est satisfaisant que je place manuellement ces fichiers sur le serveur de production (votre hébergement).

Etant donné que j'ai entièrement développé l'architecture du site moi-même, et seul, il contient naturellement ses faiblesses, mais ne contient pas de code malicieux dans son ensemble (surtout pas des eval en javascript ou ce genre de choses). En effet il y a encore beaucoup de choses à tenter d'optimiser, notamment au niveau de certaines requêtes vu le nombre extrêmement élevé d'information dans les tables, ce qui occasionne des dépassements de ressources lorsque les crawlers se mettent à parcourir le site à plusieurs et qu'une partie du cache a été vidée.
Pour avoir une idée de la taille du contenu, dans ma console google j'avais encore douze millions de pages qui sont en attente d'indexation à cause d'indisponibilités des pages (erreur 503) dues aux dépassements de ressources lors de l'indexation.
La dernière indisponibilité, cette fois de l'intégralité de l'hébergement, a encore eu un impact extrêmement désastreux au niveau SEO quand je regarde la console des derniers jours.

Je tente toujours d'utiliser la dernière version de php et de mettre à jour le code en conséquence. Je ne me contente pas du code existant, mais je fais un refactoring des classes quand les technologies évoluent, ou que des manières plus performantes de faire apparaissent.

Ce qui a été mis en place

Un système de cache des requêtes existait déjà sur le site depuis très longtemps. Il a été amélioré de cette manière:

  • cache des objets les plus souvent utilisés afin de ne pas demander à la DB à chaque fois, appelé en php;
  • cache au niveau du code généré html pour la page, appelé avant php (c'est un fichier html en cache qu'Apache ou nginx sert directement au lieu de faire appel au moteur php);
  • encore au dessus de tout ça je vais mettre en place cloudflare;
  • je n'utilise plus php pour les pages d'erreur 404 afin de ne pas solliciter trop le serveur (à présent c'est un simple fichier html);
  • j'ai interdit aux différents robots que j'ai trouvé dans les logs (de manière soft via robots.txt, et plus agressive dans la config Apache ou nginx);
  • toujours dans la config du serveur web, et après analyse des logs et des retours des pages d'erreurs (principalement 404), j'ai identifié les patterns des url malformées (intentionnellement ou pas) que l'on tentait d'atteindre sur le site, et elles n'atteignent plus php mais directement une page d'erreur statique;

Les pistes à explorer

Vu les dépassements de ressources, et le manque de communication lors de ce dernier incident,

  • j'ai la possibilité de changer d'hébergeur (je suis depuis 25 ans chez OVH donc je ne suis pas un client versatile qui change sur un simple coup de tête, mais c'est un point que j'étudie vu les impacts négatifs depuis ces derniers mois);
  • j'envisage de passer sur un VPS-3 qui me permettrait plus de contrôle, de réactivité, et de ne pas impacter d'autres utilisateurs. Mais cette démarche a un coût en temps que je vais devoir investir dans la configuration et la maintenance; coût dont je me passerai bien, vu que je passe déjà mes nuits à développer le site et son contenu.
    Malheureusement, encore une fois, la communication n'est pas optimum car je n'ai eu aucune réponse à mes questions et je dois moi-même gratter dans la doc sur le site et sur le net pour évaluer la faisabilité et les conséquences du projet. Je ne demande pas qu'on me serve les infos sur un plateau, mais je pense que commercialement, une société qui propose des services payant devrait pouvoir répondre à quelques questions pour savoir si c'est la bonne direction ou pas.

Pour finir

Merci à Gaston, à Bruno B., à Corentin O. et à Marvin A. pour leurs intervenions positives malgré le manque de compréhension du problème (ou la totale absence de réponse) de la part d'autres du service helpdesk d'OVH.

Merci @Steph pour ce débrief très complet et circonstancié.

et merci à @Bruno B. de répondre toujours présent quand il y a de vrais problèmes (qui ne sont pas des bêtes déficiences de l'interface chaise-clavier :)