Sécurité Linux VPS : couches, menaces, durcissement

Vous venez de provisionner un VPS Linux. En moins de 90 secondes, des scanners automatisés l'ont déjà repéré. Dans la première heure, vos logs SSH afficheront des centaines de tentatives de connexion par force brute, émanant de botnets qui testent des noms d'utilisateur et des mots de passe courants.

Ce n'est pas un scénario hypothétique. Cela arrive à chaque serveur exposé sur internet.

La plupart des guides de sécurité VPS vous livrent une liste numérotée de 20 conseils ou plus, sans structure ni priorité. Ce guide adopte une approche différente. Il représente la sécurité comme des couches concentriques, chacune réduisant davantage votre surface d'attaque. Vous comprendrez quelles attaques ciblent réellement votre serveur et quelles défenses les bloquent.

Si vous configurez votre premier VPS, commencez par les 5 premières étapes de sécurité. Cette seule section bloque plus de 90 % des attaques automatisées.

Si vous êtes un administrateur expérimenté, utilisez les liens d'ancrage pour aller directement à la couche qui vous intéresse.

Ce guide couvre Debian 12 et Ubuntu 24.04. Toutes les commandes sont testées sur les deux distributions.

Quelles attaques ciblent un VPS Linux fraîchement provisionné ?

Un VPS avec une IP publique fait face à des attaques automatisées dans les secondes qui suivent sa mise en ligne. Des botnets balaient en permanence l'ensemble de l'espace IPv4. Les attaques les plus courantes sont le credential stuffing SSH, le scan de ports pour détecter les services exposés, et l'exploitation de vulnérabilités connues dans les logiciels non mis à jour.

Comprendre le modèle de menace donne du contexte à chaque recommandation ci-dessous. Voici ce qui se passe réellement.

Scan automatisé

Les botnets analysent en continu l'ensemble de la plage IPv4. Des projets comme Shodan et Censys indexent chaque port accessible. Votre serveur n'est pas ciblé spécifiquement. Il est découvert parce qu'il existe.

Dans la première heure suivant le provisionnement, attendez-vous à :

Plus de 200 tentatives de connexion SSH depuis des IP distribuées
Des scans de ports sondant les bases de données (3306, 5432), les serveurs web (80, 443) et les panneaux d'administration
Des requêtes vers des chemins vulnérables connus (/wp-admin, /phpmyadmin, /.env)

Credential stuffing et force brute

Les attaquants utilisent des bases de données d'identifiants compromis pour tester des combinaisons identifiant/mot de passe contre votre service SSH. Ils alternent entre root, admin, ubuntu, deploy et d'autres noms courants. Si l'authentification par mot de passe est activée avec un mot de passe faible, la compromission se produit en quelques minutes.

Supply chain et post-compromission

Une fois à l'intérieur, les attaquants installent des cryptomineurs, ajoutent des backdoors SSH ou utilisent votre serveur comme relais pour d'autres attaques. Certains installent des rootkits qui survivent aux redémarrages. Un VPS compromis peut servir à attaquer d'autres serveurs, ce qui vous rend responsable du trafic généré.

Il y a aussi une tendance croissante aux attaques de supply chain ciblant les dépôts de paquets et les scripts d'installation. Le pattern curl | bash, répandu dans de nombreux guides, exécute du code arbitraire depuis internet sans vérification. À éviter. Téléchargez les scripts, vérifiez les checksums, puis exécutez-les.

Reconnaissance par divulgation de version

Les attaquants prennent l'empreinte de votre logiciel serveur pour trouver les exploits correspondants. Un serveur web répondant avec Server: nginx/1.24.0 ou une bannière SSH révélant la version exacte d'OpenSSH indique à l'attaquant précisément quelles CVE tester. Masquer les versions est une petite mesure, mais elle supprime le ciblage à faible effort. Dans ce guide et les tutoriels liés, vous verrez comment désactiver la divulgation de version pour chaque service.

Ce que cela signifie pour vos défenses

Chaque couche de ce guide adresse des vecteurs d'attaque spécifiques :

Vecteur d'attaque	Couche de défense
Force brute SSH	Authentification par clé, Fail2Ban
Scan de ports	Pare-feu (UFW/nftables)
Credential stuffing	Désactiver l'auth par mot de passe, utilisateur non-root
Vulnérabilités non patchées	Mises à jour de sécurité automatiques
Accès non autorisé aux services d'administration	VPN (WireGuard/Tailscale)
Élévation de privilèges	Permissions utilisateur, sudo

Quelles sont les 5 premières étapes de sécurité sur un nouveau VPS ?

Si vous ne faites qu'une chose, faites ces cinq-là. Elles prennent moins de 15 minutes et bloquent la grande majorité des attaques automatisées : 1) mettre à jour tous les paquets, 2) créer un utilisateur non-root avec sudo, 3) configurer l'authentification SSH par clé et désactiver les mots de passe, 4) activer un pare-feu, 5) installer Fail2Ban.

Voici la séquence de démarrage rapide. Chaque étape renvoie à un tutoriel détaillé.

1. Mettre à jour tous les paquets

apt update && apt upgrade -y

Cette commande applique les correctifs de vulnérabilités connues. Sur un VPS fraîchement provisionné, l'image de base peut avoir plusieurs semaines ou mois de retard sur les correctifs de sécurité.

2. Créer un utilisateur non-root

adduser deploy
usermod -aG sudo deploy

Travailler en root signifie que la moindre erreur ou exploit dispose d'un accès complet au système. Un utilisateur sudo nécessite une élévation de privilèges explicite.

3. Configurer l'authentification SSH par clé

Sur votre machine locale, générez une paire de clés Ed25519 si vous n'en avez pas :

ssh-keygen -t ed25519 -C "your-email@example.com"

Copiez-la sur votre serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

Puis sur le serveur, éditez /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Redémarrez SSH. Sur Ubuntu 24.04, SSH utilise l'activation par socket :

# Ubuntu 24.04
sudo systemctl restart ssh.socket

# Debian 12
sudo systemctl restart sshd

Vérifiez avant de vous déconnecter : ouvrez un second terminal et confirmez que vous pouvez vous connecter avec votre clé en tant que nouvel utilisateur. Ne fermez jamais votre session en cours avant d'avoir vérifié l'accès. Sécuriser SSH sur un VPS Linux : guide sshd_config

4. Activer un pare-feu

# Installer UFW (pré-installé sur Ubuntu, à installer sur Debian)
sudo apt install ufw -y

# Autoriser SSH avant d'activer le pare-feu
sudo ufw allow ssh

# Activer le pare-feu
sudo ufw enable

# Vérifier
sudo ufw status

Vous devriez voir SSH (port 22) listé comme ALLOW. Tout le reste est refusé par défaut. Comment configurer un pare-feu Linux avec UFW et nftables sur un VPS

5. Installer Fail2Ban

sudo apt install fail2ban -y

Créez une configuration locale de jail :

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 1800
EOF

Sur Debian 12, Fail2Ban doit lire depuis journald plutôt que auth.log :

# Debian 12 uniquement
echo "sshd_backend = systemd" | sudo tee -a /etc/fail2ban/paths-debian.conf

Démarrez et activez le service :

sudo systemctl enable --now fail2ban

Vérifiez qu'il tourne :

sudo systemctl status fail2ban
sudo fail2ban-client status sshd

Vous devriez voir la jail sshd listée comme active avec 0 IP actuellement bannies. En quelques heures, vous commencerez à voir des bans. Installer et configurer Fail2Ban sur un VPS Linux

Comment le durcissement SSH protège-t-il votre serveur ?

SSH est la porte d'entrée de votre serveur et la cible numéro un des attaques automatisées. Durcir SSH, c'est remplacer l'authentification par mot de passe par des clés cryptographiques, désactiver la connexion root et limiter les utilisateurs et algorithmes acceptés par le serveur. Ces changements font passer la surface d'attaque SSH de « essayer n'importe quel mot de passe » à « présenter exactement cette clé privée ».

Au-delà des bases couvertes dans les 5 premières étapes, une configuration SSH durcie inclut :

Clés Ed25519 uniquement. Plus rapides et plus sûres que RSA. La clé fait 256 bits mais offre une sécurité de 128 bits, équivalente à RSA-3072.
Timeout d'inactivité. Déconnectez les sessions inactives pour éviter que des terminaux abandonnés ne soient détournés :

ClientAliveInterval 300
ClientAliveCountMax 2

Restreindre les utilisateurs. Limitez l'accès SSH à des comptes spécifiques :

AllowUsers deploy

Désactiver les méthodes d'authentification inutilisées :

KbdInteractiveAuthentication no
X11Forwarding no

Masquer la bannière de version SSH. Bien qu'OpenSSH ne permette pas de supprimer complètement sa version de protocole, vous pouvez supprimer les bannières personnalisées et limiter les fuites d'information :

Banner none
DebianBanner no

Après chaque modification de sshd_config, validez la syntaxe avant de redémarrer :

sudo sshd -t

Si la commande ne produit aucune sortie, la configuration est valide. Redémarrez ensuite SSH et vérifiez que vous pouvez toujours vous connecter depuis un second terminal. Testez toujours depuis une seconde session. Si la configuration est cassée, votre connexion existante reste ouverte.

Pour le guide complet de durcissement SSH avec des configurations testées pour Debian 12 et Ubuntu 24.04, voir Sécuriser SSH sur un VPS Linux : guide sshd_config.

Pourquoi votre VPS a-t-il besoin d'un pare-feu ?

Un pare-feu contrôle quel trafic réseau atteint votre serveur. Sans pare-feu, chaque service que vous exécutez est exposé sur internet. Une base de données sur le port 5432, un serveur de développement sur le port 3000, une instance Redis sur le port 6379 : tous accessibles par n'importe qui. Le pare-feu garantit que seuls les ports que vous ouvrez explicitement sont accessibles.

Debian 12 et Ubuntu 24.04 utilisent tous deux nftables comme framework de filtrage de paquets au niveau du kernel. UFW (Uncomplicated Firewall) se place au-dessus comme interface conviviale. Pour la plupart des cas d'usage VPS, UFW est le bon choix.

UFW vs nftables : lequel utiliser

	UFW	nftables
Idéal pour	Serveurs uniques, applications web	Multi-serveurs, routage avancé
Courbe d'apprentissage	Quelques minutes	Des heures à des jours
Activé par défaut sur	Ubuntu (pré-installé)	Debian 12 (backend)
Syntaxe des règles	`ufw allow 443/tcp`	Tables, chaînes, expressions de règles
Quand basculer	N/A	Besoin de logs par paquet, règles de rate limiting, NAT complexe

Configuration typique d'un pare-feu pour serveur web avec UFW :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Contrôlez les règles :

sudo ufw status numbered

Chaque port ouvert est un point d'entrée potentiel. N'ouvrez que ce dont votre application a besoin. Si vous supprimez un service, supprimez aussi sa règle de pare-feu.

Pour la configuration détaillée du pare-feu incluant les règles nftables, le rate limiting et le contrôle d'accès par port, voir Comment configurer un pare-feu Linux avec UFW et nftables sur un VPS.

Comment Fail2Ban arrête-t-il les attaques par force brute ?

Fail2Ban surveille les fichiers de logs (ou journald sur Debian 12) pour détecter les tentatives d'authentification répétées et bloque temporairement les adresses IP fautives via des règles de pare-feu. Il transforme une attaque par force brute de « essayer 10 000 mots de passe » en « essayer 3 mots de passe, être bloqué 30 minutes, recommencer depuis une IP différente ».

Comment ça fonctionne

Fail2Ban surveille les logs d'authentification SSH
Après maxretry échecs dans findtime, il crée une règle de pare-feu bloquant cette IP
Après l'expiration du bantime, la règle est supprimée
Les attaquants persistants tournent entre les IP, mais la limitation de débit rend le credential stuffing impraticable

Paramètres recommandés pour un VPS

Les valeurs par défaut sont trop permissives pour un serveur exposé sur internet. Voici une configuration de production :

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 3600
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 86400
EOF

Cette configuration bannit une IP pendant 1 heure après 3 échecs. Si la même IP revient, le ban double à chaque fois, jusqu'à 24 heures. C'est plus efficace qu'un temps de ban fixe, car les scanners automatisés finiront par délaisser votre serveur.

Redémarrez Fail2Ban pour appliquer :

sudo systemctl restart fail2ban

Assurez-vous les bans actifs :

sudo fail2ban-client status sshd

Observez les bans en temps réel :

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

Pour le guide complet de configuration Fail2Ban couvrant les jails personnalisées pour Nginx, Postfix et d'autres services, voir Installer et configurer Fail2Ban sur un VPS Linux.

Comment les permissions utilisateur réduisent-elles votre surface d'attaque ?

Exécuter des services en root donne à un attaquant un accès complet au système si ce service est compromis. Le principe du moindre privilège signifie que chaque processus tourne avec les permissions minimales dont il a besoin. La compromission d'un serveur web ne doit pas donner accès à votre base de données, vos clés SSH ou votre configuration système.

Pratiques essentielles

Ne jamais exécuter des services applicatifs en root. Les serveurs web, bases de données et runtimes applicatifs doivent chacun avoir leur propre utilisateur système :

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/myapp myapp

Le flag --system crée un utilisateur sans login de répertoire personnel. --shell /usr/sbin/nologin empêche la connexion interactive. Cet utilisateur peut exécuter votre application, mais ne peut pas se connecter en SSH ni exécuter des commandes arbitraires.

Restreindre l'accès sudo. Seuls les utilisateurs du groupe sudo doivent avoir des privilèges élevés. Vérifiez qui a sudo :

getent group sudo

Définir correctement les permissions des fichiers. Les fichiers de configuration contenant des mots de passe ou des clés API ne doivent pas être lisibles par tous :

# Restreindre un fichier de config au propriétaire uniquement
sudo chmod 600 /etc/myapp/config.env
sudo chown myapp:myapp /etc/myapp/config.env

# Vérifier
ls -la /etc/myapp/config.env

Vous devriez voir les permissions -rw-------, ce qui signifie que seul le propriétaire peut lire et écrire.

Utiliser des fichiers d'environnement pour les secrets. Au lieu de coder en dur les identifiants dans les fichiers de configuration, créez un fichier d'environnement dédié avec des permissions restreintes :

sudo tee /etc/myapp/env > /dev/null << 'EOF'
DB_PASSWORD=your-generated-password
API_KEY=your-api-key
EOF

sudo chmod 600 /etc/myapp/env
sudo chown myapp:myapp /etc/myapp/env

Référencez-le dans les unités systemd avec EnvironmentFile=/etc/myapp/env. Générez les mots de passe avec openssl rand -base64 32 plutôt que de les choisir manuellement.

Pour le guide complet sur la gestion des utilisateurs Linux, la configuration sudo et les modèles de permissions, voir.

Pourquoi automatiser les mises à jour de sécurité ?

Les logiciels non mis à jour sont l'un des vecteurs d'attaque les plus exploités. Lorsqu'une vulnérabilité est divulguée, les attaquants commencent à scanner les serveurs non patchés dans les heures qui suivent. Les mises à jour manuelles laissent votre serveur vulnérable depuis la divulgation jusqu'à la prochaine fois que vous pensez à lancer apt upgrade. Les mises à jour de sécurité automatiques ferment cette fenêtre.

Configurer unattended-upgrades

Ubuntu 24.04 inclut unattended-upgrades dans son installation serveur par défaut, mais certains fournisseurs VPS livrent des images minimales sans ce paquet. Debian 12 l'exige aussi. Sur les deux distributions, installez-le s'il n'est pas déjà présent :

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

Vérifiez qu'il est actif :

cat /etc/apt/apt.conf.d/20auto-upgrades

Vous devriez voir :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Le "1" signifie quotidien. Les listes de paquets se mettent à jour chaque jour et les correctifs de sécurité s'installent automatiquement.

Ce qui est mis à jour

Par défaut, seules les mises à jour de sécurité depuis le dépôt officiel sont installées. C'est le bon paramètre pour un serveur en production. Les mises à jour de fonctionnalités et les changements de version majeure nécessitent toujours une intervention manuelle, ce qui évite que les mises à jour automatiques ne cassent votre application.

Surveiller les mises à jour

Vérifiez ce qui a été installé automatiquement :

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

Configurez des notifications par email pour les mises à jour appliquées en éditant /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

Pour la gestion des redémarrages automatiques lors des mises à jour du kernel :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

N'activez les redémarrages automatiques que si votre application gère les redémarrages proprement. Pour la plupart des configurations, une vérification manuelle hebdomadaire est préférable aux redémarrages surprises.

Pour le guide complet incluant la surveillance et le dépannage, voir.

Quand ajouter un accès VPN à votre VPS ?

Ajoutez un accès VPN quand vous exécutez des services qui ne doivent jamais être exposés sur internet : panneaux d'administration, bases de données, tableaux de bord de supervision, ou API internes. Un VPN crée un tunnel chiffré pour que ces services ne soient accessibles que depuis les appareils de votre réseau privé. Au lieu d'ouvrir le port 3000 au monde entier en espérant que votre authentification tienne, fermez-le complètement depuis internet et accédez-y via le VPN.

WireGuard vs Tailscale

	WireGuard	Tailscale
Temps de configuration	15-30 minutes par pair	2-5 minutes au total
Configuration	Échange de clés manuel, fichiers de config	Login SSO, automatique
Traversée NAT	Redirection de port manuelle	Automatique
Contrôle	Total, vous gérez tout	Serveur de coordination tiers
Coût	Gratuit, auto-hébergé	Gratuit jusqu'à 100 appareils
Idéal pour	Infrastructure fixe, contrôle total	Équipes, appareils dynamiques, déploiement rapide

Choisissez WireGuard si vous voulez un contrôle total sur votre réseau, avez une infrastructure statique et êtes à l'aise avec la gestion des paires de clés et des fichiers de configuration.

Choisissez Tailscale si vous avez besoin d'un déploiement rapide sur plusieurs appareils, travaillez en équipe, ou voulez une traversée NAT automatique sans redirection de port.

Les deux utilisent le protocole WireGuard en dessous. Tailscale, c'est WireGuard avec de l'orchestration.

Ce qui doit passer par le VPN

Ports de bases de données (PostgreSQL 5432, MySQL 3306, Redis 6379)
Panneaux d'administration (phpMyAdmin, Adminer, Grafana)
Endpoints de supervision (Prometheus, Node Exporter)
API internes non destinées au public
Accès SSH (double protection : auth par clé + VPN)

Un pattern courant : gardez les ports 80 et 443 ouverts pour votre application web publique. Tout le reste passe par le VPN. Vos règles de pare-feu deviennent :

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 51820/udp  # WireGuard
# SSH uniquement depuis le sous-réseau VPN
sudo ufw allow from 10.0.0.0/24 to any port 22

Pour la mise en place pas à pas de WireGuard et Tailscale sur votre VPS, voir WireGuard et Tailscale VPN sur un VPS Linux.

Et changer le port SSH ?

Beaucoup de guides recommandent de changer SSH du port 22 vers un port à numéro élevé. C'est de la sécurité par l'obscurité. Cela arrête les bots les plus paresseux qui n'essaient que le port 22. Cela n'arrête aucun attaquant qui lance un scan de ports, ce qui prend quelques secondes.

Le vrai coût : vous devez maintenant vous souvenir de -p 2222 dans chaque commande SSH, le configurer dans chaque script de déploiement et pipeline CI, et risquer de vous bloquer vous-même si vous oubliez. L'authentification SSH par clé avec Fail2Ban offre une vraie sécurité. Changer le port ajoute de la complexité opérationnelle pour un gain minimal.

La même logique s'applique à la désactivation d'IPv6. Si votre serveur a une adresse IPv6, la désactiver ne réduit pas la surface d'attaque. Cela casse la compatibilité future. Configurez votre pare-feu pour IPv4 et IPv6 à la place.

Les couches de sécurité en un coup d'œil

Chaque couche de ce guide adresse une partie spécifique de votre défense. Voici comment elles s'empilent :

Couche	Ce qu'elle protège	Priorité
Mises à jour système	Corrige les vulnérabilités connues	À faire en premier
Permissions utilisateur	Limite la portée d'une compromission	À faire en premier
Durcissement SSH	Bloque l'accès distant non autorisé	À faire en premier
Pare-feu	Contrôle l'exposition réseau	À faire en premier
Fail2Ban	Ralentit les attaques par force brute	À faire en premier
Mises à jour automatiques	Maintient les correctifs à jour sur le long terme	À mettre en place dans la première semaine
Accès VPN	Cache les services internes	Quand vous exécutez des services non publics
Durcissement du kernel	Limite les techniques d'exploitation	Avancé, systèmes en production
Journalisation d'audit	Détecte une compromission après coup	Avancé, conformité

Les cinq premières couches sont non négociables pour tout serveur connecté à internet. Les couches suivantes ajoutent de la profondeur selon ce que vous exécutez et vos exigences de conformité.

Aucune couche seule n'est suffisante. Le durcissement SSH sans pare-feu laisse quand même des services exposés. Un pare-feu sans mises à jour automatiques laisse des vulnérabilités connues ouvertes. Les couches fonctionnent ensemble. Chacune rattrape ce que les autres manquent.

Quand opter pour un hébergement managé ?

Si la gestion de la sécurité empiète sur le temps que vous consacrez à votre produit, envisagez un hébergement managé. Ce n'est pas un échec. C'est une décision d'allocation de ressources.

Signes que vous devriez envisager un hébergement managé :

Vous exploitez un service en production mais n'avez pas le temps de suivre les avis de sécurité
Votre équipe manque d'expérience en administration Linux
Vous avez besoin de certifications de conformité (SOC 2, ISO 27001) et ne pouvez pas assurer le processus d'audit
Vous avez déjà été compromis et manquez d'expertise pour investiguer

Un serveur managé chez un fournisseur comme Virtua Cloud gère les patches OS, la gestion du pare-feu, la détection d'intrusion et les sauvegardes. Vous vous concentrez sur votre application. Le fournisseur gère la couche sécurité de l'infrastructure.

Pour les équipes qui veulent la flexibilité d'un VPS avec une couverture sécurité partielle, un compromis existe : provisionnez un VPS non managé pour le développement et la préproduction, et utilisez un hébergement managé pour la production.

Quelque chose s'est mal passé ?

Vérifier l'accès SSH

Si vous êtes bloqué après avoir modifié la configuration SSH :

Utilisez la console web ou la console série de votre fournisseur VPS pour accéder au serveur
Vérifiez la syntaxe de la configuration SSH : sudo sshd -t
Vérifiez que votre clé est dans ~/.ssh/authorized_keys pour le bon utilisateur
Consultez les logs SSH : journalctl -u ssh -n 50 (Ubuntu) ou journalctl -u sshd -n 50 (Debian)

Vérifier le pare-feu

Si un service n'est pas accessible :

sudo ufw status numbered

Assurez-vous que le port est listé comme ALLOW. Si vous venez d'activer UFW et avez oublié d'autoriser SSH d'abord, utilisez la console web du fournisseur.

Vérifier Fail2Ban

Si une IP légitime a été bannie :

# Vérifier si l'IP est bannie
sudo fail2ban-client status sshd

# Débannir une IP spécifique
sudo fail2ban-client set sshd unbanip 1.2.3.4

Lire les logs

Les logs vous disent ce qui s'est passé :

# Authentification SSH
journalctl -u ssh -f     # Ubuntu 24.04
journalctl -u sshd -f    # Debian 12

# Activité Fail2Ban
sudo tail -f /var/log/fail2ban.log

# Blocages du pare-feu (si vous utilisez la journalisation nftables)
journalctl -k | grep nft

# Messages système
journalctl -p err -b

Apprenez à lire les logs. Chaque fois que quelque chose casse, la réponse est presque toujours dans les logs.

Prochaines étapes

Ce guide couvre les couches de sécurité pour un VPS Linux. Chaque section renvoie à un tutoriel détaillé et pratique :

Sécuriser SSH sur un VPS Linux : guide sshd_config - Guide complet de durcissement SSH
Comment configurer un pare-feu Linux avec UFW et nftables sur un VPS - Configuration du pare-feu avec UFW et nftables
Installer et configurer Fail2Ban sur un VPS Linux - Configuration Fail2Ban pour SSH et services web
- Gestion des utilisateurs et moindre privilège
- Configuration et supervision des mises à jour automatiques
WireGuard et Tailscale VPN sur un VPS Linux - Accès VPN avec WireGuard et Tailscale

Commencez par les 5 premières étapes de sécurité si vous ne l'avez pas encore fait, puis parcourez les tutoriels dans l'ordre.