# Sécuriser soi-même un serveur dédié et un vServer

> Sécuriser un vServer après PHP2Shell : vérifier les paquets PHP, repérer les backports, redémarrer tous les workers et durcir durablement le serveur dédié.

Source : https://phpsos.de/fr/server/root-server-vserver/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** qui administre lui-même un serveur dédié ou un vServer doit aussi le sécuriser lui-même après PHP2Shell : amener les paquets PHP à un état corrigé, redémarrer tous les processus PHP et vérifier le résultat. L'exploitant du centre de données ne s'occupe en général que du matériel, de la virtualisation et du réseau. Il vaut ensuite la peine de durcir durablement le serveur.

## Votre responsabilité avec votre propre serveur

Avec un serveur dédié ou un vServer non managé, vous louez de la puissance de calcul, pas un suivi. Système d'exploitation, serveur web, PHP, base de données, pare-feu, sauvegardes et supervision sont entre vos mains. Pour la direction et les propriétaires, cela signifie : si personne en interne ou chez un prestataire n'a expressément repris ces tâches, personne ne les effectue.

PHP2Shell rend cela visible. Les deux failles CVE-2026-109618 et CVE-2026-109619 se trouvent dans PHP lui-même et permettent l'exécution de code sans authentification. Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande la mise à jour immédiate et, si ce n'est pas possible, de déconnecter temporairement le serveur web du réseau.

## Sécuriser un vServer : vérifier l'inventaire et l'état des paquets

Commencez par vous faire une idée des versions de PHP installées et de leur origine. De nombreux serveurs utilisent, en plus des paquets de la distribution, des sources de paquets supplémentaires. Les commandes suivantes se contentent de lire. Les noms de paquets sont des exemples.

```bash
# Debian/Ubuntu : paquets PHP installés et leur provenance
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'

# Quels binaires PHP existent au juste ?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
```

Le numéro de version seul ne suffit pas. Les distributions livrent souvent les corrections de sécurité sous forme de backport ; le numéro affiché reste alors plus ancien. Le journal des modifications du paquet est déterminant.

```bash
# Debian/Ubuntu (nom de paquet à titre d'exemple)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# Famille RHEL (nom de paquet à titre d'exemple)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
```

Un guide détaillé figure sous [Vérifier la version de PHP et l'état du correctif](https://phpsos.de/fr/php2shell/php-version-pruefen/).

## Installer la mise à jour et renouveler tous les processus

Installez les mises à jour via le gestionnaire de paquets, puis redémarrez chaque service qui charge PHP. Selon l'architecture, il s'agit de PHP-FPM, d'Apache avec mod_php, de LiteSpeed ou d'un serveur d'applications. De nouveaux fichiers sur le disque ne suffisent pas tant que d'anciens processus tournent en mémoire.

```bash
# Trouver les services qui utilisent PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Afficher les processus avec leur heure de démarrage
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu : repérer les programmes avec des bibliothèques obsolètes (si installé)
needrestart -r l
```

Chaque processus concerné devrait avoir été démarré après la mise à jour. L'outil `needrestart` sur les systèmes Debian, qui affiche les services dotés de bibliothèques obsolètes, est utile. Les détails du redémarrage sont décrits dans [Redémarrer PHP-FPM et tous les workers](https://phpsos.de/fr/php2shell/php-fpm-neustart/).

> **Important:**
> Un correctif ne supprime pas les logiciels malveillants introduits avant la mise à jour. Conservez les journaux du serveur web à partir du 20 octobre 2026 et recherchez des traces sur le serveur avant de le classer comme sain.

Pour une première recherche de traces, quelques vérifications qui ne modifient rien s'offrent à vous. Recherchez les fichiers PHP créés ou modifiés dans les répertoires web depuis le 17 octobre 2026, les entrées inconnues dans les crontabs de tous les utilisateurs, les nouveaux utilisateurs système et clés SSH, ainsi que les processus de l'utilisateur du serveur web qui maintiennent des connexions sortantes.

```bash
# Fichiers PHP modifiés depuis le 17/10/2026 (chemin à titre d'exemple)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Connexions réseau avec le processus associé
ss -tupn
```

Aucune de ces vérifications ne prouve à elle seule une intrusion, et un résultat vide ne prouve pas le contraire. Elles montrent toutefois si une analyse plus approfondie est nécessaire. Travaillez sur des copies des journaux et ne modifiez pas les fichiers suspects tant que l'état du système n'est pas sauvegardé. En cas de découverte, une enquête méthodique est la voie sûre. Dans ce cas, n'éteignez pas simplement le serveur et ne le réinstallez pas immédiatement, car vous perdriez des traces importantes pour évaluer les obligations de notification et pour un éventuel dépôt de plainte.

## Durcir le serveur durablement

Après le correctif d'urgence vient la sécurisation de base. Elle n'empêche pas toutes les failles, mais limite les dégâts et raccourcit le temps de réaction la prochaine fois. Les points suivants ont fait leurs preuves :

- **Accès :** SSH uniquement par clé, pas de connexion root directe, interfaces d'administration accessibles uniquement depuis des réseaux connus.
- **Pare-feu :** n'ouvrir que les ports réellement nécessaires, restreindre les connexions sortantes du serveur web.
- **Configuration PHP :** désactiver les fonctions dangereuses, `open_basedir` par site, pools et utilisateurs propres à chaque application.
- **Droits sur les fichiers :** le serveur web ne doit pas pouvoir écrire dans le code du programme, les répertoires d'envoi n'exécutent pas PHP.
- **Mises à jour :** installer automatiquement les mises à jour de sécurité, prévoir de façon fixe le redémarrage et le contrôle.
- **Sauvegardes :** sauvegardes selon la règle 3-2-1, au moins une copie en dehors du serveur et protégée contre toute modification.
- **Journaux :** collecter les journaux de façon centralisée et les conserver assez longtemps.

À quoi ressemble une sauvegarde fiable, vous le trouverez dans [Sauvegardes selon la règle 3-2-1](https://phpsos.de/fr/ratgeber/backups-3-2-1/). Pour les entreprises, l'IT-Grundschutz du BSI constitue un cadre approprié.

## Quand un serveur managé est le meilleur choix

Un serveur dédié propre vaut la peine si quelqu'un en assure l'entretien de façon fiable : suivre les mises à jour, évaluer des situations comme PHP2Shell, pouvoir réagir la nuit. Si cette capacité manque, un serveur managé ou un contrat de maintenance ferme est judicieux. Dans les deux cas, il est important de consigner les responsabilités par écrit. Plus de détails sous [Serveur managé : clarifier la responsabilité](https://phpsos.de/fr/server/managed-server/).

## Comment PHP SOS aide-t-il concrètement ?

- Nous recensons toutes les installations PHP, sources de paquets et services de votre serveur et évaluons l'état réel des correctifs.
- Nous installons les mises à jour, redémarrons tous les processus et documentons le résultat.
- Nous examinons le serveur à la recherche de traces de compromission et sauvegardons les journaux pour une analyse ultérieure.
- Dans le cadre de notre [durcissement de serveur](https://phpsos.de/fr/leistungen/server-haertung/), nous configurons proprement les accès, le pare-feu, les pools PHP et les droits.
- Sur demande, nous assurons l'entretien continu par un [contrat de maintenance sécurité](https://phpsos.de/fr/leistungen/security-wartungsvertrag/).


## Questions fréquentes

**Mon centre de données corrige-t-il automatiquement le vServer ?**  
Pour les serveurs dédiés et vServers non managés, en général non. Le fournisseur met à disposition le matériel ou la virtualisation et le réseau ; vous gérez vous-même le système d'exploitation et tous les services qui y tournent. En cas de doute, consultez votre contrat.

**Les mises à jour de sécurité automatiques suffisent-elles ?**  
Elles aident, mais ne remplacent pas le contrôle. Les mises à jour automatiques ne redémarrent pas toujours les processus PHP en cours et ne couvrent souvent pas les paquets issus de sources tierces. Après chaque mise à jour de sécurité, vérifiez l'état des paquets et les heures de démarrage des processus.

**Comment savoir si mon paquet contient un backport ?**  
Dans le journal des modifications du paquet et dans les avis de sécurité de votre distribution. Si le numéro CVE y figure, la correction est incluse, même si le numéro de version paraît plus ancien. Si l'entrée manque, clarifiez l'état avant de classer le serveur comme corrigé.

**Que faire si aucun correctif ne sort pour ma version de PHP ?**  
PHP 8.1 et antérieur ne reçoivent plus de mises à jour officielles. Appliquez les mesures transitoires selon php.net, planifiez rapidement le passage à une version prise en charge et, si nécessaire, déconnectez temporairement le serveur du réseau, conformément à la recommandation du BSI.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net : versions prises en charge](https://www.php.net/supported-versions.php)
- [BSI IT-Grundschutz (socle de sécurité informatique de l'office fédéral allemand)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)