Hardening Linux endpoints (Ubuntu, Debian) : règles minimales pour PME

Un poste Linux non durci n'est pas un poste sécurisé

L'idée reçue persiste : Linux serait intrinsèquement plus sûr que Windows. Sur un parc de 30 postes développeurs Ubuntu ou Debian dans une PME tech romande, un seul compte local avec sudo sans MFA, un service SSH exposé sur le LAN et un kernel non patché depuis 90 jours suffisent à transformer ce mythe en incident. Le Centre national pour la cybersécurité (NCSC) documente régulièrement des compromissions initiales via des endpoints Linux mal configurés dans des PME considérant que leur faible visibilité les protège.

Référentiel de base : CIS Benchmarks Ubuntu/Debian

Le point de départ opérationnel est le CIS Benchmark pour Ubuntu 22.04 LTS ou Debian 12. Il couvre plus de 250 contrôles regroupés en deux niveaux :

• Level 1 — contrôles applicables sans impact fonctionnel majeur, recommandés pour tous les endpoints.
• Level 2 — durcissement renforcé adapté aux environnements à haute criticité (accès données de santé, comptabilité, secrets industriels).

Pour une PME de 20 à 150 endpoints, le niveau 1 est le minimum non négociable. Le niveau 2 s'applique aux postes traitant des données personnelles sensibles au sens de la nouvelle Loi fédérale sur la protection des données (nLPD) en vigueur depuis le 01.09.2023 — catégories médicales, financières, syndicalisme, biométrie.

Outil d'audit automatisé : OpenSCAP et Lynis

Lynis (open source, Cisofy) produit un score d'audit et un rapport exploitable en 5 minutes :

sudo lynis audit system --quick

Un score inférieur à 65/100 sur un poste de production doit déclencher un plan de remédiation documenté. OpenSCAP avec les profils SCAP Security Guide permet un audit conforme CIS automatisable en CI/CD ou via un outil de gestion de flotte comme FleetDM.

Contrôles techniques prioritaires

1. Gestion des comptes et privilèges

• Supprimer ou verrouiller tous les comptes inutilisés : passwd -l <user> ou suppression via userdel -r.
• Interdire la connexion root via SSH : PermitRootLogin no dans /etc/ssh/sshd_config.
• Limiter sudo au strict nécessaire : pas de NOPASSWD en production, audit via /etc/sudoers.d/ avec granularité par commande.
• Durée de vie des mots de passe : PASS_MAX_DAYS 90, PASS_MIN_DAYS 1, PASS_WARN_AGE 14 dans /etc/login.defs.
• MFA sur SSH via PAM + clés FIDO2 pour les comptes admin. L'authentification par mot de passe seul sur SSH doit être désactivée (PasswordAuthentication no) dès lors qu'une clé d'infrastructure gère les secrets.

2. Chiffrement des disques et des flux

• LUKS2 sur toute partition contenant des données utilisateur. Sur Ubuntu 22.04, l'installateur propose LUKS natif ; sur un parc existant, migration à planifier avec backup préalable vérifié.
• Vérifier que /tmp et /var/tmp sont montés avec noexec,nosuid,nodev dans /etc/fstab.
• TLS 1.2 minimum sur tous les services internes ; désactiver SSLv3, TLS 1.0, TLS 1.1 dans les configurations applicatives.

3. Durcissement réseau

• Activer et configurer UFW (Uncomplicated Firewall) ou nftables : politique par défaut deny incoming, allow outgoing, ouverture explicite des ports nécessaires uniquement.
• Désactiver IPv6 si non utilisé : net.ipv6.conf.all.disable_ipv6 = 1 dans /etc/sysctl.d/99-hardening.conf.
• Paramètres noyau anti-spoofing :
  net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
• SSH sur port non standard (ex. 2222/TCP) combiné à fail2ban : maxretry = 5, bantime = 3600.

4. Gestion des patchs et du kernel

• Ubuntu Pro (gratuit jusqu'à 5 machines) active Livepatch : correctifs kernel sans redémarrage. Sur un parc PME de 10 à 50 postes, c'est une réduction de fenêtre d'exposition mesurable.
• Unattended-upgrades configuré pour les mises à jour de sécurité uniquement :
  Unattended-Upgrade::Allowed-Origins limité à ${distro_id}:${distro_codename}-security.
• Délai maximal acceptable entre publication d'un CVE critique (CVSS ≥ 9.0) et application du patch : 72 heures selon le NIST Cybersecurity Framework (fonction Respond, sous-catégorie RS.MI-3).

5. Journalisation et détection

• Activer auditd avec règles CIS minimales : surveillance des appels execve, modifications de /etc/passwd, /etc/shadow, /etc/sudoers, usages de chmod/chown sur des binaires système.
• Centraliser les logs vers un SIEM ou un agrégateur hors-machine (rsyslog vers un collecteur dédié, port UDP/514 ou TCP/6514 TLS). Un log local modifiable par root n'est pas une preuve forensique.
• Rétention minimale : 90 jours en ligne, 1 an en archive froide — cohérent avec les exigences de traçabilité nLPD et les recommandations FINMA pour les entités régulées.
• AppArmor (actif par défaut sur Ubuntu) : vérifier que les profils sont en mode enforce et non complain pour les services exposés (nginx, sshd, cups).

Intégration dans un workflow MDM / FleetDM

Gérer manuellement 30 postes Linux est viable ; au-delà de 15 endpoints, une approche fleet-as-code devient nécessaire pour garantir la cohérence et l'auditabilité. FleetDM (osquery-based) permet de :

• Requêter en temps réel l'état de chaque contrôle CIS : SELECT * FROM shadow WHERE password != '' AND username != 'root'; pour détecter les comptes sans mot de passe.
• Déclencher des alertes sur des états de non-conformité (kernel version, statut AppArmor, présence de ports ouverts non autorisés).
• Générer des rapports d'inventaire pour l'annexe technique d'un audit ISO 27001 ou une due diligence client.

Pour les PME sans équipe infrastructure dédiée, une configuration Ansible ou Puppet permet de rejouer le hardening baseline sur chaque nouveau poste provisionné — principe d'idempotence : l'état cible est toujours le même, quelle que soit l'histoire du poste.

Cas pratique : studio de développement de 28 postes Ubuntu à Lausanne

Contexte : startup tech de 35 personnes, Lausanne, 28 postes Ubuntu 22.04 LTS pour les développeurs, 7 postes Windows 11 pour l'administration. Aucun MDM en place. Audit Lynis moyen : 58/100. Trois comptes avec NOPASSWD sudo. SSH ouvert sur toutes les interfaces (0.0.0.0:22). Pas de LUKS sur 12 postes anciens.

Objectif : atteindre un score Lynis ≥ 75/100 et CIS Level 1 compliance ≥ 80 % en 6 semaines, sans interruption de service.

Procédure déployée

1. Semaine 1 — Inventaire et audit initial (DSI + responsable IT) : déploiement de l'agent FleetDM sur les 28 postes via script Ansible (15 min/poste). Rapport d'état : versions kernel, statut LUKS, comptes sudo, ports ouverts. Coût : 0 CHF (FleetDM Community Edition).
2. Semaine 2 — Hardening comptes et SSH : suppression des 3 entrées NOPASSWD, rotation des clés SSH (Ed25519, 256 bits), activation du MFA SSH via libpam-google-authenticator pour les 6 comptes admin, restriction SSH à l'interface interne uniquement (ListenAddress 10.0.1.0/24), déplacement sur port 2222/TCP.
3. Semaine 3 — Chiffrement disques : les 12 postes sans LUKS sont réinstallés via PXE avec un preseed Debian incluant LUKS2. Durée par poste : 2h dont 1h45 de sauvegarde/restauration données utilisateur. Coût main-d'œuvre estimé : 12 × 2h × CHF 120/h = CHF 2'880.
4. Semaine 4 — Durcissement noyau et réseau : déploiement du fichier /etc/sysctl.d/99-cis.conf via Ansible (paramètres réseau, désactivation modules inutiles : usb-storage blacklisté sur les postes sans besoin métier, cramfs, freevxfs). UFW activé, politique default deny.
5. Semaine 5 — Journalisation et AppArmor : déploiement auditd avec ruleset CIS, rsyslog vers un collecteur centralisé (VM dédiée, 4 vCPU, 8 Go RAM, rétention 90 jours SSD + export S3 chiffré). Profils AppArmor basculés en enforce après une semaine de monitoring en complain.
6. Semaine 6 — Audit final et documentation : score Lynis moyen : 79/100 (+21 points). CIS Level 1 compliance : 83 %. Rapport transmis au conseil d'administration. Un registre des activités de traitement mis à jour pour répondre à l'art. 12 nLPD (documentation des mesures techniques).

Coût total estimé : CHF 4'200 (main-d'œuvre interne 28h × CHF 120/h) + CHF 2'880 (réinstallations LUKS) = CHF 7'080, hors abonnement Ubuntu Pro (gratuit jusqu'à 5 machines, CHF 500/an au-delà pour 28 postes). Rapport coût/risque positif si l'on considère qu'un incident de type ransomware sur un poste développeur coûte en moyenne CHF 15'000 à CHF 80'000 en temps d'arrêt et forensique selon les données NCSC 2023.

Récapitulatif opérationnel

1. Auditer l'état initial avec Lynis ou OpenSCAP avant toute intervention — score de référence documenté.
2. Supprimer ou verrouiller tous les comptes inutilisés ; éliminer les entrées NOPASSWD sudo.
3. Désactiver l'authentification SSH par mot de passe, imposer les clés Ed25519 et le MFA pour les comptes admin.
4. Chiffrer tous les disques avec LUKS2, y compris les partitions /tmp et /home.
5. Déployer le fichier sysctl.d de durcissement réseau et activer UFW avec politique default deny.
6. Activer unattended-upgrades sur les seuls dépôts de sécurité ; cibler un délai de patch CVE critique ≤ 72h.
7. Passer AppArmor en mode enforce après une période de validation en complain.
8. Centraliser les logs (auditd + rsyslog) hors du poste, rétention ≥ 90 jours, archive 1 an.
9. Requêter l'état de conformité en continu via FleetDM ou équivalent osquery.
10. Documenter les mesures techniques dans le registre des activités de traitement (art. 12 nLPD) et lors de chaque audit ISO 27001.

SynGuard accompagne les PME romandes dans le déploiement et la supervision de ces contrôles sur des parcs Linux, macOS et Windows via une console unifiée adaptée aux équipes sans SOC dédié.

Sources

• CIS Benchmarks — Center for Internet Security — Référentiels de durcissement par OS, dont Ubuntu 22.04 et Debian 12, niveaux 1 et 2.
• nLPD — Loi fédérale sur la protection des données (RS 235.1) — Texte consolidé en vigueur depuis le 01.09.2023, base légale pour les exigences de mesures techniques.
• NCSC — Centre national pour la cybersécurité — Alertes, statistiques d'incidents et recommandations pour les PME suisses.
• NIST Cybersecurity Framework — Cadre de référence pour la gestion du risque cyber, fonctions Identify / Protect / Detect / Respond / Recover.
• PFPDT — Préposé fédéral à la protection des données et à la transparence — Lignes directrices sur les obligations de documentation et de notification sous nLPD.