Blinder votre serveur en trois couches
Votre serveur tourne, vos applications aussi, et une question vous empêche d'y penser sereinement : il est exposé sur internet et vous savez qu'il n'est pas blindé. Le pire, ce ne sont pas les attaques, c'est la peur de mal faire : une commande de pare-feu mal posée et vous voilà enfermé dehors de votre propre serveur. Alors la sécurisation attend, et la porte reste ouverte.
Cette masterclass vous donne la méthode de blindage en six étapes, dans un ordre strict : SSH sur un port non standard, pare-feu UFW, redémarrage et test à deux terminaux, règles DOCKER-USER, clé SSH seule, fail2ban. Avec, avant chaque commande sensible, le filet de sécurité qui garantit que vous ne vous enfermez jamais dehors.
Ce que cet exercice ne peut pas casser
La peur de vous enfermer dehors est légitime, et la méthode est construite contre elle : aucune commande sensible ne se lance sans un second terminal déjà connecté, et la console de secours de votre hébergeur reste le filet ultime. L'exercice ci-dessous, lui, ne modifie rien sur le serveur : vous ne faites que lire et noter.
Ce que vous saurez faire à la fin
- Dérouler les six étapes de sécurisation dans le bon ordre, sans jamais vous couper l'accès à votre serveur.
- Appliquer le filet de sécurité du second terminal avant chaque commande qui peut couper l'accès SSH, jamais après.
- Vérifier d'une seule commande d'audit que les six couches sont bien en place.
- Niveau membre· le prompt prêt à coller qui génère votre plan de sécurisation complet, commandes exactes et filets de sécurité inclus.
- Niveau Pro· je sécurise votre serveur avec vous, en direct, et personne ne reste enfermé dehors.
Un ordre strict : chaque couche suppose que la précédente tient, et le test à deux terminaux verrouille le passage.
Six couches, un ordre strict, zéro porte claquée
Un serveur ne se blinde pas d'un coup, il se blinde en couches, et l'ordre n'est pas négociable : chaque étape suppose que la précédente tient, et la moindre inversion peut vous couper l'accès. La méthode a une obsession : à aucun moment vous ne devez vous retrouver enfermé dehors. D'où la règle qui traverse les six étapes : avant chaque commande qui peut couper SSH, un second terminal ouvert, toujours.
1Déplacer SSH sur un port non standarddoute : « et si je me coupe l'accès ? »
Le port standard de SSH est frappé en continu par des robots qui testent des mots de passe toute la journée. Première couche : déclarer un port non standard dans la configuration SSH. À ce stade, vous ne redémarrez rien : on prépare le terrain, le test viendra à l'étape trois, une fois le pare-feu prêt à laisser passer le nouveau port.
2Monter le pare-feu UFWdoute : « et si je bloque mes propres applications ? »
UFW ferme tout par défaut, puis vous n'ouvrez que le nécessaire : votre nouveau port SSH, HTTP, HTTPS, et les ports propres à vos applications. D'où l'importance de la liste établie avant : un port applicatif oublié, c'est un service qui tombe ; un port deviné, c'est un trou. Si vous n'êtes pas sûr d'un port, vérifiez, ne devinez jamais.
3Redémarrer SSH et tester à deux terminauxdoute : « comment être sûr de ne pas rester dehors ? »
C'est la commande la plus sensible de toute la méthode, et elle a son filet de sécurité : votre session actuelle reste ouverte dans le premier terminal, et c'est depuis le second que vous testez la connexion sur le nouveau port. Tant que le second terminal n'est pas connecté, vous ne fermez rien. Si le test échoue, votre première session est toujours là pour corriger, et la console de secours de votre hébergeur reste le filet ultime.
4Fermer la porte Docker avec DOCKER-USERdoute : « pourquoi UFW ne suffit pas ? »
Vos conteneurs Docker n'obéissent pas à UFW : Docker publie leurs ports directement, par-dessus le pare-feu. Des applications comme n8n ou NocoDB peuvent donc rester exposées alors que UFW affiche tout fermé. La chaîne DOCKER-USER est l'endroit où l'on filtre ce trafic : on y rejoue les mêmes règles, cette fois pour les conteneurs.
5Couper l'authentification par mot de passedoute : « et si ma clé ne marche pas ? »
Une fois votre clé SSH en place, le mot de passe ne sert plus qu'aux attaquants : on le coupe. C'est une commande sensible, donc même rituel que pour le redémarrage : vous vérifiez d'abord, dans un second terminal, qu'une connexion par clé passe, et seulement ensuite vous fermez la porte aux mots de passe.
6Installer fail2ban, le gardien permanentdoute : « qui surveille quand je dors ? »
Les cinq premières couches sont statiques. fail2ban ajoute la couche vivante : il observe les tentatives de connexion et bannit automatiquement les adresses qui insistent. Une fois les six couches posées, une commande d'audit unique vérifie que tout est en place, avec la liste exacte de ce que vous devez voir.
À vous de jouer : constituez votre matière
Avant de lancer le prompt, rassemblez ce dont il a besoin pour ne rien deviner. Rien n'est modifié sur le serveur : vous lisez et vous notez.
Le résultat, en 30 secondes
À partir de votre matière (hébergeur, applications, ports, sortie de ufw status verbose), le prompt déroule votre plan : les six étapes numérotées avec les commandes exactes, la réponse attendue à chaque fois, et la commande d'audit finale.
Votre plan en une ligne : SSH déplacé sur un port non standard, ports 80 et 443 ouverts, port de n8n filtré dans DOCKER-USER. Étape 3, filet de sécurité : gardez votre session actuelle ouverte, connectez-vous depuis le second terminal sur le nouveau port ; tant que cette connexion n'a pas réussi, ne fermez rien. En bas : la commande d'audit unique des six couches et les trois pièges probables vu vos applications.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur système spécialisé dans la sécurisation de serveurs Linux pour des indépendants non techniciens. Tu es rigoureux, pédagogue, et tu as une obsession : ne jamais enfermer l'utilisateur dehors de son propre serveur. Tu ne t'appuies QUE sur ce que je te donne. Ce qui manque, tu me le demandes, tu ne l'inventes jamais. Si une commande peut casser l'accès au serveur, tu le signales en clair avant de la donner. # CONTEXTE J'ai un serveur Linux exposé sur internet et je veux le blinder en couches : SSH sur port non standard, pare-feu UFW, règles DOCKER-USER, clé SSH, fail2ban. Je ne suis pas ingénieur réseau, j'ai besoin que tu m'expliques chaque geste et que tu me protèges de l'erreur qui m'enferme dehors. Ma matière (si j'en ai) :
Le prompt génère votre plan de sécurisation complet : les six étapes dans l'ordre strict, les commandes exactes pour votre serveur, le filet de sécurité avant chaque geste sensible et la commande d'audit finale. Si vous n'avez pas encore de matière, il passe en mode interview et vous interroge étape par étape. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous venez de déclarer le nouveau port SSH et de régler UFW. Il faut maintenant redémarrer le service SSH. Que faites-vous ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
Expliquez en une phrase, à quelqu'un qui n'a jamais touché un serveur : pourquoi garde-t-on un second terminal ouvert avant de redémarrer SSH ? Si votre réponse est limpide, la méthode est à vous.
Ce que vous savez faire maintenant
- Dérouler les six couches dans l'ordre strict : port SSH, UFW, test à deux terminaux, DOCKER-USER, clé SSH, fail2ban.
- Ouvrir un second terminal avant toute commande qui peut couper l'accès, jamais après.
- Constituer la matière exacte dont le prompt a besoin pour générer un plan sans approximation.
Une commande sensible ne se lance jamais sans une seconde porte déjà ouverte.
Faites-le avec moi
Je sécurise votre serveur avec vous, en direct : vous tapez, je vérifie, et personne ne se retrouve enfermé dehors.