Partie 5 — Provisionner & durcir le VPS

⏱️ TL;DR — Le fournisseur vient de te livrer un VPS nu : une IP, un accès root, rien d’autre. C’est le moment le plus dangereux de sa vie — exposé sur Internet, ouvert, et déjà scanné par des robots dans la minute qui suit. Cette partie transforme cette machine crue en un serveur de production sûr, geste par geste : première connexion et réglages système (MàJ, fuseau, hostname, swap), maîtrise d’apt, création de l’utilisateur deploy (fini root), pare-feu UFW en deny-by-default, fail2ban contre le bruteforce et mises à jour de sécurité automatiques. À la fin, tu tiens une checklist de durcissement initial que tu rejoueras sur chaque nouveau serveur, les yeux fermés.

Le problème qu’on résout

Un VPS fraîchement créé est une porte ouverte. Il écoute sur une IP publique, la connexion root par mot de passe est souvent active, aucun pare-feu ne filtre, aucune mise à jour n’est appliquée. Ce n’est pas de la paranoïa : dès qu’une IP apparaît sur Internet, des robots commencent à tester root avec des milliers de mots de passe courants. Un serveur laissé « par défaut » quelques jours se fait compromettre — c’est la règle, pas l’exception.

Le durcissement initial n’est pas une étape optionnelle qu’on fera « plus tard ». C’est la toute première chose à faire, avant même de penser à installer Nginx ou déployer quoi que ce soit. Cette partie te donne la séquence exacte : dans quel ordre, avec quelles commandes, en expliquant pourquoi chaque geste ferme une porte. On part du VPS cru livré par le fournisseur, on finit avec une base saine, à jour, filtrée et défendue — prête à accueillir ton app.

Ce que tu sauras faire à la fin de cette partie

• Te connecter à un VPS neuf et exécuter les premiers réflexes : mise à jour, fuseau horaire, hostname, vérification des ressources, ajout de swap.
• Maîtriser apt et dpkg : rafraîchir l’index, installer, supprimer, nettoyer, gérer les dépôts tiers (clés GPG) sans compromettre la machine.
• Créer l’utilisateur deploy avec sudo et sa clé SSH, puis couper l’accès root sans te verrouiller dehors.
• Poser un pare-feu UFW en deny-by-default qui n’ouvre que le strict nécessaire (SSH, 80, 443).
• Installer fail2ban et unattended-upgrades, et dérouler une checklist de durcissement reproductible.

Les chapitres

Ces cinq chapitres se déroulent dans l’ordre d’un vrai provisioning : on se connecte, on met à jour, on crée deploy, on ferme les ports, on arme les défenses. Chacun ajoute une couche au durcissement — et le dernier chapitre les rassemble toutes dans une checklist de durcissement initial que tu garderas sous la main.

La checklist de durcissement, fil conducteur de la partie

Tout au long de ces chapitres, on construit une seule chose : une liste de gestes de sécurité à appliquer sur chaque serveur neuf. La voici en aperçu — chaque item est traité et justifié dans les chapitres, et la version complète (à cocher) clôt le 5.5.

• Système à jour dès la première minute, et maintenu à jour automatiquement.
• Utilisateur non-root (deploy) avec sudo ; connexion root désactivée.
• SSH par clés uniquement : mot de passe désactivé (rappel de la Partie 4).
• Pare-feu deny-by-default : seuls SSH, 80 et 443 sont ouverts ; la base jamais exposée.
• fail2ban qui bannit les IP qui bruteforcent.
• swap, hostname et fuseau réglés proprement.

On démarre, VPS tout neuf sous la main : Première connexion. Une fois le serveur durci, on lui donnera un nom sur Internet en Partie 6 — Réseau, DNS & domaine.