Introduction
Une règle de pare-feu est utile uniquement si elle produit la limite d'accès prévue tout en préservant le service requis. Ajouter une règle d'autorisation seule sous une politique ACCEPT par défaut ne prouve pas que quiconque a été restreint.
Ce lab fournit un service Kali dédié et deux clients d'exercice. Vous examinerez leur accès initial, appliquerez dans Kali des règles ordonnées fondées sur la source, enregistrerez et restaurerez la politique d'exercice, puis testerez les deux chemins clients.
Observer le réseau d'entraînement avant de restreindre l'accès
Dans cette étape, vous testerez deux vues clientes fournies et examinerez le pare-feu qui protège leur service d'entraînement.
Ce lab fournit un petit réseau dédié dans la VM. Le service d'entraînement Kali se trouve à 172.30.77.10:8080 ; le client autorisé utilise 172.30.77.20 et le client à bloquer utilise 172.30.77.30. Les deux ont initialement accès. Ce sont des adresses de réseau d'exercice, pas des cibles publiques.
Commencez dans le Terminal initial de l'hôte Ubuntu. La commande préparée training-client effectue une requête depuis un client d'exercice nommé. Elle s'exécute sur l'hôte, tandis que l'administration du pare-feu aura lieu dans Kali. Choisissez l'espace de travail partagé :
cd /home/labex/project
Enregistrez l'état HTTP initial du client autorisé :
training-client allowed > allowed-before.txt
cat allowed-before.txt
La ligne d'état doit contenir 200 OK. Consignez l'accès initial de l'autre client :
training-client blocked > blocked-before.txt
cat blocked-before.txt
Il doit aussi signaler 200 OK ; l'étiquette nomme le client que vous bloquerez, pas son état initial.
Entrez maintenant dans Kali pour examiner son pare-feu :
kali
Iptables évalue les règles de filtrage de paquets dans des chaînes. INPUT traite les paquets destinés à cet environnement, OUTPUT traite les paquets générés localement et FORWARD traite les paquets routés. -L INPUT liste la chaîne d'entrée ; -n conserve les adresses et ports numériques et -v inclut les compteurs :
sudo iptables -L INPUT -n -v
La chaîne d'exercice a initialement la politique ACCEPT. La politique d'une chaîne s'applique lorsqu'aucune règle n'a déjà décidé du sort du paquet. Dans ce lab, vous ajouterez des règles précises pour le service dédié, sans toucher aux politiques par défaut ni au pare-feu de l'hôte.
Appliquer et enregistrer une politique de service ordonnée
Dans cette étape, vous autoriserez le client attribué avant de refuser les autres sources du réseau d'exercice pour le même service.
Restez dans Kali. -A INPUT ajoute une règle à la fin de la chaîne d'entrée, -p tcp correspond à TCP, -s correspond à une adresse source, --dport sélectionne le port de destination et -j choisit l'action. Ajoutez d'abord la règle d'autorisation précise :
sudo iptables -A INPUT -p tcp -s 172.30.77.20 --dport 8080 -j ACCEPT
Refusez ensuite les autres sources du sous-réseau d'exercice dédié pour ce même port. Le préfixe /24 identifie la plage réseau 172.30.77.0 :
sudo iptables -A INPUT -p tcp -s 172.30.77.0/24 --dport 8080 -j REJECT
Les règles sont évaluées dans l'ordre. La source autorisée correspond à la première règle ACCEPT terminale ; l'autre client d'exercice atteint la règle REJECT ultérieure. Inverser ces règles refuserait aussi le client autorisé. Les autres ports et sources suivent toujours la politique par défaut inchangée.
Affichez l'ordre des règles et leurs compteurs. --line-numbers inclut la position de chaque règle :
sudo iptables -L INPUT -n -v --line-numbers
La première règle doit autoriser le client attribué sur TCP 8080 et la règle suivante doit refuser le reste du trafic de ce service provenant du sous-réseau d'exercice.
iptables-save affiche les règles actives dans un format restaurable. Enregistrez la configuration de cet exercice dans l'espace de travail partagé :
sudo iptables-save > /home/labex/project/training.rules
L'opérateur < du shell fournit un fichier comme entrée standard d'une commande. iptables-restore lit cette configuration enregistrée ; ici, vous restaurez exactement les règles d'exercice que vous venez d'enregistrer :
sudo iptables-restore < /home/labex/project/training.rules
Cela agit uniquement dans l'environnement réseau Kali dédié. Ne videz pas le pare-feu de l'hôte et ne remplacez pas les politiques par défaut pour réaliser une restriction précise de service.
Vérifier les accès clients autorisés et refusés
Dans cette étape, vous testerez la politique depuis les deux sources clientes et confirmerez que le service d'entraînement reste disponible.
Revenez de Kali au Terminal de l'hôte Ubuntu pour utiliser les vues clientes fournies :
exit
L'invite de l'hôte nomme labex. Consignez le nouveau résultat du client autorisé :
training-client allowed > /home/labex/project/allowed-after.txt
cat /home/labex/project/allowed-after.txt
Il doit toujours signaler 200 OK.
L'échec de la prochaine commande est attendu, avec une connexion refusée ou une autre erreur de connexion : c'est le client que vous avez délibérément bloqué. Continuez après cet échec intentionnel :
training-client blocked
Une requête échouée du client bloqué est significative uniquement tant que le chemin autorisé fonctionne toujours. Arrêter le service web casserait les deux chemins et ne démontrerait pas la politique requise.
Revenez dans Kali et examinez les compteurs après les tests :
kali
sudo iptables -L INPUT -n -v --line-numbers
Les compteurs des règles pertinentes doivent avoir augmenté. Vous avez vérifié le comportement réel du trafic ainsi que le texte des règles et le Terminal de l'hôte LabEx reste disponible pendant tout l'exercice.
Résumé
Vous avez examiné les politiques des chaînes, ajouté des règles ordonnées fondées sur la source pour un service, enregistré et restauré la configuration d'exercice et testé l'accès réel de deux clients. La source autorisée et le service sont restés disponibles tandis que la source désignée a été refusée.
