Durcissement VPS (Durcissement et sécurité Linux VPS)

1. Vue d'ensemble du concept et problème systémique

Dès l'initialisation d'un serveur virtuel (VPS) chez un fournisseur cloud (Hetzner, DigitalOcean, AWS), l'instance est ciblée par des scans de botnets mondiaux dans les 5 à 15 premières minutes. Par défaut, de nombreuses images OS ont l'authentification par mot de passe activée pour l'utilisateur root, exposent des ports de service ouverts et manquent de protections de base contre la force brute.

Le VPS Hardening (Durcissement du serveur) est une discipline d'ingénierie visant à renforcer la sécurité du système d'exploitation Linux selon les standards CIS Benchmarks (Center for Internet Security). Les objectifs du hardening sont :

• Minimiser la surface d'attaque (Attack Surface).
• Exclure totalement la possibilité de connexion par mot de passe via des canaux non sécurisés.
• Isoler l'exécution des processus depuis le compte superutilisateur (Root).
• Configurer l'audit des événements, la correction automatique des vulnérabilités zero-day (0-day) et le filtrage de paquets au niveau du noyau.

État initial du VPS (Risque élevé) :
[Internet] ---> [Port 22 : SSH (Root + Mot de passe)] ---> [Compromission totale du système]

Après durcissement (Défense en profondeur) :
[Internet] ---> [Pare-feu UFW (Refus par défaut)]
                     |
                     v
                [Fail2ban (Blocage des scanners)]
                     |
                     v
                [SSH : Clés Ed25519 uniquement, sudo non-root]
                     |
                     v
                [Mises à jour automatiques (unattended-upgrades)]

2. Taxonomie architecturale et modèle mental

Le hardening se déploie sur quatre plans de sécurité isolés :

1. Niveau Authentification et Contrôle d'accès (Identity & Access) :
   • Désactivation complète de la connexion directe en root via SSH (PermitRootLogin no).
   • Interdiction de l'authentification par mot de passe (PasswordAuthentication no).
   • Création d'un utilisateur non privilégié avec une appartenance obligatoire au groupe sudo.
   • Installation de clés cryptographiques Ed25519.
2. Niveau Réseau (Network Perimeter) :
   • Activation de ufw avec une politique de rejet de tous les paquets entrants (default deny incoming).
   • Ouverture uniquement des ports vitaux (par exemple, 2222/tcp, 80/tcp, 443/tcp).
   • Déploiement de fail2ban pour bannir automatiquement les hôtes générant des requêtes anormales.
3. Niveau Système d'exploitation et Noyau (OS & Kernel) :
   • Tuning des paramètres sysctl pour protéger la pile réseau (interdiction des redirections ICMP, protection contre les attaques SYN-flood).
   • Activation des mises à jour de sécurité étendues (unattended-upgrades).
4. Niveau Application et Environnement d'exécution (Runtime Isolation) :
   • Lancement des conteneurs Docker et des agents IA sous des UID/GID distincts et non privilégiés, sans accès à /var/run/docker.sock.

3. Pipeline technique et mécanique interne

Étape 1. Création d'un utilisateur sudo et déploiement de la clé SSH

Connectez-vous au serveur vierge avec le mot de passe root temporaire, puis créez immédiatement un utilisateur dédié à l'ingénierie :

# Створення користувача deploy з домашньою директорією та zsh/bash
adduser --gecos "" deploy
usermod -aG sudo deploy

# Копіювання публічного ключа Ed25519
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Étape 2. Durcissement du démon OpenSSH (/etc/ssh/sshd_config.d/99-hardening.conf)

Créez un fichier de configuration SSH isolé pour éviter qu'il ne soit écrasé lors des mises à jour de paquets :

# Зміна порту (опціонально, але рекомендовано)
Port 2222

# Повна заборона root-доступу та паролів
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Дозвіл виключно надійних криптографічних ключів
PubkeyAuthentication yes
AuthenticationMethods publickey

# Захист сесій від зависання
ClientAliveInterval 300
ClientAliveCountMax 2

# Відключення небезпечних функцій перенаправлення
X11Forwarding no
AllowTcpForwarding yes

Testez la configuration avant le redémarrage :

# Валідація синтаксису (якщо порожній вивід — конфіг коректний)
sudo sshd -t
sudo systemctl restart sshd

Étape 3. Configuration des paramètres du noyau Linux (/etc/sysctl.d/99-security.conf)

# Захист від TCP SYN Flood атак
net.ipv4.tcp_syncookies = 1

# Заборона перенаправлення пакетів маршрутизації (захист від Man-in-the-Middle)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Ігнорування підроблених ICMP-відповідей
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Заборона IP Source Routing
net.ipv4.conf.all.accept_source_route = 0

Appliquez les modifications du noyau sans redémarrer :

sudo sysctl --system

4. Scénarios d'ingénierie pratiques en production

01. Hardening automatisé via Cloud-Init sur Hetzner Cloud

Lors de la création d'un serveur virtuel via Terraform ou le panneau de contrôle Hetzner, un script User Data (cloud-init) est transmis. Le serveur démarre déjà avec le root fermé, un utilisateur pré-créé, des règles UFW générées et SSH configuré sur un port non standard, éliminant ainsi totalement la fenêtre de vulnérabilité durant les premières minutes de vie de la machine.

02. Mise à jour automatique des patchs de sécurité du noyau sans intervention

Configuration du paquet unattended-upgrades sur Ubuntu :

sudo apt install unattended-upgrades update-notifier-common
sudo dpkg-reconfigure --priority=low unattended-upgrades

Le serveur télécharge et installe automatiquement les mises à jour critiques de sécurité provenant des dépôts officiels Security chaque nuit, tandis que l'utilitaire needrestart relance automatiquement les services compromis sans nécessiter de redémarrage du système d'exploitation.

03. Isolation du trafic interne du démon Docker

Docker tente automatiquement d'exposer les ports sur toutes les interfaces réseau (0.0.0.0). Lors du hardening, le fichier /etc/docker/daemon.json est configuré pour limiter le binding par défaut :

{
  "iptables": true,
  "live-restore": true,
  "userland-proxy": false
}

Cela garantit que les services sans mapping explicite vers localhost restent confinés dans le pont réseau virtuel Docker et n'exposent pas leurs ports sur Internet public.

5. Pièges courants, erreurs typiques et sécurité

1. Auto-blocage accidentel (SSH Lockout) : L'erreur la plus fréquente des ingénieurs : fermer l'accès par mot de passe et interdire root, tout en oubliant de vérifier si la clé publique fonctionne pour le nouvel utilisateur ou si le nouveau port est autorisé dans UFW. Ne fermez jamais la session initiale du terminal tant que vous n'avez pas réussi à vous connecter dans un onglet parallèle.
2. Stockage du mot de passe sudo dans les scripts ou .bash_history : L'utilisation de echo "password" | sudo -S ... dans des scripts shell ou la saisie de mots de passe dans le terminal entraîne une fuite en clair dans l'historique des commandes. Utilisez sudo visudo pour déléguer des commandes spécifiques sans mot de passe (NOPASSWD) pour les comptes de service CI/CD spécialisés.
3. Ignorance de la sécurité de la console out-of-band du fournisseur : Même un serveur parfaitement durci peut être compromis si le compte sur la console du fournisseur d'hébergement (Hetzner Cloud Console, DigitalOcean Dashboard) est protégé par un simple mot de passe sans authentification à deux facteurs matérielle (2FA / WebAuthn). L'accès à la console du fournisseur est équivalent à un accès physique direct à la carte mère du serveur.