Hardening d’un serveur Debian auto-hébergé

Limiter la surface d’exposition

N’ouvrir que les ports nécessaires. Si une box redirige un port vers le serveur, ne rediriger que celui du service concerné. Quand c’est possible, isoler le serveur du reste du réseau local (réseau invité, VLAN ou DMZ) pour qu’une compromission ne donne pas accès aux autres appareils.

Sécuriser SSH

Des clés plutôt que des mots de passe, et pas de connexion directe en administrateur. Dans /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers username

Changer le port d’écoute n’est pas une vraie protection, mais cela réduit le bruit dans les logs.

Firewall et mises à jour

• Firewall (nftables ou ufw) : tout bloquer en entrée par défaut (default deny), puis autoriser SSH et le service exposé.
• Mises à jour de sécurité automatiques avec unattended-upgrades.

Least privilege pour les services

Un service exposé, comme un serveur de jeu, tourne sous un utilisateur dédié, sans droits d’administration, avec des restrictions systemd :

[Service]
User=minecraft
NoNewPrivileges=yes
ProtectSystem=strict
ReadWritePaths=/srv/minecraft
PrivateTmp=yes

Monitoring et backups

Un outil comme fail2ban bloque les adresses qui échouent à se connecter en boucle, et journalctl permet de relire les logs. Les backups se font hors de la machine, et on teste la restauration : un backup jamais restauré n’est qu’une hypothèse.

Sources

• Securing Debian Manual
• sshd_config (OpenSSH)
• systemd.exec : options de sandboxing