Sur un serveur Apache exposé au public, la sécurité repose sur plusieurs couches complémentaires. Il est crucial de combiner pare-feu, authentification stricte et renforcement SELinux pour réduire la surface d’attaque.
Ce texte propose des étapes pratiques pour configurer SELinux et protéger Apache contre les cyberattaques courantes. La suite présente les points clés et bascule vers des vérifications opérationnelles et des outils d’audit.
A retenir :
- Mode enforcing activé, politique ciblée appliquée
- Étiquetage correct des répertoires web et uploads
- Booléens ajustés pour fonctionnalités requises uniquement
- Journaux d’audit centralisés vers SIEM externe
Sécuriser Apache avec SELinux : modes et vérification
Partant des éléments listés précédemment, la première étape consiste à confirmer le mode SELinux et l’état du service Apache. Vérifier ces paramètres évite des interruptions imprévues lors des corrections d’étiquettes et des changements de configuration. Selon Red Hat, la vérification régulière du mode et de la politique est une pratique recommandée pour tout serveur en production.
Vérifier le mode SELinux et l’état du service Apache
Ce contrôle confirme si le serveur bénéficie d’un contrôle d’accès obligatoire actif ou seulement d’un journal permissif. Exécutez getenforce et sestatus pour connaître le mode et la politique en vigueur, puis relevez les anomalies. Selon Red Hat, maintenir SELinux en mode appliqué renforce fortement la protection post-exploitation.
Guide de vérification :
- Commande getenforce pour mode courant
- Commande sestatus pour détails de la politique
- Vérification des logs audit et journald
Commande
But
Sortie attendue
getenforce
Afficher le mode SELinux
Enforcing ou Permissive
sestatus
État détaillé et politique
SELinux status and policy type
systemctl status httpd
État du service Apache
Service actif et sans erreurs
journalctl -u httpd
Logs récents d’Apache
Accès et erreurs applicatives
« J’ai basculé mes webmasters en enforcing et les refus ont révélé des étiquettes manquantes. »
Julie R.
Politiques SELinux pour Apache : contextes, ports et booléens
Enchaînant sur la vérification initiale, la gestion des contextes et des ports s’impose pour éviter les refus intempestifs. Adapter les étiquettes et les booléens préserve le principe du moindre privilège sans ouvrir inutilement le firewall. Selon Red Hat, privilégier semanage fcontext et restorecon évite les solutions temporaires et fragiles.
Contexte des fichiers et correction pérenne des étiquettes
Ce point traite de l’usage de semanage fcontext et restorecon pour appliquer des étiquettes durables aux chemins web. Utiliser chcon seulement pour tests, puis convertir en règle semanage afin d’éviter la perte d’étiquettes au relabelling. Selon des guides d’administration, corriger les étiquettes reste la solution la plus sûre contre les erreurs 403.
Type SELinux
Usage typique
Exemple de chemin
httpd_sys_content_t
Contenu web en lecture seule
/var/www/html
httpd_sys_rw_content_t
Répertoires uploads en écriture
/var/www/html/uploads
httpd_var_run_t
Sockets et runtime HTTPD
/var/run/httpd
var_log_t
Fichiers de logs système
/var/log/httpd
Ports, booléens et modules de politique minimaux
Cette sous-partie explique comment ajouter des ports non standards et activer des booléens nécessaires pour Apache. Utilisez semanage port pour ajouter un port HTTP personnalisé et setsebool -P pour rendre un booléen persistant. Selon des retours de terrain, limiter les modules personnalisés et documenter chaque changement évite les dérives sécuritaires.
Mesures rapides :
- Ajouter http_port_t pour ports non standards
- Activer httpd_can_network_connect si besoin
- Documenter chaque module personnalisé
« Nous avons évité une panne en corrigeant les étiquettes plutôt qu’en désactivant SELinux. »
Marc L.
Le passage suivant aborde l’audit et les réponses automatisées aux refus SELinux sur Apache. La surveillance continue transforme les refus en pistes d’investigation exploitables.
Surveillance, audit et réponse aux cyberattaques pour serveur Apache
Ce chapitre relie la configuration SELinux aux procédures d’audit et d’alerte pour détecter les cyberattaques en temps réel. Centraliser les logs d’audit et coupler setroubleshoot avec un SIEM réduit le temps moyen de détection d’incidents. Selon des pratiques opérationnelles, l’export de /var/log/audit vers un SIEM protège les preuves même après compromission.
Audit, setroubleshoot et intégration SIEM
Cette sous-section explique comment recueillir, analyser et exporter les AVC pour corrélation SIEM. Utilisez ausearch et aureport pour des synthèses quotidiennes, puis filtrez les pics et domaines critiques. Selon les opérateurs de sécurité, automatiser des alertes pour sshd_t et httpd_t permet une réaction plus rapide.
Éléments pour audit :
- Exporter /var/log/audit vers SIEM externe
- Installer setroubleshoot pour diagnostics lisibles
- Configurer alertes pour domaines critiques
Conteneurs, virtualisation et checklist opérationnelle
Pour les hôtes exécutant des conteneurs, le bon étiquetage des volumes est essentiel pour maintenir l’isolation SELinux. Utilisez :Z ou :z lors des montages Docker/Podman pour réétiqueter automatiquement les chemins hôtes. Selon des guides de déploiement, l’inclusion de contrôles SELinux dans CI/CD évite les régressions de sécurité après livraison.
Checklist de renforcement :
- Maintenir SELinux en enforcing sur tous les serveurs
- Étiqueter chemins personnalisés via semanage fcontext
- Automatiser rapports journaliers d’AVC vers équipe
« En production, SELinux a limité un mouvement latéral après compromission, et cela a sauvé notre service. »
Sophie P.
« L’ajout de règles minimales via audit2allow a résolu un blocage sans affaiblir la politique. »
Antoine B.
Source : Red Hat, « SELinux User’s and Administrator’s Guide », Red Hat Documentation, 2024 ; NIST, « Guide to Cybersecurity Practices », NIST, 2022.