Objectif
Ce guide explique comment réagir méthodiquement lorsqu’Imunify360 signale un fichier suspect ou malveillant. L’objectif n’est pas de supprimer précipitamment des fichiers, mais de confirmer l’incident, préserver les éléments utiles au diagnostic, restaurer un site fiable et supprimer la cause probable de la compromission. Imunify360 met notamment à disposition un scanner de fichiers, des incidents et, selon la configuration activée, des actions de nettoyage ou de quarantaine.[1]
La prévention associe un hébergement web adapté, un certificat SSL et le guide pour renforcer la sécurité de l’hébergement.
Prérequis
Vous devez disposer de l’accès à l’Espace client NovaHoster et, si votre forfait l’autorise, à Imunify360 depuis le panneau de contrôle. Préparez le nom de domaine concerné, l’heure approximative de l’alerte, l’URL éventuellement touchée et une sauvegarde récente connue comme saine. Ne modifiez pas le fichier signalé avant d’avoir noté son chemin, sa date de modification et le détail de l’alerte.
L’accès à Imunify360, l’affichage des résultats, la restauration depuis une quarantaine, le nettoyage automatique et certaines fonctions de protection peuvent dépendre du forfait, de la licence ou des droits accordés par NovaHoster. Confirmez ces points dans l’Espace client ou auprès du support.
Procédure
1. Confirmer le périmètre de l’alerte
Ouvrez Imunify360 depuis le panneau de contrôle, puis consultez la section dédiée aux fichiers malveillants ou aux incidents. Relevez le domaine, le chemin complet du fichier, le type de détection, la date, l’état du traitement et, lorsqu’il est disponible, le détail fourni par le scanner. Le tableau de bord Imunify360 peut également présenter des incidents, des alertes et un historique des fichiers nettoyés.[1]
Ne concluez pas qu’un compte entier est compromis à partir d’un seul fichier. Cherchez les détections similaires dans les autres répertoires du même site et des sites associés au même compte. Un fichier récemment modifié dans un répertoire d’upload, un plugin ou un cache mérite une attention particulière, mais son emplacement ne suffit pas à établir la cause.
2. Préserver les éléments utiles
Avant toute suppression, exportez ou copiez les informations disponibles dans l’interface et notez les horaires. Si vous disposez d’une sauvegarde Plesk ou de la sauvegarde externalisée, identifiez une version antérieure à la première alerte. Évitez de télécharger puis d’ouvrir un fichier suspect sur votre poste : conservez-le uniquement pour analyse par le support ou un professionnel compétent.
3. Vérifier l’application et les comptes
Mettez en pause les opérations non indispensables sur le site concerné. Depuis l’administration du CMS, vérifiez la version du cœur, des thèmes et des extensions. Supprimez les composants inutilisés uniquement après avoir contrôlé qu’ils ne sont pas nécessaires à un autre site. Réinitialisez les mots de passe du CMS, du panneau, du SFTP/FTP, des bases de données et des comptes d’administration exposés, en utilisant des mots de passe distincts.
Contrôlez également les utilisateurs inconnus, les tâches planifiées, les redirections, les fichiers récemment modifiés et les clés d’accès. Une suppression réussie ne suffit pas si l’attaquant conserve un accès valide.
4. Utiliser la quarantaine ou le nettoyage disponible
Si l’interface propose une mise en quarantaine, privilégiez-la avant une suppression irréversible lorsque le fichier est critique ou lorsque la détection doit être confirmée. Si un bouton de nettoyage est proposé, lisez le résumé de l’action et vérifiez l’existence d’une sauvegarde avant de confirmer. Une fonction de nettoyage peut être désactivée pour les comptes ou les utilisateurs selon la formule souscrite ; dans ce cas, ouvrez un ticket NovaHoster plutôt que de contourner la restriction.[2]
Ne restaurez jamais un fichier depuis la quarantaine sans avoir compris pourquoi il a été détecté. Une restauration peut réintroduire le code signalé. En cas de faux positif présumé, transmettez le chemin et le rapport au support afin de demander une vérification.
5. Tester le site après traitement
Videz les caches applicatifs avec prudence, puis testez la page d’accueil, la connexion d’administration, les formulaires, les paiements éventuels et les tâches essentielles. Vérifiez les journaux d’erreurs et les redirections inattendues. Lancez une nouvelle analyse si l’interface le permet et observez si les mêmes fichiers réapparaissent.
6. Documenter la clôture de l’incident
Conservez la date, les fichiers traités, la sauvegarde utilisée, les comptes dont les mots de passe ont été changés et les mises à jour effectuées. Cette chronologie aidera NovaHoster à distinguer une réinfection d’une alerte résiduelle et à recommander une mesure adaptée.
Chez NovaHoster, concrètement
Le guide décrit la procédure. Cette section dit ce que notre équipe constate réellement sur les sites qu'elle nettoie, dans quel ordre les causes reviennent, et surtout ce que l'outil ne réglera pas à votre place — c'est cette dernière partie qui explique pourquoi un site se réinfecte.
Par où l'infection est entrée, dans l'ordre de fréquence
Une extension ou un thème pas à jour, très loin devant tout le reste. Pas un composant douteux : un composant parfaitement légitime, dont l'auteur a publié un correctif il y a huit mois et que personne n'a appliqué. Les failles de ce type sont publiées, documentées, et balayées automatiquement par des robots qui testent des millions de sites. Il n'y a pas d'attaquant qui vous a choisi — il y a un programme qui a trouvé une porte ouverte.
Un thème ou une extension payants récupérés gratuitement ailleurs. Ils fonctionnent, ils sont souvent complets, et ils embarquent un accès. C'est la cause la plus douloureuse à annoncer, parce qu'elle a fait économiser soixante dinars et qu'elle en coûte plusieurs centaines à réparer.
Un mot de passe d'administration réutilisé ailleurs et récupéré dans la fuite d'un service sans aucun rapport. Imunify360 ne voit rien d'anormal dans cette connexion : elle est parfaitement légitime, avec les bons identifiants. C'est le cas le plus difficile à détecter et le plus facile à prévenir.
Un poste de travail compromis, enfin, d'où partent les identifiants FTP. Le site est propre, le serveur est propre, et pourtant les fichiers changent. Quand tout le reste a été écarté, c'est là qu'il faut regarder.
Ce que le nettoyage ne fait pas — et pourquoi un site se réinfecte
Le nettoyage retire les fichiers malveillants. Il ne referme pas la porte par laquelle ils sont entrés, et il ne supprime pas ce que l'attaquant a laissé derrière lui.
C'est la raison pour laquelle un site se réinfecte trois jours après un nettoyage techniquement réussi, et pourquoi le client conclut à tort que l'outil ne sert à rien. Quatre choses sont à faire après chaque nettoyage, et aucune n'est automatisable :
Mettre à jour l'extension ou le thème en cause — sinon la même faille sera retrouvée par le même robot dans la semaine. Lister les comptes administrateurs et supprimer ceux que vous ne reconnaissez pas : en créer un second est la première chose que fait un attaquant, et il porte souvent un nom crédible. Changer les mots de passe, tous, y compris ceux de la base et du FTP. Et inspecter les tâches planifiées : une tâche qui retélécharge le code chaque nuit est le grand classique, et c'est elle qui explique les réinfections « inexplicables ».
Nous faisons ces vérifications avec vous quand vous nous sollicitez. Nous ne les faisons pas à votre place sans vous prévenir, parce que supprimer un compte administrateur légitime ou désactiver une tâche utile casse un site tout aussi sûrement qu'un malware.
Restaurer une sauvegarde : rarement la bonne idée
Revenir à une sauvegarde d'avant l'infection paraît la solution évidente. Deux problèmes se posent, et le second est le plus méchant.
Le premier est connu : vous perdez tout ce qui a été fait depuis, commandes comprises. Sur une boutique, c'est souvent rédhibitoire à lui seul.
Le second l'est beaucoup moins. La date de l'infection n'est presque jamais la date à laquelle vous l'avez remarquée. Un site compromis reste souvent discret des semaines : il envoie du courrier indésirable, il place des liens cachés vers d'autres sites, il attend. Vous découvrez le problème le jour où Google vous signale, ou le jour où vos e-mails cessent d'arriver — c'est-à-dire longtemps après. La sauvegarde « propre » de la semaine dernière est donc fréquemment déjà infectée, et la restaurer ne fait que remettre le compteur à zéro.
La bonne méthode est donc : nettoyer, refermer la porte, surveiller — et ne restaurer que si le nettoyage échoue. Le guide de sauvegarde et restauration décrit la procédure quand elle s'impose vraiment.
Si votre domaine a servi à envoyer du courrier indésirable
C'est la conséquence la plus coûteuse d'une infection, et de très loin la plus longue à réparer. Un site compromis sert souvent de relais : pendant des semaines, du courrier part en votre nom vers des milliers d'adresses.
Le résultat vous survit au nettoyage. Votre domaine peut être signalé auprès des services de messagerie, et vos e-mails parfaitement légitimes — vos factures, vos devis, vos confirmations de commande — finissent en indésirables chez vos clients pendant des semaines après que le site a été assaini.
Le nettoyage est donc nécessaire mais pas suffisant. Vérifiez que SPF, DKIM et DMARC sont correctement posés, ce que décrit le guide d'authentification du domaine — une authentification propre est ce qui permet à la réputation de remonter. Et si la messagerie est un enjeu central de votre activité, notre serveur mail privé avec adresse IP dédiée isole votre réputation d'envoi de celle des autres comptes.
Nous ne promettons pas de délai sur cette remontée : elle ne dépend pas de nous, mais du comportement d'envoi observé sur plusieurs semaines. Ce que nous pouvons faire, c'est vérifier que plus rien ne part de votre espace, et que votre authentification est en règle.
Ce qui protège vraiment, avant l'infection
Imunify360 PRO tourne sur tous nos packs et fait son travail : détection, mise en quarantaine, pare-feu applicatif. CloudLinux et CageFS empêchent qu'un compte compromis contamine ses voisins — c'est l'objet du guide CloudLinux.
Mais la protection la plus efficace ne coûte rien et ne dépend pas de nous : appliquer les mises à jour. Un site dont les extensions sont à jour n'est pas invulnérable, il est simplement hors de portée des attaques automatisées, qui représentent l'écrasante majorité de ce que nous voyons.
Le deuxième réflexe, tout aussi gratuit : désinstaller ce que vous n'utilisez pas. Une extension désactivée reste présente sur le disque et reste exploitable. « Désactivée » n'est pas « supprimée », et c'est une confusion qui nous vaut plusieurs nettoyages par an.
Cas d’erreur et diagnostic
| Symptôme | Interprétation possible | Action recommandée |
|---|---|---|
| Imunify360 n’apparaît pas dans le panneau | Fonction non activée, panneau différent ou droits insuffisants | Confirmer le forfait et la licence dans l’Espace client ; contacter NovaHoster si l’accès devrait être présent. |
| Le bouton de nettoyage est absent ou désactivé | Nettoyage non inclus, protection utilisateur désactivée ou compte restreint | Ne pas tenter de modifier la configuration serveur ; demander au support quelles actions sont disponibles. |
| Le fichier réapparaît après nettoyage | Vulnérabilité non corrigée, identifiants compromis, tâche planifiée ou autre porte dérobée | Changer les identifiants, mettre à jour le CMS et demander une analyse approfondie avec les journaux. |
| Le site renvoie une erreur après traitement | Fichier légitime modifié, dépendance manquante, cache ou permissions incorrectes | Restaurer une sauvegarde saine si nécessaire, comparer les journaux et faire valider l’action par le support. |
| L’alerte semble être un faux positif | Code obfusqué légitime, fichier de cache ou règle trop sensible | Ne pas ajouter aveuglément une exception ; transmettre le rapport complet à NovaHoster. |
Questions fréquentes
Imunify360 garantit-il qu’un site est propre après un seul scan ?
Puis-je supprimer directement tous les fichiers signalés ?
Pourquoi le nettoyage automatique n’est-il pas accessible ?
Une sauvegarde suffit-elle à résoudre une infection ?
Que dois-je envoyer au support ?
Par où les infections entrent-elles le plus souvent ?
Pourquoi mon site s'est-il réinfecté après le nettoyage ?
Vaut-il mieux restaurer une sauvegarde d'avant l'infection ?
Mes e-mails partent en indésirables depuis l'infection, combien de temps ça dure ?
Une extension désactivée est-elle sans danger ?
Nettoyez-vous mon site à ma place ?
Quand contacter l’Espace client NovaHoster
Contactez NovaHoster si Imunify360 est inaccessible, si le nettoyage ou la quarantaine n’est pas disponible, si l’infection revient, si plusieurs comptes semblent touchés, si le site reste bloqué après traitement ou si vous suspectez une compromission des identifiants de panneau. Demandez explicitement si une analyse serveur, une restauration ou une action administrateur est incluse dans votre offre.
Guides liés
Sources techniques
Les permissions et options visibles peuvent dépendre de votre formule ou de vos droits. Faites vérifier le contexte depuis l’Espace client.
Demander une vérification