Partie 2.4 - Sécuriser Linux à l’aide du pare-feu local et autoriser l’accès HTTP distant

S’applique à : .NET Core 2.1, .NET Core 3.1, .NET 5

Cet article explique comment configurer un pare-feu local pour sécuriser votre machine virtuelle Linux.

Prerequisites

Il n’existe aucun prérequis pour effectuer cette partie du didacticiel.

Objectif de cette partie

Vous allez apprendre à sécuriser votre machine virtuelle Linux en configurant un pare-feu.

Bien qu’il n’existe aucun prérequis pour cette partie, la configuration idéale suivrait les instructions des parties précédentes. Vous devez disposer des éléments suivants :

• Nginx s’exécute automatiquement et écoute des demandes envoyées sur le port 80
• Nginx configuré en tant que proxy inverse et routage des requêtes entrantes vers une application ASP.NET Core qui écoute sur le port 5000.
• Application ASP.NET Core configurée pour démarrer automatiquement une fois le serveur redémarré ou lorsque le processus est arrêté ou se bloque

Configurer un pare-feu local pour autoriser l’accès à partir d’ordinateurs distants

Presque toutes les distributions Linux incluent un pare-feu local nommé iptables. Ce guide de débutant est suffisant pour un démarrage rapide. Iptables est un pare-feu léger et puissant qui utilise des chaînes de stratégie pour autoriser ou bloquer le trafic.

Selon la page d’aide de la communauté Ubuntu, par défaut, les iptables sont installés sur toutes les distributions Ubuntu officielles et sont configurés pour autoriser tout le trafic.

Bien que les iptables soient un pare-feu léger, il n’est pas facile de gérer les règles persistantes. Heureusement, il existe plusieurs outils de configuration de pare-feu qui facilitent considérablement la configuration des règles de pare-feu dans Linux. Selon la documentation officielle du pare-feu Ubuntu, l’outil de configuration de pare-feu par défaut pour Ubuntu est ufw. Cet outil fournit une méthode plus conviviale que les iptables fournit pour créer un pare-feu IPv4 ou IPv6 basé sur l’hôte.

Note

ufw est initialement désactivé par défaut. Par conséquent, vous devez l’activer pour pouvoir l’utiliser.

La machine virtuelle Linux qui a été utilisée tout au long de ce didacticiel n’est pas protégée par une règle de pare-feu. Cela est dû au fait que, bien que les iptables soient installées et en cours d’exécution, il n’existe aucune règle définie.

L’objectif ici est d’autoriser uniquement le trafic HTTP et SSH (Secure Shell) à atteindre la machine virtuelle à partir de l’extérieur. Pour ce faire, procédez comme suit :

1. Avant d’activer ufw, vérifiez que la règle de stratégie par défaut est définie pour autoriser. Sinon, vous risquez de perdre la connexion SSH à la machine virtuelle. La règle par défaut est la règle qui est traitée si aucune autre règle n’est mise en correspondance. L’activation de la règle « allow » par défaut garantit que le trafic SSH entrant n’est pas bloqué. À ce stade, il n’existe aucune règle de « refus » du tout. Par conséquent, tout le trafic entrant est autorisé.

2. Important

   Ajoutez explicitement des règles SSH et HTTP « allow ». Notez également que, si vous avez configuré le port SSH sur une valeur différente de la valeur par défaut de 22, vous devez autoriser ce port. Par exemple, si vous avez modifié le port SSH en 2222, vous devez exécuter cette commande : sudo ufw allow 2222.

3. Définissez la règle par défaut comme règle de « refus ». Cela permet de s’assurer que si le protocole est différent de SSH ou HTTP, la règle « refuser » par défaut refuse le trafic. Par exemple, le trafic HTTP entrant est refusé.
4. Activez le ufw.

Les commandes de ces étapes sont répertoriées dans la capture d’écran suivante.

C’est ce qui se produit dans chaque étape.

1. vérifie l’état de l’ufw en exécutant la sudo ufw status verbose commande. Par défaut, l’ufw n’est pas activé et est inactif.

2. exécute la sudo ufw default allow commande. Étant donné qu’il n’existe aucune autre règle que la règle « autoriser » par défaut, chaque port de la machine virtuelle est considéré comme ouvert.

3. Important

   Ajoutez le protocole SSH à la liste autorisée en exécutant la sudo ufw allow ssh commande. Protocol.ssh est un protocole connu et est défini dans le fichier /etc/services . Par conséquent, « ssh » peut être utilisé au lieu de « 22 ». N’oubliez pas que si vous configurez le service SSH pour écouter sur un port autre que le port par défaut 22, vous devez ajouter explicitement l’autre port. Par exemple, si vous configurez SSH pour écouter le port 2222, exécutez cette commande : sudo ufw allow 2222.

4. Autorisez le protocole HTTP en exécutant sudo ufw allow http. HTTP est un protocole connu défini dans le fichier /etc/services. Par conséquent, le nom du protocole peut être utilisé et la sudo ufw allow http commande peut être exécutée. L’exécution sudo ufw allow 80 est également parfaitement valide.

   Note

   Après avoir autorisé les protocoles SSH et HTTP, vous devez ajouter tous les autres protocoles à la liste « refuser ».

5. Pour ce faire, modifiez la règle par défaut pour refuser en exécutant la sudo ufw default deny commande. Seuls les protocoles SSH et HTTP sont autorisés. Les autres protocoles seront refusés.

6. Activez ufw.

Voici la sudo ufw status verbose sortie une fois cette procédure terminée.

Une fois le pare-feu configuré, vérifiez s’il fonctionne.

Tester le pare-feu local

Testez facilement le pare-feu : créez une règle de « refus » pour le protocole HTTP, puis essayez d’accéder au site à partir d’un autre ordinateur. La requête doit être bloquée.

Avant de créer cette règle de « refus », vérifiez que l’application est accessible au navigateur dans sa configuration actuelle. Pour ce faire, modifiez le fichier C :\Windows\System32\drivers\etc\hosts sur l’ordinateur client en ajoutant le nom d’hôte buggyamb et en utilisant l’adresse IP publique de votre machine virtuelle Linux. Le nom d’hôte buggyamb résout l’adresse IP de la machine virtuelle Linux. Vous pouvez ajouter n’importe quel nom d’hôte à votre fichier hosts, ou vous pouvez essayer de vous connecter directement à l’adresse IP publique de votre machine virtuelle Linux.

Après avoir vérifié que les requêtes HTTP peuvent atteindre la machine virtuelle, essayez d’activer une règle qui bloque le trafic HTTP. Cela permet de s’assurer que le pare-feu fonctionne. Pour ce faire, ajoutez une règle de « refus » pour HTTP en exécutant sudo ufw deny http. Cela ajoute deux règles de « refus » pour le protocole HTTP (sur le port 80). L’un est pour IPv4, l’autre est pour IPv6.

Ouvrez à nouveau le navigateur, puis essayez d’accéder à l’application ASP.NET Core qui s’exécute dans Linux.

Cette capture d’écran montre le résultat attendu.

Vous pouvez exécuter un test similaire directement à l’intérieur de la machine virtuelle Linux à l’aide de la wget commande. La capture d’écran suivante montre les étapes requises pour le même test en exécutant wget.

C’est ce qui se produit dans chaque étape.

1. La règle de « refus » pour le protocole HTTP a été ajoutée.

2. La wget buggyamb-external commande a été exécutée. Comme vous pouvez le deviner, le nom d’hôte « buggyamb-external » résout l’adresse IP publique de la machine virtuelle Linux. Pour ce faire, modifiez le fichier à l’aide /etc/hosts de vi. Comme indiqué, wget essayez de vous y connecter, mais n’avez jamais réussi. Pour sortir de l’opération, vous devez appuyer sur Ctrl+C.

3. Une règle « autoriser » pour le protocole HTTP a été ajoutée.

4. L’exécution de la wget buggyamb-external commande a de nouveau produit des résultats différents. Cette fois, wget a pu se connecter, car le protocole HTTP a été autorisé. Comme indiqué, wget télécharge le fichier Index.html dans votre répertoire actif.

Vous êtes maintenant plus proche de la fin de la configuration requise pour déboguer l’application ASP.NET Core. Avant d’accéder à la partie suivante, vérifiez à nouveau que SSH et HTTP sont autorisés dans le pare-feu local.

Prochaines étapes

Partie 2.5 : copiez les fichiers de votre environnement de développement sur une machine virtuelle Linux, puis extrayez les fichiers dans Linux.