Intégrer avec le Serveur d'origine

Cette page couvre deux étapes d’intégration :

1. Intégration directe — La périphérie CDN transfère directement vers le serveur d’origine (tests de référence)
2. Insertion F5 XC — L’équilibreur de charge HTTP F5 XC est inséré entre le CDN et l’origine (démonstration de sécurité)

Commencez par l’intégration directe pour établir la référence, puis insérez F5 XC lorsque vous êtes prêt.

Référence du Serveur d’origine

Le composant de laboratoire origin-server fournit des applications web vulnérables pour les tests de sécurité.

Propriété	Valeur
Documentation	f5-sales-demo.github.io/origin-server
Référentiel	github.com/f5-sales-demo/origin-server
Port par défaut	80
Vérification de l’état	GET /health

Applications disponibles

Récupérez le catalogue d’applications actuel depuis le manifeste publié du serveur d’origine :

MANIFEST_URL=$(curl -sf https://api.github.com/repos/f5-sales-demo/origin-server/releases/latest \
  | python3 -c "import sys,json; assets=json.load(sys.stdin).get('assets',[]); print(next((a['browser_download_url'] for a in assets if a['name']=='manifest.json'),''))")
curl -sf "$MANIFEST_URL" | python3 -m json.tool

Si aucune version n’existe encore, utilisez directement la source du référentiel :

curl -sf https://raw.githubusercontent.com/f5-sales-demo/origin-server/main/manifest.json | python3 -m json.tool

Le manifeste répertorie tous les chemins d’application, les vérifications d’état, les images de conteneurs et les correspondances de fonctionnalités de démonstration.

Chemins d’application

Chemin	Application	Fonctionnalités de démonstration
/	Page d’accueil	—
/health	Vérification de l’état	—
/juice-shop/	OWASP Juice Shop	Pare-feu applicatif (WAF), Défense Bot, Sécurité des API
/dvwa/	DVWA	Pare-feu applicatif (WAF), Défense Bot
/vampi/	VAmPI	Sécurité des API
/httpbin/	httpbin	Diagnostics
/whoami/	whoami	Vérification des en-têtes
/csd-demo/	CSD Demo	Défense côté client

Étape 1 : Intégration directe (référence)

┌──────────┐     ┌──────────────────────┐     ┌─────────────────────┐
│  Client   │────▶│  CDN Edge (NGINX)    │────▶│  Origin Server      │
│           │     │  20.65.90.112        │     │  20.12.78.159       │
└──────────┘     │  67+ CDN headers     │     │  Juice Shop, DVWA,  │
                 │  Disk cache           │     │  VAmPI, httpbin,    │
                 └──────────────────────┘     │  whoami, CSD Demo   │
                                              └─────────────────────┘

Configurer l’origine

Définissez l’adresse IP du serveur d’origine dans la configuration NGINX de la périphérie CDN :

ssh azureuser@<CDN_EDGE_IP>
sudo sed -i 's|proxy_pass .*;|proxy_pass http://<ORIGIN_IP>;|' /etc/nginx/conf.d/cdn-edge.conf
sudo rm -rf /var/cache/nginx/cdn/*
sudo nginx -t && sudo systemctl reload nginx

Ou définissez-la lors du déploiement Terraform via terraform.tfvars :

origin_server = "http://<ORIGIN_IP>"

Vérifier toutes les applications

Testez chaque application d’origine via le CDN :

CDN=<CDN_EDGE_IP>

# Vérification de l'état (CDN local)
curl -sf "http://$CDN/health" | python3 -m json.tool

# Page d'accueil
curl -sf -o /dev/null -w "/ : HTTP %{http_code}\n" "http://$CDN/"

# Juice Shop
curl -sf -o /dev/null -w "/juice-shop/ : HTTP %{http_code}\n" "http://$CDN/juice-shop/"

# DVWA (suit la redirection vers la page de connexion)
curl -sf -o /dev/null -w "/dvwa/ : HTTP %{http_code}\n" -L "http://$CDN/dvwa/"

# API VAmPI
curl -sf "http://$CDN/vampi/users/v1" | python3 -m json.tool | head -5

# En-têtes httpbin (affiche les en-têtes CDN en JSON)
curl -sf "http://$CDN/httpbin/headers" | python3 -m json.tool | head -10

# whoami (affiche TOUS les en-têtes reçus par l'origine)
curl -sf "http://$CDN/whoami/"

# CSD Demo
curl -sf -o /dev/null -w "/csd-demo/ : HTTP %{http_code}\n" "http://$CDN/csd-demo/"

Tous les chemins doivent retourner HTTP 200 (DVWA retourne 302 puis 200 après suivi de redirection).

Vérifier les en-têtes CDN à l’origine

Le point de terminaison /whoami/ affiche chaque en-tête reçu par l’origine. Lorsqu’il est accédé via le CDN, il affiche les 67+ en-têtes fournisseur :

curl -sf "http://$CDN/whoami/"

Vérifiez que ces en-têtes clés sont présents :

Fournisseur	En-tête	Valeur attendue
Standard	X-Forwarded-For	<your_ip>, <cdn_edge_ip>
Akamai	True-Client-Ip	<your_ip>
Cloudflare	Cf-Connecting-Ip	<your_ip>
CloudFront	Cloudfront-Viewer-Country	US
Fastly	Fastly-Client-Ip	<your_ip>
Azure FD	X-Azure-Clientip	<your_ip>

Corrélation des journaux

Comparez les journaux d’accès sur les deux serveurs pour vérifier le flux de trafic :

# Journal de la périphérie CDN — affiche votre IP client comme source
ssh azureuser@<CDN_EDGE_IP> "sudo tail -5 /var/log/nginx/access.log"

# Journal de l'origine — affiche l'IP de la périphérie CDN comme source
ssh azureuser@<ORIGIN_IP> "sudo tail -5 /var/log/nginx/access.log"

Le journal de l’origine doit afficher l’IP de la périphérie CDN comme client connecté, tandis que l’IP réelle du client est transmise dans X-Forwarded-For et les en-têtes spécifiques aux fournisseurs.

Comportement du cache

# Première requête — MISS (récupérée depuis l'origine)
curl -s -I "http://$CDN/whoami/" | grep X-Cache-Status

# Deuxième requête — HIT (servie depuis le cache CDN)
curl -s -I "http://$CDN/whoami/" | grep X-Cache-Status

Étape 2 : Insertion F5 XC (démonstration de sécurité)

Après les tests de référence, insérez un équilibreur de charge HTTP F5 XC entre le CDN et l’origine :

┌──────────┐     ┌────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│  Client   │────▶│  CDN Edge      │────▶│  F5 XC HTTP LB   │────▶│  Origin Server  │
│           │     │  (NGINX)       │     │  WAF + Bot + API  │     │                 │
└──────────┘     └────────────────┘     └──────────────────┘     └─────────────────┘

1. Créez l’équilibreur de charge HTTP F5 XC avec le serveur d’origine dans son pool d’origine
2. Mettez à jour la périphérie CDN pour pointer vers le VIP F5 XC au lieu de l’origine directement :

ssh azureuser@<CDN_EDGE_IP>
sudo sed -i 's|proxy_pass .*;|proxy_pass https://<F5XC_LB_VIP>;|' /etc/nginx/conf.d/cdn-edge.conf
sudo rm -rf /var/cache/nginx/cdn/*
sudo nginx -t && sudo systemctl reload nginx

3. Vérifiez l’application du Pare-feu applicatif (WAF) à travers la chaîne complète :

# Injection SQL via CDN → le Pare-feu applicatif (WAF) F5 XC doit bloquer
curl -I "http://$CDN/dvwa/vulnerabilities/sqli/?id=%27+OR+1%3D1--"

# La requête normale doit passer
curl -sf -o /dev/null -w "%{http_code}" "http://$CDN/juice-shop/"

4. Configurez l’en-tête IP client de confiance dans F5 XC pour lire l’IP réelle du client depuis les en-têtes CDN (par exemple, True-Client-IP pour la simulation Akamai, CF-Connecting-IP pour la simulation Cloudflare)

Architecture multi-composants

Composant	Référentiel	Objectif
CDN Edge (celui-ci)	cdn-simulator	Mise en cache, en-têtes fournisseur
Serveur d’origine	origin-server	Applications web vulnérables
Configuration F5 XC	Divers (waf, api-protection, bot-*, etc.)	Politiques de sécurité

Chaque composant publie de la documentation que les assistants IA lisent pour déployer l’infrastructure. Le serveur d’origine publie un manifeste de points de terminaison en tant qu’artefact de version GitHub répertoriant tous les chemins d’application et les vérifications d’état.