Sécuriser serveur Linux VPS 2025 : la checklist complète en 20 minutes
Chaque jour, des milliers de VPS fraîchement provisionnés sont scannés par des bots en moins de 15 minutes. Si vous déployez des projets sur Hetzner, OVH, Scaleway ou tout autre provider, ce guide est votre première ligne de défense.
Chez Otomy, chaque serveur que nous configurons pour nos clients (PME en France et en Algérie) passe par cette checklist. Elle est conçue pour être exécutée en 20 minutes sur Ubuntu 22.04 / 24.04 ou Debian 12.
Étape 1 — Connexion initiale et mise à jour système (2 min)
ssh root@VOTRE_IP
apt update && apt upgrade -y && apt autoremove -y
Pourquoi c'est critique : Les CVE non patchées sont le vecteur d'attaque n°1 sur les VPS. Une mise à jour immédiate élimine les vulnérabilités connues.
Activez les mises à jour automatiques de sécurité :
apt install unattended-upgrades -y
dpkg-reconfigure -plow unattended-upgrades
Étape 2 — Créer un utilisateur non-root avec sudo (2 min)
Ne travaillez jamais en root. C'est la règle d'or.
adduser deploy
usermod -aG sudo deploy
Testez la connexion avec le nouvel utilisateur avant de continuer :
ssh deploy@VOTRE_IP
sudo whoami # doit retourner "root"
Étape 3 — Authentification par clé SSH uniquement (3 min)
Sur votre machine locale :
ssh-keygen -t ed25519 -C "deploy@monprojet"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@VOTRE_IP
Puis sur le serveur, verrouillez la configuration SSH :
sudo nano /etc/ssh/sshd_config
Modifiez ces lignes :
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
sudo systemctl restart sshd
Astuce Otomy : On utilise 1Password SSH Agent ou Secretive (macOS) pour gérer les clés sans fichier sur disque.
Étape 4 — Configurer le pare-feu UFW (2 min)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp comment 'SSH'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw enable
sudo ufw status verbose
Si vous hébergez Supabase, n8n ou d'autres services sur des ports custom, ajoutez-les explicitement. Ne jamais ouvrir tous les ports.
Étape 5 — Installer et configurer Fail2Ban (3 min)
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
Configuration recommandée :
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600
findtime = 600
sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
Résultat : Toute IP qui échoue 3 fois en 10 minutes est bannie pendant 1 heure.
Étape 6 — Durcir le kernel avec sysctl (2 min)
sudo nano /etc/sysctl.d/99-hardening.conf
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
sudo sysctl --system
Ces paramètres bloquent le spoofing, les redirections ICMP et activent les SYN cookies contre les attaques DDoS basiques.
Étape 7 — Installer un monitoring minimal (3 min)
Pas besoin de stack complète. Deux outils suffisent pour commencer :
Logwatch (rapports quotidiens par email)
sudo apt install logwatch -y
sudo logwatch --detail Med --mailto votre@email.com --range today
Netdata (monitoring temps réel, interface web)
curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel
Important : Ne l'exposez jamais publiquement. Utilisez un tunnel SSH ou un reverse proxy avec auth :
ssh -L 19999:localhost:19999 deploy@VOTRE_IP -p 2222
Étape 8 — Bonus DevSecOps : automatiser l'audit (3 min)
Lynis — Audit de sécurité automatisé
sudo apt install lynis -y
sudo lynis audit system
Lynis génère un score de durcissement et des recommandations concrètes. Chez Otomy, on intègre ce rapport dans nos pipelines CI/CD via GitHub Actions pour auditer chaque nouveau déploiement.
Automatisation avec n8n
Si vous utilisez n8n (que nous déployons fréquemment chez nos clients), créez un workflow qui :
- Exécute
lynis audit systemvia SSH - Parse le score de durcissement
- Envoie une alerte Slack/Telegram si le score descend sous 70
Récapitulatif — Votre checklist en 20 minutes
| Étape | Action | Temps |
|---|---|---|
| 1 | Mise à jour système + unattended-upgrades | 2 min |
| 2 | Utilisateur non-root + sudo | 2 min |
| 3 | Clé SSH Ed25519 + durcir sshd_config | 3 min |
| 4 | UFW : deny all, allow SSH/HTTP/HTTPS | 2 min |
| 5 | Fail2Ban sur SSH | 3 min |
| 6 | Sysctl hardening | 2 min |
| 7 | Logwatch + Netdata | 3 min |
| 8 | Lynis audit + alertes n8n | 3 min |
Ce qu'il faut faire APRÈS ces 20 minutes
- Configurer des backups automatiques (Restic + B2 ou S3)
- Déployer un reverse proxy Caddy ou Nginx avec TLS automatique
- Mettre en place CrowdSec comme alternative communautaire à Fail2Ban
- Conteneuriser vos apps avec Docker + réseau isolé
- Planifier un audit Lynis mensuel automatisé
Conclusion
Sécuriser un serveur Linux VPS en 2025, ce n'est pas optionnel — c'est un prérequis. Ces 20 minutes d'investissement vous évitent des semaines de galère en cas de compromission.
Chez Otomy, nous appliquons cette checklist sur chaque serveur que nous déployons pour nos clients, qu'il s'agisse d'héberger un site e-commerce, une instance n8n, une base Supabase ou un projet déployé via Vercel avec backend dédié.
Besoin d'un audit de sécurité complet ou d'une infogérance DevSecOps ? Contactez l'équipe Otomy.