Pourquoi je fais ça dès le départ ?
Dès qu’un serveur (même un vieux portable recyclé) expose des services (site, API, Git, Nextcloud, dashboard, reverse proxy…), il devient une cible.
Mon setup rapide
J’ai déjà Debian 12 Bookworm installé sur un vieux portable Toshiba recyclé (batterie HS, écran éteint, headless).
Matériel Vieux Toshiba Satellite → faible conso, discret une fois le ventilo calmé, idéal pour débuter.
Ce que je veux obtenir
- IP fixe → pour toujours savoir où est le serveur
- SSH durci → seul moyen d’accès distant, ultra protégé
- Pare-feu → bloque tout ce qu’on n’a pas explicitement autorisé
- Fail2Ban → punit les robots qui essaient des milliers de mots de passe
- Mises à jour auto → corrige les failles sans que j’y pense
1. IP fixe via réservation DHCP
Pourquoi ?
Si l’IP change à chaque redémarrage (comportement normal du DHCP), tu dois checker à chaque fois quelle IP ton serveur a pris. C’est chiant et source d’erreurs.
Avec une IP fixe (réservée par la box), tu te connectes toujours au même endroit : ssh lab.
Comment ça protège ?
Pas de protection directe, mais évite de se tromper d’IP et d’exposer accidentellement un autre appareil.
Comment faire
- Sur le serveur :
ip -brief link show→ note la MAC (ex.00:1f:29:ab:cd:ef) - Sur ta box (interface web, section DHCP / baux statiques) : associe MAC → IP fixe (ex.
192.168.1.200, hors plage dynamique)
Vérification :
ip a show | grep inet
Alternative si la box ne permet pas la réservation
- Configurer une IP statique directement sur le serveur (
/etc/network/interfacesounmcli/systemd-networkd) - → Moins pratique si tu changes de réseau / box
- → Risque de conflit d’IP si tu oublies de changer l’adresse
2. Nom simple + alias SSH (~/.ssh/config)
Pourquoi ?
Taper ssh level@192.168.1.200 50 fois par jour, c’est long et source d’erreurs de frappe.
Avec un alias ssh lab, c’est instantané + tu peux ajouter des options (clé, keepalive…).
Comment ça protège ?
Pas directement, mais réduit les erreurs humaines (ex. taper une mauvaise IP).
Méthode recommandée : ~/.ssh/config
Crée/modifie ~/.ssh/config sur ton PC client :
Host lab
HostName 192.168.1.200
User level
Port 22 # Recommandé de changer le port
IdentityFile ~/.ssh/id_ed25519
ServerAliveInterval 60 # évite que la connexion tombe
ServerAliveCountMax 3
Sécurise le fichier :
chmod 600 ~/.ssh/config
→ Tu tapes juste ssh lab
Alternative
- Ajouter dans
/etc/hosts:192.168.x.x lab-home - → Plus simple, mais moins puissant (pas d’options SSH)
3. Premier accès SSH (avant durcissement)
Pourquoi ?
C’est la porte d’entrée. On commence par un accès classique (mot de passe) pour pouvoir ensuite le verrouiller.
Commande :
ssh lab
(accepte la fingerprint la première fois + mot de passe actuel)
4. Durcissement SSH – la partie la plus critique
Pourquoi c’est vital ?
SSH est le seul service exposé par défaut → 99 % des attaques sur un serveur domestique passent par là (brute-force, exploits sur vieux mots de passe, root login direct). On coupe tout ce qui est faible.
Modifs clés dans /etc/ssh/sshd_config
PermitRootLogin no
Pourquoi ? Les attaquants essaient systématiquement root avec des mots de passe courants. Interdire root via SSH force à passer par un utilisateur normal (level) → double couche (faut cracker deux comptes).
PasswordAuthentication no
Pourquoi ? Les mots de passe sont faibles (même complexes) et vulnérables au brute-force. Les clés privées (ed25519) sont beaucoup plus fortes et impossibles à brute-forcer.
PubkeyAuthentication yes
→ Active les clés (on l’active explicitement pour être sûr)
Bonus perso
MaxAuthTries 3 # limite les essais par connexion
LoginGraceTime 30 # empêche les attaques lentes
X11Forwarding no # désactive X11
AllowTcpForwarding no # désactive le forwarding TCP
Applique les changements
sudo systemctl restart ssh
Installation de la clé
# Génère la paire de clés
ssh-keygen -t ed25519 -C "level@lab-home"
# Copie la clé publique sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519.pub lab
⚠️ Règle absolue
Toujours garder une session SSH ouverte en parallèle quand tu modifies sshd_config. Si tu te plantes → lock-out = reboot + clavier/écran obligatoire.
Alternatives si clés SSH plantent
- Garder temporairement
PasswordAuthentication yes(mais avec mot de passe très fort) - Utiliser Google Authenticator / Yubikey 2FA sur SSH (plus complexe, à ajouter après)
5. Pare-feu UFW
Pourquoi ?
Par défaut, Debian n’a pas de firewall actif. Si tu installes un service (ex. Nginx sur port 80), il est directement exposé au monde. UFW = interface simple pour iptables → on bloque tout sauf ce qu’on autorise explicitement.
Règles de base
# Bloque TOUT entrant sauf exceptions
sudo ufw default deny incoming
# Autorise les sorties (mises à jour, ping…)
sudo ufw default allow outgoing
# Garde SSH ouvert
sudo ufw allow OpenSSH
# Active le pare-feu
sudo ufw enable
Vérification
sudo ufw status verbose
Alternative
iptables/nftablesdirect → plus puissant mais beaucoup plus complexefirewalld→ plus lourd, pas natif sur Debian
6. Fail2Ban (anti-bruteforce)
Pourquoi ?
Même avec clés SSH, certains bots essaient encore des mots de passe (ou si tu oublies de couper PasswordAuthentication). Fail2Ban lit les logs SSH → après 3 échecs → ban IP pendant 10 min.
Installation
sudo apt install -y fail2ban
Config minimale dans /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 3
bantime = 10m
findtime = 10m
Redémarre le service
sudo systemctl restart fail2ban
Alternative
- CrowdSec (plus moderne, communautaire)
- Juste couper PasswordAuthentication (déjà très efficace)
7. Mises à jour automatiques
Pourquoi ?
Les failles de sécurité (ex. OpenSSH, kernel) sortent régulièrement. Sans MAJ, ton serveur devient vulnérable même s’il est bien configuré.
unattended-upgrades installe automatiquement les mises à jour de sécurité (pas les paquets normaux).
Installation et configuration
sudo apt install -y unattended-upgrades
# Configure l'installation automatique
sudo dpkg-reconfigure unattended-upgrades # → Oui
Alternative
- Cron maison ou
apt-listchangespour être notifié
8. Checklist rapide (copier-coller)
# Vérifie l'IP
ip -brief a
# Vérifie la config SSH
sudo grep -E "PermitRootLogin|PasswordAuthentication" /etc/ssh/sshd_config
# Vérifie UFW
sudo ufw status verbose
# Vérifie Fail2Ban
sudo fail2ban-client status sshd
# Vérifie les ports ouverts
sudo ss -tulpn
Validé quand
- IP fixe configurée
- Root SSH interdit
- Passwords SSH désactivés
- UFW actif (seul SSH ouvert)
- Fail2Ban en cours d’exécution
- Peu de ports ouverts
Conclusion
Cette configuration de base est un excellent point de départ pour tout serveur Debian. Elle couvre les fondamentaux de la sécurité sans être trop complexe.
Prochaines étapes possibles :
- Ajouter 2FA (Google Authenticator ou Yubikey) sur SSH
- Configurer des sauvegardes automatiques
- Installer un reverse proxy (Nginx/Caddy) avec HTTPS
- Configurer des alertes mail pour les tentatives de connexion
Points clés à retenir :
- La sécurité se fait par couches : chaque mesure ajoute une barrière supplémentaire
- SSH est le point critique : c’est votre seule porte d’entrée, protégez-la au maximum
- Automatise ce qui peut l’être : les mises à jour, les bans, les sauvegardes
- Garde toujours un accès de secours : ne te lock pas dehors !
Si tu veux que je développe encore plus une partie (ex. pourquoi ed25519 > RSA, comment tester un brute-force simulé, ou ajouter 2FA), dis-le-moi !