Skip to main content

Chapitre 4.1 Quiz - Architecture pare-feu, segmentation et Zero Trust

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Un ingenieur junior ajoute les regles iptables suivantes a un serveur web de production dans cet ordre :

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 192.168.1.0/24 -j DROP
iptables -A INPUT -j DROP

L'intention etait de bloquer le sous-reseau 192.168.1.0/24 d'acceder a HTTPS. Pourquoi ce jeu de regles echoue-t-il, quel est l'ordre correct, et quelle regle supplementaire manque-t-il pour une configuration durcie complete ?

Reveler la reponse

Reponse : Le jeu de regles echoue a cause de l'evaluation a la premiere correspondance - la regle ACCEPT large en ligne 1 correspond a tout le trafic TCP/443, y compris le trafic de 192.168.1.0/24. La regle DROP en ligne 2 n'est jamais atteinte pour ce sous-reseau.

Pourquoi cela echoue : iptables evalue les regles de haut en bas et s'arrete a la premiere correspondance. Tout paquet destine au port 443 correspond a la regle 1 et est immediatement accepte - la verification de l'IP source en regle 2 est inutile car l'evaluation a deja termine.

Ordre correct - regles specifiques avant regles generales :

# Vider et reconstruire
iptables -F INPUT

# 1. Permettre d'abord les connexions etablies/associees (performance + exactitude)
iptables -A INPUT -m conntrack \\
  --ctstate ESTABLISHED,RELATED -j ACCEPT

# 2. Supprimer l'etat invalide (empeche les scans ACK, paquets hors fenetre)
iptables -A INPUT -m conntrack \\
  --ctstate INVALID -j DROP

# 3. Bloquer le sous-reseau specifique AVANT la regle d'acceptation generale
iptables -A INPUT \\
  -p tcp --dport 443 \\
  -s 192.168.1.0/24 \\
  -j DROP                            # Sous-reseau specifique bloque en premier

# 4. Acceptation generale pour toutes les autres sources
iptables -A INPUT \\
  -p tcp --dport 443 \\
  -m conntrack --ctstate NEW \\
  -j ACCEPT

# 5. Permettre le loopback (devrait etre en premier en pratique)
iptables -I INPUT 1 -i lo -j ACCEPT

# 6. Refus par defaut (catch-all final)
iptables -A INPUT -j DROP

Regle supplementaire manquante : La regle ESTABLISHED,RELATED est absente. Sans elle, le trafic de retour pour les connexions sortantes initiees par le serveur (ex. : mises a jour apt, appels API) serait bloque, rompant toutes les connexions initiees par le serveur.

Egalement manquant : la journalisation avant le DROP final pour la visibilite sur le trafic bloque, et la limitation de debit sur SSH pour prevenir la force brute.

MITRE ATT&CK : Cette mauvaise configuration est liee a T1562.004 (Alterer les defenses : desactiver ou modifier le pare-feu systeme).

Question 2

Votre reseau comporte trois segments : Internet (eth0), DMZ (eth1 : 192.168.10.0/24) et LAN interne (eth2 : 10.0.0.0/24). Un attaquant compromet le serveur web a 192.168.10.50. Decrivez les trois regles de pare-feu qui empeche structurellement d'atteindre le LAN interne, meme avec un controle total de l'hote DMZ, et expliquez ce que chaque regle bloque.

Reveler la reponse

Reponse : Trois regles qui assurent l'isolation de la DMZ :

Regle 1 - Bloquer DMZ vers Interne (isolation principale)

iptables -A FORWARD \\
  -i eth1 \\\\                          # Trafic arrivant depuis l'interface DMZ
  -o eth2 \\\\                          # Tentant de sortir vers l'Interne
  -j DROP
# Bloque : tout le trafic de tout hote DMZ (y compris le compromis 192.168.10.50)
# vers tout hote Interne. C'est la regle de confinement principale.
# Contrecarre : mouvement lateral via relai SMB, pass-the-hash, scan des hotes internes

Regle 2 - Bloquer DMZ vers Interne via l'etat (defense en profondeur)

iptables -A FORWARD \\
  -i eth1 -o eth2 \\
  -m conntrack --ctstate NEW \\
  -j LOG --log-prefix "DMZ_TO_INTERNAL: "
iptables -A FORWARD \\
  -i eth1 -o eth2 \\
  -m conntrack --ctstate NEW \\
  -j DROP
# Meme si la Regle 1 etait contournee, cela supprime explicitement les NOUVELLES connexions
# de DMZ vers Interne et les enregistre - l'entree de journal alerte sur la tentative.

Regle 3 - Restreindre l'egress DMZ vers Internet (limiter les canaux C2)

iptables -A FORWARD \\
  -i eth1 -o eth0 \\\\                  # DMZ vers Internet
  -p tcp -m multiport \\
  --dports 80,443 \\\\                  # Uniquement HTTP/HTTPS sortant
  -m conntrack --ctstate NEW \\
  -j ACCEPT
iptables -A FORWARD \\
  -i eth1 -o eth0 \\
  -j DROP                            # Bloquer tout autre sortant DMZ
# Bloque : shells inverses sur ports non standard, tunnellisation DNS (port 53 bloque),
# SMB/RDP sortant direct. Force l'attaquant a utiliser uniquement le C2 HTTP/HTTPS -
# que l'inspection TLS (Chapitre 2.4) peut detecter.

Ce qu'un hote DMZ compromis PEUT encore faire avec ces regles :

  • Communiquer avec Internet sur les ports 80/443 (C2 via HTTPS)
  • Attaquer d'autres hotes DMZ (est-ouest dans la DMZ)
  • Exploiter les services que le pare-feu autorise explicitement depuis Internet vers DMZ

Ce qu'il ne peut PAS faire : atteindre directement les hotes Internes sur n'importe quel port, quelles que soient les identifiants ou les outils dont dispose l'attaquant sur l'hote DMZ compromis.

Question 3

Expliquez la difference architecturale entre un modele de pare-feu perimetre et un modele d'application Zero Trust quand un attaquant a compromis des identifiants de domaine valides. Pourquoi le modele perimetre echoue-t-il, et quels controles Zero Trust specifiques attentuent la menace ?

Reveler la reponse

Reponse :

Echec du modele perimetre : Le modele perimetre accorde une confiance implicite basee sur l'emplacement reseau. Un attaquant avec des identifiants valides qui est a l'interieur du perimetre reseau (via VPN, hameconnage ou hote compromis) recoit le meme niveau de confiance qu'un employe legitime. Les controles pare-feu sont :

  • Nord-sud : appliques (Internet vers Interne est bloque)
  • Est-ouest : minimaux ou absents (Interne vers Interne est largement non restreint)

Des identifiants valides defient les controles d'authentification. Combine avec un acces est-ouest plat, l'attaquant peut :

  • Interroger LDAP librement (enumeration du domaine)
  • S'authentifier a tout hote ou l'identifiant est valide
  • Effectuer pass-the-hash, Kerberoasting, DCSync
  • Acceder aux partages de fichiers, bases de donnees, interfaces d'administration

Le pare-feu perimetre n'a aucune visibilite sur ce qu'un utilisateur authentifie fait a l'interieur du perimetre.

Controles Zero Trust qui adressent specifiquement le compromis d'identifiants valides :

1. Verification de la posture de l'appareil
   -----------------------------------------
   L'acces requiert : identifiant valide ET appareil gere avec posture saine
   (EDR en cours d'execution, disque chiffre, OS patche, aucun IOC connu)

   Un attaquant avec des identifiants voles mais sur un appareil non gere est refuse.

   Implementation : Okta + CrowdStrike device trust, politique de conformite Intune,
   Google BeyondCorp - identite d'appareil basee sur les certificats
# 2. Jetons d'acces par session, par ressource
# --------------------------------------------
# L'acces a chaque ressource requiert une nouvelle decision de politique
# Pas de sessions persistantes "vous etes admis, allez ou vous voulez"

# JWT avec expiration courte + claim audience
# Exemple : jeton valide uniquement pour api.internal.corp, expire dans 15 minutes
{
  "sub": "jsmith@corp.com",
  "aud": "api.internal.corp",        # Ressource specifique
  "exp": 1700000900,                 # 15 minutes a partir de maintenant
  "device_trust": "managed",
  "iat": 1700000000
}
# Meme si vole, le jeton ne fonctionne que pour une ressource, pendant 15 minutes
3. Detection d'anomalies comportementales
   ----------------------------------------
   Reference : jsmith accede normalement a 3 systemes entre 9h et 17h EST
   Alerte : jsmith s'authentifie a 47 systemes a 2h du matin depuis une IP inhabituelle

   Implementation : Microsoft Defender for Identity, Splunk UBA, Vectra
   Meme des identifiants valides declenchent une alerte utilises de maniere anormale
4. Acces au moindre privilege + elevation juste-a-temps
   ------------------------------------------------------
   Le compte normal de jsmith n'a acces ni au DC, ni aux systemes financiers, ni a MSSQL
   L'acces admin est accorde pour un ticket/fenetres specifique uniquement, puis revoque

   Implementation : CyberArk, Azure PIM (Privileged Identity Management)
   Le Kerberoasting est inefficace si les comptes de service ont des mots de passe
   geres de 240 caracteres (gMSA)

MITRE ATT&CK : T1078 (Comptes valides) - la posture d'appareil + detection comportementale de Zero Trust cible specifiquement cette technique, que les pare-feu perimetre ne peuvent pas adresser du tout.

Question 4

Vous auditez un jeu de regles pare-feu et trouvez la regle suivante en haut de la chaine INPUT : iptables -A INPUT -p tcp -s 10.0.0.0/8 --dport 22 -j ACCEPT. Listez trois problemes de securite specifiques avec cette regle et fournissez la version corrigee.

Reveler la reponse

Reponse :

Probleme 1 - Plage source trop large (tout le /8 RFC 1918) 10.0.0.0/8 couvre 16 millions d'adresses IP - incluant chaque hote dans chaque sous-reseau 10.x.x.x de l'organisation, plus tout futur sous-reseau. Si un hote dans cette plage est compromis, il a un acces SSH illimite a ce serveur. La regle devrait specifier uniquement le sous-reseau de gestion specifique (ex. : 10.0.100.0/24).

Probleme 2 - Aucune restriction d'etat de connexion La regle autorise TOUS les paquets TCP vers le port 22, y compris les paquets d'etat ESTABLISHED et INVALID. Sans --ctstate NEW, cette regle est redondante avec la regle ESTABLISHED,RELATED et accepte egalement les paquets d'etat invalide (qui peuvent indiquer des scans ACK ou des attaques par port knocking). Les nouvelles connexions devraient etre explicitement limitees.

Probleme 3 - Aucune limitation de debit (exposition a la force brute) N'importe lequel des 16 millions d'IPs dans la plage peut faire des connexions SSH illimitees par seconde. Sans limitation de debit, un hote interne compromis peut faire de la force brute sur les identifiants SSH a pleine vitesse reseau.

Jeu de regles corrige :

# Supprimer la regle originale trop permissive
iptables -D INPUT -p tcp -s 10.0.0.0/8 --dport 22 -j ACCEPT

# Remplacer par une regle SSH durcie

# Etape 1 : Enregistrer les tentatives de connexion excessives avant de les bloquer
iptables -A INPUT \\
  -p tcp --dport 22 \\
  -m conntrack --ctstate NEW \\
  -s 10.0.100.0/24 \\\\                 # Uniquement le sous-reseau de gestion
  -m recent --set --name SSH_MGMT    # Suivre les tentatives de connexion

iptables -A INPUT \\
  -p tcp --dport 22 \\
  -m conntrack --ctstate NEW \\
  -s 10.0.100.0/24 \\
  -m recent --update --name SSH_MGMT \\
  --seconds 60 --hitcount 5 \\\\        # > 5 nouvelles connexions en 60s = bloquer
  -j LOG --log-prefix "SSH_BRUTE: "

iptables -A INPUT \\
  -p tcp --dport 22 \\
  -m conntrack --ctstate NEW \\
  -s 10.0.100.0/24 \\
  -m recent --update --name SSH_MGMT \\
  --seconds 60 --hitcount 5 \\
  -j DROP

# Etape 2 : Autoriser le nouveau SSH uniquement depuis le sous-reseau de gestion, sous limite de debit
iptables -A INPUT \\
  -p tcp --dport 22 \\
  -s 10.0.100.0/24 \\\\                 # CIDR de gestion specifique uniquement
  -m conntrack --ctstate NEW \\\\       # Nouvelles connexions uniquement (ESTABLISHED gere separement)
  -j ACCEPT

# Bloquer SSH de tout le reste
iptables -A INPUT -p tcp --dport 22 -j DROP

# S'assurer que cet hote est accessible uniquement depuis un hote jump/bastion
# (Zero Trust : n'exposez pas SSH a n'importe quel sous-reseau interne - utilisez un hote jump)

Durcissement supplementaire au-dela de la regle pare-feu :

  • sshd_config : PermitRootLogin no, PasswordAuthentication no (cles uniquement), liste blanche AllowUsers
  • Envisager de restreindre SSH a un hote bastion uniquement - pas de SSH direct depuis les postes de travail
  • Utiliser fail2ban pour la limitation de debit au niveau application comme complement a iptables

Fin du Quiz 4.1 - Architecture pare-feu, segmentation et Zero Trust