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

Le problème concret

Un poste Ubuntu 22.04 LTS ou Debian 12 sorti de l'installation standard tourne avec sshd activé, sans politique de mots de passe enforce, sans audit des appels système, et avec un root accessible via sudo sans délai de session. Dans 80 % des PME suisses de moins de 150 collaborateurs, ces endpoints Linux ne font l'objet d'aucune baseline de sécurité documentée — contrairement aux postes Windows pilotés via Autopilot ou aux Mac gérés sous Apple Business Manager. Pourtant, les machines Linux hébergent souvent les workloads les plus sensibles : postes de développeurs, serveurs de fichiers internes, appliances réseau. Voici les règles minimales, terrain, pour y remédier sans armée de sysadmins.

Cadre de référence : CIS Benchmarks et contexte suisse

Le CIS Benchmarks publie des profils de configuration pour Ubuntu LTS et Debian. Le niveau Level 1 cible les environnements sans contrainte de certification formelle ; le niveau Level 2 convient aux machines traitant des données à fort enjeu (données de santé, données financières FINMA). Pour une PME romande, le Level 1 est le plancher minimum acceptable.

Sur le plan légal suisse, la nouvelle loi sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose des mesures techniques et organisationnelles appropriées pour protéger les données personnelles. Un endpoint Linux non durci qui stocke ou traite des données de clients ou d'employés peut constituer un manquement documentable en cas d'incident. Le NCSC recommande par ailleurs explicitement l'application de baselines de configuration pour tous les systèmes d'exploitation, y compris Linux.

La norme ISO 27001:2022 (contrôle A.8.9 – gestion de la configuration) exige une configuration sécurisée documentée pour tous les actifs informationnels. Si votre PME vise la certification ou s'y prépare, une baseline CIS Level 1 sur Linux est une preuve d'audit directement exploitable.

Les 7 familles de contrôles prioritaires

1. Système de fichiers et montages

Désactiver les systèmes de fichiers inutiles réduit la surface d'attaque au niveau du noyau. Dans /etc/modprobe.d/disable-fs.conf, bloquer :

• cramfs, freevxfs, jffs2, hfs, hfsplus, squashfs, udf

Les partitions /tmp, /var/tmp et /home doivent être montées avec les options nodev, nosuid, noexec (pour /tmp et /var/tmp). Un /tmp en tmpfs avec ces options est la configuration standard recommandée par CIS.

2. Gestion des comptes et authentification

Paramètres minimaux à appliquer dans /etc/login.defs :

• PASS_MAX_DAYS 90 — expiration des mots de passe tous les 90 jours
• PASS_MIN_DAYS 1 — délai minimal entre deux changements
• PASS_WARN_AGE 7 — avertissement 7 jours avant expiration
• ENCRYPT_METHOD SHA512 — hachage robuste

Installer libpam-pwquality et configurer dans /etc/security/pwquality.conf : longueur minimale 14 caractères, minclass 4. Verrouiller tout compte système sans shell valide (usermod -s /usr/sbin/nologin). Le compte root doit être verrouillé (passwd -l root) ; l'élévation passe exclusivement par sudo avec journalisation.

Pour les PME avec plus de 20 endpoints, l'intégration à un annuaire central (LDAP/AD via sssd) simplifie la gestion tout en centralisant les logs d'authentification.

3. Services réseau et pare-feu

Inventorier les services en écoute :

ss -tlnp

Désactiver et masquer tout service non justifié : systemctl disable --now <service> suivi de systemctl mask <service>. Services fréquemment inutiles sur un poste de travail : avahi-daemon (mDNS, port UDP 5353), cups (TCP 631), isc-dhcp-server, rpcbind (TCP/UDP 111).

Activer ufw (Ubuntu) ou configurer nftables directement (Debian 12+). Politique par défaut :

• INPUT : DROP
• FORWARD : DROP
• OUTPUT : ACCEPT (restreindre si besoin selon le contexte)

Autoriser uniquement les ports métier documentés. Sur un poste développeur avec accès SSH interne : ouvrir TCP 22 uniquement depuis le sous-réseau de gestion (ex. 10.10.10.0/24), jamais depuis 0.0.0.0/0.

4. Audit système avec auditd

Installer auditd et audispd-plugins. Appliquer la ruleset CIS ou STIG disponible publiquement. Règles minimales à inclure dans /etc/audit/rules.d/cis.rules :

• Modifications de /etc/passwd, /etc/shadow, /etc/group, /etc/sudoers
• Appels système chmod, chown, fchmod, fchownat
• Tentatives d'accès non autorisées (-a always,exit -F arch=b64 -S open -F exit=-EACCES)
• Exécutions sudo (/var/log/auth.log + règles audit dédiées)
• Chargements de modules noyau (init_module, finit_module)

Configurer max_log_file_action = keep_logs et une rétention d'au moins 90 jours sur site (365 jours recommandés pour conformité nLPD en cas d'incident). Exporter les logs vers un SIEM ou un serveur syslog centralisé dès que le parc dépasse 5 machines Linux.

5. Mises à jour et gestion des paquets

Activer unattended-upgrades pour les correctifs de sécurité uniquement :

• Ubuntu : paquet unattended-upgrades, origine Ubuntu:22.04-security
• Debian : paquet unattended-upgrades, origine Debian:12/stable-security

Délai maximal acceptable entre publication d'un patch critique et déploiement : 72 heures pour les CVE de score CVSS ≥ 9.0, 7 jours pour les CVE CVSS 7.0–8.9. Ces seuils sont cohérents avec les pratiques de SLA recommandées par le NCSC pour les PME.

Vérifier l'intégrité des paquets : ne jamais désactiver la vérification GPG (APT::Get::AllowUnauthenticated doit rester à false). Supprimer les dépôts non officiels non documentés dans l'inventaire.

6. Chiffrement des données au repos

Pour les endpoints mobiles (laptops développeurs, machines terrain), chiffrer le disque complet avec LUKS à la mise en service. Sur Ubuntu, l'installeur propose le chiffrement dès l'installation ; sur Debian, la configuration manuelle via cryptsetup est requise. Clé de récupération à stocker hors du poste (gestionnaire de secrets d'entreprise, ou escrow MDM si FleetDM le supporte dans votre déploiement).

Pour les partitions de données sensibles sur serveurs, LUKS ou VeraCrypt (open source, audité) selon le contexte. Le chiffrement seul ne dispense pas de la gestion des accès : une partition LUKS montée avec une clé faible ou un mauvais contrôle d'accès aux fichiers reste vulnérable.

7. Gestion à distance et MDM Linux

Un endpoint Linux non géré centralement est invisible : pas d'inventaire fiable, pas de détection de dérive de configuration. Deux approches pragmatiques pour PME :

• FleetDM / osquery : agent léger, interrogation en SQL de l'état de la machine (version OS, paquets installés, utilisateurs actifs, ports ouverts, statut chiffrement). Fonctionne sur Ubuntu et Debian. Permet de vérifier la conformité CIS en quasi-temps réel.
• Ansible + dépôt Git : pour les PME avec compétences DevOps internes, un playbook Ansible idempotent appliquant la baseline CIS est versionnable, auditable et reproductible. Chaque modification de configuration est tracée dans le dépôt.

Dans les deux cas, l'objectif est le même : détecter une dérive (un service cups réactivé par une mise à jour, un ufw désactivé par un utilisateur) avant qu'elle ne soit exploitée.

Cas pratique : bureau d'ingénierie, 35 endpoints Linux à Lausanne

Contexte : une PME lausannoise de génie civil emploie 35 personnes. 12 d'entre elles utilisent des laptops Ubuntu 22.04 LTS pour des calculs BIM et l'accès à un serveur de fichiers interne Debian 12 (NFS + SFTP). Les données incluent des plans confidentiels de clients publics (communes vaudoises). Aucune baseline de sécurité n'a jamais été appliquée. Deux anciens employés ont conservé des comptes actifs 3 semaines après leur départ.

Évaluation initiale (J1–J3)

1. DSI / sysadmin — Exécuter le script d'audit CIS-CAT Lite (gratuit, disponible sur cisecurity.org) sur 3 machines représentatives. Score moyen constaté : 38 % de conformité Level 1.
2. DSI — Inventaire des comptes : awk -F: '($3 >= 1000) {print $1}' /etc/passwd sur chaque machine. Identifier les comptes orphelins et les verrouiller immédiatement.
3. RSSI (ou DSI en PME sans RSSI dédié) — Cartographier les services en écoute sur le serveur Debian : ss -tlnp. Résultat : rpcbind (TCP 111), avahi-daemon (UDP 5353) et un ftpd legacy (TCP 21) actifs sans justification.

Plan de remédiation (J4–J15)

1. Sysadmin — Écrire un playbook Ansible structuré en rôles : role/cis-base (filesystem, accounts, PAM), role/cis-network (ufw, services), role/cis-audit (auditd, rsyslog vers serveur central). Durée estimée : 2 jours de développement.
2. Sysadmin — Tester le playbook sur une VM de staging identique à la production. Vérifier l'idempotence (deux passages successifs = aucun changement au second passage).
3. DSI — Déployer sur le serveur Debian en premier (hors heures de bureau, snapshot VM préalable). Durée d'exécution du playbook : 8–12 minutes par machine.
4. Sysadmin — Déployer sur les 12 laptops Ubuntu via un déploiement Ansible en push (SSH depuis le bastion de gestion sur le réseau 10.10.10.0/24). Durée totale : 4 heures pour 12 machines.
5. DSI / juriste — Documenter la baseline appliquée, versionner dans Git, archiver la preuve d'audit pour conformité nLPD. Coût estimé : 2 jours/homme sysadmin senior à CHF 950/jour = CHF 1'900.

Résultat à J+30

Score CIS-CAT Level 1 : 84 % (objectif interne fixé à 80 %). Les 3 services non justifiés ont été désactivés. Les comptes orphelins sont supprimés. Les logs auditd sont centralisés sur un serveur syslog dédié avec rétention 365 jours. Coût total du projet (hors licences) : CHF 2'400 en charge interne. Un re-audit trimestriel est planifié via un job Ansible ad hoc couplé à FleetDM pour la surveillance continue.

Récapitulatif opérationnel

• Désactiver les systèmes de fichiers inutiles dans /etc/modprobe.d/ et appliquer nodev,nosuid,noexec sur /tmp et /var/tmp.
• Appliquer une politique de mots de passe stricte : SHA512, longueur ≥ 14, expiration 90 jours, libpam-pwquality configuré.
• Verrouiller le compte root (passwd -l root) et n'autoriser l'élévation que via sudo avec journalisation complète.
• Inventorier et fermer les services réseau non justifiés (ss -tlnp), puis configurer ufw ou nftables en politique DROP par défaut.
• Activer auditd avec les règles CIS minimales et exporter les logs vers un serveur central ; rétention ≥ 90 jours (365 jours recommandés).
• Activer unattended-upgrades pour les correctifs de sécurité uniquement ; délai ≤ 72 h pour CVE CVSS ≥ 9.0.
• Chiffrer les disques des endpoints mobiles avec LUKS dès la mise en service ; stocker les clés de récupération hors du poste.
• Versionner la baseline dans un dépôt Git (Ansible ou scripts idempotents) et mesurer la conformité régulièrement via CIS-CAT Lite ou osquery/FleetDM.
• Supprimer les comptes orphelins dans les 24 heures suivant un départ ; intégrer ce contrôle au processus RH off-boarding.
• Documenter et archiver chaque déploiement de baseline pour preuve de conformité nLPD et/ou ISO 27001.

SynGuard accompagne les PME romandes dans le déploiement et la supervision de baselines CIS sur l'ensemble du parc endpoints, Linux inclus.

Sources

• CIS Benchmarks – Center for Internet Security — Profils de configuration Level 1 et Level 2 pour Ubuntu LTS et Debian.
• nLPD – Fedlex (RS 235.1) — Texte consolidé de la nouvelle loi fédérale sur la protection des données, en vigueur dès le 01.09.2023.
• NCSC – Centre national pour la cybersécurité — Recommandations et alertes pour la sécurisation des systèmes d'information des PME suisses.
• ISO 27001:2022 – Organisation internationale de normalisation — Norme de management de la sécurité de l'information, contrôle A.8.9 sur la gestion de la configuration.
• NIST Cybersecurity Framework — Cadre de référence pour l'identification, la protection, la détection, la réponse et la récupération en matière de cybersécurité.