Durcir un serveur Debian avec Ansible : checklist opérationnelle

Réponse rapide

Le durcissement Debian via Ansible se fait par couches : accès SSH, surface réseau, mises à jour, services actifs, et audit continu.

- name: Disable root SSH login
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^PermitRootLogin'
    line: 'PermitRootLogin no'

Contexte

Un serveur exposé avec configuration par défaut augmente le risque. L’objectif n’est pas “zéro risque”, mais une réduction mesurable de la surface d’attaque.

Axes de durcissement

1) SSH

  • désactiver root login
  • authentification par clé
  • limiter les utilisateurs autorisés

2) Réseau

  • ouvrir uniquement les ports nécessaires
  • désactiver services inutiles

3) Patching

  • mises à jour de sécurité planifiées
  • vérification post-update

4) Journalisation et audit

journalctl -p err -n 100 --no-pager
ss -tulpen
systemctl list-units --type=service --state=running

Erreurs fréquentes

  • durcir sans préprod/test d’accès,
  • appliquer trop de changements simultanément,
  • oublier la procédure de rollback.

Checklist de contrôle

  • SSH durci
  • ports limités
  • services maîtrisés
  • logs exploités
  • revue périodique

FAQ

Le hardening est-il one-shot ?

Non. C’est un processus continu.

Glossaire rapide

  • Regex : expression régulière pour décrire un motif de recherche texte.
  • MTTR : temps moyen de rétablissement après incident.
  • CI/CD : intégration continue / déploiement continu.
  • Idempotence : relancer une tâche donne le même état final sans effet secondaire indésirable.

Sources officielles

Conclusion

Avec Ansible, le durcissement Debian devient répétable, auditable et maintenable dans la durée.

Tags: , ,

Laisser un commentaire