Bonjour à tous,
Pour faire le point
- 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.
- 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.
- 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.