Linux n’est pas sécurisé “par défaut”

Cédric :
Beaucoup d’utilisateurs pensent encore qu’installer Linux suffit à sécuriser un serveur. C’est une idée reçue. Dans la réalité, une installation standard nécessite de nombreuses mesures supplémentaires pour être réellement sécurisée.

Le hardening consiste précisément à réduire la surface d’attaque d’un système, en appliquant une série de bonnes pratiques :

• configuration stricte des accès
• limitation des services
• sécurisation du réseau
• gestion rigoureuse des logs et des sauvegardes

Le choix de la distribution

Cédric :
La première décision concerne le choix de la distribution.

Chez Bearstech, la préférence va à Debian, notamment pour :

• sa stabilité
• la qualité du packaging
• la sécurité des mises à jour
• sa fiabilité en production

Olivier :
Un point important : Debian stable n’intègre généralement pas les correctifs avant qu’ils soient correctement audités et packagés, ce qui limite les risques d’installer un correctif problématique en production.

Authentification et contrôle d’accès

SSH comme point d’entrée principal

Olivier :
Quand on se connecte à une machine Linux, le point d’entrée principal reste SSH. Et il faut être clair : dans la pratique, tout finit par passer par SSH.

La première règle est donc simple :

• SSH doit être maintenu à jour
• les accès doivent être strictement contrôlés
• les connexions doivent se faire par clé, pas par mot de passe

Chez Bearstech, l’authentification par clé SSH est obligatoire.

Gestion des mots de passe

Un autre sujet critique est la politique de mots de passe.

Olivier :
Nous utilisons un gestionnaire interne basé sur Vaultwarden (protocole Bitwarden). Tous les mots de passe ne sont pas accessibles à tous :

• chaque utilisateur accède uniquement aux secrets nécessaires
• les accès sont segmentés
• la responsabilité est claire

Donner un mot de passe à quelqu’un qui n’en a pas besoin est une mauvaise pratique : cela crée un risque inutile.

Blocage des tentatives de connexion

Une autre mesure classique consiste à verrouiller les comptes après plusieurs tentatives échouées.

Olivier :
Dans la plupart des services, nous bannissons l’IP après quelques tentatives ratées. Si quelqu’un se trompe plusieurs fois de mot de passe, c’est soit une erreur, soit une attaque brute force.

Pour SSH, la logique est légèrement différente :
le système étant sécurisé par clé, les attaques sont beaucoup plus difficiles.

Faut-il désactiver la connexion root ?

Dans de nombreux guides de sécurité, on recommande de désactiver la connexion directe root.

Chez Bearstech, la pratique est un peu différente.

Olivier :
Oui, dans beaucoup de cas on passe par sudo. Mais chez nous, certains administrateurs peuvent se connecter directement en root via clé SSH.

La raison est organisationnelle :

• petite équipe
• forte confiance
• traçabilité déjà assurée par les logs et les IP

Cela montre un point important :
le hardening dépend toujours du contexte.

Bastions et accès aux machines

Pour sécuriser les accès aux infrastructures, les bastions SSH sont une pratique fréquente.

Olivier :

Nous utilisons des configurations SSH qui permettent :

• d’identifier automatiquement les machines bastion
• de router la connexion via ces machines
• d’appliquer des règles spécifiques selon les machines

Certaines machines sensibles interdisent par exemple l’export de l’agent SSH, afin d’éviter tout risque de propagation d’accès.

L’importance des logs

Les logs sont essentiels pour comprendre ce qui se passe sur un système.

Olivier :
Les logs doivent être considérés comme des données précieuses. Ils servent notamment pour :

• analyser un incident
• réaliser un post-mortem
• répondre aux audits de sécurité
• reconstruire une chronologie d’attaque

Chez Bearstech, les logs sont envoyés vers des serveurs dédiés, distincts des machines surveillées.

Durcissement du système

SELinux ou AppArmor

Un système Linux peut être renforcé via des mécanismes de contrôle comme :

• SELinux
• AppArmor

Olivier :
Oui, c’est pénible à configurer. Oui, ça casse parfois des choses. Mais c’est indispensable.

Sur les machines de test, on peut temporairement désactiver ces protections pour comprendre un problème. En production, elles doivent être actives.

Chiffrement du système

Autre élément essentiel : le chiffrement des données.

Olivier :

Chez Bearstech, les machines utilisent généralement :

• LUKS
• LVM chiffré

Ce n’est pas toujours simple à gérer, surtout avec des centaines de machines virtuelles. Mais il n’y a pas de bonne raison de ne pas chiffrer les données. 

Installer uniquement le strict nécessaire

Un principe simple du hardening :

Moins il y a de logiciels installés, moins il y a de vulnérabilités possibles.

Chez nous, les images Debian sont extrêmement minimalistes.

• pas de paquets inutiles
• installation spécifique par rôle
• images standardisées

Chaque service installé est justifié par un besoin réel.

Sécurité réseau

Limiter les ports ouverts

Un autre principe fondamental : ouvrir uniquement les ports nécessaires.

Par exemple :

• une base de données n’a aucune raison d’être exposée sur Internet
• un service interne doit rester accessible uniquement sur le LAN

Firewall par défaut

Les machines doivent être protégées par un firewall strict.

Chez Bearstech :

• les ports sont fermés par défaut
• un service doit explicitement demander l’ouverture d’un port

Cela permet d’éviter qu’une mauvaise configuration expose accidentellement un service.

Chiffrement des communications

Même à l’intérieur d’une infrastructure, il est préférable de chiffrer les communications.

Historiquement, certains acteurs considéraient les réseaux internes comme sûrs.

Mais aujourd’hui :

• les architectures sont distribuées
• les réseaux sont partagés
• les attaques internes existent

Conclusion : chiffrer est devenu la norme.

Sauvegardes et PRA

La sécurité ne concerne pas uniquement les attaques : elle inclut aussi la résilience.

Chez Bearstech :

• les sauvegardes sont quotidiennes
• elles sont stockées sur des machines distinctes
• elles sont répliquées dans un autre datacenter

Une règle simple :

un backup doit survivre à la perte complète d’un site.

En pratique, les backups sont souvent répliqués à plus de 300 km.

Conclusion : la sécurité est une pratique continue

Le Linux hardening ne se résume pas à une checklist.

C’est :

• un ensemble de bonnes pratiques
• une adaptation au contexte
• une amélioration continue

Olivier :

Après 20 ans d’exploitation Linux, on continue encore d’améliorer nos configurations. Chaque incident, chaque audit et chaque découverte permet de renforcer le système.

La sécurité n’est jamais terminée. Elle se construit petit pas par petit pas.