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).
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.
Vous avec le numéro de ticket svp ? CSxxx
Je vais check en interne.
En attendant j'ai check le dernier scan, et il est clean, le service est donc réouvert. J'ai bien pris note de votre feedback de potentiel faux positif, nous allons l'analyser et apporter les adaptations nécessaires si c'est avéré.
Sachez toutefois, que les scans ne sont pas instantanés, en fonction de la donnée qui est présente sur votre service, cela peut prendre de quelques minutes à quelques heures pour faire le tour malgré toutes les optimisations mises en place pour optimiser cela.
--
Bruno B.
Team Lead hébergements mutualisés
Bonjour@Steph
Je comprends tes doutes.
Mais ces doutes pourraient être levés très rapidement.
Voir dans mon guide le paragraphe : T - Restauration OVH de votre site à une date antérieure
Demande à OVH, l'activation de ton hébergement.Deux cas :
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
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:
Les pistes à explorer
Vu les dépassements de ressources, et le manque de communication lors de ce dernier incident,
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 :)