Un hébergement qui résiste à la prochaine faille PHP
— sans mettre les sites hors ligne.
Des couches de protection plutôt que l'espoir : filtrage en amont de PHP, conteneurs isolés sans shell, détection, délais de réaction engagés et preuves par client. Aussi pour les sites hébergés ailleurs.
PHP2Shell : des attaques avant le correctif
La faille est déclenchée avant l'exécution du code applicatif. Connexion, droits applicatifs et mises à jour WordPress n'y changent donc rien.
L'exploitation a été observée avant que la faille ne soit publique.
Versions corrigées pour les branches PHP actuellement supportées.
Les branches anciennes n'ont que des correctifs source. Beaucoup d'hébergeurs et de systèmes en dépendent.
NSA, NCSC et CERT-EU conseillent de déconnecter les systèmes non corrigeables. HostOps est l'alternative.
En toute transparence : les mesures provisoires ne sont pas un correctif complet
Le durcissement de la configuration, les règles de filtrage et l'isolation des conteneurs réduisent nettement le risque, mais ne remplacent pas la mise à jour vers une version PHP corrigée. Nous vous indiquons ouvertement où vous en êtes et planifions le chemin vers une version supportée. Nous ne promettons pas une sécurité à 100 %.
Sources : Datadog Security Labs · NCSC-NL
Six couches de protection plutôt qu'un pare-feu
Chaque couche arrête ce que la précédente laisse passer. Un zero-day devient un incident maîtrisé plutôt qu'une compromission.
1Filtre périmétrique
Des règles WAF et Caddy (« virtual patching ») sont déployées en quelques minutes : noms de champs démesurés, octets nuls, limites de taille du corps.
2Exécution isolée
Un conteneur par site, versions PHP supportées uniquement, images figées, pas de shell dans l'image, lecture seule, limite mémoire, pas de trafic sortant sans autorisation.
3Détection
Alerte quand un processus PHP lance un shell, en cas de journaux d'erreurs suspects et de nouveaux fichiers (analyse de webshell, contrôle d'intégrité).
4Réaction aux correctifs
Flux CVE, comparaison avec votre inventaire, reconstruction de l'image, instance de test, déploiement progressif. Objectif pour les failles critiques : protégé sous 4 heures.
5Restauration
Instantanés horaires immuables, code du site dans Git, reconstruction plutôt que nettoyage après compromission.
6Transparence
Rapport CVE par client avec horodatage, page de statut et aide pour les notifications NIS2.
Trois raisons pour lesquelles l'hébergement classique ne suffit pas
Corriger seul est trop lent
Des jours s'écoulent entre les premières attaques et un correctif, et les branches PHP anciennes n'ont pas de mise à jour prête. Sans protection avant le correctif, il ne reste qu'à tout couper.
Une faille ne doit pas tout ouvrir
En hébergement mutualisé, de nombreux sites partagent processus, droits et réseau. Dans HostOps, un impact reste limité à un site.
Vous devez pouvoir prouver ce qui s'est passé
NIS2 et les contrats clients exigent des preuves. Pour chaque CVE, nous montrons quand quel système était protégé.
De l'alerte à la preuve en quatre étapes
Chaque intervention en production passe par une validation humaine. Pas de mises à jour de masse à l'aveugle.
Inventaire
Nous relevons versions PHP, mode d'exécution et exposition de vos sites. Uniquement des systèmes qui vous appartiennent ou avec mandat écrit.
Sécuriser
Filtre périmétrique et durcissement immédiats, puis migration vers des conteneurs supportés et isolés.
Surveiller
Détection permanente ; les alertes alimentent un processus d'incident avec responsable désigné.
Prouver
Vous recevez un rapport par CVE : détecté, protégé, corrigé, avec horodatage.
Quatre situations typiques
Les quatre ont le même problème : PHP est partout, mais personne ne veut corriger la nuit pour chaque faille.
PME avec WordPress ou un CMS
Votre site tourne chez un hébergeur bon marché. Vous voulez savoir si vous êtes concerné et avoir un exploitant qui réagit.
Agences
Beaucoup de sites clients, un risque de responsabilité. Il vous faut un délai de réaction ferme et des rapports transmissibles.
Intégrateurs et revendeurs
Vous accompagnez des clients au parc hétérogène et voulez proposer la solution sous votre marque.
Clients existants d'Intelego
Nous connaissons vos systèmes. Nous les contrôlons de façon ciblée et les durcissons dans le cadre de votre suivi actuel.
Preuves pour auditeurs et clients
HostOps fournit les justificatifs : qui a détecté, sécurisé et corrigé quelle faille, et quand.
Gestion des correctifs et des vulnérabilités avec preuve horodatée, aide pour la première notification.
Mesures techniques documentées, exploitation dans l'UE, aide lors d'une notification de violation.
Gestion des vulnérabilités techniques et des changements avec validation et journal.
Sous-traitance des données et délais de réaction par écrit, pas comme argument marketing.
Revendeurs et agences
Vous gardez la relation client, nous assurons l'exploitation. Votre marque, vos prix, notre plateforme et notre délai de réaction.
Marque blanche
Votre image, votre domaine pour les pages de statut et de rapport.
Une réaction pour tous
Une seule réaction CVE s'applique à tous vos clients en même temps.
Rapports pour vos clients
Preuves prêtes à l'emploi par client et par incident, faciles à transmettre.
Quatre niveaux — du test autonome à l'exploitation
Commencez petit et évoluez avec votre situation.
- Déterminer version PHP et mode d'exécution
- Évaluer l'exposition à PHP2Shell
- Recommandation en langage clair
- Systèmes propres ou avec mandat écrit uniquement
- Durcissement de la configuration PHP
- Filtre périmétrique (virtual patch)
- Limites mémoire et frontières de conteneurs
- Règles de détection des appels de shell
- Rapport final avec risque résiduel
- Conteneurs isolés par site
- Versions PHP supportées, images figées
- Réaction aux correctifs avec délai cible pour failles critiques
- Instantanés horaires immuables
- Rapport CVE par client
- En option : TLS via CertOps
- Votre marque et vos rapports
- Plusieurs clients finaux sous un contrat
- Réaction CVE unifiée
- Support de second niveau pour votre équipe
Tous les prix hors TVA, B2B. Les valeurs actuelles figurent dans le configurateur. Les délais de réaction sont des objectifs et dépendent de la disponibilité en amont.
Questions fréquentes
Pourquoi une mise à jour WordPress n'aide-t-elle pas ?
La faille est dans PHP lui-même et se déclenche lors du traitement de la requête, avant WordPress ou tout plugin. Une mise à jour du CMS n'y change rien. Ce qui compte : la version de PHP et la protection en amont.
Suis-je concerné ?
Probablement, si votre site utilise PHP. PHP 5.4 à 8.5 est concerné dans tous les modes courants. Le contrôle rapide évalue votre situation.
Un filtre ou un WAF suffit-il ?
Il réduit nettement le risque mais reste une mesure provisoire. C'est pourquoi HostOps combine plusieurs couches et vous mène vers une version PHP supportée.
Et PHP 7.4 ou 8.0 ?
Seuls des correctifs source existent. Nous n'exploitons ces branches que temporairement et durcies, et planifions la migration avec vous.
Contrôlez-vous aussi des sites tiers ?
Non. Nous ne contrôlons que des systèmes qui vous appartiennent ou couverts par un mandat écrit. Scanner des systèmes tiers sans demande peut être pénalement répréhensible en Allemagne.
Que se passe-t-il après une compromission ?
Nous reconstruisons à partir d'un code sain et d'un instantané immuable au lieu de nettoyer. Vous recevez un rapport d'incident qui vous aide pour vos obligations de notification.
Où tournent les données ?
Dans l'UE. Nous concluons avec vous un contrat de sous-traitance.
Savoir où vous en êtes
Nous contrôlons vos systèmes PHP, les sécurisons et vous montrons le chemin
vers une exploitation qui résiste à la prochaine faille.