Pourquoi ton serveur Linux est vulnérable dès l'installation — et comment le durcir en 30 minutes

Intro : La fausse confiance

C'était un mardi matin. J'avais fraîchement déployé un serveur Ubuntu flambant neuf sur une VPS. Configuration basique, rien de fou. J'étais fier du truc — Linux, c'est sécurisé par défaut, non ?

48 heures plus tard, j'ai reçu une alerte de mon hébergeur : "Activité SSH suspecte détectée. Votre serveur lance des tentatives de connexion sur d'autres machines."

Mon serveur avait été compromis. En 48 heures. Juste en le brancher.

Je n'avais rien fait pour le sécuriser. Pas de firewall, root exposé, SSH sur le port 22, aucune clé, mot de passe par défaut sur pas grand-chose (bon, Ubuntu force un mot de passe), mais c'était la fête en fait.

Cette histoire, c'est la réalité de 90% des admins qui commencent. On achète un serveur, on l'allume, on SSH dessus, et basta. Et puis un matin, surprise.

Mais ça ne devrait pas être comme ça. Et spoiler : durcir un Linux en basique, c'est 30 minutes de travail max. Pas plus.

Pourquoi un Linux neuf est une porte ouverte ?

Les distros Linux sont conçues pour l'usabilité, pas pour la paranoïa. Ubuntu, Debian, CentOS — elles sortent de la boîte avec des trucs activés par défaut pour que tout marche directement. SSH ? Activé. Root accessible ? Oui. Firewall ? Désactivé. C'est par design.

Et puis il y a les attaquants. Des robots, des scanners, des scripts qui tournent 24/7 à la recherche de serveurs mal configurés. On parle de millions de tentatives par jour. Pas des hackers en capuche qui te ciblent personnellement — juste du bruteforce automatisé.

Les chiffres sont flous, mais je dirais que 75% des compromissions arrivent dans les 72 premières heures après le déploiement, quand le serveur traîne en attente de config de sécu.

Et pas besoin d'être connu. J'ai vu des serveurs de startups à peine lancées se faire pwner juste parce qu'ils attendaient "d'avoir le temps" de les durcir.

Le problème ? La sécurité n'est pas activée par défaut. Elle doit être ajoutée.

Étape 1 : Changer le port SSH (mais pas comment tu penses)

D'accord, le port 22. C'est la première cible. Tous les bots attaquent le port 22. Je le dis directement : changer de port n'est pas vraiment de la sécurité, c'est juste une réduction du bruit.

Mais honnêtement ? C'est utile pour diminuer les logs remplis de spam SSH.

sudo nano /etc/ssh/sshd_config
# Trouve la ligne "Port 22" et change-la en un port entre 10000 et 65535
# Genre Port 2847
sudo systemctl restart ssh

Teste la connexion avant de fermer ta session SSH. Fais pas comme moi qui ai locké mon propre serveur. C'est pas malin.

ssh -p 2847 user@ton-serveur

Si ça marche, OK. Si ça marche pas, tu as encore ta session actuelle pour corriger.

Étape 2 : Configurer les clés SSH (la vraie sécurité)

Les mots de passe SSH ? C'est 2010. Les clés, c'est mieux. Beaucoup mieux.

Sur ta machine locale (pas le serveur) :

ssh-keygen -t ed25519 -C "admin@ton-serveur"
# Ça génère une clé en Ed25519 (plus moderne qu'RSA)
# Sauvegarde-la, définis une passphrase si tu veux

Ça crée deux fichiers : une clé privée (à garder zéro). Une clé publique.

Tu copie la clé publique sur le serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2847 user@ton-serveur

Ou manuellement, si c'est ta première fois :

cat ~/.ssh/id_ed25519.pub | ssh -p 2847 user@ton-serveur "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Ensuite, désactive l'authentification par mot de passe entièrement :

sudo nano /etc/ssh/sshd_config
# PasswordAuthentication no
# PubkeyAuthentication yes
sudo systemctl restart ssh

Teste encore, sur une autre session. Avant de fermer celle-ci.

Les bots peuvent scanner le port 22 pendant mille ans, ils n'auront rien. Pas de clé privée, c'est dead.

Étape 3 : Activer le firewall (UFW, c'est simple)

Linux a ufw, le "Uncomplicated Firewall". Le nom dit tout. C'est simple.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2847/tcp
sudo ufw enable

Ça dit : "Refuse tout en entrée, sauf le port 2847 pour SSH". C'est ça.

Si tu as un web server :

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Vérifier :

sudo ufw status

Ça prend 2 minutes. Et ça stoppe 95% des attaques basiques. Les bots testent des ports aléatoires, trouvent rien, passent au suivant.

Étape 4 : Désactiver l'accès root direct

Root est dangereux. Non pas qu'il faut LE supprimer, mais le rendre inaccessible directement est une bonne idée.

sudo nano /etc/ssh/sshd_config
# PermitRootLogin no
sudo systemctl restart ssh

Désormais, personne ne peut SSH directement en root. Ils doivent d'abord SSH en user normal, puis sudo su - s'ils ont les permissions.

C'est une couche supplémentaire. Pas une protection absolue, mais ça filtre 80% du bruit.

Étape 5 : Ajouter fail2ban (pour les tenaces)

Les bots vont quand même essayer. 100 fois. 1000 fois. À un moment, tu veux les bannir.

fail2ban regarde les logs SSH, voit quelqu'un qui échoue 5 fois d'affilée, et le bloque pour 10 minutes.

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Vérifier :

sudo fail2ban-client status sshd

Ça filtre les attaques bruteforce de façon automatique. Pas le game-changer absolu, mais utile.

Étape 6 : Mettre à jour le système

Les paquets contenaient des failles. Tu dois les patcher. C'est pas une option.

sudo apt update
sudo apt upgrade

Fais ça maintenant. Et configure une mise à jour auto une fois par semaine :

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

Les vuln zéro-day, c'est rare. Mais les patchs normaux, c'est constant.

Étape 7 : Ajouter un utilisateur sans accès root (et virer root)

Jamais faire tourner des services en root. Jamais. Une app buguée en root = serveur buggué.

sudo useradd -m -s /bin/bash appuser
sudo usermod -aG sudo appuser

Les apps tournent sous appuser. Si elles se font compromettre, elles ne peuvent faire que ce qu'appuser peut faire, pas l'intégralité du serveur.

Étape 8 : Surveiller les logs (juste les basics)

Les logs, c'est le SIEM gratuit.

sudo tail -f /var/log/auth.log

Ça te montre les tentatives SSH en temps réel. Ça paraît simple, mais tu vois directement l'attaque happening.

Pour automatiser, tu peux envoyer les logs intéressants quelque part (Syslog, CloudWatch, ou même un fichier local).

Les erreurs courantes (et pourquoi elles te font ch*er)

Erreur 1 : "Je vais juste utiliser root partout, c'est plus simple" Ouais, et tu vas te faire pwner plus vite. Vu ça 100 fois. Pas exagéré.

Erreur 2 : "Je vais laisser un mot de passe SSH faible, je changerai demain" Demain ne viendra jamais. Et deux jours après, t'es compromis.

Erreur 3 : "Mon firewall va étouffer les perfs" Non. ufw sur une VPS moderne, c'est négligeable. 0.001ms de latence. Ridicule.

Erreur 4 : "Je vais désactiver l'SSH temporairement" Et puis t'oublies de l'activer. Tu te retrouves bloqué.

Erreur 5 : "Changer le port 22 c'est security by obscurity" Oui, un peu. Mais c'est réduire le bruit. Les deux ont de la valeur.

Le coût réel (temps + argent)

Durci un Linux en basique ? 30 minutes de travail.

Un serveur compromis ?

• Temps de diagnostic : 4-6 heures (minimum)
• Temps de cleanup : 8-12 heures
• Temps de forensique : 2-3 jours
• Perte de données : ???
• Perte de confiance client : Inestimable
• Facture d'hébergeur pour "activité malveillante" : 50-500€

Je n'exagère pas. J'ai vu des startups qui ont dû rebouler 2 serveurs complets parce qu'ils n'avaient pas fait ces étapes. Ça leur a coûté 3 jours de dev ops pour rien.

Le ROI : 30 minutes maintenant = potentiellement des milliers d'euros + semaines de chaos évités.

C'est du bon calcul.

Comment VaultAura peut t'aider

Écrire une checklist, c'est une chose. La mettre en place à l'échelle, c'en est une autre.

Si tu gères 10 serveurs, 30 minutes c'est... 5 heures. Doable.

Si tu en gères 50 ? 100 ? Tu besoin d'automatiser.

C'est là que VaultAura intervient. On aide les équipes infra à :

• Automatiser le hardening : Appliquer ces configs en 5 minutes via Ansible/Terraform, pas manuellement
• Centraliser la gestion des secrets : Clés SSH, certificats, crédentiels — tout en un endroit, chiffré
• Auditer la conformité : Vérifier que tous les serveurs respectent les standards de sécu
• Gérer le cycle de vie des clés : Rotation automatique, gestion des durées de vie
• Ajouter des layers supplémentaires : 2FA, SSO, audit logging

On a aidé une boîte à passer de "30 serveurs à peu près sécurisés" à "100 serveurs avec un standard cohérent" en 6 semaines.

Le truc ? Une fois que tu as une base solide (ces 30 minutes), escalader devient du standard ops.

Au final

Ton serveur Linux neuf n'est pas sécurisé par défaut. C'est un fait. Mais le durci ? Hyper rapide.

30 minutes. Clés SSH, firewall, port custom, fail2ban, mises à jour. Boom. Tu passes de "Je vais me faire pwner" à "Les bots trouveront pas grand-chose ici".

C'est pas la sécurité maximale (ça n'existe pas). Mais c'est la base. Et la base qui manque à 80% des serveurs en prod.

Si tu en gères un ou deux, fais-le manuellement. Si t'en gères dix, rends-le scriptable. Si t'en gères plus, contacte nous pour l'automatiser.

Besoin d'aide pour durcir ton infra en vrai ? Contactez VaultAura — on peut auditer tes serveurs, t'aider à mettre en place une stratégie globale, ou automatiser tout ça pour toi.

À bientôt 🔒