Chapitre 4.1 - Architecture de Pare-feu, Segmentation & Zero Trust

Module 4 : Ingénierie Défensive & Durcissement Ce module change entièrement de perspective - de l'attaquant au défenseur. Chaque technique du Module 3 possède une contre-mesure structurelle. Ce chapitre couvre les contrôles fondamentaux.

Table des Matières

Générations de Pare-feu & Modèles de Traitement
Inspection Avec État - Suivi de Connexion & Tables d'État
Pare-feu de Nouvelle Génération - Connaissance Applicative & Inspection Profonde
iptables & nftables - Filtrage de Paquets Linux en Profondeur
Segmentation Réseau - Zones, Conception DMZ & VLANs
Micro-Segmentation & Contrôle du Trafic Est-Ouest
Architecture Zero Trust - Principes, Composants & Mise en Oeuvre
Audit des Règles de Pare-feu & Détection des Mauvaises Configurations
Métriques Défensives & Validation
Correspondance MITRE ATT&CK & Couverture des Contrôles

1. Générations de Pare-feu & Modèles de Traitement

Les pare-feu ont évolué de simples filtres de paquets vers des moteurs d'inspection conscients des applications. Comprendre ce que chaque génération peut et ne peut pas appliquer est essentiel pour concevoir des défenses en couches - aucune génération ne gère seule toutes les classes de menaces.

Évolution de la Technologie de Pare-feu

Génération	Mécanisme Principal	Visibilité	Points Aveugles
Filtre de paquets (L3/L4)	ACL sur IP/port/protocole	Champs d'en-tête uniquement	Tout le contenu ; sans état = contournement par scan ACK
Inspection avec état	Suivi de l'état des connexions	Cycle de vie de la session TCP	Contenu applicatif ; charges utiles chiffrées
Passerelle applicative (proxy)	Proxy protocole complet	Commandes applicatives (FTP, DNS)	Protocoles non proxifiés ; TLS sans inspection
NGFW	DPI + App-ID + User-ID + IPS	Application, utilisateur, contenu	C2 chiffré sans inspection TLS ; zero-days
Cloud-natif / SASE	Identité + contexte + livraison cloud	Utilisateur, appareil, application, comportement	Dépend du déploiement d'agent ; aveugle sur les appareils non gérés

Pipeline de Traitement des Paquets

Comprendre l'ordre dans lequel les règles sont évaluées évite les mauvaises configurations logiques - une règle qui ne peut jamais être atteinte parce qu'une règle plus large la précède est une constatation courante lors des audits :

Interface d'entrée
      │
      ▼
 [ACL d'entrée]          ← Filtre pré-routage (peut bloquer avant la décision de routage)
      │
      ▼
 [Décision de routage]   ← Détermine l'interface de sortie
      │
      ▼
 [Suivi d'état]          ← S'agit-il d'une connexion établie/liée ?
      │
      ├── Établie → chemin rapide (ignore l'inspection approfondie)
      │
      └── Nouvelle → recherche de politique
                    │
                    ▼
             [Correspondance de politique]   ← La première règle correspondante l'emporte (la plupart des pare-feu)
                    │
                    ▼
             [Action : autoriser/refuser/inspecter/journaliser]
                    │
                    ▼
             [ACL de sortie]
                    │
                    ▼
             Interface de sortie

Première correspondance vs meilleure correspondance : La plupart des pare-feu (iptables, Palo Alto, Cisco ASA) utilisent la première correspondance - les règles sont évaluées de haut en bas et la première correspondance termine l'évaluation. Une règle AUTORISER large au-dessus d'une règle REFUSER spécifique rend la règle REFUSER inaccessible. C'est la source de la grande majorité des mauvaises configurations de pare-feu découvertes lors des audits.

2. Inspection Avec État - Suivi de Connexion & Tables d'État

Les pare-feu avec état suivent les sessions TCP/UDP/ICMP dans une table de suivi de connexions (conntrack). Chaque entrée enregistre le 5-tuple, l'état, le délai d'expiration et les transitions suivantes attendues. Cela permet au pare-feu de :

Autoriser le trafic retour pour les connexions sortantes établies sans règles explicites
Détecter les paquets hors état (TCP ACK sans SYN correspondant = scan potentiel)
Appliquer le comportement protocolaire (canal de données FTP, erreurs ICMP liées)

Suivi de Connexions Linux

# Afficher la table de suivi de connexions
conntrack -L                          # Lister toutes les connexions suivies
conntrack -L --proto tcp              # TCP uniquement
conntrack -L --state ESTABLISHED      # Uniquement les sessions établies

# Surveillance d'événements en temps réel (nouvelles connexions, sessions détruites)
conntrack -E                          # Mode événement - observer en temps réel
conntrack -E -e NEW                   # Uniquement les événements de nouvelles connexions
conntrack -E -e DESTROY               # Uniquement les connexions détruites

# Exemple de sortie conntrack :
# tcp  6  431999  ESTABLISHED  src=10.0.1.5 dst=203.0.113.1 sport=54231 dport=443
#                               src=203.0.113.1 dst=10.0.1.5 sport=443 dport=54231
#                               [ASSURED] mark=0 use=1
# Champs : proto  délai  état  tuple_original  tuple_réponse  drapeaux

# Statistiques de la table conntrack
conntrack -S                          # Stats par CPU
# Surveiller : insert_failed (table pleine), drop (collision de hachage)

# Définir la taille de la table conntrack (pour les environnements à fort trafic)
sysctl net.netfilter.nf_conntrack_max                   # Maximum actuel
sysctl -w net.netfilter.nf_conntrack_max=1048576        # Définir à 1M entrées
echo "net.netfilter.nf_conntrack_max = 1048576" >> /etc/sysctl.conf

# Délais d'expiration conntrack - réduire pour la résilience DDoS/scan
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300   # 5 min (défaut : 5 jours !)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent=10       # Délai SYN 10s
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=15      # TIME_WAIT

# Vider toute la table conntrack (utiliser avec précaution - supprime toutes les sessions suivies)
conntrack -F

Suivi d'État TCP et Techniques de Contournement

# Règle avec état : autoriser uniquement NEW et ESTABLISHED en entrée, bloquer INVALID
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP   # Abandonner l'état invalide
iptables -A INPUT -j DROP                                   # Refus par défaut

# Pourquoi INVALID est important :
# Les paquets sans entrée conntrack correspondante et sans drapeau SYN = INVALID
# Cela capture : scans ACK, RST hors fenêtre, attaques par paquets fragmentés
# Sans cette règle, certains scanners de ports contournent l'inspection avec état

# Détecter les attaques d'épuisement de table conntrack (flood SYN remplit la table)
watch -n 1 'conntrack -S | grep insert_failed'
# insert_failed croissant = table pleine = nouvelles connexions abandonnées = DoS effectif

3. Pare-feu de Nouvelle Génération - Connaissance Applicative & Inspection Profonde

Les NGFW opèrent au niveau L7, identifiant les applications par signatures de contenu plutôt que par numéros de port. Cela est important car les attaquants font couramment tourner des services sur des ports non standard (SSH sur 443, C2 via HTTP sur 8080) ou font transiter des protocoles dans des protocoles autorisés (tunneling DNS, tunneling HTTP sur le port 80).

Identification d'Application

Les moteurs App-ID des NGFW fonctionnent par :

Décodage protocolaire - analyser le protocole applicatif pour l'identifier de façon définitive
Correspondance de patterns - faire correspondre la charge utile aux signatures d'application
Analyse comportementale - classifier selon le comportement du flux (tailles de paquets, timing, ratios directionnels)
Gestion des applications inconnues - classifier par port si le contenu est non reconnaissable (repli risqué)

Palo Alto Networks - Concepts de Politique

Palo Alto est le NGFW d'entreprise dominant. Son modèle de politique organise les règles par paires de zones de sécurité plutôt que par plages IP seules :

# PAN-OS CLI - afficher les règles de politique de sécurité
show security policy-rule all

# Afficher l'utilisation des applications sur une règle de politique
show running security-policy

# Vérifier l'identification des applications sur les sessions actives
show session all filter application unknown     # Sessions avec application non identifiée
show session all filter state active            # Toutes les sessions actives
show session id 12345                           # Détail pour une session spécifique

# Remplacement d'application - forcer la classification du trafic (utiliser avec parcimonie)
# Force PAN à ignorer App-ID et classifier par port uniquement
# Utile pour les applications internes personnalisées qu'App-ID ne peut pas identifier

# Vérifier quelles applications sont autorisées par une règle
show security policy-rule "Allow-Internet" application

# Journaux de menaces - menaces bloquées par IPS/AV
show log threat direction equal forward | match "critical\\\\|high"

# Journaux de trafic avec détail d'application
show log traffic application equal unknown start-time equal last-5-minutes

Politique d'Inspection SSL/TLS

# PAN-OS : vérifier que l'inspection SSL est active
show running ssl-decrypt

# Points de configuration clés :
# - Cert Forward Trust : cert CA d'entreprise chargé sur le pare-feu, approuvé par les terminaux
# - Cert Forward Untrust : CA différente pour les sites avec certs non approuvés (les utilisateurs voient un avertissement)
# - Profil de déchiffrement : contrôle la version TLS, les exigences de chiffrement, la validation de certificat
# - Exclusions : banque, santé, comptes personnels (exigences légales/confidentialité)

# Vérifier ce qui est exclu du déchiffrement
show decryption exclude-cache

# Équivalent Linux/open-source : Squid avec ssl-bump
# Vérifier quelles connexions Squid déchiffre vs laisse passer :
tail -f /var/log/squid/access.log | grep "CONNECT\\\\|TUNNEL"
# CONNECT = Squid a intercepté et déchiffré
# TUNNEL = Squid a laissé passer sans inspection (exclu)

4. iptables & nftables - Filtrage de Paquets Linux en Profondeur

iptables - Tables, Chaînes & Règles

iptables organise les règles en tables (filter, nat, mangle, raw) et en chaînes (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING). Pour les pare-feu, la table filter est primaire.

# Afficher toutes les règles avec numéros de ligne et compteurs de paquets/octets
iptables -L -n -v --line-numbers           # Table filter (par défaut)
iptables -t nat -L -n -v --line-numbers    # Table NAT
iptables -t mangle -L -n -v               # Table Mangle

# Sauvegarder et restaurer les règles (persistant après redémarrage)
iptables-save > /etc/iptables/rules.v4     # Sauvegarder les règles actuelles
iptables-restore < /etc/iptables/rules.v4  # Restaurer les règles sauvegardées

# Jeu de règles de durcissement pour serveur de production
# ============================================
# Vider les règles existantes
iptables -F
iptables -X
iptables -t nat -F
iptables -t mangle -F

# Politiques par défaut - tout refuser, rien autoriser
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT                  # Autoriser le trafic sortant (ajuster selon la politique)

# Autoriser la boucle locale (requis pour les services locaux)
iptables -A INPUT -i lo -j ACCEPT

# Autoriser le trafic retour établi/lié
iptables -A INPUT -m conntrack \\
  --ctstate ESTABLISHED,RELATED -j ACCEPT

# Abandonner les paquets en état invalide (scans ACK, hors état)
iptables -A INPUT -m conntrack \\
  --ctstate INVALID -j DROP

# Limiter le débit des nouvelles connexions SSH (protection contre le brute-force)
iptables -A INPUT -p tcp --dport 22 \\
  -m conntrack --ctstate NEW \\
  -m recent --set --name SSH_BRUTE        # Suivre les sources de nouvelles connexions SSH

iptables -A INPUT -p tcp --dport 22 \\
  -m conntrack --ctstate NEW \\
  -m recent --update --name SSH_BRUTE \\
  --seconds 60 \\\\                          # Dans les 60 secondes
  --hitcount 4 \\\\                          # Plus de 4 tentatives
  -j DROP                                 # Abandonner la connexion

iptables -A INPUT -p tcp --dport 22 \\
  -m conntrack --ctstate NEW -j ACCEPT   # Autoriser SSH si sous le seuil

# Autoriser HTTP/HTTPS pour le serveur web
iptables -A INPUT -p tcp \\
  --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p tcp \\
  --dport 443 -m conntrack --ctstate NEW -j ACCEPT

# Autoriser le ping ICMP (contrôlé - limité en débit)
iptables -A INPUT -p icmp --icmp-type echo-request \\
  -m limit --limit 5/second \\\\            # Max 5 pings/seconde
  -j ACCEPT

# Journaliser et abandonner tout le reste
iptables -A INPUT -m limit \\
  --limit 10/minute \\\\                    # Ne pas inonder syslog
  -j LOG --log-prefix "IPT_DROP: " --log-level 4
iptables -A INPUT -j DROP

nftables - Remplacement Moderne

nftables est le successeur du noyau Linux à iptables, offrant de meilleures performances, des mises à jour de règles atomiques et une syntaxe plus claire. La plupart des distributions livrent désormais nftables par défaut :

# Afficher le jeu de règles actuel
nft list ruleset

# Équivalent nftables du jeu de règles iptables ci-dessus :
cat > /etc/nftables.conf << 'EOF'
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    # Ensembles de suivi de connexions pour la limitation de débit
    set ssh_brute {
        type ipv4_addr
        flags dynamic, timeout
        timeout 60s
    }

    chain input {
        type filter hook input priority 0
        policy drop                       # Refus par défaut

        iif lo accept                     # Autoriser la boucle locale
        ct state established,related accept   # Autoriser le trafic retour
        ct state invalid drop             # Abandonner l'état invalide

        # Limitation de débit SSH utilisant les ensembles nftables
        tcp dport 22 ct state new \\
            add @ssh_brute { ip saddr limit rate over 4/minute } \\
            drop                          # Abandonner si > 4 nouveaux SSH/min depuis la même IP

        tcp dport 22 ct state new accept  # Autoriser SSH sous le seuil

        # Trafic web
        tcp dport { 80, 443 } ct state new accept

        # Limite de débit ICMP
        ip protocol icmp icmp type echo-request \\
            limit rate 5/second accept

        # Journalisation
        limit rate 10/minute log prefix "NFT_DROP: " level warn
    }

    chain forward {
        type filter hook forward priority 0
        policy drop                       # Refus du transfert par défaut
    }

    chain output {
        type filter hook output priority 0
        policy accept                     # Autoriser tout le trafic sortant
    }
}
EOF

# Appliquer le jeu de règles
nft -f /etc/nftables.conf

# Mise à jour atomique de règle (ajouter une règle sans perturber les connexions existantes)
nft add rule inet filter input \\
  tcp dport 8080 ct state new accept

# Lister les règles avec handles (nécessaire pour la suppression)
nft list chain inet filter input -a

# Supprimer une règle spécifique par handle
nft delete rule inet filter input handle 15

# Activer le service nftables (persiste après redémarrage)
systemctl enable nftables
systemctl start nftables

5. Segmentation Réseau - Zones, Conception DMZ & VLANs

Architecture de Zones de Sécurité

Le principe fondamental de la segmentation : un hôte compromis dans une zone ne doit pas avoir automatiquement accès aux hôtes d'une autre zone. Chaque technique de mouvement latéral du Chapitre 3.3 repose sur un accès réseau plat - la segmentation le contrecarre structurellement.

Modèle de zone standard :

Zone	Hôtes	Niveau de Confiance	Politique de Pare-feu
Internet	Tout ce qui est externe	Non approuvé	Refuser tout le trafic entrant par défaut
DMZ	Serveurs web, messagerie, DNS, VPN	Semi-approuvé	Autoriser le trafic entrant spécifique depuis Internet ; sortant restreint
Interne	Postes de travail, imprimantes	Confiance moyenne	Autoriser le trafic sortant vers Internet via proxy ; pas d'entrée Internet directe
Serveur	Applications internes, bases de données	Haute confiance	Accès strict depuis des sous-réseaux internes spécifiques uniquement
OT/ICS	Contrôle industriel	Critique	Isolation physique ou quasi-isolation ; pas d'accès Internet
Management	Pare-feu, commutateurs, serveurs (OOB)	Plus haute	Accessible uniquement depuis un hôte passerelle ; MFA requis

Conception DMZ

# Exemple : pare-feu DMZ à trois interfaces
# eth0 = Internet (non approuvé)
# eth1 = DMZ (serveurs web : 192.168.10.0/24)
# eth2 = LAN interne (10.0.0.0/24)

# Internet vers DMZ : autoriser HTTP/HTTPS vers les serveurs web uniquement
iptables -A FORWARD -i eth0 -o eth1 \\
  -p tcp --dport 443 \\
  -d 192.168.10.0/24 \\
  -m conntrack --ctstate NEW -j ACCEPT

iptables -A FORWARD -i eth0 -o eth1 \\
  -p tcp --dport 80 \\
  -d 192.168.10.0/24 \\
  -m conntrack --ctstate NEW -j ACCEPT

# Internet vers Interne : refuser TOUT (aucune exception)
iptables -A FORWARD -i eth0 -o eth2 -j DROP

# DMZ vers Interne : refuser TOUT (la compromission d'un serveur web ne signifie pas l'accès au LAN)
iptables -A FORWARD -i eth1 -o eth2 -j DROP

# DMZ vers Internet : autoriser uniquement le trafic sortant spécifique (mises à jour, appels API)
iptables -A FORWARD -i eth1 -o eth0 \\
  -p tcp --dport 443 \\
  -s 192.168.10.0/24 \\
  -m conntrack --ctstate NEW -j ACCEPT

# Interne vers DMZ : autoriser HTTP/HTTPS vers les serveurs web (accès interne)
iptables -A FORWARD -i eth2 -o eth1 \\
  -p tcp -m multiport --dports 80,443 \\
  -m conntrack --ctstate NEW -j ACCEPT

# Interne vers Internet : autoriser via proxy uniquement (proxy transparent sur le port 3128)
# Forcer tout le trafic web sortant à travers Squid
iptables -t nat -A PREROUTING -i eth2 \\
  -p tcp --dport 80 \\
  -j REDIRECT --to-port 3128        # Rediriger HTTP vers le proxy transparent Squid

# Autoriser le trafic retour établi dans toutes les directions
iptables -A FORWARD -m conntrack \\
  --ctstate ESTABLISHED,RELATED -j ACCEPT

# Journaliser les violations inter-zones
iptables -A FORWARD -j LOG \\
  --log-prefix "FW_FORWARD_DENY: " --log-level 4
iptables -A FORWARD -j DROP

Configuration VLAN pour la Segmentation

# Linux : créer des sous-interfaces VLAN (étiquetage 802.1Q)
# Requis : modprobe 8021q

modprobe 8021q
echo "8021q" >> /etc/modules

# Créer des interfaces VLAN
ip link add link eth0 name eth0.10 type vlan id 10   # VLAN 10 = DMZ
ip link add link eth0 name eth0.20 type vlan id 20   # VLAN 20 = Interne
ip link add link eth0 name eth0.30 type vlan id 30   # VLAN 30 = Serveur

# Assigner les IPs
ip addr add 192.168.10.1/24 dev eth0.10
ip addr add 10.0.20.1/24 dev eth0.20
ip addr add 10.0.30.1/24 dev eth0.30

# Activer les interfaces
ip link set eth0.10 up
ip link set eth0.20 up
ip link set eth0.30 up

# Commutateur Cisco IOS - configuration VLAN (pour référence)
# vlan 10
#   name DMZ
# vlan 20
#   name Internal
# interface GigabitEthernet0/1
#   switchport mode trunk
#   switchport trunk allowed vlan 10,20,30
# interface GigabitEthernet0/2
#   switchport mode access
#   switchport access vlan 10

# Vérifier la séparation VLAN - le trafic sur VLAN 10 ne doit pas atteindre VLAN 20
# sans passer par le pare-feu/routeur
ping -I eth0.10 10.0.20.5           # Doit échouer si correctement segmenté

6. Micro-Segmentation & Contrôle du Trafic Est-Ouest

La segmentation traditionnelle contrôle le trafic nord-sud (entre les zones). La micro-segmentation contrôle le trafic est-ouest (entre les hôtes au sein d'une même zone) - le chemin d'attaque exploité par le mouvement latéral.

Le Problème du Mouvement Latéral

Dans un réseau plat (sans micro-segmentation), un poste de travail compromis sur le VLAN interne peut atteindre chaque autre poste - permettant la propagation de vers, le pass-the-hash et le relais SMB sur tout le segment. La micro-segmentation limite le rayon d'impact.

Application du Pare-feu Basé sur l'Hôte

# Windows : appliquer le pare-feu Windows via GPO
# Configuration Ordinateur -> Paramètres Windows -> Paramètres de sécurité ->
# Pare-feu Windows Defender avec sécurité avancée
# Bloquer SMB entrant entre les postes de travail :

# PowerShell : bloquer SMB entrant depuis les sous-réseaux non-serveur
New-NetFirewallRule \\
  -DisplayName "Block Lateral SMB" \\
  -Direction Inbound \\
  -Protocol TCP \\
  -LocalPort 445 \\
  -RemoteAddress "10.0.0.0/24" \\\\    # Bloquer depuis le sous-réseau de postes vers les postes
  -Action Block \\
  -Profile Domain

# Autoriser SMB uniquement depuis le sous-réseau de gestion IT
New-NetFirewallRule \\
  -DisplayName "Allow SMB from IT" \\
  -Direction Inbound \\
  -Protocol TCP \\
  -LocalPort 445 \\
  -RemoteAddress "10.0.100.0/24" \\\\  # Sous-réseau de gestion IT uniquement
  -Action Allow \\
  -Profile Domain

# Linux : restreindre l'accès latéral entre les serveurs
# Autoriser uniquement des IPs sources spécifiques à atteindre un service
nft add rule inet filter input \\
  ip saddr != 10.0.30.0/24 \\\\        # Pas depuis le sous-réseau Serveur
  tcp dport 5432 drop               # Bloquer PostgreSQL depuis les hôtes non-serveur

Périmètre Défini par Logiciel avec eBPF/Cilium

Pour les environnements Kubernetes et cloud-natifs, Cilium utilise eBPF pour appliquer la politique réseau au niveau du noyau sans impact sur les performances :

# Politique réseau Cilium - autoriser uniquement des pods spécifiques à atteindre la base de données
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: db-access-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: postgres                   # La politique s'applique aux pods postgres
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-server           # Seuls les pods api-server peuvent se connecter
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP
  egress:
    - toFQDNs:                        # Autoriser uniquement la résolution DNS
        - matchPattern: "*.internal"

# Appliquer la politique
kubectl apply -f db-access-policy.yaml

# Vérifier que la politique est appliquée
cilium policy get
cilium endpoint list                  # Afficher le statut de politique par pod

# Tester l'application de la politique
kubectl exec -it test-pod -- nc -zv postgres-svc 5432
# Doit réussir depuis le pod api-server, échouer pour tous les autres

7. Architecture Zero Trust - Principes, Composants & Mise en Oeuvre

Principes Zero Trust

Zero Trust rejette le modèle de sécurité périmétrique ("approuvé à l'intérieur, non approuvé à l'extérieur") car :

Le mouvement latéral est trivial une fois le périmètre franchi (démontré dans le Module 3)
Le travail à distance, le cloud et le BYOD ont dissous le périmètre
Les menaces internes contournent entièrement les contrôles périmètraux

Principes fondamentaux (NIST SP 800-207) :

Toutes les ressources sont accessibles via des canaux sécurisés et authentifiés - l'emplacement (IP, VLAN, connecté via VPN) n'est pas un signal de confiance implicite
L'accès est accordé par session et par ressource - pas d'accès larges et persistants
La politique d'accès intègre tout le contexte disponible - identité utilisateur, santé de l'appareil, emplacement, heure, comportement de la requête
Le réseau est supposé hostile - le trafic est-ouest est inspecté, pas approuvé

Composants Zero Trust

+--------------------------------------------------------------+
|                    Plan de Contrôle                          |
|  +-------------------+    +------------------+              |
|  | Moteur de politique|<---|  Fournisseur      | (Okta, AAD) |
|  | (Point de décision |    |  d'identité       |             |
|  |  d'accès)          |    |  Confiance device | (Intune, MDM)|
|  +--------+----------+    |  Intel Menaces    |(CrowdStrike) |
|           | Décision de politique              +------------------+              |
+-----------+--------------------------------------------------+
            |
+-----------v--------------------------------------------------+
|                    Plan de Données                           |
|  +------------------------------------------------------+   |
|  |  Point d'Application de Politique (PEP)              |   |
|  |  - Proxy inverse / passerelle API                    |   |
|  |  - Contrôle d'accès réseau                           |   |
|  |  - Agent de terminal                                 |   |
|  +------------------------------------------------------+   |
|           ^                    v                             |
|       Sujet                 Ressource                        |
|    (Utilisateur + Appareil)  (App / Données / Service)       |
+--------------------------------------------------------------+

Mise en Oeuvre de Zero Trust avec nginx + mTLS

Un point de départ pratique : remplacer la confiance réseau implicite par une authentification mTLS explicite au niveau de la couche de service :

# Générer CA et certificats de service
# Étape 1 : Créer la CA
openssl genrsa -out ca.key 4096
openssl req -new -x509 \\
  -key ca.key \\
  -out ca.crt \\
  -days 3650 \\
  -subj "/CN=ZeroTrust-Internal-CA"

# Étape 2 : Générer le certificat serveur pour le service protégé
openssl genrsa -out server.key 2048
openssl req -new -key server.key \\
  -out server.csr \\
  -subj "/CN=api.internal.corp"
openssl x509 -req \\
  -in server.csr \\
  -CA ca.crt -CAkey ca.key \\
  -CAcreateserial \\
  -out server.crt -days 365

# Étape 3 : Générer le certificat client pour chaque service autorisé
openssl genrsa -out client-api.key 2048
openssl req -new -key client-api.key \\
  -out client-api.csr \\
  -subj "/CN=frontend-service/O=api-access"
openssl x509 -req \\
  -in client-api.csr \\
  -CA ca.crt -CAkey ca.key \\
  -CAcreateserial \\
  -out client-api.crt -days 365

# Configuration nginx - exiger un certificat client pour l'accès
# /etc/nginx/sites-available/protected-api
server {
    listen 443 ssl;
    server_name api.internal.corp;

    ssl_certificate     /etc/ssl/server.crt;
    ssl_certificate_key /etc/ssl/server.key;
    ssl_client_certificate /etc/ssl/ca.crt;   # CA qui a signé les certs clients
    ssl_verify_client on;                      # EXIGER le cert client
    ssl_verify_depth 2;

    ssl_protocols TLSv1.3;                     # TLS 1.3 uniquement
    ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    location / {
        # Optionnel : vérifier le CN ou l'OU spécifique du cert client
        if ($ssl_client_s_dn !~ "O=api-access") {
            return 403;                        # Rejeter le mauvais objet de certificat
        }
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Client-CN $ssl_client_s_dn_cn;   # Transmettre l'identité en aval
    }
}

Zero Trust avec le Modèle BeyondCorp / Google IAP

# Implémenter un contrôle d'accès style IAP avec OAuth2 + posture d'appareil
# Utilisant oauth2-proxy comme point d'application :

docker run -d \\
  --name oauth2-proxy \\
  -p 4180:4180 \\
  quay.io/oauth2-proxy/oauth2-proxy:latest \\
    --provider=google \\
    --client-id=YOUR_OAUTH_CLIENT_ID \\
    --client-secret=YOUR_OAUTH_SECRET \\
    --cookie-secret=$(python3 -c 'import secrets; print(secrets.token_hex(16))') \\
    --email-domain=corp.com \\\\          # Autoriser uniquement les adresses @corp.com
    --upstream=http://internal-app:8080 \\
    --redirect-url=https://app.corp.com/oauth2/callback \\
    --skip-provider-button=true        # Redirection automatique vers le fournisseur

# nginx : router tout le trafic via oauth2-proxy
location / {
    auth_request /oauth2/auth;         # Vérifier l'authentification en premier
    error_page 401 = /oauth2/sign_in;  # Rediriger vers la connexion si non authentifié

    auth_request_set $user $upstream_http_x_auth_request_user;
    auth_request_set $email $upstream_http_x_auth_request_email;

    proxy_set_header X-Forwarded-User $user;
    proxy_set_header X-Forwarded-Email $email;
    proxy_pass http://internal-app:8080;
}

location /oauth2/ {
    proxy_pass http://oauth2-proxy:4180;
    proxy_set_header Host $host;
}

8. Audit des Règles de Pare-feu & Détection des Mauvaises Configurations

La prolifération de règles est universelle dans les pare-feu anciens - règles masquées, règles any/any trop permissives et règles obsolètes pour des systèmes mis hors service s'accumulent au fil des années.

# fwaudit - analyse open-source des règles de pare-feu
# Détecte : règles masquées, règles inaccessibles, any/any, journalisation manquante

# Analyser les règles iptables
iptables-save > /tmp/current_rules.txt
fwaudit --iptables /tmp/current_rules.txt \\
  --report /tmp/audit_report.html

# Analyse manuelle : trouver les règles any/any dans iptables
iptables -L -n | grep -E "0\\\\.0\\\\.0\\\\.0/0.*0\\\\.0\\\\.0\\\\.0/0.*ACCEPT"
# Toute règle acceptant depuis n'importe où vers n'importe où = constatation immédiate

# Trouver les règles sans journalisation (règles d'acceptation sans règle de journalisation correspondante)
iptables -L -n -v | grep ACCEPT | \\
  awk '{print $8, $9, $10}' | sort -u  # Afficher les destinations des règles ACCEPT

# Trouver les règles masquées - une règle qui ne peut jamais être atteinte
# Exemple : ACCEPT any -> 10.0.0.0/8 (règle 3) est masquée par ACCEPT any -> 0.0.0.0/0 (règle 1)
# Inspection manuelle requise - iptables ne signale pas cela automatiquement

# Validation de règle basée sur nmap - tester depuis l'extérieur ce qui devrait être bloqué
# Depuis l'interface orientée Internet, tester que les restrictions DMZ tiennent :
nmap -sS \\
  -p 22,3389,445,1433,3306 \\\\          # Ports à haut risque qui devraient être bloqués
  --open \\
  192.168.10.0/24                     # Sous-réseau DMZ
# Tout résultat ouvert = mauvaise configuration du pare-feu

# Tester les contrôles inter-zones depuis l'intérieur
# Depuis le LAN interne, vérifier que la base de données n'est pas directement accessible
nmap -sT -p 5432,3306,1433 \\
  10.0.30.0/24 \\\\                      # Sous-réseau Serveur
  --source-ip 10.0.20.50              # Depuis l'IP du poste de travail

# Cisco ASA : vérifier les règles any/any
show access-list | grep "permit ip any any"
show access-list | grep "permit tcp any any"

# Palo Alto : trouver les règles trop permissives
show security policy-rule all | \\
  match "any.*any.*any.*allow"

9. Métriques Défensives & Validation

Mesurer l'Efficacité de la Segmentation

# Test de segmentation automatisé - balayage Nmap depuis chaque zone
# Doit être exécuté après tout changement de règle de pare-feu

# Créer un script de test de zone
cat > /usr/local/bin/segmentation_test.sh << 'EOF'
#!/bin/bash
# Exécuter depuis chaque zone, rediriger la sortie vers SIEM/log

ZONES=(
    "10.0.20.0/24:Interne"
    "192.168.10.0/24:DMZ"
    "10.0.30.0/24:Serveur"
)

PROBE_PORTS="22,23,80,443,445,3389,1433,3306,5432"

for zone_entry in "${ZONES[@]}"; do
    subnet=$(echo $zone_entry | cut -d: -f1)
    name=$(echo $zone_entry | cut -d: -f2)
    echo "=== Test d'accès VERS $name ($subnet) ==="
    nmap -sT -p $PROBE_PORTS --open $subnet \\
      -oG - 2>/dev/null | \\
      grep "open" | \\
      awk -v zone="$name" '{print zone, $2, $5}'
    echo ""
done
EOF
chmod +x /usr/local/bin/segmentation_test.sh

# Métriques clés du pare-feu à suivre :
# - Connexions par seconde (planification de capacité)
# - Taux de blocage (croissant = scan/attaque ; décroissant = dérive de politique)
# - Top des IPs sources bloquées (renseignement sur les menaces)
# - Comptages de hits des règles (règles à zéro hit = candidates à la suppression)
# - Utilisation de la table de connexions (approchant le max = risque de DoS)

# iptables : afficher les comptages de hits des règles
iptables -L -n -v | awk '$1 > 0'   # Afficher uniquement les règles avec des hits de paquets

# Réinitialiser les compteurs après une revue de politique
iptables -Z                         # Remettre à zéro tous les compteurs de paquets/octets

# Exporter les métriques iptables vers Prometheus (node_exporter)
# node_exporter avec le flag --collector.iptables expose les comptages de hits des règles
# Puis visualiser dans Grafana

10. Correspondance MITRE ATT&CK & Couverture des Contrôles

Technique ATT&CK	ID	Contrôle Pare-feu/Segmentation	Contrôle Zero Trust
Mouvement latéral : SMB	T1021.002	Bloquer 445 est-ouest via micro-seg	Confiance appareil requise par session
Mouvement latéral : WMI	T1021.006	Bloquer 135/RPC dynamique entre postes	L'agent de terminal vérifie la requête
C2 : Couche applicative standard	T1071	App-ID NGFW bloque les apps inconnues	Proxy de sortie avec inspection TLS
Exfiltration : Transfert de données	T1041	Filtrage de sortie + DLP	Jetons d'accès par session ; classification des données
Découverte : Scan réseau	T1046	Journaliser/alerter sur les scans de ports inter-zones	Chaque accès requiert une requête authentifiée
Comptes valides : Domaine	T1078	Impossible à bloquer (identifiants valides)	Anomalie comportementale + vérification posture appareil
DCSync / RPC	T1003.006	Bloquer MS-DRSR depuis les IPs non-DC	Le PEP conscient de l'identité rejette les non-DC
Exploitation d'application publique	T1190	WAF + IPS NGFW	SASE inspecte tout le trafic quelle que soit la source
Accès initial : Phishing	T1566	Passerelle email ; pas de blocage réseau	MFA contrecarre le phishing de credentials
Évasion de défense : Port Knocking	T1205	L'inspection avec état détecte la séquence	L'authentification mutuelle (mTLS) rend le knocking inutile

Fin du Chapitre 4.1 - Architecture de Pare-feu, Segmentation & Zero Trust

Suivant : Chapitre 4.2 - SIEM, SOAR & Ingénierie de Détection

Table des Matières​

1. Générations de Pare-feu & Modèles de Traitement​

Évolution de la Technologie de Pare-feu​

Pipeline de Traitement des Paquets​

2. Inspection Avec État - Suivi de Connexion & Tables d'État​

Suivi de Connexions Linux​

Suivi d'État TCP et Techniques de Contournement​

3. Pare-feu de Nouvelle Génération - Connaissance Applicative & Inspection Profonde​

Identification d'Application​

Palo Alto Networks - Concepts de Politique​

Politique d'Inspection SSL/TLS​

4. iptables & nftables - Filtrage de Paquets Linux en Profondeur​

iptables - Tables, Chaînes & Règles​

nftables - Remplacement Moderne​

5. Segmentation Réseau - Zones, Conception DMZ & VLANs​

Architecture de Zones de Sécurité​

Conception DMZ​

Configuration VLAN pour la Segmentation​

6. Micro-Segmentation & Contrôle du Trafic Est-Ouest​

Le Problème du Mouvement Latéral​

Application du Pare-feu Basé sur l'Hôte​

Périmètre Défini par Logiciel avec eBPF/Cilium​

7. Architecture Zero Trust - Principes, Composants & Mise en Oeuvre​

Principes Zero Trust​

Composants Zero Trust​

Mise en Oeuvre de Zero Trust avec nginx + mTLS​

Zero Trust avec le Modèle BeyondCorp / Google IAP​

8. Audit des Règles de Pare-feu & Détection des Mauvaises Configurations​

9. Métriques Défensives & Validation​

Mesurer l'Efficacité de la Segmentation​

10. Correspondance MITRE ATT&CK & Couverture des Contrôles​