Auditer les services de protection réseau

La conformité vous envoie une ligne : confirmez que chaque application exposée sur internet dans le compte de production est protégée par un web application firewall. Vous ouvrez la console, vous trouvez un web ACL nommé prod-web-acl avec 14 règles dont le core rule set géré par AWS, et vous répondez que la couverture est en place.

Vous venez peut-être de signer pour rien. Un web ACL est une ressource autonome. Tant qu'il n'est pas associé à une distribution CloudFront ou à un load balancer précis, il inspecte zéro requête, et la page de la console a exactement la même allure dans les deux cas. La même forme de trou existe dans les 4 services de cette leçon, et c'est pour cela que l'examen consacre une compétence à les auditer plutôt qu'à les configurer.

Quatre services, quatre portions de trafic différentes

Avant d'auditer ces services, il faut savoir ce que chacun est seulement en position de voir. Ce ne sont pas des couches d'un même mur. Ils siègent sur des chemins différents, et un trou dans l'un est totalement invisible pour les 3 autres.

Deux frontières de ce tableau méritent leur propre phrase.

AWS WAF voit des requêtes, Network Firewall voit des paquets. WAF n'existe que devant des types de ressources qui parlent HTTP : distributions CloudFront, Application Load Balancers, REST APIs API Gateway, APIs GraphQL AppSync, user pools Cognito, services App Runner, Bedrock AgentCore Gateways, instances Verified Access et Amplify. Rien d'autre. Si votre charge de travail est un réplica de base de données qui expédie des données sur un port TCP maison, WAF n'est pas le contrôle qui aurait pu l'attraper, Network Firewall si.

DNS Firewall voit des requêtes DNS, Network Firewall voit des connexions. Les deux savent filtrer par nom de domaine, et ce recouvrement est un piège d'examen favori. DNS Firewall filtre la résolution elle-même au passage par le Route 53 VPC Resolver, donc il empêche la charge de travail d'apprendre l'adresse. Network Firewall inspecte le trafic qui en résulte sur le fil mais n'a aucune visibilité sur les requêtes du Resolver. AWS le dit directement : les 2 services filtrent des noms de domaine sur 2 chemins réseau distincts.

Les 4 questions auxquelles un audit répond

Chacun de ces services peut être déployé et ne rien protéger, et la défaillance tombe toujours sur l'une des mêmes 4 étapes. Gardez ce cadre pour la suite de la leçon et appliquez-le au service que l'examen nomme :

1. Est-il déployé ? La ressource existe-t-elle dans ce compte et cette Région ?
2. Est-il rattaché à ce que vous croyez ? Association, subnet, route ou liaison au VPC.
3. Applique-t-il, ou observe-t-il seulement ? Count, Alert et Pass produisent tous une télémétrie d'apparence saine tout en laissant passer le trafic.
4. Pouvez-vous prouver ce qu'il a fait ? Le logging est désactivé par défaut sur la plupart d'entre eux, et un audit sans preuve est un avis.

La question 3 est celle sur laquelle les environnements réels échouent, parce que l'étape 3 est une partie normale et correcte de tout déploiement. Vous démarrez une nouvelle règle en mode comptage volontairement. Personne ne planifie le jour où on l'active.

Auditer AWS WAF

Commencez par l'association, parce que c'est la question que l'auditeur a réellement posée. Les web ACLs vivent dans 2 scopes séparés, et le scope CloudFront n'existe que dans us-east-1 :

# Ressources régionales : ALB, API Gateway, AppSync, Cognito, App Runner, Verified Access
aws wafv2 list-web-acls --scope REGIONAL --region eu-west-1

aws wafv2 list-resources-for-web-acl \
  --web-acl-arn arn:aws:wafv2:eu-west-1:111122223333:regional/webacl/prod-web-acl/a1b2c3d4 \
  --region eu-west-1

# Les distributions CloudFront sont toujours dans le scope CLOUDFRONT en us-east-1
aws wafv2 list-web-acls --scope CLOUDFRONT --region us-east-1

Une liste ResourceArns vide est le constat. Travaillez aussi dans l'autre sens : listez vos ALBs et vos distributions CloudFront et cherchez ceux qui n'ont aucun web ACL, parce qu'une ressource sans association n'apparaîtra jamais dans la liste de ressources d'un web ACL.

Une fois l'association confirmée, 4 détails de configuration décident si le web ACL bloque quoi que ce soit.

L'action par défaut. Un web ACL applique son action par défaut à chaque requête qu'aucune règle n'a terminée. Allow est normal pour un site public protégé par des règles de blocage explicites. Block est normal pour une API interne verrouillée. Lire l'action par défaut vous dit pour quel modèle le web ACL a été conçu, et un défaut Block accompagné d'une règle Allow large en tête n'a rien de la posture que son nom suggère.

Actions terminantes et non terminantes. Allow et Block arrêtent l'évaluation immédiatement, et celle qui correspond la première décide de la requête. Count ne termine jamais : elle incrémente une métrique et l'évaluation continue. CAPTCHA et Challenge sont conditionnelles, terminantes seulement quand la requête n'a pas de token valide. Un ensemble de règles peut donc être rempli de bonnes règles de blocage qui ne s'exécutent jamais.

La priorité des règles. AWS WAF évalue les règles de la plus petite priorité numérique vers le haut. Une règle Allow en priorité 10 qui correspond à la plage IP de vos bureaux terminera avant que la règle d'injection SQL en priorité 50 ne voie la requête. Les règles Allow larges près du sommet sont ce qu'un audit de web ACL a de plus rentable à chercher.

Les overrides de rule group. Quand vous ajoutez un managed rule group, vous pouvez forcer l'action de tout le groupe sur Count, ou forcer des règles individuelles à l'intérieur. C'est la façon prévue d'essayer le core rule set géré par AWS sans casser une application vivante. C'est aussi la raison la plus courante pour laquelle un web ACL aux excellentes règles ne bloque rien. Vérifiez-le explicitement, la console l'affiche comme un petit badge facile à sauter en lisant vite.

Pour la question 4, le logging WAF reste inactif tant que vous ne le configurez pas. Vous envoyez les logs d'un web ACL vers un log group CloudWatch Logs, un bucket S3 ou un delivery stream Amazon Data Firehose, avec la possibilité de masquer des champs et de filtrer les enregistrements conservés. Séparément, l'échantillonnage de requêtes donne une vue glissante des requêtes récemment évaluées sans aucune configuration de logging, et c'est le moyen le plus rapide de voir si une règle correspond à quelque chose. Les métriques CloudWatch à lire sont AllowedRequests, BlockedRequests et CountedRequests. Un web ACL dont BlockedRequests reste plat à zéro depuis des mois pendant que CountedRequests grimpe vous donne la réponse à la question 3.

Auditer AWS Shield

Shield se coupe nettement en une moitié automatique et une moitié souscrite, et les questions d'audit diffèrent pour chacune.

Shield Standard est actif pour tout client AWS sans frais supplémentaires et défend contre les inondations courantes des couches réseau et transport. Rien à activer, rien à rattacher, rien à auditer au-delà de savoir qu'il est là.

Shield Advanced est un abonnement à 3 000 $ par mois avec un engagement d'un an, facturé par payer account dès que ce payer ou un compte lié est souscrit. Il protège les instances EC2, les load balancers Elastic Load Balancing, les distributions CloudFront, les hosted zones Route 53 et les accélérateurs standard Global Accelerator.

Voici l'idée fausse qui mérite d'être nommée : souscrire à Shield Advanced ne protège pas vos ressources. L'abonnement débloque la capacité. Vous créez encore une protection pour chaque ressource à couvrir. Le constat d'audit prévisible est un load balancer créé 3 mois après le début de l'abonnement que personne n'a ajouté, pendant que le compte paie 3 000 $ par mois en partie pour une couverture qu'il n'a pas.

aws shield describe-subscription          # le compte est-il souscrit, et quand le terme finit-il
aws shield list-protections               # quels ARNs de ressources sont réellement protégés

Comparez cette liste de protections aux ressources éligibles du compte. Cet écart est votre constat.

Trois autres réglages Shield Advanced pèsent vraiment dans un audit :

• L'automatic application layer DDoS mitigation se configure pour compter ou pour bloquer les requêtes web qu'elle identifie comme faisant partie d'une attaque. Réglée sur count, c'est un détecteur. L'activer ajoute au web ACL associé un rule group qui consomme 150 WCUs, comptés dans la capacité du web ACL.
• La détection basée sur la santé associe un health check Route 53 à une ressource protégée pour que Shield distingue un impact réel d'un pic de trafic bénin. Elle existe pour tous les types de ressources sauf les hosted zones Route 53, et l'engagement proactif de la Shield Response Team ne fonctionne que sur les ressources qui l'ont activée.
• L'accès à la Shield Response Team réclame en plus un plan de support Business ou Enterprise. Un abonnement sans le plan de support signifie que le numéro de téléphone de votre runbook ne répond pas.

Shield Advanced propose aussi une protection contre les pics de facture causés par une attaque, accordée sous forme de crédits de service après coup plutôt que comme une remise automatique.

Auditer AWS Network Firewall

Network Firewall a le plus grand écart entre "la ressource existe" et "la ressource fait quelque chose", donc c'est le plus profond des 4 audits.

Le service crée un firewall endpoint dans chaque subnet que vous désignez, et chaque endpoint donne au firewall sa disponibilité dans sa zone de disponibilité. Une firewall policy porte les réglages et pointe vers des rule groups, stateless et stateful. Rien de tout cela ne met le firewall sur le chemin du trafic.

Les route tables sont le mécanisme d'application. Vous modifiez les route tables du VPC pour que le trafic d'un subnet protégé aille au firewall endpoint, et pour que le trafic retour venu de l'internet gateway repasse par l'endpoint avant d'atteindre le subnet. Sautez cette étape et vous avez un firewall entièrement configuré, une facture mensuelle et zéro paquet. Quand un scénario dit que le firewall est déployé et correctement configuré mais que le trafic n'est pas filtré, les routes sont la réponse.

Quatre autres contrôles, dans l'ordre où ils mordent habituellement :

La couverture des zones de disponibilité. Un endpoint par AZ, et la disponibilité de l'endpoint se limite à sa propre zone. Les charges de travail dans une AZ sans firewall endpoint sont non filtrées, ou bien leur trafic traverse une frontière d'AZ pour atteindre un endpoint ailleurs et ramasse au passage des frais de transfert inter-zone. Comparez la liste des AZ qui portent des subnets de charge de travail à celle des AZ qui portent des subnets de firewall.

Des subnets de firewall dédiés. Un firewall endpoint ne peut pas filtrer le trafic qui entre dans le subnet où il réside ni celui qui en sort. Placez une charge de travail dans un subnet de firewall et cette charge est exemptée d'inspection. AWS est explicite : n'utilisez les subnets de firewall pour rien d'autre.

Les stateless default actions. Le moteur stateless s'exécute en premier et décide si chaque paquet est passé, rejeté ou transféré au moteur stateful. Si la stateless default action est Pass et qu'aucune règle stateless ne transfère le trafic plus loin, vos règles Suricata et vos domain lists ne s'exécutent jamais. La policy est parfaitement valide, et c'est ce qui en fait un constat d'audit au lieu d'une erreur. Le même réglage dispose d'un défaut séparé pour les fragments de paquets UDP, et Network Firewall rejette silencieusement les fragments des autres protocoles.

L'ordre d'évaluation des règles stateful. Une policy utilise soit l'action order, soit le strict order, et RuleOrder ne se règle qu'à la création de la policy. Il ne se modifie pas ensuite. En action order, Suricata évalue toutes les règles pass avant toute règle drop, reject ou alert, quel que soit le mot-clé priority, donc une règle pass permissive placée n'importe où dans n'importe quel rule group l'emporte sur tout ce qui est en dessous. En strict order, les rule groups s'exécutent par priorité croissante et les règles dans leur ordre d'écriture, et vous choisissez aussi des actions par défaut comme Drop all ou Drop established. AWS recommande le strict order exactement pour cette prévisibilité. Si un audit trouve une règle drop qui ne se déclenche jamais, l'action order plus une règle pass large est la première hypothèse.

Côté preuve, le logging de Network Firewall reste inactif tant que vous ne le configurez pas, et il produit 3 types de logs que vous activez séparément :

La contrainte qui piège : seul le trafic transféré au moteur stateful est journalisé. Les rejets stateless n'apparaissent jamais dans ces logs. Les métriques CloudWatch couvrent les deux moteurs et sont le bon endroit pour confirmer que le firewall reçoit du trafic.

Un dernier point à consigner : la delete protection est activée à la création d'un firewall et doit être désactivée explicitement par l'API avant toute suppression. La console ne montre pas le réglage parce que le flux de suppression le désactive pour vous.

Auditer Route 53 Resolver DNS Firewall

DNS Firewall filtre les requêtes DNS sortantes au passage par le Route 53 VPC Resolver. Sa mission principale est d'arrêter l'exfiltration DNS, où un attaquant ayant compromis une instance encode des données dans des résolutions vers un domaine qu'il contrôle. Il bloque aussi la résolution des enregistrements de private hosted zones, des noms de VPC endpoints et des noms d'instances EC2.

L'association. Les rule groups ne font rien tant qu'ils ne sont pas associés à un VPC, et vous pouvez en associer jusqu'à 5 par VPC et par Région. Confirmez l'association et sa priorité, puis vérifiez que l'ordre des priorités correspond à votre intention, car les nombres les plus bas s'évaluent en premier aussi bien entre rule groups associés qu'entre les règles d'un même groupe.

aws route53resolver list-firewall-rule-group-associations --vpc-id vpc-0abc123
aws route53resolver list-firewall-rules --firewall-rule-group-id rslvr-frg-0abc123
aws route53resolver list-firewall-configs        # le réglage fail open par VPC

L'action de la règle. Chaque règle porte exactement une action parmi 3 :

AWS recommande lui-même de créer une règle de blocage en Alert d'abord, pour mesurer combien de requêtes elle aurait bloquées. Ce conseil produit le constat DNS Firewall le plus fréquent qui soit : un rule group dont chaque règle est encore sur Alert un an plus tard. Alert est un détecteur, Block est un contrôle. Lire la liste des actions prend 30 secondes et a de vraies conséquences.

La block response. Quand l'action est Block, vous choisissez ce que le client entend en retour :

• NODATA répond que la requête a réussi mais qu'aucun enregistrement n'est disponible.
• NXDOMAIN répond que le nom de domaine n'existe pas.
• OVERRIDE retourne un CNAME de votre choix, avec une durée de vie qui vaut 0 par défaut pour que la réponse ne soit pas mise en cache. C'est ainsi que vous dirigez les résolutions bloquées vers un sinkhole ou une page d'avertissement interne.

Les managed domain lists. AWS maintient 4 listes utilisables gratuitement : Malware, Botnet/Command and Control, Aggregate Threat List (un sur-ensemble des autres, qui ajoute ransomware, spyware et tunneling DNS) et Amazon GuardDuty Threat List (domaines issus des findings DNS de GuardDuty). Vous ne pouvez ni consulter ni télécharger leur contenu, et c'est délibéré : une liste de blocage publiée est un mode d'emploi pour la contourner. Quand une liste gérée produit un faux positif, le correctif consiste à ajouter une règle allow pour ce domaine précis avec une priorité numérique plus basse que la règle de blocage, pour qu'elle s'exécute avant.

Le mode de défaillance. C'est le réglage que personne ne vérifie. Quand le VPC Resolver n'obtient aucune réponse de DNS Firewall, la configuration firewall du VPC décide de la suite :

• Fail closed est le défaut. La requête est bloquée et le VPC Resolver retourne SERVFAIL. Sécurité avant disponibilité.
• Fail open, réglé par le champ FirewallFailOpen, laisse passer la requête. Disponibilité avant sécurité.

Les deux sont des choix légitimes, et aucun n'est une erreur. Mais un VPC en fail open perd ses protections DNS exactement aux moments où un attaquant voudrait les voir disparaître, donc le constat d'audit n'est pas "fail open est une erreur", c'est "fail open est réglé et personne n'a documenté la décision".

À mémoriser avec la configuration : 5 rule groups par VPC, 100 règles par rule group, 1 000 rule groups par compte et par Région, 100 000 domaines répartis sur toutes vos domain lists.

Transformer les contrôles ponctuels en preuve permanente

Tout ce qui précède est une réponse à un instant donné. Un audit qu'il faut refaire à la main chaque trimestre ne sera pas refait.

AWS Config enregistre les changements de configuration de ces ressources et évalue en continu des règles gérées, donc un web ACL qui perd son association ou une firewall policy dont l'action par défaut change génère un finding non conforme tout seul. Les conformance packs regroupent les règles pertinentes en une unité déployable.

AWS Security Hub agrège ces findings Config avec les résultats de GuardDuty et d'Inspector et les note contre des standards comme les AWS Foundational Security Best Practices, ce qui transforme "sommes-nous protégés" en un chiffre avec une courbe.

Les alarmes CloudWatch ferment la question 3 définitivement. Une alarme sur BlockedRequests d'un web ACL resté à zéro pendant une semaine entière, ou sur les compteurs de paquets d'un Network Firewall tombés à rien, attrape les régressions silencieuses qu'une revue trimestrielle manque de 89 jours.

Une note de périmètre qui compte pour l'examen. Cette compétence est écrite comme un audit de ces services dans un seul compte. Dès que la question s'élargit à chaque VPC de chaque compte membre, y compris des comptes qui n'existent pas encore, la réponse devient AWS Firewall Manager, qui applique de façon centralisée des policies AWS WAF, Shield Advanced, security group, network ACL, Network Firewall et DNS Firewall à l'échelle d'une organisation et fait entrer automatiquement les nouvelles ressources dans le périmètre. Firewall Manager réclame AWS Organizations et AWS Config. Rangez-le comme la réponse à l'échelle de l'organisation, pour qu'il ne vous tente pas sur une question mono-compte.

Conseils d'examen

• Exister n'est pas protéger. Pour WAF lisez l'association, pour Shield la liste des protections, pour Network Firewall les route tables, pour DNS Firewall l'association au VPC. Ce seul mouvement répond à la plupart des questions d'audit sur cette compétence.
• Count, Alert et Pass sont les réglages qui observent seulement. Count et overrides de rule group côté WAF, mitigation automatique Shield réglée sur count, stateless default Pass côté Network Firewall, Alert côté DNS Firewall. Un scénario qui décrit "les logs montrent le trafic mais il n'est pas bloqué" pointe vers l'un d'eux.
• Le filtrage par domaine apparaît deux fois. Les requêtes qui passent par le Resolver, c'est DNS Firewall ; le trafic sur le fil, c'est Network Firewall. Network Firewall n'a aucune visibilité sur les requêtes du Resolver.
• AWS WAF ne se rattache qu'à des types de ressources HTTP. CloudFront, ALB, API Gateway, AppSync, user pools Cognito, App Runner, Bedrock AgentCore Gateway, Verified Access, Amplify. Ni EC2, ni NLB, ni RDS.
• Shield Standard est gratuit et automatique ; Shield Advanced coûte 3 000 $ par mois avec un engagement d'un an et ne protège que les ressources que vous ajoutez explicitement.
• Network Firewall : route tables, subnets de firewall dédiés et un endpoint par AZ. Un firewall endpoint ne peut pas filtrer son propre subnet.
• RuleOrder se règle à la création de la policy et ne change plus. Le strict order est le choix recommandé.
• DNS Firewall échoue fermé par défaut et retourne SERVFAIL. Le fail open est une option explicite.
• Un seul compte, c'est l'audit ; AWS Organizations, c'est Firewall Manager.

L'habitude à emporter de cette leçon est plus petite que la liste des services : pour tout contrôle de protection, trouvez la liaison qui le relie à du trafic réel, puis trouvez le réglage qui décide s'il agit ou s'il regarde. Ces 2 faits sont l'audit. La leçon suivante regarde le même réseau depuis l'autre bout, en demandant non pas s'il est protégé mais ce que chaque gigaoctet qui le traverse vous coûte.