Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Exemple : Configuration d’un filtre de pare-feu sans état pour la protection contre les inondations TCP et ICMP

Cet exemple montre comment créer un filtre de pare-feu sans état qui protège contre les attaques par déni de service TCP et ICMP.

Conditions préalables

Aucune configuration particulière au-delà de l’initialisation de l’équipement n’est requise avant de configurer les filtres de pare-feu sans état.

Présentation

Dans cet exemple, nous créons un filtre de pare-feu sans état appelé protect-RE à policer les paquets TCP et ICMP. Il utilise les mécanismes de contrôle décrits ici :

  • tcp-connection-policer— Ce mécanismes de contrôle limite le trafic TCP à 1 000 000 bits par seconde (b/s) avec une taille d’rafale maximale de 15 000 octets. Le trafic dépassant les deux limites est éliminé.

  • icmp-policer— Ce mécanismes de contrôle limite le trafic ICMP à 1 000 000 milliards de paquets par jour pour une taille d’rafale maximale de 15 000 octets. Le trafic dépassant les deux limites est éliminé.

Lorsque vous spécifiez les limites, la limite de bande passante peut être de 32 000 milliards de paquets par jour à 32 000 000 000 de paquets par jour et la limite de bande passante peut être de 1 500 octets à 100 000 000 octets. Utilisez les abréviations suivantes lors de la définition des limites : k (1 000), m (1 000 000) et g (1 000 000 000).

Chaque policer est intégré à l’action d’un terme de filtre. Cet exemple comprend les termes suivants :

  • tcp-connection-term— Contrôle certains paquets TCP avec une adresse source de 192.168.0.0/24 ou 10.0.0.0/24. Ces adresses sont définies dans la liste des trusted-addresses préfixes.

    Les paquets filtrés incluent tcp-established des paquets La tcp-established condition de correspondance est un alias pour la condition tcp-flags “(ack | rst)”de correspondance du champ de bits, qui indique une session TCP établie, mais pas le premier paquet d’une connexion TCP.

  • icmp-term— Contrôle des paquets ICMP. Tous les paquets ICMP sont comptés dans le icmp-counter compteur.

Remarque :

Vous pouvez déplacer des termes dans le filtre de pare-feu à l’aide de la insert commande. Reportez-vous à l’insérer dans le Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Vous pouvez appliquer un pare-feu sans état sur les côtés d’entrée ou de sortie, ou les deux, d’une interface. Pour filtrer les paquets transitant par l’équipement, appliquez le filtre de pare-feu à n’importe quelle interface non moteur de routage. Pour filtrer les paquets provenant ou destinés au moteur de routage, appliquez le filtre de pare-feu à l’interface de bouclage (lo0).

Figure 1 affiche l’exemple de réseau.

Figure 1 : Filtre de pare-feu pour vous protéger contre les inondations TCP et ICMPFiltre de pare-feu pour vous protéger contre les inondations TCP et ICMP

Comme ce filtre de pare-feu limite le trafic du moteur de routage aux paquets TCP, les protocoles de routage qui utilisent d’autres protocoles de transport pour la couche 4 ne peuvent pas établir de sessions lorsque ce filtre est actif. Pour preuve, cet exemple définit OSPF entre l’équipement R1 et l’équipement R2.

Configuration rapide CLI affiche la configuration de tous les équipements dans Figure 1.

La section #configuration1102__policy-firewall-tcp-icmp-st décrit les étapes relatives à l’équipement R2.

Configuration

Procédure

Configuration rapide CLI

Pour configurer rapidement le filtre de pare-feu sans état, copiez les commandes suivantes dans un fichier texte, supprimez les sauts de ligne, puis collez les commandes dans l’interface de ligne de commande.

Équipement R1

Équipement R2

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous Utiliser l’éditeur CLI en mode configurationà .

Pour configurer le filtre de pare-feu sans état pour jeter :

  1. Configurez les interfaces de l’équipement.

  2. Configurez la session d’appairage BGP.

  3. Configurez le numéro de système autonome (AS) et l’ID du routeur.

  4. Configurez OSPF.

  5. Définir la liste des adresses sécurisées.

  6. Configurez une stratégie pour la publicité des routes directes.

  7. Configurez le dispositif de contrôle TCP.

  8. Créez le dispositif de contrôle ICMP.

  9. Configurez les règles de filtre TCP.

  10. Configurez les règles de filtre ICMP.

  11. Appliquez le filtre à l’interface de bouclage.

Résultats

Confirmez votre configuration en entrant les show interfacescommandes , show protocols, show routing-options show policy-optionset show firewall les commandes du mode de configuration. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Remarque :

Pour vérifier le dispositif de contrôle TCP, vous pouvez utiliser un outil de génération de paquets. Cette tâche n’est pas visible ici.

Affichage du filtre de pare-feu sans état en vigueur

But

Vérifiez la configuration du filtre de pare-feu.

Action

Dans le mode opérationnel, saisissez la show firewall commande.

Sens

La sortie affiche le filtre, le compteur et les mécanismes de contrôle qui sont en vigueur sur l’unité R2.

Utilisation de Telnet pour vérifier la condition établie par tcp dans le filtre de pare-feu TCP

But

Assurez-vous que le trafic Telnet fonctionne comme prévu.

Action

Vérifiez que l’équipement peut établir uniquement des sessions TCP avec des hôtes conformes à cette from tcp-established condition.

  1. À partir de l’unité R2, assurez-vous que la session BGP avec l’équipement R1 est établie.

  2. De l’équipement R2, telnet à l’équipement R1.

  3. De l’équipement R1, telnet à l’équipement R2.

  4. Sur l’unité R2, désactivez la condition de from tcp-established correspondance.

  5. De l’unité R1, réessayer vers Telnet vers l’équipement R2.

Sens

Vérifiez les informations suivantes :

  • Comme prévu, la session BGP est établie. La from tcp-established condition de correspondance ne doit pas bloquer l’établissement de session BGP.

  • De l’équipement R2, vous pouvez telnet vers l’équipement R1. L’équipement R1 n’a pas configuré de filtre de pare-feu. C’est donc le comportement attendu.

  • De l’équipement R1, vous ne pouvez pas telnet vers l’équipement R2. Telnet utilise TCP comme protocole de transport, ce qui peut être surprenant. La cause du manque de connectivité Telnet est la condition de from tcp-established correspondance. Cette condition limite le type de trafic TCP accepté sur l’équipement R2. Une fois cette condition de match désactivée, la session Telnet réussit.

Utilisation de telnet pour vérifier l’état des préfixes approuvés dans le filtre de pare-feu TCP

But

Assurez-vous que le trafic Telnet fonctionne comme prévu.

Action

Vérifiez que l’équipement peut établir uniquement des sessions Telnet avec un hôte à une adresse IP correspondant à l’une des adresses source certifiées. Par exemple, connectez-vous à l’équipement à l’aide de la telnet commande d’un autre hôte avec l’un des préfixes d’adresse approuvé. Vérifiez également que les sessions Telnet avec des adresses source non fiables sont bloquées.

  1. De l’équipement R1, telnet à l’équipement R2 à partir d’une adresse source non fiable.

  2. À partir du nœud R2, ajoutez 172.16/16 à la liste des préfixes approuvés.

  3. De l’unité R1, réessayer vers Telnet vers l’équipement R2.

Sens

Vérifiez les informations suivantes :

  • De l’équipement R1, vous ne pouvez pas telnet vers l’équipement R2 avec une adresse source non fiable. Une fois le préfixe 172.16/16 ajouté à la liste des préfixes approuvés, la requête telnet de l’adresse source 172.16.0.1 est acceptée.

  • L’établissement de session OSPF est bloqué. OSPF n’utilise pas TCP comme protocole de transport. Une fois la condition de correspondance désactivée, l’établissement from protocol tcp de session OSPF n’est pas bloqué.

Utilisation d’OSPF pour vérifier le filtre de pare-feu TCP

But

Assurez-vous que le trafic OSPF fonctionne comme prévu.

Action

Vérifiez que l’équipement ne peut pas établir de connectivité OSPF.

  1. À partir de l’unité R1, vérifiez les sessions OSPF.

  2. À partir de l’unité R2, vérifiez les sessions OSPF.

  3. Dans l’unité R2, retirez la condition de from protocol tcp correspondance.

  4. Dans le nœud R1, revérez les sessions OSPF.

  5. Dans le nœud R2, revérez les sessions OSPF.

Sens

Vérifiez les informations suivantes :

  • L’établissement de session OSPF est bloqué. OSPF n’utilise pas TCP comme protocole de transport. Une fois que la condition de from protocol tcp correspondance est désactivée, l’établissement de session OSPF réussit.

Vérification du filtre de pare-feu ICMP

But

Vérifiez que les paquets ICMP sont contrôlés et comptés. Assurez-vous également que les requêtes ping sont écartées lorsque celles-ci proviennent d’une adresse source non fiable.

Action

  1. Annuler les modifications de configuration apportées aux étapes de vérification précédentes.

    Réactivez les paramètres du pare-feu TCP et supprimez l’adresse source certifiée 172.16/16.

  2. Depuis l’unité R1, ping sur l’interface de bouclage sur le périphérique R2.

  3. À partir du nœud R2, consultez les statistiques du pare-feu.

  4. À partir d’une adresse source non fiable sur l’équipement R1, envoyez une requête ping à l’interface de bouclage de l’équipement R2.

Sens

Vérifiez les informations suivantes :

  • La sortie ping indique que 10 % des paquets sont perdus.

  • Le compteur de paquets ICMP est incrémenté, et le icmp-policer est incrémenté.

  • L’unité R2 n’envoie pas de réponses ICMP à la ping 172.16.0.2 source 172.16.0.1 commande.