Qu’est-ce qui est désactivé par défaut sur la plupart des serveurs Linux (et pourquoi c’est important)

Lorsque vous configurez un serveur Linux neuf — qu’il s’agisse d’un VPS, d’un serveur dédié, ou d’une machine virtuelle hébergée dans le cloud — le système démarre dans un environnement volontairement minimaliste et renforcé. Ce n’est pas une omission ou une configuration incomplète. C’est une philosophie de conception intentionnelle intégrée dans chaque grande distribution Linux.

Les builds de serveurs Linux modernes éliminent les services inutiles, les protocoles et les interfaces pour minimiser la surface d’attaque, économiser les ressources système et donner aux administrateurs un contrôle précis sur ce qui s’exécute sur leur infrastructure. Comprendre ce qui est désactivé par défaut — et pourquoi — est une connaissance fondamentale pour tout administrateur système, ingénieur DevOps ou développeur gérant des charges de travail en production.

Ce guide disséque les fonctionnalités et services les plus courants qui sont désactivés ou absents par défaut sur les serveurs Linux, explique le fondement de sécurité et opérationnel derrière chaque décision, et vous montre exactement comment vérifier chaque paramètre sur votre propre système.

Pourquoi « Désactivé par défaut » est une stratégie de sécurité, pas une limitation

Le principe en jeu ici s’appelle souvent « sécurisé par défaut, extensible par choix ». Plutôt que de livrer un système complet et de faire confiance aux administrateurs pour le verrouiller, les distributions Linux modernes livrent un système verrouillé et font confiance aux administrateurs pour n’activer que ce dont ils ont besoin.

Cette approche réduit directement le risque de mauvaise configuration — l’une des principales causes de violations de serveurs. Chaque service qui ne s’exécute pas est un service qui ne peut pas être exploité. Chaque protocole qui n’est pas activé est un protocole qui ne peut pas être intercepté. Chaque port ouvert qui n’existe pas est un point d’entrée que les attaquants ne peuvent pas sonder.

Avec ce contexte établi, examinons chaque restriction par défaut en détail.

1. Connexion SSH Root

Statut : Désactivée par défaut sur pratiquement toutes les distributions Linux serveur modernes

La connexion directe root via SSH est universellement désactivée dans les builds serveur Linux contemporains — et pour une excellente raison. Autoriser l’accès root à distance crée un point de défaillance cataclysmique unique : un mot de passe compromis donne à un attaquant un contrôle complet et sans restriction sur l’ensemble du système.

Le flux de travail correct consiste à se connecter en tant qu’utilisateur non privilégié et à escalader les privilèges en utilisant sudo ou su uniquement si nécessaire. Cela crée une piste d’audit, limite le rayon d’impact du vol d’identifiants et force une action délibérée avant d’exécuter des commandes privilégiées.

Comment vérifier :

grep PermitRootLogin /etc/ssh/sshd_config

Résultat attendu sur un serveur correctement renforcé :

PermitRootLogin no

Si vous voyez PermitRootLogin yes ou PermitRootLogin prohibit-password, examinez immédiatement votre configuration SSH et alignez-la sur la politique de sécurité de votre organisation.

Meilleure pratique :

Créez un utilisateur administratif dédié, ajoutez-le au groupe sudo et assurez-vous que PermitRootLogin no est défini avant de déployer tout service accessible au public.

2. Authentification par mot de passe dans SSH

Statut : Désactivée par défaut sur la plupart des serveurs provisionnés dans le cloud

Sur de nombreuses plateformes cloud et environnements d’hébergement gérés, l’authentification par mot de passe SSH est entièrement désactivée au moment du provisionnement. Les paires de clés SSH sont le seul mécanisme d’authentification accepté.

C’est une amélioration significative de la sécurité. L’authentification par mot de passe est vulnérable aux attaques par force brute, au credential stuffing et aux attaques par dictionnaire. Les clés SSH — particulièrement lorsqu’elles sont protégées par une phrase de passe — sont informatiquement impossibles à forcer par force brute avec la technologie actuelle.

Les installations traditionnelles basées sur ISO peuvent toujours autoriser les connexions par mot de passe par défaut, mais la meilleure pratique est de les désactiver immédiatement après la configuration de l’authentification basée sur les clés.

Comment vérifier :

grep PasswordAuthentication /etc/ssh/sshd_config

Résultat attendu :

PasswordAuthentication no

Comment désactiver l’authentification par mot de passe :

Modifiez /etc/ssh/sshd_config et définissez :

PasswordAuthentication no
PubkeyAuthentication yes

Ensuite, rechargez le daemon SSH :

# Ubuntu/Debian
sudo systemctl reload ssh

# RHEL/AlmaLinux/Rocky Linux
sudo systemctl reload sshd

> Avertissement : Confirmez toujours que votre clé SSH fonctionne avant de désactiver l’authentification par mot de passe, sinon vous risquez de vous verrouiller hors du serveur.

3. Protocoles réseau hérités et en texte clair

Statut : Absent des builds de serveurs modernes

Les services tels que Telnet, FTP, Rlogin et Rsh ne sont pas installés sur les images de serveur Linux modernes. Ces protocoles ont été conçus à une époque où le chiffrement n’était pas une priorité. Ils transmettent les identifiants, les commandes et les données en texte clair — ce qui les rend triviales à intercepter avec un analyseur de paquets sur n’importe quel segment de réseau entre le client et le serveur.

Ces protocoles ont été remplacés par des alternatives sécurisées :

Comment vérifier qu’aucun service hérité n’est en cours d’exécution :

ss -tulnp

Si les ports 21 (FTP) ou 23 (Telnet) n’apparaissent pas dans la sortie, ces services ne sont pas actifs. S’ils apparaissent, enquêtez immédiatement et supprimez-les ou désactivez-les sauf s’il existe une exigence spécifique et justifiée.

4. Interfaces Graphiques Utilisateur (GUI)

Statut : Non installé sur les éditions serveur

Les distributions serveur — y compris Ubuntu Server, Debian, AlmaLinux, Rocky Linux et CentOS Stream — ne sont pas livrées avec des environnements de bureau graphiques tels que GNOME, KDE Plasma ou XFCE. C’est un choix délibéré et bien fondé.

Un environnement GUI :

• Consomme des ressources RAM et CPU importantes qui devraient être dédiées aux charges de travail
• Introduit un grand nombre de paquets logiciels supplémentaires, chacun représentant une vulnérabilité potentielle
• Est entièrement inutile pour l’administration serveur, qui est effectuée via la ligne de commande sur SSH

L’attente est sans ambiguïté : les serveurs sont gérés via la CLI. Si vous trouvez que vous souhaitez une interface graphique sur un serveur de production, c’est généralement un signal qu’un processus ou un flux de travail doit être reconsidéré.

> Remarque : Des outils comme Panneaux de Contrôle VPS — tels que cPanel, Plesk ou DirectAdmin — fournissent des interfaces de gestion graphiques basées sur le web sans nécessiter l’installation d’un environnement de bureau complet sur le serveur.

5. Chaînes d’outils de développement et compilateurs

Statut : Non installé dans les images serveur minimales

Les compilateurs tels que gcc et les utilitaires de compilation tels que make, cmake et autoconf sont intentionnellement absents de la plupart des images Linux serveur minimales. La justification est double :

1. Taille d’image réduite : Les images minimales se déploient plus rapidement, sont plus faciles à sauvegarder et consomment moins de ressources.
2. Durcissement de la sécurité : Si un attaquant accède à un serveur, l’absence de compilateur l’empêche de compiler des binaires malveillants ou du code d’exploitation directement sur le système. C’est un obstacle significatif dans de nombreuses chaînes d’attaque.

Comment vérifier :

gcc --version

Si la chaîne d’outils n’est pas installée, vous verrez :

-bash: gcc: command not found

Comment installer si nécessaire :

# Ubuntu/Debian
sudo apt update && sudo apt install build-essential

# RHEL/AlmaLinux/Rocky Linux
sudo dnf groupinstall "Development Tools"

Installez les outils de développement uniquement sur les serveurs où la compilation est une exigence opérationnelle véritable — tels que les serveurs de compilation ou les environnements de développement — et évitez de les installer sur les serveurs d’application de production ou les serveurs de base de données.

6. ICMP (Réponses Ping)

Statut : Activé par défaut au niveau du système d’exploitation ; souvent restreint au niveau du réseau/pare-feu

Les serveurs Linux répondent aux demandes d’écho ICMP (ping) par défaut au niveau du système d’exploitation. Cependant, de nombreux fournisseurs d’hébergement et plateformes cloud bloquent ICMP au niveau du pare-feu réseau ou du groupe de sécurité, ce qui rend les serveurs inaccessibles au ping même s’ils sont entièrement opérationnels.

Supprimer les réponses ICMP rend un serveur moins découvrable lors des analyses de reconnaissance réseau. Cependant, cela complique également la surveillance et les diagnostics légitimes — des outils comme ping et traceroute dépendent d’ICMP pour fonctionner correctement.

Comment tester :

ping your_server_ip

Comment bloquer ICMP au niveau du système d’exploitation avec iptables (si nécessaire) :

sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

La décision de bloquer ICMP doit être prise délibérément, en pesant l’avantage marginal en matière de sécurité par rapport au coût opérationnel pour les flux de travail de surveillance et de dépannage.

7. IPv6

Statut : Activé par défaut dans la plupart des distributions ; peut être restreint au niveau du fournisseur

IPv6 est activé par défaut dans les distributions Linux modernes, notamment Ubuntu, Debian, Fedora et les dérivés RHEL. Cependant, de nombreux fournisseurs d’hébergement désactivent IPv6 au niveau du réseau si leur infrastructure ne le supporte pas, ce qui signifie que le système d’exploitation peut être configuré pour IPv6 mais que le serveur n’aura pas d’adresse IPv6 routable.

Comment vérifier les adresses IPv6 :

ip a | grep inet6

Si seul ::1 (l’adresse de bouclage) apparaît, IPv6 n’est pas configuré au niveau du réseau même s’il est activé dans le système d’exploitation.

Si votre charge de travail ne nécessite pas IPv6 et que votre fournisseur ne l’offre pas, vous pouvez le désactiver au niveau du noyau en ajoutant ce qui suit à /etc/sysctl.conf :

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Ensuite, appliquez la modification :

sudo sysctl -p

8. Services système et démons inutiles

Statut : Varie selon la distribution ; les installations minimales désactivent la plupart des services non essentiels

Au-delà des éléments énumérés ci-dessus, les installations minimales de serveurs Linux désactivent ou omettent généralement une gamme de services présents sur les builds de bureau ou complets :

• Bluetooth — sans pertinence sur les serveurs ; non installé
• Avahi/mDNS — découverte du réseau local ; inutile et potentiellement une préoccupation de sécurité sur les serveurs
• Cups (impression) — aucun cas d’usage sur un serveur
• ModemManager — sans pertinence sur le matériel serveur
• NetworkManager — souvent remplacé par systemd-networkd ou configuration netplan manuelle sur les serveurs

Comment auditer les services en cours d’exécution :

systemctl list-units --type=service --state=running

Examinez cette liste périodiquement et désactivez tout service qui ne remplit pas une fonction documentée sur ce serveur spécifique.

Checklist de sécurité pratique pour un serveur Linux fraîchement provisionné

Après la mise en service d’un nouveau serveur — qu’il s’agisse d’un hébergement web partagé mis à niveau vers un VPS ou d’un tout nouveau serveur dédié — parcourez cette checklist pour confirmer votre posture de sécurité de base :

Choisir le bon environnement d’hébergement pour vos exigences de sécurité

La posture de sécurité par défaut de votre serveur est également influencée par l’environnement d’hébergement que vous choisissez. Un VPS avec cPanel fournit une interface gérée et basée sur le web qui simplifie l’administration tout en préservant le modèle de sécurité Linux sous-jacent. Un serveur dédié bare-metal vous donne un contrôle total sur chaque couche de la pile, du firmware à l’application.

Pour les équipes exécutant des applications web sécurisées par SSL, l’appairage de votre serveur avec un certificat SSL correctement configuré est un complément essentiel au renforcement au niveau du serveur — chiffrant les données en transit tout comme l’authentification par clé SSH protège l’accès au serveur lui-même.

Conclusion

Les serveurs Linux prêts à l’emploi sont provisionnés dans un état délibérément sécurisé et épuré. La connexion SSH en tant que root est désactivée. L’authentification par mot de passe est restreinte ou éliminée. Les protocoles en texte clair hérités sont absents. Aucun environnement graphique n’est installé. Les compilateurs et outils de compilation sont exclus des images de base.

En revanche, des services tels que les réponses ICMP et IPv6 restent activés au niveau du système d’exploitation par défaut, mais sont fréquemment restreints au niveau du réseau ou du pare-feu selon l’infrastructure du fournisseur et sa posture de sécurité.

Cette philosophie « sécurisé par défaut, extensible par choix » garantit que les administrateurs conservent une agentivité totale sur leur environnement. Le serveur n’expose que ce qui est explicitement requis pour son rôle prévu — rien de plus. Chaque service que vous activez, chaque port que vous ouvrez et chaque paquet que vous installez est une décision délibérée avec une justification documentée.

Cette discipline est le fondement de la sécurité opérationnelle. Ce n’est pas une limitation des serveurs Linux. C’est précisément ce qui en fait la plateforme de choix pour l’infrastructure de production dans le monde entier.