Skip to content

Instantly share code, notes, and snippets.

@stephdl

stephdl/securize_a_linux.md

Created December 23, 2025 07:10
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save stephdl/b068fafbd8ddd07d2f64c6b493ce0927 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save stephdl/b068fafbd8ddd07d2f64c6b493ce0927 to your computer and use it in GitHub Desktop.
Download ZIP
Sécurisation d'un système Linux
Raw
securize_a_linux.md

Sécurisation d'un système Linux

Guide pratique basé sur les recommandations de l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information)

Table des matières

Introduction

Ce document aborde deux principes fondamentaux de la sécurité informatique recommandés par l'ANSSI pour sécuriser un système GNU/Linux. Ces principes sont complémentaires et doivent être appliqués ensemble pour obtenir une protection efficace.

Sources officielles :

  • ANSSI-BP-028 : Recommandations de configuration d'un système GNU/Linux (03/10/2022)
  • Note Technique ANSSI : Recommandations de sécurité relatives à un système GNU/Linux (27/07/2012)

1. Défense en profondeur

Définition

La défense en profondeur consiste à mettre en place plusieurs couches de sécurité indépendantes et complémentaires pour retarder ou bloquer les attaques. Si une couche est contournée, d'autres prennent le relais.

Citation ANSSI : « Sous Unix et dérivés, la défense en profondeur doit reposer sur une combinaison de barrières qu'il faut garder indépendantes les unes des autres. »

Concept clé

Au lieu de dépendre d'une seule mesure de sécurité, on en empile plusieurs. Chaque couche remplit une fonction différente et utilise des mécanismes distincts.

Exemple concret : Protection d'un serveur web

Imaginons un serveur hébergeant une application web. Sans défense en profondeur, l'application serait la seule barrière. Si elle est compromisée, tout est perdu.

Avec défense en profondeur, on met en place :

Couche Mesure Rôle
1 Firewall système Bloque les ports inutiles
2 MFA (Multi-Factor Authentication) 2e facteur d'authentification indépendant
3 Authentification SSH Restreint l'accès administrateur
4 Fail2ban / CrowdSec Détecte et bloque les attaques par brute-force
5 Permissions des fichiers L'application n'accède qu'aux fichiers nécessaires
6 Isolation du processus L'app s'exécute sous un utilisateur non-root
7 AppArmor/SELinux Contrôle fin des actions de l'application
8 Journalisation auditd Enregistre toute activité suspecte

Scénario d'attaque :

  • Un attaquant exploite une faille dans l'application web (RCE - Remote Code Execution)
  • Couche 1 (firewall) : pas d'aide, l'attaquant venait de l'internet autorisé
  • Couche 2 (MFA) : tentatives de SSH bloquées (pas le bon 2e facteur)
  • Couche 3 (SSH) : bloque l'accès root, l'attaquant reste limité
  • Couche 4 (Fail2ban) : après 5 tentatives échouées, IP bannie temporairement
  • Couche 5 (permissions) : ne peut pas accéder aux fichiers sensibles (/etc/passwd)
  • Couche 6 (isolation) : essaie d'escalader les privilèges, mais aucune vulnérabilité majeure
  • Couche 7 (AppArmor) : le daemon tente une action non autorisée, elle est bloquée
  • Couche 8 (logs) : les tentatives sont enregistrées, détection rapide possible

Avantages :

  • Détection : chaque couche peut générer des alertes
  • Ralentissement : plus long pour l'attaquant
  • Résilience : si une couche échoue, d'autres protègent encore

Implémentation pratique en Linux

# 1. Firewall - bloquer les ports inutiles
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp   # SSH
sudo ufw allow 80/tcp   # HTTP
sudo ufw allow 443/tcp  # HTTPS

# 2. MFA sur SSH - ajouter TOTP (Time-based One-Time Password)
sudo apt install libpam-google-authenticator
# Pour chaque utilisateur :
google-authenticator
# Scanne le QR code avec Google Authenticator, Microsoft Authenticator, Authy...
# Sauvegarde les codes de secours
# Éditer /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,password publickey,keyboard-interactive
# Éditer /etc/pam.d/sshd
auth required pam_google_authenticator.so nullok

# 3. SSH - désactiver root et l'authentification par mot de passe
# Éditer /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

# 4. Fail2ban - détecter et bloquer les attaques par brute-force
sudo apt install fail2ban
sudo systemctl enable fail2ban
# Créer /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 3600
# Après 5 tentatives échouées en 10 minutes, bloquer l'IP pendant 1 heure

# 5. Permissions - limiter les accès
chmod 750 /var/www/app/data
chown www-data:www-data /var/www/app/data

# 6. Isolation du processus - créer un utilisateur dédié
useradd -r -s /usr/sbin/nologin appweb
# L'appli s'exécute sous cet utilisateur, pas root

# 7. AppArmor - confiner l'application
# Créer un profil AppArmor limitant les actions de Nginx
# Éditer /etc/apparmor.d/usr.sbin.nginx

# 8. Journalisation - enregistrer les activités
auditctl -w /etc/passwd -p wa -k passwd_changes

2. Moindre privilège

Définition

Le principe de moindre privilège (least privilege) stipule que tout utilisateur ou processus ne doit avoir accès qu'au strict minimum nécessaire pour accomplir sa tâche.

Citation ANSSI : « Un utilisateur ou un programme ne doit avoir accès qu'à ce dont il a strictement besoin. »

Concept clé

Ne pas donner une clé maître si une clé ordinaire suffit. Cela minimise les dégâts en cas de compromission.

Exemple concret : Serveur de base de données

Mauvaise pratique (un seul compte) :

# L'application web et toutes ses opérations
# utilisent le même compte root
# Si l'appli est compromise, l'attaquant a accès à TOUT
mysql -u root -p < app.sql

Conséquences : L'attaquant peut supprimer les bases, modifier l'historique, accéder à d'autres données.

Bonne pratique (moindre privilège) :

# Créer des comptes différents selon le rôle

# Compte pour les lectures seules (consultation des données)
CREATE USER 'app_read'@'localhost' IDENTIFIED BY 'password1';
GRANT SELECT ON database.* TO 'app_read'@'localhost';

# Compte pour les écritures (modifications)
CREATE USER 'app_write'@'localhost' IDENTIFIED BY 'password2';
GRANT SELECT, INSERT, UPDATE ON database.* TO 'app_write'@'localhost';

# Compte pour l'admin (maintenance)
CREATE USER 'app_admin'@'localhost' IDENTIFIED BY 'password3';
GRANT ALL ON database.* TO 'app_admin'@'localhost';

L'application utilise :

  • app_read pour afficher les données (SELECT)
  • app_write pour créer/modifier les données (INSERT/UPDATE)
  • app_admin seulement en maintenance (pas automatisé)

Scénario d'attaque :

  • Faille SQL injection sur la page "connexion utilisateur"
  • L'attaquant peut lire les données via app_read, mais rien d'autre
  • Les tentatives de suppression échouent (pas de DELETE)
  • Les tentatives d'écriture dans d'autres tables échouent
  • Dégâts limités à la lecture des données publiques

Exemple concret : Permissions sur les fichiers

Mauvaise pratique :

# Tous les utilisateurs lisent tout
chmod 777 /home/alice
chmod 777 /home/bob
# Alice peut lire les fichiers personnels de Bob
# Risque de fuite d'informations sensibles

Bonne pratique :

# Chaque utilisateur accède seulement à son dossier
chmod 700 /home/alice
chmod 700 /home/bob

# Configuration du masque de création de fichiers
umask 0077  # Les nouveaux fichiers ont 600 (rw-------)
            # Les nouveaux dossiers ont 700 (rwx------)

# Résultat : les fichiers personnels restent privés

Configurer les permissions par défaut :

Éditer /etc/login.defs pour définir les paramètres par défaut lors de l'ajout de nouveaux utilisateurs :

UMASK 077

Cela signifie que les nouveaux répertoires home créés auront les permissions 700 (rwx------) et les fichiers 600 (rw-------). L'utilisateur est le seul à avoir accès, ce qui respecte le moindre privilège.

Exemple concret : Utilisateurs système et services

Mauvaise pratique :

# Tous les services s'exécutent en root
ps aux | grep root
# Nginx tourne en root
# MySQL tourne en root
# Si l'un d'eux est compromise, tout l'est

Bonne pratique :

# Créer des utilisateurs dédiés à chaque service
useradd -r -s /usr/sbin/nologin www-data  # Pour Nginx
useradd -r -s /usr/sbin/nologin mysql     # Pour MySQL

# Démarrer chaque service avec son utilisateur
# Dans le fichier de configuration du service
# User=www-data
# Group=www-data

# Si Nginx est compromis, l'attaquant est limité à cet utilisateur
# Il ne peut pas accéder aux fichiers de MySQL
# Il ne peut pas modifier /etc/shadow

Exemple concret : Sudo et escalade de privilèges

Mauvaise pratique :

# Dans /etc/sudoers - accès trop permissif
alice ALL=(ALL) ALL  # Alice peut tout faire sans mot de passe !

Bonne pratique :

# Créer un groupe pour les administrateurs
groupadd sudogrp

# Ajouter les utilisateurs au groupe
usermod -aG sudogrp alice

# Dans /etc/sudoers - accès spécifique
%sudogrp ALL=(ALL) /usr/bin/systemctl, /usr/bin/apt update, /usr/bin/apt upgrade

# Résultat :
# - Alice peut redémarrer les services
# - Alice peut mettre à jour les packages
# - Alice CANNOT lire /etc/shadow ou supprimer des fichiers
# - Chaque commande est enregistrée

Vérifier avec sudo visudo :

sudo visudo  # Éditer en toute sécurité

Contrôle des permissions Linux

Le système de permissions Unix/Linux est une application du moindre privilège :

-rw-r--r-- 1 www-data www-data 4096 document.txt
  • rw- (propriétaire) : www-data peut lire et écrire
  • r-- (groupe) : d'autres utilisateurs du groupe peuvent lire
  • r-- (autres) : les autres utilisateurs peuvent lire

Pour respecter le moindre privilège :

# Document sensible : seul le propriétaire lit
chmod 600 secret.txt     # rw-------

# Script système : propriétaire exécute, groupe lit
chmod 750 /opt/backup.sh # rwxr-x---

# Répertoire personnel : propriétaire accède, autres exclus
chmod 700 /home/alice    # rwx------

3. Combinaison défense en profondeur + moindre privilège

Ces deux principes se renforcent mutuellement.

Exemple global : Serveur LAMP (Linux + Apache + MySQL + PHP)

Couche physique/OS (défense profonde + moindre privilège) :

  • Partitionnement : /, /home, /var, /tmp séparés
  • Options de montage : noexec sur /tmp, nosuid sur /home

Couche réseau (défense profonde) :

  • Firewall externe : port 80/443 seulement
  • Firewall local (ufw/iptables) : applications locales isolées

Couche services (moindre privilège) :

  • Apache : utilisateur www-data (non-root)
  • MySQL : utilisateur mysql (non-root)
  • PHP : s'exécute sous www-data

Couche application (moindre privilège) :

  • Base MySQL : 3 comptes (read, write, admin)
  • Dossiers web : propriétaire www-data, permissions 750

Couche détection (défense profonde) :

  • AppArmor : confine Apache et PHP
  • auditd : enregistre les accès sensibles
  • Logs centralisés : syslog pour tous les services

Résultat :

  • Attaquant pénètre via PHP (faille web)
  • Limité par l'utilisateur www-data
  • AppArmor bloque ses tentatives de modifier /etc
  • Firewall bloque ses connexions sortantes
  • auditd enregistre tout
  • Escalade de privilèges très difficile

4. Niveaux de recommandations ANSSI

L'ANSSI propose 4 niveaux progressifs :

Niveau Effort Protection Public
M - Minimal Faible Basique Tous
I - Intermédiaire Moyen Renforcée Serveurs
R - Renforcé Important Forte Données sensibles
E - Élevé Très important Maximale Données critiques

Recommandations Minimal (niveau M)

Basiques, applicable à tous les systèmes :

  • Désactiver les comptes utilisateur inutilisés
  • Utiliser des mots de passe robustes
  • N'installer que les paquets strictement nécessaires
  • Désactiver les services non nécessaires
  • Appliquer les mises à jour régulièrement

Recommandations Intermédiaire (niveau I)

Pour serveurs en production :

  • Partitionner les disques
  • Configurer SSH correctement
  • Configurer un firewall local
  • Implémenter sudo
  • Restreindre les droits des fichiers sensibles

Recommandations Renforcé (niveau R)

Pour données sensibles :

  • AppArmor ou SELinux
  • auditd pour la journalisation
  • Cloisonnement des services
  • Capacités Linux (capabilities)

Recommandations Élevé (niveau E)

Pour données critiques :

  • Chiffrement disque
  • IMA (Integrity Measurement Architecture)
  • Hardening du noyau
  • Isolation complète des services

5. Checklist pratique de démarrage

Pour mettre en place défense en profondeur + moindre privilège :

Phase 1 : Audit initial

# Voir le score de sécurité actuel
sudo lynis audit system

# Lister les services actifs
sudo systemctl list-units --type=service --all

# Voir les utilisateurs et groupes
cat /etc/passwd
cat /etc/group

# Vérifier les permissions sensibles
ls -la /etc/shadow /etc/sudoers

Phase 2 : Niveau Minimal (OBLIGATOIRE)

# Désactiver les comptes inutilisés
lastlog | grep "Never logged in"

# Supprimer les comptes de test
userdel testuser

# Désactiver les services inutiles
sudo systemctl disable avahi-daemon
sudo systemctl disable cups
sudo systemctl disable bluetooth

# Configurer les mises à jour automatiques
sudo apt install unattended-upgrades

Phase 3 : Niveau Intermédiaire (RECOMMANDÉ)

# Installer et configurer le firewall
sudo ufw enable
sudo ufw default deny incoming
sudo ufw allow 22/tcp

# Configurer SSH (éditer /etc/ssh/sshd_config)
PermitRootLogin no
PasswordAuthentication no

# Créer des utilisateurs dédiés aux services
useradd -r -s /usr/sbin/nologin appservice

# Configurer sudo
sudo visudo
# %admins ALL=(ALL) /usr/bin/systemctl, /usr/bin/apt

Phase 4 : Monitoring continu

# Installer auditd pour la journalisation
sudo apt install auditd

# Vérifier régulièrement les logs
sudo tail -f /var/log/auth.log
sudo ausearch -m avc

6. Ressources officielles

  • Site ANSSI : https://cyber.gouv.fr
  • Guide complet : ANSSI-BP-028 (Recommandations de configuration d'un système GNU/Linux)
  • Cloisonnement : Guide ANSSI sur la mise en place de cloisonnement système
  • Outils de vérification : OpenSCAP, Lynis

Conclusion

La sécurité Linux repose sur deux piliers indissociables :

  1. Défense en profondeur : empiler les couches de sécurité
  2. Moindre privilège : donner juste assez, pas plus

Appliquées conjointement avec cohérence et régularité, ces deux approches transforment un système Linux ordinaire en infrastructure résiliente et difficile à comprommettre.

L'ANSSI propose un cadre structuré (niveaux M, I, R, E) pour adapter ces principes à votre contexte et à vos risques.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment