Sécuriser son VPS Linux : UFW, fail2ban et durcissement SSH

Mettre en production un serveur virtuel expose immédiatement votre infrastructure aux menaces réseau. Securiser un VPS Linux devient alors une priorité stratégique pour toute entreprise soucieuse de protéger ses données et services. Ce guide détaille les étapes concrètes pour durcir votre environnement Linux, de la configuration SSH jusqu'à l'automatisation de la surveillance, en s'appuyant sur les standards de l'industrie et les recommandations du CERT-FR.

Sécuriser l'accès SSH et éliminer les vecteurs d'attaque initiaux

Le protocole SSH constitue le point d'entrée principal sur un VPS Linux OmegaCloud. Par défaut, une authentification par mot de passe reste vulnérable aux attaques par force brute. La première action consiste à générer une paire de clés asymétriques sur votre poste de travail, puis à désactiver complètement l'authentification par mot de passe.

ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@IP_DU_VPS

Une fois la clé publique déployée, éditez le fichier /etc/ssh/sshd_config et appliquez les directives suivantes :

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
Port 22
Protocol 2

Redémarrez le daemon SSH pour appliquer les changements :

systemctl restart sshd

Modifier le port par défaut (22) vers un port élevé non-standard (par exemple 49152) réduit significativement les scans automatisés. Attention toutefois à mettre à jour vos règles de pare-feu avant de redémarrer sshd. L'infrastructure OmegaCloud inclut un système anti-DDoS volumétrique transparent qui bloque les attaques réseau en amont, mais sécuriser l'accès applicatif reste une responsabilité de l'administrateur.

Configurer le pare-feu système avec UFW ou nftables

Pour securiser un VPS Linux efficacement, le pare-feu représente la deuxième couche de défense. UFW (Uncomplicated Firewall) simplifie la gestion d'iptables/nftables en offrant une syntaxe lisible et cohérente. Sur Debian, Ubuntu ou Rocky Linux, installez et activez UFW en quelques commandes :

apt update && apt install ufw -y
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'SSH'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
ufw enable
ufw status verbose

Si vous avez modifié le port SSH, n'oubliez pas de remplacer le 22 par votre port personnalisé avant d'activer UFW, sous peine de vous retrouver verrouillé hors du serveur. Pour les environnements de production complexes, nftables offre des possibilités plus granulaires, notamment les ensembles (sets) et les règles conditionnelles sur plusieurs critères. Consultez la documentation officielle nftables pour les cas d'usage avancés.

Restreindre l'accès par IP source

Si votre équipe accède au serveur depuis des adresses fixes (bureaux, VPN d'entreprise), limitez l'accès SSH à ces plages uniquement :

ufw delete allow 22/tcp
ufw allow from 198.51.100.0/24 to any port 22 proto tcp comment 'SSH Bureau'
ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH Admin VPN'

Cette restriction rend les attaques par force brute presque impossibles, puisque les tentatives de connexion depuis des IP non autorisées sont rejetées au niveau kernel. L'infrastructure européenne d'OmegaCloud assure une latence optimale pour vos équipes basées en France et en Union Européenne, ce qui facilite l'utilisation de VPN d'entreprise avec des temps de réponse sub-ms.

Automatiser la détection d'intrusion avec Fail2ban

Fail2ban surveille les logs système à la recherche de motifs suspects (échecs de connexion SSH, scans de ports, tentatives d'exploitation), puis bannit automatiquement les adresses IP malveillantes en créant des règles pare-feu temporaires. L'installation et la configuration se font en quelques minutes sur Debian ou Ubuntu :

apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

Créez un fichier de configuration local /etc/fail2ban/jail.local pour personnaliser les jails sans modifier le fichier d'origine :

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
destemail = [email protected]
sendername = Fail2ban VPS Prod
action = %(action_mwl)s

[sshd]
enabled = true
port = 22
logpath = /var/log/auth.log
maxretry = 3
bantime = 7200

Rechargez la configuration et vérifiez l'état des jails actives :

systemctl restart fail2ban
fail2ban-client status
fail2ban-client status sshd

Fail2ban peut également protéger les services web (Nginx, Apache), les bases de données (MySQL, PostgreSQL) et les panneaux d'administration. Chaque jail se configure indépendamment, avec des seuils de déclenchement adaptés à la criticité du service.

Whitelist et gestion des faux positifs

Si une IP légitime se retrouve bannie (un administrateur qui se trompe trois fois de mot de passe), débannissez-la manuellement :

fail2ban-client set sshd unbanip 198.51.100.42

Pour éviter le bannissement de vos propres IP, ajoutez-les dans ignoreip de la section [DEFAULT] :

ignoreip = 127.0.0.1/8 ::1 198.51.100.0/24

Maintenir le système à jour et surveiller les vulnérabilités

Les mises à jour de sécurité corrigent les vulnérabilités découvertes dans le noyau Linux, les bibliothèques système et les applications. Sur Debian et Ubuntu, activez les mises à jour automatiques de sécurité grâce au paquet unattended-upgrades :

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

Éditez /etc/apt/apt.conf.d/50unattended-upgrades pour configurer les origines autorisées et les notifications par email :

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};
Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";

Pour Rocky Linux et AlmaLinux, utilisez dnf-automatic :

dnf install dnf-automatic -y
systemctl enable --now dnf-automatic.timer

Configurez le fichier /etc/dnf/automatic.conf en passant apply_updates = yes pour appliquer automatiquement les correctifs de sécurité. Vérifiez régulièrement le journal /var/log/dnf.log pour suivre les paquets mis à jour.

Audit de sécurité avec Lynis

Lynis est un outil d'audit open-source qui scanne votre système et émet des recommandations de durcissement. Installez et lancez un scan complet :

apt install lynis -y
lynis audit system

Le rapport final identifie les failles potentielles : permissions de fichiers trop permissives, services inutiles actifs, mots de passe faibles, configurations SSH dangereuses. Suivez les suggestions pas à pas pour renforcer votre posture de sécurité. Le panel OmegaCloud offre une vue en temps réel de la consommation CPU, RAM et SSD, ce qui facilite la détection de charges anormales liées à des processus malveillants.

Segmenter les services et limiter la surface d'attaque

Chaque service exposé représente un point d'entrée potentiel. Privilégiez l'isolation : un VPS dédié aux bases de données, un autre pour les applications web, un troisième pour les tâches cron et les scripts. Si le budget impose un seul serveur, utilisez des utilisateurs système distincts et des chroot ou namespaces pour cloisonner les processus.

Exemple : isoler un serveur web Nginx

Créez un utilisateur dédié non-privilégié pour Nginx :

useradd -r -s /bin/false -d /var/www nginx-web
chown -R nginx-web:nginx-web /var/www/html

Configurez Nginx pour s'exécuter sous cette identité en modifiant la directive user dans /etc/nginx/nginx.conf :

user nginx-web;
worker_processes auto;

Redémarrez Nginx et vérifiez les processus :

systemctl restart nginx
ps aux | grep nginx

Désactivez les modules inutiles et limitez les méthodes HTTP autorisées dans vos blocs server :

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
    return 405;
}

Pour les applications critiques, envisagez l'utilisation d'AppArmor ou SELinux afin de confiner les processus avec des profils MAC (Mandatory Access Control). La documentation Securing Debian Manual détaille les profils AppArmor disponibles et la procédure de création de règles personnalisées.

Désactiver les services superflus

Listez tous les services activés au démarrage et désactivez ceux qui ne sont pas indispensables :

systemctl list-unit-files --type=service --state=enabled
systemctl disable avahi-daemon.service
systemctl disable cups.service
systemctl stop avahi-daemon cups

Moins de services actifs signifie moins de surface d'attaque et moins de charge système. Concentrez-vous sur les services métier essentiels : SSH, pare-feu, serveur web, base de données, monitoring.

Mettre en place une surveillance continue et des alertes

La surveillance proactive détecte les anomalies avant qu'elles ne deviennent critiques. Installez un agent léger comme prometheus-node-exporter ou telegraf pour exporter les métriques système vers une stack de monitoring (Prometheus + Grafana, InfluxDB + Chronograf). Pour une approche simple, utilisez monit ou netdata :

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Netdata démarre automatiquement sur le port 19999 et expose un tableau de bord temps réel avec alertes sur seuils (CPU > 80%, RAM > 90%, disque plein, processus zombie). Configurez les notifications Slack, Discord ou email dans /etc/netdata/health_alarm_notify.conf.

Centraliser les logs avec rsyslog ou journald

Envoyez vos logs système vers un serveur de collecte centralisé pour éviter la perte de traces en cas de compromission. Avec rsyslog, configurez un remote logging :

echo "*.* @@logs.mondomaine.fr:514" >> /etc/rsyslog.d/50-remote.conf
systemctl restart rsyslog

Le double @@ active le transport TCP au lieu d'UDP, garantissant la livraison des messages. Côté serveur de logs, utilisez un stockage redondant et des sauvegardes chiffrées. Le panel OmegaCloud permet de créer des snapshots du VPS en un clic, offrant une copie instantanée de l'ensemble du système en cas d'incident.

Conclusion

Sécuriser un VPS Linux en production repose sur une approche en couches : authentification par clés SSH, pare-feu applicatif, détection d'intrusion automatisée, mises à jour continues et surveillance proactive. Chaque mesure réduit la surface d'attaque et complique la tâche des attaquants. Combinée à l'anti-DDoS inclus dans l'infrastructure VPS Linux OmegaCloud, cette stratégie assure une résilience optimale face aux menaces actuelles.

FAQ

Faut-il changer le port SSH par défaut pour sécuriser un VPS Linux ?

Modifier le port SSH de 22 vers un port élevé non-standard réduit drastiquement les scans automatisés et les tentatives de brute-force opportunistes. Cette mesure, combinée à l'authentification par clés et à Fail2ban, améliore significativement la sécurité sans complexité technique majeure. Pensez toutefois à mettre à jour vos règles de pare-feu avant de redémarrer sshd.

Quelle différence entre UFW et nftables pour un VPS en production ?

UFW simplifie la gestion d'iptables avec une syntaxe lisible, idéale pour les configurations courantes (ports ouverts, whitelist IP). Nftables offre une performance supérieure et des fonctionnalités avancées (ensembles dynamiques, règles conditionnelles), recommandé pour les infrastructures complexes avec centaines de règles ou besoins de filtrage applicatif.

Comment détecter une compromission active sur un serveur Linux ?

Surveillez les connexions réseau inhabituelles avec netstat -tulpn, les processus suspects via ps auxf, et les modifications de fichiers système avec debsums ou aide. Installez un IDS comme OSSEC ou Wazuh pour une détection en temps réel basée sur les signatures d'attaques connues et les anomalies comportementales. Consultez régulièrement /var/log/auth.log et les journaux Fail2ban.