Durcissement Linux VPS : checklist agence après livraison

La première action après connexion root est d'amener le système à son niveau de correctifs courant.

apt update && apt upgrade -y
apt install -y auditd audispd-plugins curl gnupg2 ufw fail2ban

Notez dans votre runbook : la date, la version du noyau (uname -r), et la liste des paquets installés (dpkg -l > /root/inventory-$(date +%F).txt). Ce fichier d'inventaire constitue la baseline du serveur à la livraison — c'est la pièce que vous produirez si un client conteste l'état initial de sa machine.

Référence CIS Benchmark : contrôle CIS 1.1 (Ubuntu Linux 24.04 LTS Benchmark, section « Initial Setup »).

apt install -y unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

Vérifiez que la ligne Unattended-Upgrade::Allowed-Origins inclut bien ${distro_id}:${distro_codename}-security. Pour un parc clients, activez les mises à jour automatiques et planifiez une revue mensuelle des mises à jour non-sécurité — elles demandent une validation humaine.

Référence CIS : contrôle CIS 1.9 (Ensure updates, patches, and additional security software are installed).

Ne jamais utiliser root pour les tâches courantes. Créez un compte nominatif par technicien ou un compte de service agence :

useradd -m -s /bin/bash adminagence
usermod -aG sudo adminagence
passwd adminagence

Conseil agence : utilisez un nom de compte identifiable dans les logs (jean.dupont ou agency-admin), pas un générique admin. Quand auditd trace une action, le compte exécutant est enregistré — un nom générique rend l'audit inutilisable.

sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
grep PermitRootLogin /etc/ssh/sshd_config

Attention : ne rechargez sshd qu'après avoir vérifié que votre utilisateur sudo peut se connecter et exécuter sudo su. Sinon vous vous bloquez hors du serveur.

Référence CIS : contrôle CIS 5.2.8 (Ensure SSH root login is disabled).

mkdir -p /home/adminagence/.ssh
chmod 700 /home/adminagence/.ssh
echo "<CLE_PUBLIQUE_AGENCE>" >> /home/adminagence/.ssh/authorized_keys
chmod 600 /home/adminagence/.ssh/authorized_keys
chown -R adminagence:adminagence /home/adminagence/.ssh

Conseil agence : maintenez un dépôt de clés publiques versionné (un fichier par technicien, rotation annuelle). Toute clé déployée sur un VPS client doit être référencée dans ce dépôt — c'est ce qui vous permet de révoquer un accès quand un collaborateur quitte l'équipe.

Une fois la clé vérifiée (testez depuis un autre terminal avant de valider) :

sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/' /etc/ssh/sshd_config
systemctl reload sshd

Référence CIS : contrôle CIS 5.2.11 (Ensure only approved MAC algorithms are used) et CIS 5.2.19 (Ensure SSH PasswordAuthentication is disabled).

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'SSH agence'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
ufw --force enable
ufw status verbose

N'ouvrez que les ports réellement utilisés par le projet client. Si l'application du client n'utilise pas de port email direct, ne l'ouvrez pas.

Pour l'installation de fail2ban et les options avancées d'UFW, consultez les guides dédiés : Protéger un VPS avec fail2ban et Pare-feu UFW sur VPS.

Référence CIS : contrôle CIS 3.5.1 (Ensure a firewall package is installed).

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Éditez /etc/fail2ban/jail.local et ajustez la section [sshd] :

[sshd]
enabled = true
maxretry = 5
findtime = 600
bantime = 3600

systemctl enable fail2ban
systemctl start fail2ban
fail2ban-client status sshd

Pour un parc clients, envisagez CrowdSec en remplacement ou en complément : sa blocklist communautaire mutualise l'intelligence de milliers de serveurs.

auditd est le composant que les agences oublient le plus souvent — et pourtant c'est lui qui fournit la preuve opposable en cas d'incident.

systemctl enable auditd
systemctl start auditd

Créez un fichier de règles agence dans /etc/audit/rules.d/agency.rules :

# Tracer toutes les élévations de privilèges
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_changes

# Tracer les connexions SSH
-w /var/log/auth.log -p wa -k auth_log

# Tracer les modifications de fichiers de configuration système
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes

# Tracer les commandes exécutées en root
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

augenrules --load
auditctl -l

Référence CIS : contrôle CIS 4.1.1 (Ensure auditing is enabled) et CIS 4.1.3 (Ensure events that modify date and time information are collected).

Les logs auditd doivent être conservés hors du serveur pour être opposables. Configurez un export vers votre système centralisé (rsyslog, Loki, ou un simple rsync quotidien vers un stockage agence) :

# Exemple : export rsyslog vers collecteur agence
echo ':programname, isequal, "auditd" @<IP_COLLECTEUR_AGENCE>:514' \
  >> /etc/rsyslog.d/99-auditd-remote.conf
systemctl restart rsyslog

Conservez au minimum 90 jours de logs. Le RGPD ne fixe pas de durée minimale pour les logs de sécurité, mais les référentiels comme le CIS Controls v8 (contrôle 8.3) recommandent au moins 90 jours sur site et 1 an en archive froide.