Comment sécuriser un serveur Ubuntu

Pour sécuriser un serveur Ubuntu, n'autorisez SSH que par clés, mettez en place un pare-feu qui refuse tout par défaut, installez automatiquement les mises à jour de sécurité, bloquez les échecs de connexion répétés, n'exposez que les services nécessaires et conservez des sauvegardes testées. Ces six étapes arrêtent l'immense majorité des attaques que subit un serveur public.

Les commandes concernent Ubuntu 24.04 LTS et fonctionnent sur Debian 12 avec de légères différences. Exécutez-les avec un utilisateur disposant de sudo. Si vous n'avez pas encore fait les bases, commencez par les premières étapes sur un nouveau VPS.

1. Mettre à jour d'abord, puis rester à jour

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Vérifiez que le timer est actif :

systemctl list-timers | grep apt

Les mises à jour de sécurité s'installent désormais tous les jours. Vérifiez de temps en temps si un redémarrage est en attente avec cat /var/run/reboot-required.

2. Verrouiller SSH

Clés uniquement

Assurez-vous que votre clé fonctionne pour un utilisateur sudo (voir clés SSH). Ensuite :

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
X11Forwarding no
AllowUsers deploy
EOF
sudo sshd -t && sudo systemctl reload ssh

• AllowUsers limite SSH aux comptes que vous indiquez. Remplacez deploy par votre utilisateur.
• sshd -t valide le fichier ; s'il n'affiche rien, la syntaxe est correcte.

Testez depuis un nouveau terminal avant de fermer celui en cours.

Vérifier les réglages effectifs

Les fichiers de configuration complémentaires sont lus dans l'ordre, et la première valeur l'emporte. Vérifiez ce que sshd utilise réellement :

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowusers'

Si un fichier cloud-init comme 50-cloud-init.conf définit PasswordAuthentication yes, votre fichier 10- est lu en premier et l'emporte.

3. Pare-feu UFW avec refus par défaut

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit OpenSSH          # autorise SSH, limite les tentatives répétées
sudo ufw allow 80,443/tcp       # uniquement si vous avez un serveur web
sudo ufw enable
sudo ufw status numbered

ufw limit bloque une adresse qui ouvre six connexions ou plus en 30 secondes, ce qui ralentit les scanners.

UFW couvre l'IPv6 tant que IPV6=yes est défini dans /etc/default/ufw (c'est le cas par défaut sur Ubuntu).

Restreindre SSH à vos propres adresses

Si vous vous connectez depuis une adresse fixe, n'autorisez SSH que depuis celle-ci :

sudo ufw delete limit OpenSSH
sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp   # plage d'exemple

Avertissement Docker

Docker écrit ses propres règles iptables, et les ports publiés des conteneurs contournent UFW. Liez les conteneurs à localhost (127.0.0.1:8080:80) et placez un reverse proxy devant, ou filtrez au niveau du pare-feu cloud. Le guide Docker Compose présente cette approche.

4. Ajouter un pare-feu cloud en amont

Un pare-feu situé hors du serveur continue de fonctionner même si quelqu'un désactive UFW, et un seul jeu de règles peut couvrir de nombreux serveurs. Sur Wolkra, les pare-feu sont avec état, prennent en charge les règles entrantes et sortantes, s'appliquent à des serveurs ou à des sélecteurs de labels, et ne coûtent rien. Un jeu de règles type :

Consultez les pare-feu dans la documentation pour la marche à suivre.

5. Bloquer la force brute avec Fail2ban

sudo apt install -y fail2ban python3-systemd
sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
backend  = systemd

[sshd]
enabled = true
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

backend = systemd lit directement le journal systemd, là où Ubuntu 24.04 enregistre SSH. Ajoutez votre propre adresse à ignoreip dans [DEFAULT] pour ne jamais vous bannir vous-même.

6. Réduire ce qui écoute

Chaque port ouvert est un élément de plus à maintenir à jour. Listez-les :

sudo ss -tulpn

Pour chaque ligne, demandez-vous si le service doit être joignable depuis Internet. Les bases de données, Redis et les panneaux d'administration n'en ont généralement pas besoin. Liez-les à 127.0.0.1 ou à une adresse de réseau privé, et supprimez les paquets que vous n'utilisez pas :

sudo apt purge --autoremove <package>

7. Protéger le noyau et la pile réseau

Les réglages par défaut d'Ubuntu sont raisonnables. Quelques paramètres supplémentaires sont utiles sur un serveur public :

sudo tee /etc/sysctl.d/90-hardening.conf >/dev/null <<'EOF'
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
EOF
sudo sysctl --system

Ignorez les réglages de redirection si le serveur route du trafic, par exemple en tant que passerelle VPN.

8. Utiliser sudo avec prudence

• N'accordez sudo qu'aux personnes qui en ont besoin : getent group sudo les liste.
• N'appliquez jamais NOPASSWD: ALL à des comptes interactifs. Limitez le sudo sans mot de passe à des commandes précises pour l'automatisation.
• Définissez un mot de passe pour votre utilisateur sudo, même si SSH utilise des clés : sudo passwd deploy.

9. Surveiller les journaux et les connexions

last -n 20                          # connexions récentes
sudo journalctl -u ssh --since today
sudo journalctl -p err -b           # erreurs depuis le démarrage

Pour l'intégrité des fichiers et un audit rapide, Lynis est un bon point de départ :

sudo apt install -y lynis
sudo lynis audit system

Il affiche un indice de durcissement et une liste de suggestions. Considérez-les comme des idées, pas comme des ordres.

La console Wolkra affiche des graphiques de CPU, de disque et de réseau pour chaque serveur (supervision). Un pic soudain de trafic ou de CPU est souvent le premier signe d'un service compromis.

10. Sécuriser le compte, pas seulement le serveur

Durcir le serveur ne sert à rien si quelqu'un peut se connecter à votre compte cloud. Dans la console Wolkra :

• activez l'authentification à deux facteurs (TOTP) ;
• passez en revue les sessions actives et déconnectez les anciennes ;
• attribuez aux membres de l'équipe le rôle le plus restreint qui leur suffit ;
• utilisez autant que possible des jetons d'API en lecture seule, limités par IP et avec date d'expiration.

Consultez sécurité du compte et jetons d'API.

11. Sauvegarder, et tester la restauration

La sécurité inclut la reprise après incident. Activez les sauvegardes quotidiennes ou les instantanés et gardez au moins une copie hors du serveur. Restaurez ensuite une fois sur un nouveau serveur pour prouver que cela fonctionne. Le guide de stratégie de sauvegarde propose un plan complet.

Liste de contrôle

• Mises à jour de sécurité automatiques activées
• SSH par clés uniquement, connexion root désactivée, AllowUsers défini
• UFW en refus par défaut, seuls les ports nécessaires ouverts
• Pare-feu cloud en amont, SSH limité à des plages connues
• Fail2ban en fonctionnement
• Rien d'inattendu dans ss -tulpn
• Durcissement sysctl appliqué
• Sudo limité, 2FA activée sur le compte cloud
• Sauvegardes activées et restauration testée

Si quelque chose tourne mal pendant que vous resserrez les règles, la console navigateur et le mode rescue, dans la vue du serveur, vous permettent de reprendre la main sans SSH.