Site web piraté, redirection des visiteurs vers un autre site : que faire dans la première heure ?

Tout de suite, récupérez le fichier de configuration de votre serveur via FTP et ouvrez-le. Souvent ils insèrent des règles de redirection vers des domaines externes au milieu de chaînes de caractères incompréhensibles. Si vous connaissez la structure d'origine du fichier, supprimez ces lignes suspectes et enregistrez, ça stoppera au moins la redirection temporairement.

Le fait que la redirection ne touche que le mobile et les visites Google est une vérification classique de referer. Le code injecté peut se trouver dans les fichiers sources, mais aussi directement dans les tables de configuration de la base de données. Si vous avez un accès SSH au serveur, lancez un scan des fichiers modifiés ces dernières 48 heures pour repérer instantanément les fichiers suspects.

Quand vous ouvrez votre ticket chez l'hébergeur, donnez-leur précisément ces trois éléments : 1) Les conditions de déclenchement de la redirection (type d'appareil, provenance), 2) L'heure et la minute exactes où l'incident a été constaté, 3) La présence éventuelle de fichiers inconnus récemment créés à la racine. Ça vous évitera la réponse automatique de premier niveau et fera passer le ticket direct à l'équipe sécurité.

Il nous est arrivé exactement la même chose l'année dernière sur notre site de vente en gros à Francfort. Pris de panique, on a restauré la sauvegarde de la veille et deux heures plus tard rebelote piraté à nouveau car il y avait une faille dans un plugin de formulaire qui n'était pas à jour. On a perdu 2.000 euros par jour. Se contenter de restaurer une sauvegarde sans corriger la faille ne règle absolument rien sur le long terme.

note : j'ai écrit cela d'après mon expérience, cela ne s'applique peut-être pas à tout le monde.

Est-ce que vous aviez un thème ou une extension tiers installé sur votre site qui n'a pas été mis à jour depuis longtemps ? De plus, vous êtes sur un hébergement mutualisé ou sur un serveur virtuel dédié ? Si c'est du mutualisé, il y a de fortes chances que l'infection provienne d'un autre site hébergé sur le même serveur.

si l'hébergeur a une sauvegarde auto ne l'écrasez surtout pas tout de suite. faites d'abord une copie de sauvegarde de l'état actuel infecté. bref parfois la sauvgearde d'hier qu'on pense propre est déjà vérolée il faudra peut-être remonter au moins une semaine en arrière.

Dans la mesure où vous opérez sur le marché allemand, il est primordial au regard de vos obligations légales de vérifier si des données utilisateurs ont fait l'objet d'une fuite. S'il existe une possibilité d'accès aux informations clients ou aux pages de paiement, vous pourriez être tenu d'en informer l'autorité de protection des données du Land concerné.

Vérifiez tout de suite la console de recherche si une alerte est apparue dans l'onglet des problèmes de sécurité, il faudra immédiatement demander un réexamen dès que le nettoyage sera terminé.

Beau travail. Essayer de faire cela seul est la voie la plus coûteuse.

Si vous écrivez le résultat ici cela aidera aussi d'autres personnes.

Trois avis différents sont sortis, ils se complètent tous. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

Séparons les concepts, ils sont souvent confondus. Prendre une mesure sans faire d'inventaire, c'est laisser une porte ouverte sans le savoir.

Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard. Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Chez nous, ça s'est passé comme ça. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

J'espère que cela vous sera utile.

Je suis intéressé.

chez nous, ça s'est passé comme ça mais genre le fait que la sauveegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

je suis aussi curieux de savoir si d'autres font autrement.

Résumé rapide pour les nouveaux : Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Bien sûr, cela change si votre situation est différente.

Je suis passé par là, laissez-moi vous raconter. Les décisions hâtives finissent par être corrigées six mois plus tard.

Si l'autorisation et le périmètre ne sont pas écrits, ne lancez pas ce test. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

J'aimerais poser une question. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

Corrigez-moi si je me trompe.

Si vous partez dans cette direction, réglez cela dès le départ. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur. Si vous avez des questions, écrivez-moi, je répondrai au mieux.