Comment résoudre les problèmes liés au pare-feu réseau lorsqu'une règle ne fonctionne pas comme prévu ?

Brève description

Les scénarios suivants peuvent empêcher les règles du pare-feu réseau de fonctionner comme prévu :

• Le trafic n'est pas acheminé de manière symétrique via le pare-feu.
• La règle du pare-feu réseau n'est pas correctement configurée.

Remarque : Avant de résoudre les problèmes liés au pare-feu réseau, confirmez les configurations suivantes :

• Les points de terminaison du pare-feu sont déployés dans leurs sous-réseaux et tables de routage dédiés. Les sous-réseaux du pare-feu ne doivent disposer d'aucune ressource de charge de travail.
• Les tables de routage acheminent le trafic via le point de terminaison du pare-feu. Vérifiez la métrique Receivedpackets d'Amazon CloudWatch pour vérifier que le pare-feu réseau a reçu des paquets. Si la métrique ReceivedPackets a une valeur de zéro, vérifiez que les tables de routage ont un itinéraire correct qui pointe vers le point de terminaison du pare-feu.

Résolution

Remarque : Si des erreurs surviennent lors de l’exécution des commandes de l’interface de la ligne de commande (AWS CLI), vérifiez que vous utilisez la version la plus récente d’AWS CLI.

Le trafic n'est pas acheminé de manière symétrique via le pare-feu

Pour un modèle de déploiement centralisé du pare-feu réseau, activez le mode appliance pour l'attachement de la passerelle de transit du cloud privé virtuel (VPC) d'inspection.

Exécutez la commande AWS CLI suivante pour vérifier si le mode appliance est activé :

aws ec2 describe-transit-gateway-vpc-attachments --filters Name=transit-gateway-attachment-id,Values=tgw-attach-example

Exécutez la commande AWS CLI suivante pour activer le mode appliance :

aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-example --options ApplianceModeSupport="enable"

Remarque : Dans les exemples de commandes précédents, remplacez tgw-attach-example par l’attachement de la passerelle de transit du VPC d'inspection.

Lors du déploiement d'un point de terminaison de pare-feu dans un sous-réseau public, la table de routage d'entrée de la passerelle Internet doit être acheminée vers le sous-réseau privé via le point de terminaison du pare-feu. La table de routage du sous-réseau privé doit également acheminer le trafic Internet vers le même point de terminaison du pare-feu. Pour plus d'informations, voir Architecture simple à zone unique avec passerelle Internet.

Pour une configuration de déploiement de pare-feu multi-AZ, la table de routage d'entrée de la passerelle Internet doit acheminer le trafic vers les sous-réseaux privés via le même point de terminaison du pare-feu. La table de routage doit également se trouver dans la même zone de disponibilité que le sous-réseau privé. Pour plus d'informations, voir Architecture multizone avec passerelle Internet.

La règle du pare-feu réseau n'est pas correctement configurée

Les problèmes liés aux règles du pare-feu réseau peuvent être dus à la façon dont vous configurez la règle.

Règles relatives aux apatrides

Pour que le trafic circule dans les deux sens, vous devez appliquer des règles d'apatridie aux règles d'entrée et de sortie. Si vous appliquez une règle à l'entrée pour le trafic entrant, vous devez également appliquer une règle à la sortie pour le trafic de réponse. Si vous appliquez une règle à la sortie du trafic de réponse, vous devez également appliquer une règle à l'entrée du trafic entrant. Cette configuration de règles est similaire à une liste de contrôle d'accès (ACL).

L'exemple suivant montre comment utiliser des règles sans état pour autoriser le trafic SSH entrant.

Priorité	Protocole	Source	Destination	Plage de ports source	Plage de ports de destination	Action
1	TCP	0.0.0.0/0	10.1.0.0/16	0:65535	22	Passe
2	TCP	10.1.0.0/16	0.0.0.0/0	22	0:65535	Passe

 

**Remarque :**Dans l'exemple précédent, le trafic SSH entrant est acheminé via le CIDR 10.1.0.0/16 à partir de n'importe quelle adresse IP.

Actions par défaut sans état pour les paquets

Passez en revue les actions apatrides par défaut pour les paquets complets et les paquets fragmentés. Les paramètres d'action par défaut déterminent la manière dont le moteur d'état du pare-feu gère les paquets individuels lorsqu'ils ne correspondent pas aux règles d'apatridie. Appliquez l'action d'état par défaut pour les paquets fragmentés uniquement aux fragments de paquets IPv4 qui utilisent le protocole de transport UDP.

**Remarque :**Le protocole IPv6 ne prend pas en charge la fragmentation du réseau. Si un hôte envoie un paquet dont la taille est supérieure à la MTU de l'hôte récepteur, celui-ci abandonne le paquet. Les appareils situés sur le chemin rejettent également des paquets dont la taille est supérieure à la MTU du périphérique.

Des règles strictes

Pour que le moteur de règles statiques puisse inspecter le trafic, il doit transmettre les deux sens du flux de trafic à des groupes de règles statiques.

Les règles du pare-feu réseau doivent faire référence à des adresses IP privées

Si un sous-réseau ou une charge de travail privé possède à la fois des adresses IP publiques et privées, la règle du pare-feu réseau doit faire référence à l'adresse IP privée.

Variables du groupe de règles

Les groupes de règles du pare-feu réseau Stateful utilisent la variable HOME \ _NET pour définir l'étendue de l'inspection du pare-feu. Si vous ne spécifiez pas explicitement la variable HOME \ _NET, la variable prend par défaut la plage CIDR du VPC où le pare-feu réseau est déployé. Dans ce paramètre par défaut, le pare-feu réseau inspecte le trafic provenant des sources au sein du VPC.

Lors du déploiement d'un pare-feu réseau centralisé, la variable HOME \ _NET du groupe de règles doit inclure votre VPC distant. Il doit également inclure les CIDR sources d'où provient votre trafic. Pour plus d'informations, consultez la section Groupes de domaines dynamiques standard dans AWS Network Firewall.

Pour inspecter le trafic provenant uniquement de certains sous-réseaux privés et non de l'ensemble du VPC, la variable HOME \ _NET doit contenir uniquement les CIDR du sous-réseau source. Dans l'exemple suivant, la variable HOME \ _NET contient les CIDR du sous-réseau source :

"RuleVariables": {
        "IPSets": {
           "HOME_NET": {
             "Definition": [
               "10.0.0.0/16",
               "10.1.0.0/16",
               "192.168.2.0/24"
             ]
           }
        }
    }

Vous pouvez utiliser l'API DescribeRuleGroup pour vérifier les détails du groupe de règles dynamiques. Si l'objet RuleVariables ne figure pas dans la réponse, le groupe de règles de pare-feu utilise les paramètres par défaut. Les paramètres par défaut pour HOME \ _NET sont définis sur le CIDR VPC du pare-feu réseau.

Ordre d'évaluation des règles

Les applications qui utilisent le protocole TCP ont besoin de l'établissement de liaison à 3 voies pour réussir avant que les demandes d'application ne soient envoyées. Le premier paquet que le pare-feu voit dans la connexion est un SYN TCP provenant de la source. Si des règles contradictoires bloquent les paquets TCP de niveau inférieur, l'établissement de liaison à 3 voies échoue et entraîne l'expiration du délai imparti à l'application.

Par exemple, pour détecter le nom d'hôte, un groupe de règles de liste de domaines utilise l'en-tête Hôte dans la requête HTTP. Il utilise également l'extension Server Name Indication (SNI) dans la liaison TLS. Pour qu'une requête HTTP et une négociation TLS aient lieu, l'établissement de liaison TCP à 3 voies initial sur les ports 80 (HTTP) et 443 (HTTPS) doit d'abord être terminé.

Lorsque vous utilisez des règles qui impliquent à la fois les couches application et transport, veillez à autoriser le trafic sur les ports TCP requis par l'application. Vérifiez l'ordre d'évaluation des règles pour vérifier que les règles précédentes correspondent au trafic.

Avec l'ordre d'action par défaut, assurez-vous que d'autres règles ne bloquent pas le trafic lors de l'évaluation. Utilisez le mot clé flow dans vos règles pour éviter toute correspondance avec des paquets de protocole de niveau inférieur avant que les protocoles d'application de niveau supérieur ne soient identifiés.

Exemples de configuration de règles

Configuration de règles incorrecte pour le trafic TCP

Dans l'exemple suivant, la règle n'est pas correctement configurée pour bloquer toutes les connexions TCP sortantes et n'autoriser que les requêtes HTTP vers example.com. Comme tout le trafic TCP est supprimé, le client source ne peut pas envoyer la demande d'application HTTP.

pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;) drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Drop outbound TCP traffic"; sid:172192; rev:1;)

Configuration correcte de la connexion TCP

Dans l'exemple suivant, la règle Drop established TCP:80 établit d'abord la connexion TCP. Ensuite, il supprime tous les autres paquets qui ne correspondent pas au nom d'hôte HTTP example.com.

drop tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Drop established TCP:80"; flow: from_client,established; sid:172190; rev:1;)
pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; priority:10; sid:172191; rev:1;)
drop tcp $HOME_NET any -> $EXTERNAL_NET !80 (msg:"Drop outbound non TCP:80 traffic"; sid:172192; rev:1;)

**Remarque :**L'ordre d'action par défaut autorise automatiquement les paquets qui ne correspondent à aucune règle définie.

Dans un ordre d'évaluation strict, les groupes de règles sont évalués par ordre de priorité, en commençant par le chiffre le plus bas. Les règles de chaque groupe de règles sont traitées dans l'ordre dans lequel elles ont été définies. Assurez-vous que les configurations des règles et de l'ordre de priorité manuel sont correctes. N'associez pas une règle de priorité inférieure à votre trafic réseau. Rédigez également les règles en fonction de l'action par défaut que vous sélectionnez dans le cadre de la politique de pare-feu stricte.

Configuration incorrecte entraînant des délais d'expiration

Dans l'exemple suivant, la configuration spécifiée supprime tout le trafic TCP par défaut avant que le pare-feu ne détecte la demande HTTP au niveau de l'application. Cette configuration entraîne des délais d'expiration inattendus.

Default Action: Drop all
Rule: pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)

Configuration correcte permettant la liaison TCP à 3 voies

Dans l'exemple suivant, le pare-feu réseau permet d'établir l'établissement d'une liaison TCP à 3 voies et autorise uniquement le trafic HTTP pour le domaine example.com.

Default Action: Drop established
Rule: pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:"example.com"; endswith; msg:"Allowed HTTP domain"; sid:172191; rev:1;)

Pour plus d'exemples de règles de pare-feu, voir Exemples de règles statiques pour le pare-feu réseau.

---

Informations connexes

Modèles de déploiement pour AWS Network Firewall

Définition des actions relatives aux règles dans AWS Network Firewall

Inspection de la liste des domaines pour le trafic provenant de l'extérieur du VPC de déploiement

Ordre d'évaluation pour les groupes de règles statiques