Introduction : Le Processus Continu de la Sécurité
Ce guide s'adresse à un public d'experts (administrateurs systèmes, DevOps) et a pour objectif de détailler les étapes critiques pour le durcissement d'un serveur Apache. Nous aborderons une configuration de A à Z, en partant du principe que la sécurité est un processus continu et non une simple case à cocher.
Section 1 : Fondations - Mises à Jour et Principes de Base
La sécurité d'une application ne vaut que ce que vaut la sécurité du système sous-jacent. Une base saine est non négociable.
- Maintien à jour du système : Les vulnérabilités sont découvertes en permanence. Appliquer les correctifs est la première ligne de défense. Utilisez le gestionnaire de paquets de votre distribution.
Sur Debian/Ubuntu :sudo apt-get update && sudo apt-get dist-upgrade
Sur RHEL/CentOS :sudo dnf upgrade --security - Utilisateur Apache dédié : Apache ne doit JAMAIS tourner avec les privilèges
root. Il doit utiliser un utilisateur et un groupe avec des droits minimaux (ex: `www-data`, `apache`). Vérifiez ceci dans votre fichier de configuration (`apache2.conf` ou `httpd.conf`) avec les directives `User` et `Group`. - Permissions des fichiers Web : Une configuration de permissions stricte est cruciale pour empêcher l'escalade de privilèges ou la modification de fichiers via une vulnérabilité applicative. La recommandation est de donner la propriété des fichiers à un utilisateur non-Apache (ex: `root` ou un utilisateur de déploiement) et d'assigner le groupe à l'utilisateur Apache.
Les répertoires nécessitant une écriture par l'application (uploads, cache) doivent être traités spécifiquement et avec la plus grande prudence.# Donnez la propriété de tous les fichiers à root sudo chown -R root:www-data /var/www/votre-site # Appliquez des permissions restrictives sudo find /var/www/votre-site -type d -exec chmod 750 {} \; sudo find /var/www/votre-site -type f -exec chmod 640 {} \;
Section 2 : Durcissement de la Configuration Apache
La configuration par défaut d'Apache est conçue pour être fonctionnelle, pas pour être sécurisée. Le principe de la surface d'attaque minimale doit guider chaque décision.
2.1 Dissimulation d'Informations
Ne facilitez pas la tâche des attaquants en leur donnant des informations sur votre infrastructure.
# Dans apache2.conf ou un fichier de conf dédié (ex: conf-available/security.conf)
# N'affiche que "Apache" et non la version détaillée.
ServerTokens Prod
# Supprime la signature d'Apache sur les pages d'erreur.
ServerSignature Off
# Empêche la fuite d'informations sur les inodes et la date de modification via l'en-tête ETag.
FileETag None
2.2 Désactivation des Modules et Fonctionnalités Inutiles
Chaque module activé est une porte d'entrée potentielle.
- Listez les modules :
apache2ctl -Mouhttpd -M. - Désactivez ce qui n'est pas essentiel :
mod_info,mod_status(sauf si l'accès est très restreint par IP),mod_userdir,mod_autoindex.sudo a2dismod info status autoindex - Interdire le listage des répertoires : Utilisez l'option
-Indexes. - Centraliser la configuration : Pour éviter que des fichiers
.htaccessne surchargent les directives de sécurité, interdisez-les par défaut. Cela améliore également les performances.
<Directory />
# Interdit l'utilisation des .htaccess
AllowOverride None
# Politique par défaut : tout refuser
Require all denied
</Directory>
<Directory /var/www/votre-site>
# Enlève la possibilité de lister les répertoires
Options -Indexes FollowSymLinks
# Autorise explicitement l'accès à ce répertoire
Require all granted
</Directory>
2.3 Limitation des Méthodes HTTP
N'autorisez que les verbes HTTP strictement nécessaires à votre application (typiquement `GET`, `POST`, `HEAD`).
<Directory /var/www/votre-site>
<LimitExcept GET POST HEAD>
Require all denied
</LimitExcept>
</Directory>
Section 3 : Déploiement d'un Pare-feu Applicatif Web (WAF)
Un WAF analyse le trafic HTTP en temps réel pour détecter et bloquer les attaques. `ModSecurity` avec le Core Rule Set (CRS) de l'OWASP est la référence open-source.
- Installation :
sudo apt-get install libapache2-mod-security2 - Configuration de base : Renommez
/etc/modsecurity/modsecurity.conf-recommendedenmodsecurity.confet activez le moteur.# Dans /etc/modsecurity/modsecurity.conf SecRuleEngine On - Intégration du OWASP Core Rule Set (CRS) : Le CRS est l'intelligence du WAF.
Attention : Le CRS peut générer des faux positifs. Il est crucial de le déployer d'abord en mode détection (# Dans votre configuration Apache (ex: /etc/apache2/mods-enabled/security2.conf) <IfModule security2_module> SecRuleEngine On # Inclure les règles de base de ModSecurity et le CRS de l'OWASP IncludeOptional /etc/modsecurity/*.conf IncludeOptional /usr/share/modsecurity-crs/*.conf IncludeOptional /usr/share/modsecurity-crs/rules/*.conf </IfModule>SecRuleEngine DetectionOnly) et d'analyser les logs (/var/log/apache2/modsec_audit.log) pour créer des règles d'exclusion adaptées à votre application avant de passer en mode blocage (`On`).
Section 4 : Configuration SSL/TLS Robuste
Le chiffrement n'est plus une option. Visez une note A+ sur les tests comme SSL Labs.
<VirtualHost *:443>
ServerName votre-domaine.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/votre-domaine.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/votre-domaine.com/privkey.pem
# Protocoles : N'autoriser que les versions modernes et sécurisées de TLS.
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
# Cipher Suites : Une liste moderne qui privilégie la Forward Secrecy.
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
# L'ordre des ciphers est maintenant géré côté client (plus performant).
SSLHonorCipherOrder off
# Les tickets de session peuvent présenter des faiblesses.
SSLSessionTickets off
# Activer HSTS (après avoir confirmé que tout votre site fonctionne en HTTPS)
# Durée de 2 ans, inclut les sous-domaines et demande le pré-chargement dans les navigateurs.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</VirtualHost>
Section 5 : En-têtes HTTP de Sécurité
Utilisez les en-têtes pour donner des instructions de sécurité au navigateur du client.
# À placer dans votre configuration Apache globale ou VirtualHost.
# Nécessite mod_headers (sudo a2enmod headers)
# Empêche le "MIME-sniffing"
Header set X-Content-Type-Options "nosniff"
# Contrôle l'utilisation du site dans une <frame>, <iframe>, <embed> ou <object>. Prévient le Clickjacking.
Header set X-Frame-Options "SAMEORIGIN"
# Politique de référant pour contrôler les informations envoyées dans l'en-tête Referer.
Header set Referrer-Policy "strict-origin-when-cross-origin"
# Content Security Policy (CSP) : Puissante défense contre les attaques XSS.
# ATTENTION : Une CSP doit être définie avec une grande précision pour ne pas casser votre site.
# L'exemple ci-dessous est très restrictif.
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'; frame-ancestors 'self';"
Section 6 : Journalisation et Surveillance
La sécurité est un processus actif. La surveillance est votre système d'alarme.
- Logs Apache : Augmentez le niveau de log si nécessaire (`LogLevel warn`). Analysez régulièrement les fichiers `error_log` et `access_log` à la recherche d'anomalies (pics de 404, requêtes étranges).
- Logs ModSecurity : Le fichier `modsec_audit.log` est votre mine d'or pour comprendre les attaques bloquées et affiner vos règles.
- Automatisation : Utilisez des outils comme `fail2ban` pour analyser les logs en temps réel et bannir automatiquement les adresses IP présentant un comportement malveillant (tentatives de connexion forcées, scans de vulnérabilités, etc.).