Dès l’instant où c’est devenu ‘mon serveur’, tout relève de ma responsabilité
La dernière fois, j’ai franchi le mur de la CLI Linux et des permissions. chmod, chown, et même le chmod 777 qu’il ne faut surtout jamais faire. Pour le contrôle d’accès à un fichier, j’avais à peu près saisi le principe.
Mais à ce moment-là, je me faisais une grande illusion. Je pensais que tant que je gérais bien les ‘permissions de fichiers’, le serveur serait en sécurité.
« La sécurité serveur ? Ce n’est pas l’équipe sécurité qui s’en occupe ? »
Dans une grande entreprise, peut-être. Mais moi, je suis un développeur solo. Administrateur serveur, responsable sécurité, ingénieur réseau : tout cela, c’était ‘moi’. Toute la responsabilité de la sécurité reposait sur mes épaules.
Et ce qui m’a fait prendre conscience de ce fait, c’est le journal de connexion au serveur que j’ai découvert un lundi matin.
La crise : quelqu’un frappait à la porte de mon serveur
Un lundi matin, alors que je me connectais par habitude en SSH au serveur pour vérifier les journaux, j’ai remarqué quelque chose d’étrange.
# Vérifier les dernières tentatives SSH échouées
$ grep "Failed password" /var/log/auth.log | tail -20
En voyant les journaux affichés à l’écran, j’ai eu la chair de poule.
Feb 10 03:14:22 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:25 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:27 sshd: Failed password for admin from 185.220.xx.xx
Feb 10 03:14:30 sshd: Failed password for ubuntu from 185.220.xx.xx
...
Des centaines de tentatives de connexion à partir de 3 h du matin. IP étrangère. Les noms de compte alternaient entre root, admin et ubuntu. Il s’agissait de quelqu’un qui lançait un ‘programme automatisé (bot)’ pour tester les mots de passe par force brute (Brute Force).
« Hein ? Je n’ai quand même pas encore été piraté…? »
Heureusement, rien n’a été percé. Mais devant un voleur qui essaie les clés une par une à votre porte, peut-on vraiment dire : « Il n’a pas réussi à entrer, donc tout va bien » ? J’ai immédiatement entrepris de vérifier l’état de sécurité du serveur.
Étape 1 : Verrouiller la porte d’entrée — renforcer SSH
La porte d’entrée du serveur, c’est SSH (Secure Shell). C’est précisément ce que j’utilise pour me connecter au serveur. Le problème, c’est que les pirates veulent entrer par la même porte. Il faut donc commencer par renforcer cette porte d’entrée.
Changer le port SSH (par défaut 22 → autre numéro)
Le port SSH par défaut est le 22. Les scanners automatiques des pirates frappent d’abord au port 22. Rien qu’en changeant le numéro de port, on peut filtrer plus de 90 % des attaques par force brute.
# Ouvrir le fichier de configuration SSH
$ sudo vi /etc/ssh/sshd_config
# Changer le numéro de port (par défaut 22 → par exemple 2222)
Port 2222
# Redémarrer le service SSH
$ sudo systemctl restart sshd
Pour filer la métaphore, les voleurs visent d’abord la porte principale du rez-de-chaussée (port 22). Si vous déplacez l’entrée vers la porte du toit au 3e étage (port 2222), la plupart des voleurs ne trouvent même pas où elle se trouve.
Bloquer la connexion directe au compte root
D’après les journaux, le premier compte que les pirates tentent, c’est ‘root’. root étant le compte administrateur suprême de Linux, y accéder permet de prendre le contrôle total du serveur.
# Bloquer la connexion directe en root dans le fichier de configuration SSH
$ sudo vi /etc/ssh/sshd_config
PermitRootLogin no
Désormais, se connecter en SSH en tant que root est tout simplement impossible. On se connecte avec un compte normal, puis on élève les privilèges avec sudo uniquement en cas de besoin.
Authentification par clé SSH au lieu du mot de passe
Même si un mot de passe est très complexe, un programme automatisé qui essaie des dizaines de milliers de combinaisons finira tôt ou tard par le casser. La méthode la plus sûre est de désactiver complètement la connexion par mot de passe et de ne se connecter qu’avec une ‘clé SSH (Key)’.
# Générer une paire de clés SSH sur mon poste (local)
$ ssh-keygen -t rsa -b 4096
# Copier la clé publique vers le serveur
$ ssh-copy-id -p 2222 user@my-server-ip
# Désactiver la connexion par mot de passe sur le serveur
$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
L’authentification par clé SSH n’est pas une ‘clé’, mais une ‘reconnaissance d’empreinte digitale’. Un mot de passe (clé) peut être copié, mais la clé privée (empreinte) qui n’existe que sur mon poste est pratiquement impossible à dupliquer.
Étape 2 : Ériger un mur — le pare-feu (Firewall)
Une fois la porte d’entrée (SSH) renforcée, il est temps d’ériger un mur autour du bâtiment et de contrôler les accès. C’est le ‘pare-feu (Firewall)’.
Un serveur possède au total 65 535 ports (points d’accès). Sans pare-feu, ces 60 000 portes sont toutes grandes ouvertes. Il faut n’ouvrir que les portes nécessaires et verrouiller tout le reste.
Sous Linux, l’outil pare-feu le plus facile à utiliser est ‘UFW (Uncomplicated Firewall)’.
# Activer UFW
$ sudo ufw enable
# Politique par défaut : tout bloquer en entrée, autoriser en sortie
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
# Ouvrir uniquement les ports nécessaires
$ sudo ufw allow 2222/tcp # SSH (port modifié)
$ sudo ufw allow 80/tcp # HTTP
$ sudo ufw allow 443/tcp # HTTPS
# Vérifier l'état actuel du pare-feu
$ sudo ufw status
| Port | Usage | État |
|---|---|---|
| 2222 | SSH (port modifié) | ✅ Autorisé |
| 80 | HTTP (Web) | ✅ Autorisé |
| 443 | HTTPS (Web sécurisé) | ✅ Autorisé |
| 22 | SSH (par défaut, plus utilisé) | ❌ Bloqué |
| Autres | Tous | ❌ Bloqués |
Sur 60 000 portes, seulement 3 restent ouvertes, les autres ont été murées. Il n’y a plus de porte contre laquelle le voleur puisse frapper.
Étape 3 : Chiffrer la communication — HTTPS
Si le serveur fournit un service web, il faut aussi protéger la communication entre l’utilisateur et le serveur. C’est le ‘HTTPS’.
HTTP envoie les données telles quelles, comme une ‘carte postale’. N’importe qui peut en lire le contenu en cours de route. HTTPS, lui, place les données dans une ‘lettre scellée’. Même en l’interceptant, on ne peut pas en lire le contenu.
Si l’identifiant et le mot de passe saisis par l’utilisateur dans un formulaire de connexion étaient envoyés en HTTP ? N’importe quelle personne partageant le Wi-Fi du café pourrait les lire en clair.
En pratique, la façon la plus simple de mettre en place HTTPS est d’obtenir un certificat SSL gratuit via ‘Let’s Encrypt’.
# Installer Certbot (outil d'automatisation Let's Encrypt)
$ sudo apt install certbot python3-certbot-nginx
# Émettre le certificat et l'appliquer automatiquement à Nginx
$ sudo certbot --nginx -d mydomain.com
# Tester le renouvellement automatique (le certificat doit être renouvelé tous les 90 jours)
$ sudo certbot renew --dry-run
En quelques lignes de commande, l’adresse de mon service passe de http:// à https://, et l’icône de cadenas apparaît dans la barre d’adresse du navigateur. Cela donne aux utilisateurs la confiance que « ce site est sécurisé ».
Étape 4 : Système de défense automatique — Fail2Ban
Même en changeant le port SSH et en configurant l’authentification par clé, il existe des bots persistants. Il y en a forcément qui trouvent le port modifié et tentent de s’y connecter.
Dans ces cas-là, ‘Fail2Ban’ est très utile. C’est un outil qui bloque automatiquement toute IP ayant dépassé un certain nombre d’échecs de connexion.
# Installer Fail2Ban
$ sudo apt install fail2ban
# Configurer la protection SSH
$ sudo vi /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600
findtime = 600
| Paramètre | Signification |
|---|---|
| maxretry = 5 | Après 5 échecs |
| bantime = 3600 | l’IP est bloquée pendant 1 heure |
| findtime = 600 | S’applique si 5 échecs ont lieu en moins de 10 minutes |
# Démarrer Fail2Ban
$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
# Vérifier les IP actuellement bloquées
$ sudo fail2ban-client status sshd
Fail2Ban, c’est la ‘caméra de vidéosurveillance + serrure automatique’ installée devant la porte d’entrée. Si un individu suspect se trompe plusieurs fois de mot de passe, l’accès lui est automatiquement interdit.
Conseil pratique : checklist de sécurité
Je résume sous forme de checklist tout ce que nous avons configuré jusqu’ici. En suivant cette liste chaque fois que vous mettez en place un nouveau serveur, vous disposerez d’une barrière de défense basique.
| # | Élément | Commande/Paramètre |
|---|---|---|
| 1 | Changer le port SSH | Port 2222 dans sshd_config |
| 2 | Bloquer la connexion root | PermitRootLogin no |
| 3 | Passer à l’authentification par clé SSH | PasswordAuthentication no |
| 4 | Activer le pare-feu | ufw enable, n’autoriser que les ports nécessaires |
| 5 | Mettre en place HTTPS | Let’s Encrypt + Certbot |
| 6 | Installer Fail2Ban | Blocage automatique d’IP en cas d’échecs de connexion |
| 7 | Mises à jour régulières | sudo apt update && sudo apt upgrade |
Le point 7 est plus important qu’on ne le pense. Des failles de sécurité sont découvertes quotidiennement. On a beau dresser un pare-feu, si l’OS ou le logiciel lui-même a des trous, cela ne sert à rien. Les mises à jour régulières sont la mesure de sécurité la plus basique et en même temps la plus efficace.
Pour finir : la sécurité n’est pas quelque chose d’exceptionnel, c’est une habitude
Au début, le mot sécurité me paraissait grandiloquent. Défense contre le piratage, détection d’intrusion, chiffrement… J’en venais à penser que c’étaient des histoires de film.
Mais à la pratique, cela ne nécessitait aucune technique exceptionnelle. Changer le port SSH, activer le pare-feu, configurer l’authentification par clé, installer Fail2Ban. Quelques lignes de commande et c’était réglé. L’important, ce n’est pas de ‘savoir’, mais d’agir’.
Les incidents de sécurité ne se produisent pas à cause de techniques de piratage très avancées, mais sur des serveurs où les mesures de base n’ont pas été appliquées.
Depuis ce jour, chaque fois que je mets en place un nouveau serveur, j’exécute impérativement cette checklist de sécurité avant de déployer le code. Vérifier la serrure avant d’ouvrir la porte. C’est la posture la plus élémentaire pour protéger un serveur.
Jusqu’ici, nous avons bâti une condition physique de base (CLI, permissions, sécurité) pour survivre dans la jungle qu’est Linux. Mais un problème fondamental demeure. L’environnement de mon ordinateur portable (Windows) et celui du serveur Linux sont différents. La version de Java diffère, les bibliothèques aussi.
Il existe une technologie qui va définitivement mettre fin à l’excuse « Chez moi ça marche ». La prochaine fois, nous parlerons de la ‘virtualisation et des conteneurs’, qui éliminent complètement les différences d’environnement.