Protéger la base de rapports

Introduction

Une application de rapports lit des commandes synthétiques dans une autre base PostgreSQL. External Probe peut aussi l’atteindre actuellement. La page de rapports doit rester disponible pendant la fermeture de ce chemin indésirable.

Ce défi démarre dans un environnement indépendant. Appliquez les tests de connexion, l’inspection des routes et les règles ordonnées de Gateway du laboratoire à de nouvelles adresses et à un autre port.

Protéger la base de rapports

Situation actuelle

Ouvrez Order Page pour voir commandes, carte réseau et observations en direct. Report Client est le nœud applicatif légitime ; External Probe représente un client indésirable. Gateway contrôle leur trafic transféré. Ces conteneurs ont des espaces de noms réseau distincts et partagent le noyau d’une instance.

Périmètre

Modifiez uniquement la chaîne LAB_FORWARD du Gateway en cours d’exécution. Ne changez ni routes, adresses, identifiants, configuration de la base, code applicatif ou services. La chaîne parente FORWARD est déjà reliée et refuse les paquets sans correspondance. Les règles doivent durer cette session ; la persistance après redémarrage est hors périmètre.

Source	Destination	Résultat exigé
Report Client `172.29.10.40`	Base `172.29.20.15:5544`	Autoriser de vraies lectures PostgreSQL
External Probe `172.29.10.50`	Base `172.29.20.15:5544`	Bloquer les nouvelles connexions TCP
Les deux clients	État public `172.29.20.15:8001`	Autoriser

Le prochain saut des clients est 172.29.10.254 ; la base répond via 172.29.20.254. Les paramètres fixes sont l’utilisateur shopapp, le mot de passe training-only, la base shop et la table orders, avec les colonnes id et item. tcp-probe ADDRESS PORT, ip route get ADDRESS, psql et curl s’utilisent comme dans le laboratoire. L’application emploie le même identifiant.

Référence : -A ajoute à la fin, -s sélectionne la source, -d la destination, -p tcp le protocole, --dport le port de destination et -j l’action. -F CHAIN vide uniquement cette chaîne ; -nvL CHAIN affiche règles numériques et compteurs. Les réponses nécessitent le suivi des connexions. Un refus large avant une autorisation précise l’emporte.

Votre objectif

La base de rapports doit accepter le client légitime et refuser les nouvelles connexions TCP d’External Probe, en conservant la page de rapports et le service public fonctionnels. La base et son identifiant doivent rester inchangés.

Critères de réussite

Report Client lit de vraies lignes via PostgreSQL sur 5544, avec l’identifiant fixe.
External Probe ne peut pas établir une nouvelle connexion TCP à ce port.
External Probe reçoit toujours PUBLIC STATUS OK sur 8001 ; les commandes du rapport chargent toujours.
La commande practice-2, article Green tea, existe et a été créée via Order Page après la modification. Aucun rapport ni capture n’est demandé.

Indices

Quelle source utiliser dans l’exception ?

Utilisez le client qui ouvre réellement la connexion à la base, pas l’adresse du navigateur ou de Gateway. La carte et ip route get permettent de l’identifier.

Pourquoi le trafic légitime s’est-il arrêté ?

Comparez la première règle correspondante, son port de destination et le traitement des réponses. Le port diffère du laboratoire. Vous pouvez reconstruire la chaîne après une faute de frappe.

Une erreur d’authentification prouve-t-elle le confinement ?

Un refus de mot de passe signifie que PostgreSQL était accessible. Testez le chemin interdit avec TCP et le chemin autorisé par une vraie requête. Testez l’état public séparément.

Résumé

Vous avez transposé le filtrage à un autre client et un autre port, en préservant les rapports appuyés sur la base et l’état public. Les tests fonctionnels d’autorisation et de refus établissent le résultat ; une passerelle permissive, une base arrêtée ou un mauvais mot de passe ne suffisent pas.