Sécurisation de site web
Un site à jour, c’est bien. Un site protégé pendant qu’il ne l’est pas, c’est mieux
Entre le jour où une faille est publiée et celui où vous appliquez le correctif, il se passe des semaines. C’est cet intervalle que nos protections couvrent, sur la plateforme comme sur le site lui-même.
- Pare-feu applicatif à règles professionnelles, mises à jour en continu
- Faille connue corrigée virtuellement en attendant votre mise à jour
- Détection des fichiers compromis sur le site
- Certificat SSL inclus et automatique
Le principe
Une faille n’attend pas que vous mettiez à jour
L’intervalle qu’on oublie
Le raisonnement habituel — « je mets à jour, donc je suis protégé » — a un trou. Quand une faille est publiée dans WordPress, dans une extension ou dans Prestashop, elle est exploitée dans les heures qui suivent. Vous, vous mettrez à jour la semaine prochaine, ou le mois prochain.
C’est cet intervalle qui compte. Sur notre plateforme, une faille découverte est corrigée virtuellement : le pare-feu applicatif refuse la requête qui tenterait de l’exploiter, sans rien changer à votre site, et il continue de le faire jusqu’à ce que vous appliquiez le correctif. La mise à jour reste nécessaire — elle n’est simplement plus une course.
Trois lignes, pas une
La sécurité d’un site ne tient pas à un produit. Elle tient à des couches qui n’échouent pas ensemble.
Devant : sondes d’intrusion et pare-feu, matériels et applicatifs. Les règles du pare-feu applicatif sont mises à jour très régulièrement, et ce sont des règles professionnelles — pas une extension installée sur votre site, qui tomberait en même temps que lui.
Dans le site : la détection des fichiers compromis. Imunify repère les failles connues et les fichiers modifiés à votre insu dans les sites hébergés ; StopTheHacker contrôle par ailleurs que le site n’a pas été corrompu. Un site piraté est souvent parfaitement fonctionnel en apparence — c’est ce qui le rend long à découvrir.
Autour : le certificat SSL, inclus et automatique, qui empêche qu’on lise ou modifie ce qui circule entre le visiteur et le site. Et les comptes, protégés contre les attaques par force brute.
Deux extensions que nous avons écrites
Aux outils du marché s’ajoutent deux extensions PHP développées en interne, déployées sur notre plateforme et disponibles nulle part ailleurs. Elles traitent deux angles que les produits existants couvrent mal en mutualisé.
weobia_reguard attribue un score à chaque script pour repérer les fichiers
malveillants. C’est la même famille de protection que la détection de fichiers
compromis, prise par l’autre bout : au lieu de comparer un fichier à ce qu’il
devrait être, on regarde ce qu’il fait.
weobia_mailhook trace les e-mails envoyés, site par site et script par
script. Cela paraît étranger à la sécurité ; c’en est pourtant l’un des
meilleurs signaux. Le premier symptôme visible d’un site compromis est
généralement le spam qui en part — à l’insu de son propriétaire, qui ne
découvre le problème qu’au moment où son domaine est mis en liste noire. Avec
cette trace, nous savons quel site et quel fichier, au lieu de suspendre le
compte entier le temps de comprendre.
Ce qui ne se sécurise pas
Un site sous une version abandonnée par son éditeur ne se protège pas durablement : aucun correctif n’arrivera plus. Les couches ci-dessus tiennent l’attaque connue, pas celle qui n’a pas encore de règle. Dans ce cas, la seule réponse sérieuse est de sortir de cette version — et une refonte est généralement le bon moment pour le faire.
Les protections
Ce qui est en place
-
Pare-feu applicatif
Règles professionnelles mises à jour très régulièrement, en amont du site. Elles ne dépendent d’aucune extension installée chez vous, donc elles ne tombent pas avec votre site.
-
Correction virtuelle
Une faille découverte est corrigée virtuellement, le temps que vous appliquiez la mise à jour. C’est ce qui couvre l’intervalle entre la publication d’une faille et son correctif chez vous.
-
Fichiers compromis
Imunify repère les failles connues et les fichiers modifiés à votre insu ; StopTheHacker contrôle que le site n’a pas été corrompu. Un site piraté fonctionne souvent normalement.
-
Sondes et pare-feu matériels
La plateforme est protégée en amont par des sondes d’intrusion et des pare-feu matériels, avant même que la requête atteigne un serveur web.
-
Comptes protégés
Les comptes sont protégés contre les attaques par force brute — celles qui essaient les mots de passe un par un jusqu’à tomber juste.
-
Certificat SSL et Cloudflare
Let’s Encrypt inclus et automatique. Pour une audience internationale, Cloudflare accélère et protège le site tout en économisant de la bande passante.
Questions fréquentes
Sécurisation : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Faut-il installer une extension de sécurité sur mon site ?
C’est le réflexe courant, et c’est le maillon le plus faible : une extension de sécurité tourne à l’intérieur du site qu’elle protège, avec les mêmes droits et les mêmes failles. Nos protections sont en amont, sur la plateforme. Elles restent debout même si le site tombe.
Si je mets mon site à jour, suis-je protégé ?
Vous l’êtes contre ce que le correctif corrige, à partir du moment où vous l’appliquez. Le problème est l’intervalle : une faille publiée est exploitée dans les heures qui suivent, pas au rythme de vos mises à jour. C’est exactement ce que couvre la correction virtuelle du pare-feu applicatif.
Comment sait-on qu’un site a été piraté ?
Rarement en le regardant : un site compromis continue le plus souvent de fonctionner normalement, parce que l’intérêt de l’attaquant est justement qu’on ne s’en aperçoive pas. C’est pourquoi la détection porte sur les fichiers — Imunify repère ceux qui ont été modifiés à votre insu, StopTheHacker contrôle l’intégrité du site.
Que se passe-t-il si mon site se met à envoyer du spam ?
C’est le premier symptôme visible d’un site compromis, et il arrive presque toujours à l’insu du propriétaire — qui découvre le problème quand son domaine est mis en liste noire. Notre extension weobia_mailhook trace les e-mails envoyés site par site et script par script : nous savons lequel et par quel fichier, au lieu de suspendre le compte entier le temps de comprendre.
Mon site tourne sur une version obsolète, que faire ?
Les protections tiennent l’attaque connue, mais une version abandonnée par son éditeur ne recevra plus aucun correctif : le trou s’élargit chaque mois. La seule réponse durable est d’en sortir, et une refonte est généralement le bon moment — c’est même souvent la raison de l’opération.
Qui applique les mises à jour de WordPress ?
Vous, depuis le WordPress Toolkit de Plesk, qui gère les mises à jour du cœur et des extensions depuis l’interface. Si vous préférez ne pas vous en occuper, c’est une prestation d’accompagnement à part.
Un doute sur l’état de votre site ?
Donnez-nous son adresse. Nous regardons ce qui tourne, dans quelle version, et ce qui mérite d’être repris.