Introduction
L’application de commandes de Corner Shop lit et crée des enregistrements dans une base PostgreSQL privée. Sa page fonctionne, mais Visitor peut aussi atteindre directement la base. Le bon fonctionnement de l’application ne prouve donc pas la sécurité de sa frontière réseau.
Vous comparerez des connexions réelles, limiterez le transfert sur Gateway et préserverez commandes et service public d’état. Seule une utilisation élémentaire du terminal est requise. Personnes et données sont synthétiques. Les trois nœuds de terminal sont des conteneurs aux espaces de noms réseau distincts partageant le noyau d’une instance, et non des machines virtuelles indépendantes.
Suivre une commande et son chemin réseau
Dans cette étape, vous créerez une vraie commande et comparerez deux chemins vers sa base. L’application est le programme destiné au client ; la base stocke ses enregistrements. Ouvrez Order Page, trouvez seed: Green tea, saisissez practice-1 dans Order reference et cliquez sur Create tea order. La ligne est stockée dans PostgreSQL, et pas seulement affichée.
La carte indique l’adresse IP de chaque nœud, qui identifie une destination réseau. Un port identifie un service à cette adresse. PostgreSQL écoute sur 172.28.20.10:5432 ; le service public distinct utilise 8001. App Client (172.28.10.20) a besoin de la base. Visitor (172.28.10.30) a seulement besoin de l’état public.
Passez à App Client. L’outil préparé tcp-probe ouvre une vraie connexion TCP et attend au plus trois secondes. Ses deux arguments sont l’adresse de destination et le port :
tcp-probe 172.28.20.10 5432
Le résultat attendu est TCP OPEN. Il prouve l’accessibilité, pas le droit de lire. psql est le client de requêtes PostgreSQL. Cette commande fournit le mot de passe d’exercice uniquement à cette exécution. La chaîne entre guillemets regroupe serveur, port, utilisateur, base et délai de connexion de trois secondes. -c exécute le SQL entre guillemets ; SELECT lit les colonnes nommées de orders et ORDER BY les trie. Le point-virgule termine l’instruction.
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Repérez practice-1 et Green tea. L’identifiant volontairement connu restera identique pour isoler l’effet du changement réseau.
Passez à Visitor et répétez les deux commandes :
tcp-probe 172.28.20.10 5432
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Elles réussissent : le client indésirable peut se connecter et lire les commandes synthétiques. Un mauvais mot de passe produirait une erreur d’authentification après avoir atteint PostgreSQL ; le port resterait exposé.
Une route indique où envoyer les paquets. Consultez la route préparée de Visitor vers la base :
ip route get 172.28.20.10
Les champs utiles sont via 172.28.10.254 (Gateway) et src 172.28.10.30 (Visitor). App Client utilise la même passerelle avec une autre source. La route de retour de la base vise l’autre interface de Gateway, 172.28.20.254. Aucun client n’a d’interface directement sur le réseau de la base. Ces routes sont préparées : ne les modifiez pas. La commande enregistrée constitue le contrôle de cette étape ; aucun rapport n’est demandé.
Autoriser uniquement le chemin applicatif vers la base
Dans cette étape, vous filtrerez les paquets traversant Gateway. Passez à Gateway. iptables modifie les règles du filtre de paquets du noyau. Une chaîne est une liste ordonnée : la première décision correspondante s’applique. FORWARD traite le trafic traversant ce nœud, tandis que INPUT concerne le trafic destiné au nœud lui-même. L’environnement relie FORWARD à la chaîne du laboratoire LAB_FORWARD ; sa règle permissive initiale permet l’exposition.
Consultez les règles. -n conserve les adresses numériques, -v affiche les compteurs et -L liste la chaîne :
iptables -nvL LAB_FORWARD
Modifiez uniquement LAB_FORWARD dans ce terminal. Conservez règles de l’hôte, routes, identifiants et services. Les règles prennent effet immédiatement et durent pendant cette session. Quatre décisions remplaceront la règle permissive. La chaîne parente préparée refuse tout paquet sans correspondance.
-F vide cette chaîne. Les services transférés seront brièvement bloqués pendant l’ajout des règles ; le terminal et l’interface Order Page restent accessibles. Après une faute de frappe, repartez de ce vidage et ressaisissez les quatre règles.
iptables -F LAB_FORWARD
Les réponses doivent aussi revenir. Une réponse de la base va vers App Client : sa destination n’est plus le port de la base. -A ajoute à la fin, -m conntrack utilise le suivi des connexions et --ctstate ESTABLISHED,RELATED identifie les réponses ou le trafic lié à des connexions déjà permises. -j ACCEPT autorise le paquet correspondant :
iptables -A LAB_FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Autorisez les nouvelles connexions de l’application. -s sélectionne la source, -d la destination, -p tcp TCP et --dport le port de destination. Une adresse seule désigne exactement ce nœud :
iptables -A LAB_FORWARD -s 172.28.10.20 -d 172.28.20.10 -p tcp --dport 5432 -j ACCEPT
Placez le refus général de la base après l’exception applicative. Sans -s, il couvre les autres sources. REJECT --reject-with tcp-reset refuse explicitement la connexion TCP au lieu d’attendre une expiration :
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 5432 -j REJECT --reject-with tcp-reset
Préservez enfin le port public distinct pour les deux clients. L’autoriser n’expose pas le port de la base :
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 8001 -j ACCEPT
Listez le résultat :
iptables -nvL LAB_FORWARD
L’ordre est : réponses, accès applicatif à la base, refus général de la base, puis état public. Un refus avant l’exception bloquerait aussi la boutique. Les compteurs augmentent seulement quand un trafic correspondant traverse réellement Gateway ; la présence d’une règle ne suffit pas. Actualisez Order Page : App Client doit afficher OPEN, Visitor BLOCKED, l’état PUBLIC STATUS OK, et les commandes doivent toujours charger.
Retester la sécurité et la boutique
Dans cette étape, vous confirmerez la matrice des connexions et créerez une autre vraie commande. Passez à App Client et ouvrez une nouvelle connexion :
tcp-probe 172.28.20.10 5432
Attendez TCP OPEN. Relisez avec le même identifiant :
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Passez à Visitor :
tcp-probe 172.28.20.10 5432
Attendez TCP BLOCKED avec une explication de refus de connexion. Cette commande renvoie volontairement un échec. Un abandon silencieux produit plutôt une expiration ; les deux empêchent une nouvelle connexion, mais l’expiration seule n’en identifie pas la cause. Si App Client échoue aussi, contrôlez l’ordre et le traitement des réponses dans Gateway.
curl récupère une ressource web. --max-time 4 limite la requête complète à quatre secondes ; -f considère les erreurs HTTP comme des échecs, -s masque la progression et -S conserve les erreurs. Depuis Visitor, testez l’autre service public :
curl --max-time 4 -fsS http://172.28.20.10:8001/status.txt
Attendez PUBLIC STATUS OK. Bloquer tous les paquets transférés violerait cette exigence, même en fermant le chemin vers la base.
Ouvrez Order Page, créez practice-2 et confirmez la présence des deux commandes d’exercice. Cela utilise réellement la connexion de l’application après réparation. Actualisez encore : Visitor doit rester bloqué. Les compteurs aident au diagnostic, mais une commande réussie et les tests d’autorisation/refus constituent la preuve réelle. Ne stoppez pas PostgreSQL et ne changez pas son mot de passe pour faire passer un échec de requête du visiteur pour une réparation.
Résumé
Vous avez suivi une commande jusque dans PostgreSQL, comparé deux clients routés, appliqué des règles de transfert ordonnées et testé sécurité et disponibilité. Une erreur de mot de passe diffère d’une connexion TCP bloquée. Préservez l’application légitime et les services distincts en fermant un chemin exposé.
