Skip to content

Expliquez-moi comment vous durciriez un serveur Linux neuf exposé sur Internet.

Réponse courte

Réduire la surface d'attaque (supprimer paquets et services inutilisés), imposer SSH par clé uniquement sans connexion root, maintenir le système à jour, exécuter un pare-feu en deny-par-défaut n'exposant que les ports nécessaires, appliquer le moindre privilège via sudo et les permissions de fichiers, activer auditd et la journalisation centralisée, et ajouter la surveillance d'intégrité ainsi qu'un MAC comme SELinux ou AppArmor.

Le durcissement est la suppression systématique de tout ce qu'un attaquant pourrait exploiter, plus l'ajout de contrôles pour le détecter et le contenir s'il pénètre. Un cadre utile est constitué par les CIS Benchmarks, mais le raisonnement importe plus que la checklist.

Réduire la surface d'attaque

Commencez par retirer ce dont vous n'avez pas besoin : désinstallez les paquets inutilisés, désactivez les services non requis et fermez les ports en écoute inutiles. Chaque service en cours d'exécution est un point d'entrée potentiel. Une image de base minimale ne comportant que les dépendances de la charge de travail est bien plus facile à défendre.

Verrouiller l'accès distant

SSH est la porte d'entrée d'une machine exposée sur Internet :

  • Désactivez entièrement l'authentification par mot de passe ; utilisez l'authentification par clé (les clés résistent au brute force d'une manière que les mots de passe n'atteindront jamais).
  • Désactivez la connexion root directe ; les administrateurs se connectent en tant qu'utilisateur normal et élèvent leurs droits via sudo.
  • Restreignez les adresses IP source lorsque c'est possible, et envisagez des configurations non standard et fail2ban pour atténuer les attaques automatisées.

Correctifs et pare-feu

  • Maintenez le noyau et les paquets à jour, idéalement avec des mises à jour de sécurité automatisées : les logiciels non corrigés sont le vecteur d'intrusion le plus courant.
  • Exécutez un pare-feu en deny-par-défaut (nftables/iptables ou groupes de sécurité cloud) qui n'autorise que les ports entrants spécifiques dont le service a besoin.

Imposer le moindre privilège

Exécutez les services sous des utilisateurs non-root dédiés, définissez des permissions de fichiers strictes, et utilisez un contrôle d'accès obligatoire — SELinux ou AppArmor — pour confiner les processus afin qu'un service compromis ne puisse pas dépasser sa politique, même en tant que root.

Détecter et vérifier

  • Activez auditd et expédiez les journaux vers un collecteur centralisé et hors hôte afin qu'un attaquant ne puisse pas simplement effacer les preuves locales.
  • Ajoutez une surveillance d'intégrité des fichiers (AIDE/Tripwire) pour repérer les binaires ou configurations altérés.

Ce que les recruteurs recherchent

Une réponse de niveau senior est structurée — réduction de surface, contrôle d'accès, correctifs, moindre privilège, détection — et explique le pourquoi (par exemple, les clés plutôt que les mots de passe, les journaux hors hôte). Bonus pour citer les CIS Benchmarks et un MAC comme SELinux plutôt que de s'arrêter à « définir un mot de passe robuste ».

Questions de suivi probables

  • Pourquoi désactiver l'authentification SSH par mot de passe au profit des clés ?
  • Qu'apportent SELinux ou AppArmor par-dessus les permissions de fichiers ?
  • Comment détecteriez-vous qu'un binaire de l'hôte a été altéré ?

Sources

Certifications

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.