La sécurisation des serveurs web repose souvent sur l’architecture du noyau Linux et des choix d’architecture techniques concrets. Cet exposé présente des pratiques vérifiables pour réduire la surface d’attaque, contrôler les accès et protéger les services.
L’approche combine durcissement du noyau Linux, contrôle des permissions et défense réseau pour préserver la protection des données. Consultez la synthèse suivante pour accéder directement aux enjeux prioritaires.
A retenir :
- Surface d’attaque réduite par suppression de services et paquets inutiles
- Gestion des accès basée sur least privilege et authentification forte
- Pare-feu et IDS/IPS avec règles Default-Deny et journalisation
- Intégrité du système assurée par contrôle des fichiers et baselines
Sécurisation du noyau Linux pour serveurs web
Après les éléments synthétiques, le durcissement du noyau Linux devient le premier rempart technique. Cette section détaille sysctl, modules et options de montage pour réduire la surface d’attaque. Les recommandations visent la robustesse sans nuire aux performances applicatives.
Durcissement du noyau et paramètres sysctl pour serveurs web
Le durcissement via sysctl complète la réduction des composants exposés au réseau. J’active tcp_syncookies, limite ICMP et configure kptr_restrict pour cacher les pointeurs. Selon l’ANSSI, ces paramètres font partie des bonnes pratiques de base.
Paramètre
Effet de sécurité
Recommandation
net.ipv4.tcp_syncookies
Protection contre les SYN flood
Activer pour serveurs exposés
kernel.kptr_restrict
Réduction des fuites d’adresses noyau
Valeur stricte en production
kernel.dmesg_restrict
Limitation des infos sensibles via dmesg
Interdire l’accès non privilégié
fs.protected_regular
Protection des fichiers non protégés
Activer pour chemins sensibles
Le tableau synthétise les options courantes et leur rôle pour la sécurité informatique du noyau. Selon Red Hat, la combinaison de ces paramètres limite les fuites d’information et les escalades.
Modules et systèmes de fichiers blacklistés
La réduction des modules actifs complète la politique de paramétrage du noyau. Je recommande de blacklister cramfs, udf, hfsplus et d’interdire le stockage USB sur les serveurs critiques. Cette approche réduit l’exposition aux exploits de pilotes et aux périphériques non sécurisés.
Modules à désactiver :
- cramfs
- udf
- hfsplus
- usb_storage
- firewire
« J’ai constaté une baisse des accès non autorisés après avoir blacklister les modules inutiles et verrouillé les options du noyau. »
Pierre N.
Le renforcement du noyau protège les services mais laisse intacte la gestion des accès. Le passage suivant adresse précisément les mécanismes d’authentification et la gestion des permissions SSH.
Gestion des accès et permissions pour serveurs web
Après le verrouillage du noyau, la gestion des accès devient cruciale pour limiter les mouvements latéraux. Cette section traite SSH, MFA, sudo et la séparation des comptes de service. Ces mesures servent à garantir l’intégrité du système et la traçabilité des opérations.
Authentification SSH, MFA et rotation de clés
La sécurisation SSH reprend les objectifs du noyau en matière d’authentification et de sessions. Je privilégie les clés et MFA, désactive les mots de passe et interdit l’accès root direct. Selon Red Hat, la rotation automatisée des clés réduit l’impact d’une compromission.
Contrôles d’accès recommandés :
- Clés SSH avec MFA obligatoire
- PermitRootLogin no et sudo centralisé
- Rotation régulière des clés et certificats
- Gestion centralisée des comptes via LDAP ou SSO
Pour illustrer, une démonstration montre la configuration sécurisée de sshd_config et des clés. La vidéo couvre PermitRootLogin, AllowUsers et la configuration des suites de chiffrement.
Permissions, séparation des comptes et politiques sudo
La séparation des comptes complète l’authentification en limitant les privilèges disponibles. J’utilise sudo audité, comptes de service distincts et umask strict pour réduire les risques. Selon Amazon AL2023, ces pratiques améliorent la résilience face aux tentatives d’escalade.
Compte
Niveau d’accès
Mesures recommandées
Administrateur
Élevé
Sudo audité, MFA, accès restreint
Compte service
Spécifique
Identités séparées, rotation des secrets
Application
Restreint
Permissions minimales, pas de root
Lecture seule
Limitée
Accès en lecture, logs séparés
« Après l’introduction de sudo audité et de clés rotatives, les incidents liés aux comptes ont chuté rapidement. »
Marc N.
La défense réseau complète ces mesures par segmentation, pare-feu et détection d’intrusion. La mise en œuvre suivante décrit la segmentation, les règles et la surveillance centrale.
Pare-feu, IDS et intégrité du système pour serveurs web
En complément des contrôles d’accès, la sécurité informatique réseau limite les vecteurs externes d’attaque. Ce chapitre traite des règles de pare-feu, IDS/IPS et de la surveillance de l’intégrité. L’enchaînement opérationnel reste centré sur la disponibilité et la protection des données.
Règles de pare-feu, segmentation et gestion des ports
Les règles de pare-feu prolongent la logique Default-Deny appliquée au noyau et aux accès. J’utilise nftables ou iptables, documente chaque ouverture et segmente les zones applicatives. Selon les guides de durcissement, la corrélation logs-IDS facilite la détection rapide des anomalies.
Règles réseau essentielles :
- Default-Deny pour les flux entrants
- Ouverture de ports sur liste blanche uniquement
- VPN pour accès d’administration
- Segmentation par VLAN ou zones
« L’équipe a réduit les faux positifs après ajustement des règles et des seuils d’alarme. »
Sophie N.
Journalisation, SIEM et contrôle d’intégrité pour serveurs web
La surveillance centrale transforme les journaux et les contrôles d’intégrité en alertes exploitables. J’agrège avec rsyslog ou journald, ajoute auditd et pousse vers un SIEM pour corrélation. Selon OpenSCAP et profils CIS, les baselines facilitent les investigations après incident.
« L’usage régulier des baselines et des contrôles d’intégrité a amélioré notre conformité interne. »
Alex N.
La mise en place d’un SIEM et d’alertes réduit le temps moyen de réponse aux incidents. Le dernier point évoque la documentation des procédures et les preuves requises pour auditer.
Source : ANSSI, « Guide de durcissement Linux », ANSSI, 03 octobre 2022 ; Red Hat, « Security Hardening RHEL 9 », Red Hat ; Amazon, « AL2023 Durcissement du noyau », Amazon.
