Optimiser et Sécuriser un Hébergement Web sous Plesk (PHP-FPM, Nginx & WAF)

Un hébergement Plesk sorti d'installation fonctionne, mais il est rarement configuré pour la performance et la sécurité en production. Deux leviers font toute la différence : l'isolation des processus PHP via PHP-FPM (chaque site tourne sous son propre utilisateur, avec ses propres pools) et l'usage de Nginx comme reverse-proxy pour délester Apache du trafic statique. En combinant ces briques avec un pare-feu applicatif (WAF) ModSecurity et un TLS strict, vous obtenez un hébergement B2B rapide, cloisonné et résilient face aux attaques web les plus courantes.

Ce guide couvre l'ensemble de la chaîne : passage de Plesk en reverse-proxy Nginx, tuning fin de PHP-FPM et d'OPcache, activation du WAF avec les règles OWASP, puis sécurisation TLS via Let's Encrypt et HSTS. Chaque étape est illustrée par des blocs de configuration copiables.

Prérequis

• Un serveur (VPS ou dédié Plennyx) sous Debian/Ubuntu avec Plesk Obsidian installé et à jour.
• Un accès SSH root ou un utilisateur dans le groupe sudo.
• Un domaine pointant sur l'adresse IP du serveur (enregistrement DNS A/AAAA correct) pour la validation Let's Encrypt.
• Les composants Nginx, PHP-FPM et ModSecurity disponibles dans l'installeur de composants Plesk.

Comprendre l'architecture : Apache seul vs Nginx + PHP-FPM

Par défaut, Plesk sert souvent le contenu via Apache avec le module mod_php, qui embarque l'interpréteur PHP dans chaque processus Apache, y compris pour livrer une simple image. Le passage à Nginx en frontal avec PHP-FPM sépare radicalement le traitement des fichiers statiques (rapide, léger) du traitement PHP (isolé dans des pools dédiés). Le tableau suivant résume les différences structurantes.

La configuration recommandée pour la majorité des hébergements B2B est Nginx en reverse-proxy devant Apache : Nginx encaisse le trafic et sert le statique, Apache reste disponible pour les directives .htaccess, et PHP est délégué à PHP-FPM. On conserve ainsi la compatibilité applicative tout en gagnant en performance.

Étape 1 : Configurer Nginx en reverse-proxy

Vérifiez d'abord que le composant Nginx est bien installé et actif au niveau du serveur, puis activez-le pour l'abonnement concerné. La commande plesk sbin nginxmng pilote l'état global du service.

# Vérifier l'état du proxy Nginx
sudo plesk sbin nginxmng --status

# Activer Nginx comme reverse-proxy (s'il ne l'est pas déjà)
sudo plesk sbin nginxmng --enable

# Recharger la configuration web générée par Plesk
sudo plesk repair web -y

Pour que Nginx serve directement les fichiers statiques sans passer par Apache, ouvrez le domaine dans Plesk (Sites web & Domaines > Apache & nginx) et cochez « Traiter les fichiers statiques directement par nginx ». En complément, ajoutez ces directives Nginx additionnelles pour activer la compression et le cache navigateur des assets.

# Cache long pour les assets statiques
location ~* \.(jpg|jpeg|png|gif|webp|svg|css|js|woff2|ico)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
    access_log off;
}

# Compression Gzip (delta réseau réduit)
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Validez toujours la syntaxe avant de recharger le service, afin de ne jamais couper la production sur une erreur de configuration.

sudo nginx -t && sudo systemctl reload nginx

Étape 2 : Optimiser PHP-FPM et OPcache

Dans Plesk, sélectionnez le domaine puis Paramètres PHP et choisissez un gestionnaire de type FPM géré par le serveur web dédié (nginx). Le cœur du réglage consiste à dimensionner le nombre de workers PHP. Le mode dynamic est un bon compromis pour un serveur mutualisé.

Dimensionner les workers

La règle de calcul de pm.max_children est simple : (RAM allouée à PHP) ÷ (mémoire moyenne par worker). Mesurez d'abord la consommation réelle d'un process PHP-FPM.

# Mémoire moyenne (RSS) consommée par les process PHP-FPM
ps --no-headers -o rss -C php-fpm \
  | awk '{ sum += $1; n++ } END { if (n>0) printf "%.0f Mo/worker\n", sum/n/1024 }'

Le tableau ci-dessous fournit des valeurs de départ réalistes selon la RAM réservée à PHP (en supposant ~60 Mo par worker). Ajustez ensuite selon vos mesures.

Ces réglages se saisissent dans le champ Directives PHP additionnelles de Plesk (section [php-fpm]) ou directement dans le pool.

pm = dynamic
pm.max_children = 64
pm.start_servers = 12
pm.min_spare_servers = 8
pm.max_spare_servers = 20

; Recycle les workers pour prévenir les fuites mémoire
pm.max_requests = 500

; Coupe les requêtes qui traînent (protège contre les blocages)
request_terminate_timeout = 120s

Activer et régler OPcache

OPcache met en cache le bytecode PHP compilé et évite de recompiler les scripts à chaque requête : c'est le gain de performance le plus rentable sur une application PHP. Ajoutez ces directives dans la configuration PHP du domaine.

opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60
opcache.save_comments = 1

; En production stable, passez validate_timestamps à 0
; puis videz le cache manuellement à chaque déploiement

Rechargez PHP-FPM pour appliquer, puis vérifiez que le service est bien opérationnel.

sudo plesk bin php_handler --reread
sudo systemctl reload "plesk-php*-fpm"

Étape 3 : Sécuriser avec le WAF ModSecurity (OWASP)

Le pare-feu applicatif web (WAF) ModSecurity filtre les requêtes HTTP/S avant qu'elles n'atteignent votre application : injections SQL, XSS, traversées de répertoires et exploits connus sont bloqués en amont. Plesk l'intègre nativement, couplé au jeu de règles OWASP Core Rule Set (CRS).

Activez ModSecurity et sélectionnez le jeu de règles OWASP en ligne de commande, ou via Outils & Paramètres > Pare-feu applicatif (ModSecurity).

# Activer ModSecurity en mode détection (recommandé au démarrage)
sudo plesk bin server_pref --update-web-app-firewall \
  -waf-rule-engine on \
  -waf-rule-set owasp \
  -waf-mode detection-only

# Vérifier la configuration active
sudo plesk bin server_pref --show-web-app-firewall

Après quelques jours en detection-only, analysez les journaux pour repérer les faux positifs, ajustez le niveau de paranoïa du CRS, puis basculez en mode blocage actif.

# Passer le moteur en mode blocage une fois les règles affinées
sudo plesk bin server_pref --update-web-app-firewall -waf-mode on

# Surveiller les blocages ModSecurity en temps réel
sudo tail -f /var/log/modsec_audit.log

• Mode détection : journalise sans bloquer, idéal pour calibrer sans risque de rupture de service.
• Paranoia level : plus il est élevé, plus la détection est stricte (et plus les faux positifs augmentent).
• Exclusions ciblées : désactivez une règle par son id plutôt que le jeu entier en cas de faux positif.

Étape 4 : Let's Encrypt et redirection HSTS obligatoire

Un hébergement moderne doit servir l'intégralité de son trafic en HTTPS. L'extension Let's Encrypt de Plesk automatise l'émission et le renouvellement des certificats gratuits. Émettez le certificat pour le domaine, ses alias www et les sous-domaines de messagerie.

# Émettre un certificat pour le domaine + www + webmail
sudo plesk bin extension --exec letsencrypt cli.php \
  -d exemple.com -d www.exemple.com -m [email protected] \
  --webmail

Activez ensuite dans Plesk la redirection permanente HTTP → HTTPS ainsi que l'option « Redirection permanente sécurisée (HSTS) ». Le mécanisme HSTS ordonne aux navigateurs de n'utiliser que HTTPS, éliminant les attaques de rétrogradation (downgrade) et de type SSL-strip. Pour un contrôle fin, ajoutez l'en-tête dans les directives Nginx du domaine.

# HSTS : force HTTPS pendant 1 an, sous-domaines inclus, éligible preload
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# Durcissement complémentaire des en-têtes
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

N'activez le drapeau preload que lorsque vous êtes certain que tout le trafic (domaine et sous-domaines) est disponible en HTTPS, car l'inscription sur la liste de préchargement des navigateurs est difficile à révoquer. Validez enfin votre configuration TLS avec un outil d'audit externe pour viser une note A+.

Récapitulatif : checklist de mise en production

• Nginx activé en reverse-proxy, fichiers statiques servis directement, Gzip et cache navigateur en place.
• PHP-FPM en mode dynamic, pm.max_children calibré sur la RAM réelle, max_requests défini.
• OPcache activé avec une mémoire et un nombre de fichiers adaptés à l'application.
• ModSecurity actif avec l'OWASP CRS, passé en mode blocage après calibration.
• Certificat Let's Encrypt émis, redirection HTTPS et HSTS obligatoires activés.

FAQ : questions fréquentes

Faut-il utiliser Nginx seul ou Nginx + Apache sur Plesk ?

Pour des performances maximales, activez le mode Nginx en reverse-proxy avec service des fichiers statiques par Nginx et PHP traité par PHP-FPM. Le mode Nginx-only (sans Apache) est encore plus rapide, mais il ignore les directives .htaccess : il n'est recommandé que si votre application n'en dépend pas, ou si vous avez migré ces règles dans la configuration Nginx.

Comment calculer la valeur de pm.max_children pour PHP-FPM ?

Divisez la RAM disponible pour PHP par la consommation moyenne d'un worker. Exemple : 4 Go réservés à PHP et 60 Mo par worker donnent environ 66 pour pm.max_children. Mesurez la consommation réelle avec la commande ps et gardez une marge de sécurité pour l'OS, la base de données et le cache.

Le WAF ModSecurity de Plesk ralentit-il le site ?

L'impact du jeu de règles OWASP CRS est généralement inférieur à quelques millisecondes par requête. Pour limiter les faux positifs et le surcoût, démarrez en mode détection seule, ajustez le niveau de paranoïa (paranoia level), puis passez en mode blocage une fois les règles affinées.