Comment les filtres de pare-feu standard évaluent les paquets

Présentation de l’évaluation des paquets de filtres de pare-feu

La séquence suivante décrit comment l’équipement évalue un paquet entrant ou sortant d’une interface si le trafic d’entrée ou de sortie au niveau de l’interface d’un périphérique est associé à un filtre de pare-feu. L’évaluation des paquets se déroule comme suit :

1. L’équipement évalue le paquet par rapport aux termes du filtre de pare-feu de manière séquentielle, en commençant par le premier terme du filtre.

   • Si le paquet correspond à toutes les conditions spécifiées dans un terme, l’équipement effectue toutes les actions spécifiées dans ce terme.

   • Si le paquet ne correspond pas à toutes les conditions spécifiées dans un terme, l’équipement passe au terme suivant dans le filtre (s’il existe un terme suivant) et évalue le paquet par rapport à ce terme.

   • Si le paquet ne correspond à aucun terme du filtre de pare-feu, l’équipement le rejette implicitement.

2. Contrairement aux filtres de service et aux filtres simples, les filtres de pare-feu prennent en charge l’action, qui n’est next term ni une action de fin ni une action non terminale, mais une action de contrôle de flux.

   REMARQUE :

   Sur Junos et Junos OS Evolved, next term ne peut pas apparaître comme le dernier terme de l’action. Un terme de filtre où next term est spécifié en tant qu’action mais sans aucune condition de correspondance configurée n’est pas pris en charge.

   • Si le terme correspondant inclut l’action, l’équipement poursuit l’évaluation next term du paquet au terme suivant dans le filtre du pare-feu.

   • Si le terme correspondant n’inclut pas l’action, l’évaluation du paquet par rapport au filtre de pare-feu donné s’arrête next term à ce terme. L’équipement n’évalue pas le paquet par rapport aux termes suivants de ce filtre.

   Un maximum de 1024 next term actions est pris en charge par configuration de filtre de pare-feu. Si vous configurez un filtre de pare-feu qui dépasse cette limite, votre configuration candidate génère une erreur de validation.

3. L’équipement arrête d’évaluer un paquet par rapport à un filtre de pare-feu donné lorsque le paquet correspond à un terme sans l’action next term ou que le paquet ne correspond pas au dernier terme du filtre de pare-feu.

4. Si un paquet local arrive à une interface de routeur associée à un filtre de pare-feu d’entrée, le filtre évalue le paquet deux fois. La première évaluation a lieu dans le moteur de transfert de paquets, qui est l’élément de traitement central du plan de transfert du routeur, et la seconde évaluation a lieu dans le moteur de routage, qui exécute le logiciel du plan de contrôle du routeur.

   REMARQUE :

   Les paquets locaux, c’est-à-dire les blocs de données destinés ou envoyés par le routeur lui-même, contiennent généralement des données de protocole de routage, des données pour les services IP tels que Telnet ou SSH, et des données pour les protocoles administratifs tels que l’Internet Control Message Protocol (ICMP).

   Si la première évaluation du filtre de pare-feu modifie les valeurs du paquet local entrant ou du contexte du paquet, la deuxième évaluation du filtre du pare-feu est basée sur les valeurs de contexte du paquet ou du paquet mises à jour.

   Par exemple, supposons que le filtre inclut une condition de correspondance basée sur la classe de transfert ou la valeur de priorité de perte associée au paquet et que le filtre inclut une action qui modifie la classe de transfert ou la valeur de priorité de perte associée au paquet. Si un paquet local entrant arrive à une interface associée et que l’évaluation du filtre dans le moteur de transfert de paquets modifie (plutôt que d’abandonner) le paquet, l’évaluation du filtre dans le moteur de routage est basée sur le contexte du paquet modifié (plutôt que sur le contexte du paquet d’origine).

Évaluation des paquets sur un seul filtre de pare-feu

Tableau 1 Décrit les comportements de filtrage de paquets au niveau d’une interface d’équipement associée à un filtre de pare-feu unique.

term t_explicit_discard {
    then discard;
}

Bonne pratique : Accepter explicitement tout trafic qui n’est pas spécifiquement ignoré

Vous souhaiterez peut-être qu’un filtre de pare-feu accepte tout trafic qu’il n’ignore pas spécifiquement. Dans ce cas, nous vous recommandons de configurer le filtre de pare-feu avec un terme final qui spécifie l’action d’arrêt accept .

Dans l’exemple d’extrait de code suivant, la configuration du t_allow_all_else terme en tant que terme final dans le filtre de pare-feu configure explicitement le filtre de pare-feu pour qu’il accepte tout trafic que le filtre n’a pas spécifiquement rejeté :

Cette bonne pratique peut simplifier le dépannage du filtre de pare-feu.

Bonne pratique : Rejeter explicitement tout trafic qui n’est pas spécifiquement accepté

D’autre part, vous souhaiterez peut-être qu’un filtre de pare-feu rejette tout trafic qu’il n’accepte pas spécifiquement. Dans ce cas, nous vous recommandons de configurer le filtre de pare-feu avec un terme final qui spécifie l’action d’arrêt reject .

Dans l’exemple d’extrait de code suivant, la configuration du t_deny_all_else terme en tant que terme final dans le filtre de pare-feu configure explicitement le filtre de pare-feu pour qu’il rejette tout trafic que le filtre n’a pas spécifiquement accepté :

Cette bonne pratique peut simplifier le dépannage du filtre de pare-feu.

Plusieurs filtres de pare-feu attachés à une seule interface

Sur les interfaces d’équipement prises en charge, vous pouvez attacher plusieurs filtres de pare-feu à une seule interface. Pour plus d’informations, reportez-vous à la section Comprendre les filtres de pare-feu multiples appliqués sous forme de liste.

Un seul filtre de pare-feu connecté à plusieurs interfaces

Sur les interfaces prises en charge, vous pouvez associer un filtre de pare-feu unique à plusieurs interfaces, et Junos OS crée une instance spécifique de ce filtre de pare-feu pour chaque interface associée.

• Junos OS associe chaque instanciation spécifique à l’interface d’un filtre de pare-feu à un nom spécifique à l’interface généré par le système.

• Pour toutes les count actions dans les termes de filtre, le moteur de transfert de paquets gère des compteurs distincts et spécifiques à l’interface, et Junos OS associe chaque compteur à un nom spécifique à l’interface généré par le système.

• Pour toutes les policer actions dans les termes de filtre, Junos OS crée des instances distinctes et spécifiques à l’interface des actions de contrôleur.

Pour plus d’informations, reportez-vous à la section Présentation des instances de filtre de pare-feu spécifiques à l’interface.