Sécurité Ubuntu 101 : Pratiques Essentielles pour un Système Sécurisé

Introduction

Construire une défense à plusieurs couches est une préoccupation cruciale pour tout système, qu'il soit exécuté dans un centre de données, un environnement cloud ou sur du matériel personnel. Si vous êtes paresseux, suivez au moins le minimum minimorum.

La sécurité est une illusion, la qualité de cette illusion dépend de vous.

Cet article concerne Ubuntu, mais les principes s'appliquent à toutes les distributions. Il y a beaucoup de terrain à couvrir, cet article sera probablement la première partie d'une série.

Concepts de Base de Sécurité

Principe du Moindre Privilège

Les utilisateurs, les processus et les applications ne devraient avoir accès qu'aux ressources dont ils ont absolument besoin pour remplir leurs fonctions. Cela réduit la surface d'attaque de votre système. Si un compte utilisateur ou une application est compromis, les dommages sont limités à ce à quoi cette entité avait accès.

En pratique, cela signifie :

• Déployer des applications en utilisant des comptes de service dédiés avec des permissions minimales requises
• Fournir un accès utilisateur externe uniquement via SSH avec des environnements chroot correctement configurés
• Implémenter des shells restreints lorsque les utilisateurs ont besoin d'un accès système limité
• Utiliser des technologies de conteneurisation pour isoler les environnements d'applications et les dépendances

Note : Bien que la conteneurisation offre des avantages de sécurité grâce à l'isolation, elle ajoute une complexité qui peut introduire de nouvelles vulnérabilités si elle n'est pas correctement implémentée et maintenue. La valeur de sécurité dépend d'une configuration et d'une gestion appropriées. En règle générale, plus votre architecture est complexe, moins elle est sécurisée. L'obscurcissement par la complexité n'est pas de la sécurité.

Cela dit, si votre système a été compromis, vos couches de sécurité ne vous donneront qu'un temps relatif pour atténuer la brèche. Une surveillance constante est nécessaire, mais cela fera partie d'un article ultérieur.

Gestion des Mises à Jour

L'une des mesures de sécurité les plus simples mais les plus efficaces consiste à maintenir votre système Ubuntu à jour. Les vulnérabilités de sécurité sont constamment découvertes et corrigées, ce qui rend les mises à jour régulières essentielles.

La façon la plus évidente est de le faire manuellement (un redémarrage peut être nécessaire) :

sudo apt update && sudo apt upgrade

Nettoyez les paquets inutilisés

sudo apt autoremove

Vous pouvez automatiser les mises à jour de sécurité en utilisant le paquet unattended-upgrades, qui peut être configuré pour installer automatiquement les mises à jour de sécurité.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Pour les systèmes critiques, vous voudrez peut-être le garder manuel. Établissez un environnement de test pour vérifier les mises à jour avant de les appliquer aux systèmes de production, en vous assurant que les correctifs de sécurité n'introduisent pas de problèmes de stabilité.

Vous pouvez également souscrire à un support fournisseur tel que Expanded Security Maintenance (ESM) de Canonical.

Création d'un Utilisateur Administratif

Le modèle de permissions d'Ubuntu est basé sur les utilisateurs, les groupes et le principe du moindre privilège. Pour une meilleure sécurité, il est recommandé de créer un utilisateur administratif dédié avec des privilèges sudo. Le mécanisme sudo permet aux utilisateurs normaux d'exécuter des commandes spécifiques avec des privilèges élevés sans avoir besoin de se connecter en tant qu'utilisateur root. Cela suit le principe du moindre privilège.

Pour créer un nouvel utilisateur administratif (Sherlock Holmes me vient à l'esprit mais n'hésitez pas...) :

# Créer un nouvel utilisateur
sudo adduser holmes

Suivez les instructions et donnez-lui un mot de passe long et aléatoire pour l'instant, par exemple : .qPhEFGQ4v2.L6uaHeH7h2a!xBtR

# Ajouter l'utilisateur au groupe sudo pour pouvoiiur élever ses privilèges quand nécessaire
sudo usermod -aG sudo holmes

À partir de là, nous pourrions devenir fous en implémentant des règles sudo pour un contrôle des permissions détaillé, en définissant des valeurs de délai d'expiration, la journalisation, etc., mais gardons notre santé mentale pour le moment.

Création d'une Clé SSH

Les clés ED25519 sont actuellement la norme recommandée pour l'authentification SSH en raison de leur excellent équilibre entre sécurité et performance. Dans notre cas, c'est ce dont nous avons besoin ici.

Pour générer une clé ED25519, allez dans votre terminal local préféré sur Linux/Mac/PowerShell :

# version courte
ssh-keygen -t ed25519 -a 100

# version longue
ssh-keygen -t ed25519 -a 100 -N 'Your passphrase' -f ~/.ssh/my_custom_key -C "user@hostname"

Paramètres :

-a 100 ce paramètre augmente les tours de la fonction de dérivation de clé (KDF), améliorant la sécurité contre les attaques par force brute en rendant la clé privée plus difficile à craquer si elle est compromise. La valeur par défaut est de 16 tours, donc l'augmentation à 100 améliore significativement la résistance aux tentatives de craquage hors ligne.

-N 'Your passphrase' : utilisez ce qui vous vient à l'esprit, n'utilisez pas de citations connues ou de mots de passe simples. Une phrase de passe n'est pas un mot de passe.

-C 'user@location' : utilisez quelque chose dont vous pouvez vous souvenir et qui indique l'appareil sur lequel vous stockez votre clé privée, par exemple : maxime@macbookpro

Sources :

Ajout de la Clé Publique

Avant de désactiver la connexion par mot de passe et de désactiver la connexion root, vous voulez ajouter sa clé au serveur. Depuis votre ordinateur local où vous avez créé la clé, vous voulez afficher le contenu de la clé publique que vous venez de créer.

# si le nom de votre clé est id_ed25519
cat ~/.ssh/id_ed25519.pub

Vous devriez avoir quelque chose comme "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFy+0NNSyO3q90Z2ZMUDtg6uX1sK4awI/FBnrtPGIyiE holmes@example.com".

Collez-le dans votre serveur où vous avez créé l'utilisateur holmes :

# Faire en sorte que le répertoire .ssh existe et avec les bonne permissions
mkdir -p /home/holmes/.ssh
chmod 700 /home/holmes/.ssh

# utilisez nano si vous préférez
vi /home/holmes/.ssh/authorized_keys

# Mettre les bonnes permissions pour le fichier authorized_keys
chmod 600 /home/holmes/.ssh/authorized_keys
chown -R holmes:holmes /home/holmes/.ssh

Authentification par Clé SSH

L'authentification par clé SSH offre plusieurs avantages par rapport à l'authentification par mot de passe :

1. Immunité contre les attaques par force brute
2. Pas de mots de passe à retenir ou potentiellement exposés
3. Couplée avec une phrase de passe pour une meilleure sécurité
4. Adaptée à l'automatisation

Pour imposer l'authentification par clé SSH uniquement :

Option 1 : Édition du fichier de configuration principal :

sudo vi /etc/ssh/sshd_config

# Ajoutez ces lignes au fichier
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Option 2 (Recommandée) : Utilisation du répertoire de configuration '.d' :

Include /etc/ssh/sshd_config.d/*.conf

Nous pouvons simplement ajouter les nouvelles configurations ou les remplacements ici : créer un fichier de configuration personnalisé avec un préfixe numérique élevé. Ajoutez les paramètres ci-dessus et enregistrez le fichier :

sudo vi /etc/ssh/sshd_config.d/99-custom-security.conf

Après avoir effectué des modifications avec l'une ou l'autre approche, redémarrez le service SSH (ou ouvrez une nouvelle session):

sudo systemctl restart ssh

L'utilisation de ce répertoire est préférable car nous n'ajoutons ou ne remplaçons que ce dont nous avons besoin. Il est plus facile à gérer que de faire défiler la longue configuration par défaut. Cela donne également une taille plus petite à enregistrer sur un système de contrôle de version.

Désactivation de la Connexion Root

Désactiver la connexion root élimine la possibilité pour les attaquants de prendre le contrôle complet du système en compromettant un nom d'utilisateur largement connu, les forçant à identifier des comptes utilisateur valides avant de tenter une élévation de privilèges.

# Créer un nouveau fichier de config (avec un nom approprié)
sudo vi /etc/ssh/sshd_config.d/disable-root.conf

#  Ajoutez cette ligne
PermitRootLogin no

# Sauvegardez, quittez et redémarrez le service
# Tester si cela fonctionne

Sources :

• Ubuntu Documentation (EN) - La documentation officielle en anglais
• DigitalOcean SSH Hardening Guide (EN) - Couvre les meilleures pratiques pour la configuration SSH

Comparaison des Clés

Options Actuelles de Clés SSH

Futures Options Résistantes aux Ordinateurs Quantiques

La prochaine version d'OpenSSL 3.5 (prévue pour le 8 avril 2025) représente une avancée majeure en cybersécurité avec l'intégration de méthodes de cryptographie post-quantique (PQC) :

• Cryptographie post-quantique (PQC) : Avec l'intégration des méthodes PQC dans OpenSSL 3.5, ces algorithmes seront bientôt disponibles dans les systèmes modernes :

• ML-KEM (FIPS 203) — Module Lattice-Based Key Encapsulation Mechanism. C'est une norme PQC pour l'échange de clés, conçue pour remplacer les méthodes d'échange de clés actuelles comme ECDH.

• ML-DSA (FIPS 204) — Module Lattice-Based Digital Signature Algorithm. Cette norme PQC pour les signatures numériques utilise la méthode de signature Dilithium et sert de remplacement pour RSA et ECDSA.

• SLH-DSA (FIPS 205) — Stateless Hash-Based Digital Signature Algorithm. Cette norme PQC pour les signatures numériques utilise la méthode de signature SPHINCS+.

L'intégration de ces méthodes dans OpenSSL, la bibliothèque cryptographique la plus largement utilisée, fera avancer toute l'industrie en matière de sécurité résistante aux ordinateurs quantiques. Une fois implémentés, les systèmes Ubuntu pourront utiliser ces algorithmes pour l'authentification SSH, offrant une protection contre les futures menaces de l'informatique quantique.

• Approches hybrides : Certains systèmes prennent maintenant en charge la combinaison d'algorithmes traditionnels avec des algorithmes post-quantiques pour une sécurité à l'épreuve du futur, offrant un chemin de transition qui maintient la compatibilité tout en ajoutant une résistance quantique.

Source : - OpenSSL Finally Enters a Quantum World - Analyse détaillée de la version OpenSSL 3.5 et de son implémentation de cryptographie post-quantique (article en anglais seulement)

Protégez vos clés privées

Protégez vos clés SSH privées contre le vol :

• Utilisez des phrases fortes pour vos clés
• Stockez les clés uniquement sur des appareils de confiance
• Définissez des permissions de fichier appropriées (chmod 600)
• Envisagez d'utiliser une clé de sécurité matérielle
• Ne partagez ou ne transmettez jamais vos clés privées
• Gardez votre système à jour contre les vulnérabilités
• Méfiez-vous des logiciels malveillants et des enregistreurs de frappe (key loggers)
• Faites tourner périodiquement vos clés

Les pratiques les plus importantes sont l'utilisation de phrases de passe fortes et le maintien de permissions de fichier appropriées.

Clés de Sécurité "Hardware"

L'authentification nécessite quelque chose que vous avez (la clé) et quelque chose que vous faites (toucher)

Les normes FIDO2, WebAuthn et FIDO U2F ont été créées et développées par l'Alliance FIDO (Fast Identity Online). Les clés de sécurité matérielles comme les YubiKeys peuvent être utilisées avec OpenSSH grâce à la prise en charge de FIDO2/U2F. Elles empêchent l'extraction de la clé privée même si votre ordinateur local est compromis. Voici quelques références :

• YubiKeys - Propriétaire avec contributions Open source
• SoloKeys - Matériel et firmware entièrement open source
• Nitrokey - Matériel de sécurité open source avec des modèles conçus pour SSH
• OnlyKey - Matériel open source avec support SSH

Vous devez avoir les bibliothèques FIDO2 installées, vous pouvez vérifier ici pour plus d'informations :

# sur mac
brew install libfido2

La plupart des clés de sécurité FIDO2 ont une zone ou un bouton tactile que vous devez appuyer physiquement lors de l'authentification. Cette exigence de contact physique est une fonctionnalité de sécurité appelée "vérification de la présence de l'utilisateur" qui garantit :

• Un humain est réellement présent pendant l'authentification
• Un logiciel malveillant ne peut pas utiliser silencieusement la clé sans votre connaissance

La génération de clé ressemblera à

ssh-keygen -t ed25519-sk -O resident -f ~/.ssh/id_ed25519_sk

# vous voules encore une "passphrase"...

Une dernière chose, ne voyagez pas avec votre clé ou ne la mettez pas dans le même sac que votre ordinateur portable.

Surveiller les connexions

Puisque nous éliminons complètement l'authentification par mot de passe en faveur des clés SSH, les politiques traditionnelles de verrouillage de compte basées sur PAM deviennent inutiles pour l'accès SSH. Cependant, il est toujours important de se protéger contre les tentatives d'accès non autorisées :

Configurez une surveillance automatisée des journaux pour détecter et alerter sur les tentatives d'authentification échouées répétées :

# Installer fail2ban
sudo apt install fail2ban

# Créer une configuration de prison pour SSH
sudo vi /etc/fail2ban/jail.d/ssh-custom.conf

# Ajoutez ce qui suit au fichier (temps en secondes):
[sshd]
enabled = true
mode = aggressive
bantime = 86400
findtime = 600
maxretry = 3

Commandes utiles :

# redémarrez fail2ban après changements
sudo systemctl restart fail2ban

Vous pouvez vérifier que fail2ban fonctionne avec :

sudo systemctl status fail2ban

Vérifiez si votre "prison" est active avec :

sudo fail2ban-client status sshd

# output example
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:  0
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 0
   |- Total banned:  0
   `- Banned IP list:

Cette configuration bannira les adresses IP après 3 tentatives échouées dans les 10 minutes consécutives et pendant 24 heures. Même si nous n'utilisons pas l'authentification par mot de passe. Cela aide à réduire le nombre d'écritures dans les journaux et la charge du serveur face aux attaquants persistants.

Si besoin d'enlever le ban pour une addresse IP spécifique:

# sudo fail2ban-client set JAIL unbanip IP_ADDRESS
sudo fail2ban-client set sshd unbanip <adresse ip>

Firewall (Pare-feu)

La sécurité avec les pare-feu est un vaste sujet. Voici ce que vous pouvez faire au niveau de votre serveur. Envisagez de limiter l'accès SSH à des adresses IP ou des plages spécifiques :

# Vérifier si "Uncomplkicated Firewall (ufw)" est activé
sudo ufw status

# si inactif
sudo ufw enable

# Permettre la connexion SSH depuis certaines IPs seulement
sudo ufw allow from <your ip address or network> to any port 22

Docker "dans la place"

Docker et ufw ont des problèmes à travailler ensemble. Docker manipule directement les règles iptables, ce qui peut contourner les règles de filtrage d'UFW. Il existe des solutions mais ce n'est pas idéal. Cela ferait tout un article à part entière, donc je laisserai cette note ici.

Conclusion

En implémentant les mesures de sécurité fondamentales décrites dans cet article, de l'application du principe du moindre privilège à la configuration de l'authentification par clé SSH uniquement avec des clés ED25519, vous placez votre système dans une position plus forte que beaucoup d'autres. Les mises à jour régulières, la gestion appropriée des utilisateurs avec des comptes administratifs, et la surveillance proactive via fail2ban forment une base solide qui protège contre les vecteurs d'attaque courants.

Rappelez-vous que la sécurité est comme un oignon avec plusieurs couches. Les mesures que nous avons couvertes représentent certaines des couches internes essentielles, mais une stratégie de sécurité complète s'étend bien plus loin. Comme mentionné au début, cet article est probablement le premier d'une série, les futurs sujets avancés pourraient inclure :

• Sécurité réseau et protection de l'infrastructure (NGFW/VPN)
• Surveillance système (SIEM/IDS)
• Gestion améliorée des identités et des accès (IAM/MFA/RBAC)
• Sécurité des applications et des API (OWASP/WAF/CSP/OAUTH)
• Sécurité du déploiement (CI-CD/SAST/DAST)

La sécurité n'est pas une configuration initiale mais un processus continu. Examinez régulièrement vos journaux, testez vos mesures de sécurité et restez informé des nouvelles vulnérabilités et de leurs solutions.

Si vous cherchez à mettre en œuvre ces mesures de sécurité ou avez besoin d'aide pour des protections plus avancées pour votre environnement, n'hésitez pas à me contacter. Parfois, avoir un guide expérimenté peut vous faire économiser des heures de dépannage et garantir que vos couches de sécurité sont correctement configurées dès le début.