Contrôlez les accès réseau et transférez des fichiers de manière sécurisée

Même avec un accès SSH verrouillé, votre serveur reste exposé au quotidien. En entreprise, bien que l'infrastructure globale contrôle déjà une partie des accès, la règle est de mettre en place une défense en profondeur en protégeant directement le serveur lui-même.

Votre mission est donc de durcir votre machine locale. Pour cela, vous allez filtrer les connexions entrantes avec un pare-feu, repousser les attaques automatisées et transférer vos fichiers de manière sécurisée.

Configurez un pare-feu simple avec UFW

Pour contrôler précisément qui peut se connecter à votre machine, vous devez configurer un pare-feu. 

Comme votre accès SSH fonctionne déjà avec l’utilisateur admin, vous disposez d’un point d’entrée fiable pour administrer la machine à distance. L’objectif est maintenant de filtrer les connexions sans bloquer cet accès.

La règle de base est simple : bloquer les connexions entrantes non autorisées et n’ouvrir que les services réellement nécessaires. Pour l’instant, votre serveur n’héberge encore aucun service applicatif. Le seul accès qui doit rester ouvert est donc SSH. Les autres accès seront autorisés plus tard, uniquement lorsqu’un service précis devra être exposé.

Alex, notre architecte système, vous le rappellera toujours.

Un serveur sécurisé n’expose que ce qui est strictement nécessaire. Mais attention à l’ordre des opérations : si vous activez le pare-feu avant d’autoriser SSH, vous risquez de couper votre propre accès distant.

Découvrez alors comment mettre en place ce premier rempart défensif avec méthode, sans risquer de perdre le contrôle.

Dans cette vidéo, on a :

• vérifié l'état du pare-feu avec UFW, si nécessaire, l’installer avecsudo apt install ufw,

• autorisé le trafic pour le service SSH afin de préserver votre porte d'entrée avecsudo ufw allow ssh,

• activé le parefeu avecsudo ufw enable,

• vérifié les règles actives avecsudo ufw verbose

• testé une nouvelle connexion SSH pour vérifier que l’accès distant reste disponible.

Votre serveur est désormais protégé par un pare-feu efficace. Cependant, le port SSH que vous avez volontairement laissé ouvert reste une cible de choix pour les robots qui scannent Internet en continu. 

Renforcez la protection contre les attaques automatisées

Votre pare-feu filtre désormais les connexions entrantes, mais le port SSH reste volontairement ouvert pour permettre l’administration du serveur. Même avec une authentification par clé, ce service peut recevoir des tentatives de connexion répétées.

Sur Internet, ce bruit de fond est permanent : des robots testent automatiquement des identifiants, des ports et des configurations faibles. Votre serveur ne doit donc pas seulement refuser ces accès ; il doit aussi limiter les tentatives trop insistantes.

Pour cela, vous allez ajouter une protection active avec Fail2Ban. 

Alex vous le rappelle souvent :

La sécurité ne repose pas sur un seul outil magique. Fail2Ban complète votre pare-feu UFW et la configuration stricte de SSH. UFW contrôle ce qui peut entrer, SSH impose une authentification forte, et Fail2Ban réagit aux comportements anormaux.

Découvrez maintenant comment installer ce gardien silencieux et vérifier qu’il surveille bien votre serveur.

Dans cette vidéo, on a :

• installé Fail2Ban avecsudo apt install fail2banpour ajouter une protection active contre les tentatives répétées,

• vérifié que le service Fail2Ban est démarré,

• consulté l’état général de Fail2Ban avecsudo fail2ban-client status,

• observé les logs pour confirmer son fonctionnement avecsudo journalctl -u fail2ban.

Votre serveur dispose maintenant d’une protection supplémentaire contre les tentatives répétées. 

Il vous reste un besoin quotidien à couvrir : échanger des fichiers avec cette machine sans sortir du cadre sécurisé. Découvrons maintenant comment transférer des fichiers de manière chiffrée.

Transférez des fichiers de manière sécurisée

Au quotidien, vous aurez besoin d'échanger des documents avec votre machine : envoyer des fichiers de configuration, déployer le code d'une application ou encore récupérer des sauvegardes.

Alex est intransigeant sur ce point.

Les transferts de fichiers doivent obligatoirement utiliser une connexion chiffrée. Les anciens protocoles non chiffrés, comme FTP ou Telnet, doivent être totalement bannis. Ils font transiter nos données et parfois même nos identifiants en clair sur le réseau, ce qui est une faille de sécurité majeure.

La bonne nouvelle, c’est que votre accès SSH est déjà configuré et sécurisé. Vous pouvez donc l’utiliser pour transférer vos fichiers sans ouvrir un nouveau service sur le serveur. Deux outils sont particulièrement utiles :

• sftp, pour transférer quelques fichiers de manière interactive ;

• rsync, pour synchroniser efficacement un dossier local avec un dossier distant.

Découvrez maintenant comment envoyer et récupérer des fichiers sans installer de service supplémentaire sur votre serveur.

Dans cette vidéo, on a : 

• utilisésftppour transférer un fichier de manière interactive via SSH,

• envoyé un fichier sans utiliser de protocole non chiffré avec la commandeput,

• synchronisé un dossier avecrsyncen s’appuyant sur SSH,

• vérifié sur le serveur que les fichiers transférés sont bien présents.

À vous de jouer

Contexte 

Le serveur Debian que vous avez installé dans votre machine virtuelle est désormais accessible à distance via SSH depuis votre machine locale. Même si cet environnement reste un laboratoire de pratique, vous allez appliquer les mêmes réflexes que sur un serveur d’entreprise : limiter les connexions autorisées, vérifier que l’accès d’administration reste disponible et utiliser des outils chiffrés pour transférer des fichiers.

Consignes

1. Vérifiez l’état actuel du pare-feu UFW sur votre serveur. Si UFW n’est pas installé, installez-le.

2. Configurez le pare-feu pour n’autoriser que les connexions strictement nécessaires au fonctionnement actuel du serveur. À ce stade, seul l’accès SSH doit rester autorisé.

3. Activez UFW, puis vérifiez les règles appliquées.

4. Vérifiez impérativement que l’accès SSH reste fonctionnel après l’activation du pare-feu, en ouvrant une nouvelle connexion depuis votre machine locale.

5. Installez Fail2Ban, puis vérifiez que le service est actif. Dans votre machine virtuelle, vous n’observerez pas forcément d’attaques réelles, mais l’objectif est de vérifier que l’outil est prêt à surveiller les tentatives répétées.

6. Créez un fichier ou un dossier de test sur votre machine locale.

7. Testez un transfert de fichiers sécurisé entre votre machine locale et le serveur en utilisant successivement :

   1. sftppour un transfert interactif, 

   2. rsyncpour une synchronisation.

En résumé

• La mise en place d’un pare-feu avec UFW permet de bloquer par défaut les connexions entrantes et de n’autoriser explicitement que les services nécessaires, comme SSH, afin de réduire la surface d’exposition du serveur.

• L’activation du pare-feu doit toujours être précédée par l’autorisation du service SSH afin d’éviter de bloquer l’accès distant administrateur.

• L’outil Fail2Ban complète le pare-feu en surveillant les journaux système pour détecter des tentatives répétées de connexion et bannir temporairement les adresses IP suspectes.

• La sécurisation du serveur repose sur une approche de défense en profondeur combinant filtrage réseau, authentification forte SSH et blocage automatique des comportements anormaux.

• Les transferts de fichiers doivent utiliser des outils chiffrés commesftpoursyncvia SSH afin d’éviter toute transmission en clair et de garantir l’intégrité des échanges.

En partant d’une machine vierge, vous avez bâti un serveur Debian léger, administrable à distance et sécurisé avec méthode. Vous avez installé une base minimale, configuré le réseau, mis en place un accès SSH par clé, filtré les connexions avec UFW et utilisé des transferts de fichiers chiffrés.

Votre serveur dispose désormais d’un socle solide pour accueillir de futurs services. Avant de passer à vos propres projets, gardez en tête les règles d’or qu’Alex vous a répétées tout au long de cette mission :

• Restez minimaliste : n’installez et n’exposez que ce qui est réellement nécessaire, afin de limiter la surface d’attaque.

• Testez avant de quitter : lors d’une modification sensible, notamment sur le réseau, SSH ou le pare-feu, conservez toujours une session ouverte tant que le nouvel accès n’a pas été validé.

• Pensez défense en profondeur : la sécurité absolue n’existe pas. Combinez toujours plusieurs barrières complémentaires plutôt que de compter sur un seul outil.

Votre machine est prête à poursuivre l’aventure. À vous maintenant de la faire évoluer, service après service, en gardant les bons réflexes d’administration Linux.