cyber / cybersecurite-fondamentale

Hardening système niveau expert

Leçon 251 exercice

Explication

Ce que vous allez apprendre

Durcir la configuration SSH pour éliminer le brute force et la connexion directe en root
Comprendre le rôle du Mandatory Access Control avec SELinux et AppArmor
Régler les paramètres sysctl critiques pour se protéger du spoofing IP et du SYN flood
Auditer les binaires SUID et retirer ceux qui n'en ont pas réellement besoin
Automatiser un audit de conformité avec lynis ou OpenSCAP contre un référentiel CIS Benchmark

Dans quel contexte ?

Un serveur fraîchement provisionné avec une configuration par défaut se fait scanner en quelques minutes par des bots automatisés dès sa mise en ligne, comme n'importe quelle machine exposée sur Internet. Sans durcissement SSH, sans SELinux actif et sans réglages sysctl adaptés, chaque service exposé devient une porte d'entrée potentielle. Le hardening consiste précisément à fermer ces portes une par une, avant même qu'un attaquant ne les cherche.

Le durcissement : réduire la surface d'attaque du système lui-même

Après avoir sécurisé le code et le réseau, cette leçon s'attaque à la fondation : le système d'exploitation qui héberge tout le reste. Le hardening (durcissement) consiste à désactiver, restreindre ou verrouiller tout ce qui n'est pas strictement nécessaire, pour réduire le nombre de portes qu'un attaquant pourrait exploiter.

SSH, la porte d'entrée numéro un d'un serveur

Bonne pratique

SSH est presque toujours le premier service exposé et donc le premier ciblé par les attaques automatisées. Exiger une authentification par clé plutôt que par mot de passe élimine tout un pan d'attaques par force brute, et interdire la connexion directe en root force un attaquant qui obtiendrait un accès limité à devoir encore élever ses privilèges.

SELinux/AppArmor : au-delà des permissions classiques

Les permissions Unix traditionnelles (lecture/écriture/exécution) sont grossières.

Mécanisme	Distribution typique	Ce qu'il confine
SELinux	Red Hat, CentOS, Fedora	Chaque processus dans un contexte de sécurité strict
AppArmor	Debian, Ubuntu	Chaque application via un profil dédié

Même si un processus est compromis, il reste enfermé dans le périmètre défini par sa politique — un confinement qui limite les dégâts même en cas de faille applicative non anticipée.

Le sysctl, réglages invisibles mais critiques

Le noyau Linux possède des paramètres réseau qui, mal configurés, laissent le système vulnérable au spoofing d'adresse IP, aux redirections ICMP malveillantes ou aux attaques par inondation SYN. Ces réglages sont souvent ignorés car invisibles au quotidien, alors qu'ils forment une ligne de défense fondamentale.

L'intérêt d'un audit automatisé (lynis, OpenSCAP)

Auditer manuellement chaque paramètre de durcissement serait fastidieux et sujet à l'oubli. Ces outils comparent automatiquement la configuration réelle du système à des référentiels reconnus (CIS Benchmark), produisant une liste priorisée d'écarts à corriger — un gain de temps considérable et une garantie de ne rien oublier.

Commandes & code

Hardening système niveau expert

# SSH : durcissement de la configuration (/etc/ssh/sshd_config)
cat <<'EOF' >> /etc/ssh/sshd_config
PermitRootLogin no                  # jamais de connexion SSH directe en root
PasswordAuthentication no            # authentification par clé uniquement, pas de mot de passe
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
ClientAliveInterval 300              # déconnexion automatique après inactivité
ClientAliveCountMax 2
AllowUsers deploy@10.0.0.0/24        # restreint qui peut se connecter et depuis où
X11Forwarding no
AllowTcpForwarding no
EOF
systemctl restart sshd

# SELinux (Red Hat/CentOS) : Mandatory Access Control, confine chaque processus à un contexte strict
getenforce                          # vérifier le mode actif (Enforcing / Permissive / Disabled)
setenforce 1                         # forcer le mode Enforcing

# Exemple : autoriser explicitement nginx à se connecter en réseau (bloqué par défaut en SELinux strict)
setsebool -P httpd_can_network_connect 1

# Audit des refus SELinux pour ajuster les policies sans désactiver la protection
ausearch -m avc -ts recent
sealert -a /var/log/audit/audit.log   # génère des suggestions de règles à partir des refus observés

# AppArmor (Debian/Ubuntu) : équivalent de SELinux, profils par application
aa-status                            # liste les profils chargés et leur mode (enforce/complain)
aa-genprof /usr/bin/technologik-api  # génère un profil interactif en observant le comportement réel

# Exemple d'extrait de profil restreignant l'accès fichiers d'un service
cat <<'EOF' > /etc/apparmor.d/usr.bin.technologik-api
/usr/bin/technologik-api {
  /var/lib/technologik/** rw,
  /etc/technologik/config.yaml r,
  deny /home/** rwx,
  deny /root/** rwx,
  network inet stream,
}
EOF
apparmor_parser -r /etc/apparmor.d/usr.bin.technologik-api

# Durcissement du noyau Linux via sysctl (/etc/sysctl.d/99-hardening.conf)
cat <<'EOF' > /etc/sysctl.d/99-hardening.conf
net.ipv4.conf.all.accept_redirects = 0    # ignore les redirections ICMP (anti-MITM réseau)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0  # ignore le source routing (anti-spoofing)
net.ipv4.tcp_syncookies = 1                 # protection contre le SYN flood
net.ipv4.conf.all.rp_filter = 1             # reverse path filtering, anti-spoofing d'IP source
kernel.randomize_va_space = 2               # ASLR complet (Address Space Layout Randomization)
kernel.dmesg_restrict = 1                   # restreint la lecture du buffer noyau aux utilisateurs privilégiés
fs.suid_dumpable = 0                        # empêche la génération de core dumps de binaires suid (fuite mémoire)
EOF
sysctl -p /etc/sysctl.d/99-hardening.conf

# CIS Benchmark : automatiser l'audit de conformité avec des référentiels reconnus
# lynis est un outil d'audit de durcissement généraliste, sans dépendance à un CIS Benchmark spécifique
lynis audit system --quick
# Génère un score de durcissement (hardening index) et une liste priorisée de recommandations

# OpenSCAP pour un audit formel contre un profil CIS/DISA STIG
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis   --results results.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Durcissement des permissions de fichiers sensibles
chmod 600 /etc/shadow /etc/gshadow
chmod 644 /etc/passwd /etc/group
find / -xdev -perm -4000 -type f 2>/dev/null   # audit des binaires SUID (surface d'escalade de privilège)
# Retirer le bit SUID des binaires qui n'en ont pas réellement besoin
chmod u-s /usr/bin/binaire_suid_inutile

# Auditd : journalisation exhaustive des événements système sensibles (obligatoire en environnement expert)
cat <<'EOF' >> /etc/audit/rules.d/hardening.rules
-w /etc/passwd -p wa -k identity_changes
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/ssh/sshd_config -p wa -k ssh_config_changes
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_command_execution
EOF
augenrules --load
ausearch -k privilege_escalation   # rechercher les événements journalisés par cette règle

# Défense en profondeur : synthèse des couches de hardening système niveau expert
1. Accès    : SSH par clé uniquement, MFA sur le bastion, AllowUsers restrictif
2. Noyau     : sysctl durci (ASLR, anti-spoofing, SYN cookies)
3. MAC        : SELinux/AppArmor confinent chaque processus à son strict nécessaire
4. Fichiers    : permissions minimales, audit des binaires SUID, auditd sur les fichiers critiques
5. Conformité   : audit régulier via lynis/OpenSCAP contre un référentiel CIS Benchmark

Résumé

Le hardening SSH (clé uniquement, pas de root direct) est la première ligne de défense d'un serveur exposé.
SELinux/AppArmor apportent un Mandatory Access Control qui limite l'impact même d'un processus compromis.
sysctl durci protège contre le spoofing, les redirections malveillantes et le SYN flood au niveau noyau.
lynis/OpenSCAP automatisent l'audit de conformité contre des référentiels reconnus (CIS Benchmark).

Exercices pratiques

1 disponible

Mission : le serveur fraîchement provisionné déjà scanné par des bots

Objectif : Durcir un serveur nouvellement provisionné sur plusieurs couches et justifier l'ordre de priorité des corrections.

Contexte

Un serveur Technologik vient d'être provisionné avec une configuration Ubuntu par défaut. Les logs montrent déjà, quelques minutes après sa mise en ligne, des dizaines de tentatives de connexion SSH par seconde depuis des adresses IP différentes. La configuration par défaut autorise l'authentification par mot de passe et la connexion directe en root.

Résoudre l’exercice →