Modèle de menace et surface d'attaque

Objectif

Avant de durcir un serveur, savoir ce que l'on protège, contre qui et par où un attaquant peut entrer. Vous repartirez avec une méthode simple d'inventaire que vous réutiliserez dans toutes les leçons suivantes.

L'essentiel

• Durcir (hardening), c'est retirer à un système tout ce dont il n'a pas besoin et verrouiller ce qui reste. Ce n'est pas installer « un logiciel de sécurité ».
• Un modèle de menace répond à trois questions : quels actifs ?, quelles menaces ?, quelles mesures ?
• La surface d'attaque, c'est tout ce qu'un attaquant peut toucher : ports ouverts, comptes, logiciels installés, fichiers trop ouverts, personnes.
• Deux principes guident tout le cours : minimisation (moins de choses = moins de failles) et défense en profondeur (plusieurs barrières indépendantes).
• On mesure avant et on mesure après : sans inventaire initial, impossible de prouver qu'un serveur est plus sûr.

1. Pourquoi durcir ? Trois situations marocaines

Une PME de Casablanca vend en ligne. Son site tourne sur un VPS loué. Un matin, la page d'accueil affiche le message d'un pirate. Cause : une extension web jamais mise à jour, et un compte SSH admin avec le mot de passe Admin2024.

Un hôpital à Fès a un serveur de rendez-vous. Le serveur contient des noms, des numéros de téléphone et des motifs de consultation. Ce sont des données à caractère personnel au sens de la loi 09-08, sous le contrôle de la CNDP. Une fuite engage la responsabilité de l'établissement.

Une banque à Rabat est soumise à des règles strictes : la loi 05-20 sur la cybersécurité et les directives de la DGSSI (Direction générale de la sécurité des systèmes d'information). Les auditeurs demandent des preuves : configuration écrite, journaux, rapport d'audit.

Dans les trois cas, la question n'est pas « est-ce que mon serveur peut être attaqué ? » (oui, il le sera) mais « combien d'efforts l'attaquant devra-t-il faire, et verrai-je l'attaque ? ».

2. Construire un modèle de menace en 15 minutes

Prenez une feuille, ou un simple fichier texte, et remplissez trois colonnes.

Posez-vous ensuite la question « qui ? » :

• le robot qui scanne tout Internet (le plus fréquent : quelques minutes après sa mise en ligne, un VPS reçoit déjà des tentatives SSH) ;
• le cybercriminel qui cherche un serveur à chiffrer contre rançon ;
• l'initié : un ancien employé, un prestataire dont le compte n'a jamais été fermé ;
• l'erreur humaine : un fichier de sauvegarde laissé dans le dossier web.

Le durcissement protège surtout contre les deux premiers et le dernier. Contre l'initié, il faut en plus des procédures : fermer les comptes au départ, tracer les actions (leçon 3.2).

3. Mesurer la surface d'attaque

Voici l'inventaire de départ, à faire sur chaque serveur. Toutes ces commandes sont en lecture seule : elles ne changent rien.

# Quel système, quelle version ? (la durée du support en dépend)
cat /etc/os-release
uname -r                          # version du noyau

# Qui écoute sur le réseau ? (TCP et UDP, avec le programme)
ss -tulpn
#  0.0.0.0:22   → ouvert à tout le monde
#  127.0.0.1:3306 → seulement en local (bien pour une base de données)

# Quels comptes peuvent ouvrir une session ?
awk -F: '$7 !~ /(nologin|false)$/ {print $1, $7}' /etc/passwd

# Qui peut devenir root ?
getent group sudo wheel           # sudo sur Debian/Ubuntu, wheel sur Rocky
ls /etc/sudoers.d/

# Combien de logiciels installés ? (chaque paquet est une faille possible)
dpkg -l | grep -c '^ii'           # Debian / Ubuntu
rpm -qa | wc -l                   # Rocky / RHEL

# Quels services démarrent avec la machine ?
systemctl list-unit-files --state=enabled

# Quels programmes s'exécutent avec les droits de leur propriétaire (SUID) ?
find / -xdev -type f -perm -4000 2>/dev/null

Gardez ces sorties dans un dossier daté, par exemple /root/inventaire/2026-10-19/. À la fin du cours, vous referez le même inventaire et vous comparerez.

4. Les principes qui guident chaque décision

Minimisation. Un service qui n'est pas installé ne peut pas être piraté. Avant de « sécuriser » un serveur FTP, demandez-vous s'il est encore utile.

Moindre privilège. Chaque compte, chaque service n'a que les droits dont il a besoin. Le serveur web n'a pas à écrire dans ses propres fichiers PHP.

Défense en profondeur. Pare-feu, plus SSH durci, plus fail2ban, plus journaux : si une barrière tombe, la suivante tient.

Traçabilité. Ce qui n'est pas journalisé n'a pas existé. Sans journaux, impossible d'expliquer un incident à la direction, à la CNDP ou à maCERT (le CERT national rattaché à la DGSSI).

Réversibilité. Chaque changement est noté, testé et réversible. On ne durcit jamais un serveur en production sans une console de secours (accès VNC du fournisseur, console de la VM).

5. Les référentiels : ne pas réinventer la roue

Vous n'êtes pas seul. Des organismes publient des listes de recommandations :

• ANSSI (agence française) : Recommandations de configuration d'un système GNU/Linux. Gratuit, sous Licence Ouverte, en français. Il classe les mesures par niveau (minimal, intermédiaire, renforcé, élevé).
• CIS Benchmarks (Center for Internet Security) : des guides très détaillés par distribution. Gratuits à lire, mais leur licence interdit de les recopier.
• DGSSI : la Directive nationale de la sécurité des systèmes d'information (DNSSI) fixe des règles pour les administrations et les infrastructures d'importance vitale au Maroc.

Ce cours suit le même esprit et vous apprend à appliquer ces mesures, puis à les vérifier avec Lynis (leçon 4.1).

6. Comment se dérouleront les labs

Les labs se font sur votre propre machine virtuelle (jamais sur votre PC personnel, jamais sur un serveur de production) :

sudo ml demarrer hardening-1-1    # prépare la machine et affiche les tâches
# … vous travaillez …
sudo ml verifier                  # contrôle chaque tâche

Certaines leçons modifient des fichiers sensibles (SSH, pare-feu). Pour ne jamais vous couper l'accès, nous travaillerons souvent sur une copie dans /root/durcir/, que l'on teste avant de l'appliquer. Gardez toujours la console de la VM ouverte.

Selon la version

Pièges fréquents

• Durcir sans inventaire : vous ne saurez jamais ce que vous avez réellement amélioré, ni ce que vous avez cassé.
• Copier une liste de commandes trouvée en ligne sans comprendre : c'est la meilleure façon de se couper SSH ou de casser une application.
• Oublier les comptes « oubliés » : un prestataire parti avec un shell actif est une porte ouverte. Le compte sync (shell /bin/sync) est normal sur Debian.
• Croire qu'un VPS « tout neuf » est sûr : les images des hébergeurs ont souvent l'authentification SSH par mot de passe activée.

Lab

Vous allez commencer l'inventaire de votre serveur :

1. noter le système et sa version à partir de /etc/os-release ;
2. fermer le compte d'un prestataire parti ;
3. lister les comptes qui peuvent encore ouvrir une session ;
4. écrire votre premier modèle de menace en trois colonnes.

Quiz

1. Quelles sont les trois colonnes d'un modèle de menace ?
2. Dans la sortie de ss -tulpn, quelle différence entre 0.0.0.0:3306 et 127.0.0.1:3306 ?
3. Pourquoi un service non installé est-il plus sûr qu'un service bien configuré ?
4. Citez deux référentiels de durcissement et leur différence de licence.
5. Pourquoi faut-il une console de secours avant de durcir SSH ou le pare-feu ?

Sources de référence : guide ANSSI GNU/Linux (Licence Ouverte), documentation Red Hat, pages de manuel. Texte original MasterLinux.