SUR CETTE PAGE

Présentation des options d’écran sur les équipements SRX Series
Exemple : Configuration de plusieurs options de filtrage
Présentation des options d’écran du concentrateur de ports du module SRX5000
Comprendre la prise en charge d’IPv6 pour les écrans
Comprendre le contrôle des tunnels IPv6 à l’écran
Exemple : Amélioration de la sécurité du trafic de tunnel avec les options de l’écran de tunnelisation IP

Options d’écran pour la détection et la prévention des attaques

La détection et prévention des attaques détecte et défend le réseau contre les attaques. À l’aide des options d’écran, les plates-formes de sécurité Junos peuvent vous protéger contre différentes attaques internes et externes. Pour plus d’informations, consultez les rubriques suivantes :

Présentation des options d’écran sur les équipements SRX Series

Sur tous les pare-feu SRX Series, les écrans sont divisés en deux catégories :

Écrans basés sur des statistiques
Écrans basés sur les signatures
Comprendre les améliorations apportées à l’architecture des points centraux pour les écrans
Implémentation des options d’écran sur les équipements SRX Series

Écrans basés sur des statistiques

Le tableau 1 répertorie toutes les options d’écran basées sur les statistiques.

Tableau 1 : Options d’écran basées sur les statistiques
Nom de l’option d’écran	Description
`ICMP flood`	Utilisez l’option ICMP flood IDS pour vous protéger contre les attaques ICMP flood. Une attaque par saturation ICMP se produit généralement lorsque les demandes d’écho ICMP utilisent toutes les ressources pour répondre, de sorte que le trafic réseau valide ne peut plus être traité. La valeur de seuil définit le nombre de paquets ICMP par seconde (pps) pouvant être envoyés à la même adresse de destination avant que l’équipement ne rejette d’autres paquets ICMP.
`UDP flood`	Utilisez l’option UDP flood IDS pour vous protéger contre les attaques UDP flood. Une attaque par saturation UDP se produit lorsqu’un attaquant envoie des paquets IP contenant un datagramme UDP dans le but de ralentir les ressources, de sorte que les connexions valides ne puissent plus être gérées. La valeur de seuil définit le nombre de paquets UDP par seconde pouvant être envoyés à la même adresse IP de destination. Lorsque le nombre de paquets dépasse cette valeur au cours d’une période de 1 seconde, l’équipement génère une alarme et abandonne les paquets suivants pour le reste de cette seconde.
`TCP SYN flood source`	Utilisez l’option TCP SYN flood source IDS pour définir la valeur de seuil source. La valeur de seuil définit le nombre de segments SYN à recevoir par seconde avant que l’équipement ne commence à abandonner les demandes de connexion. La plage applicable est de 4 à 500 000 SYN pps.
`TCP SYN flood destination`	Utilisez l’option IDS de destination SYN flood pour définir la valeur de seuil de destination. La valeur de seuil définit le nombre de segments SYN reçus par seconde avant que l’équipement ne commence à abandonner les demandes de connexion. La plage applicable est de 4 à 500 000 SYN pps.
`TCP SYN flood`	Utilisez l’option TCP SYN flood IDS pour détecter et empêcher les attaques SYN flood. De telles attaques se produisent lorsque l’hôte qui se connecte envoie continuellement des requêtes TCP SYN sans répondre aux réponses ACK correspondantes.
`TCP port scan`	Utilisez l’option IDS d’analyse des ports TCP pour empêcher les attaques par analyse des ports. Le but de cette attaque est d’analyser les services disponibles dans l’espoir qu’au moins un port réponde, identifiant ainsi un service à cibler.
`TCP SYN-ACK-ACK proxy`	Utilisez l’option d’écran proxy TCP SYN-ACK-ACK pour empêcher l’attaque SYN-ACK-ACK. Une fois que le nombre de connexions à partir de la même adresse IP atteint le seuil de proxy SYN-ACK-ACK, les pare-feu SRX Series exécutant Junos OS rejettent toute autre demande de connexion provenant de cette adresse IP.
`ICMP IP sweep`	Utilisez l’option IDS de balayage IP ICMP pour détecter et empêcher une attaque par balayage IP. Une attaque par balayage IP se produit lorsqu’un attaquant envoie des requêtes d’écho ICMP (pings) à plusieurs adresses de destination. Si un hôte cible répond, la réponse révèle l’adresse IP de la cible à l’attaquant. Si l’équipement reçoit 10 demandes d’écho ICMP dans le nombre de microsecondes spécifié dans cette instruction, il signale qu’il s’agit d’une attaque par balayage IP et rejette le onzième et tous les autres paquets ICMP de cet hôte pour le reste de la seconde. La valeur de seuil définit le nombre maximal de microsecondes pendant lesquelles jusqu’à 10 demandes d’écho ICMP provenant du même hôte sont autorisées dans l’équipement.
`TCP SYN flood alarm`	Utilisez l’option IDS d’alarme d’inondation TCP SYN pour définir la valeur seuil d’alarme. La valeur de seuil définit le nombre de connexions proxy semi-complètes par seconde auxquelles l’appareil effectue des entrées dans le journal des alarmes d’événements. La plage est comprise entre 1 et 500 000 requêtes par seconde.
`TCP SYN flood attack`	Utilisez l’option IDS d’attaque par saturation TCP SYN pour définir la valeur du seuil d’attaque. La valeur de seuil définit le nombre de paquets SYN par seconde requis pour déclencher la réponse du proxy SYN. La plage est comprise entre 1 et 500 000 pps proxys.
`UDP udp sweep`	Utilisez l’option UDP udp sweep IDS pour détecter et empêcher les attaques UDP sweep. Lors d’une attaque par balayage UDP, un attaquant envoie des paquets UDP à l’équipement cible. Si l’équipement répond à ces paquets, l’attaquant reçoit une indication indiquant qu’un port de l’équipement cible est ouvert, ce qui rend le port vulnérable aux attaques. Si un hôte distant envoie des paquets UDP à 10 adresses en 0,005 seconde (5 000 microsecondes), l’équipement signale cela comme une attaque par balayage UDP. Si l’option n’est pas définie, l’équipement `alarm-without-drop` rejette le onzième paquet UDP et tous les autres paquets UDP de cet hôte pour le reste de la période de seuil spécifiée. La valeur de seuil définit le nombre de microsecondes pendant lesquelles l’équipement accepte 10 paquets UDP de la même source distante vers des adresses de destination différentes.

À partir de Junos OS version 15.1X49-D20 et de Junos OS version 17.3R1, le pare-feu ne génère qu’un seul message de journal toutes les secondes, quel que soit le nombre de paquets déclenchant la limite de session source ou de destination. Ce comportement s’applique aux écrans de protection contre les inondations avec protection contre TCP-Synflood-src-basedles inondations , , TCP-Synflood-dst-basedet UDP.

Écrans basés sur les signatures

Le tableau 2 répertorie toutes les options d’écran basées sur les signatures.

Tableau 2 : Options d’écran basées sur les signatures
Nom de l’option d’écran	Description
`TCP Winnuke`	Activez ou désactivez l’option TCP WinNuke attacks IDS. WinNuke est une attaque par déni de service (DoS) ciblant tout ordinateur sur Internet exécutant Windows.
`TCP SYN fragment`	Utilisez l’option IDS d’attaque par fragment TCP SYN pour supprimer tous les fragments de paquets utilisés pour l’attaque. Une attaque par fragment SYN inonde l’hôte cible de fragments de paquets SYN. L’hôte met ces fragments en cache en attendant l’arrivée des fragments restants afin de pouvoir les réassembler. Le flot de connexions qui ne peuvent pas être effectuées finit par remplir la mémoire tampon de l’hôte. Aucune autre connexion n’est possible et le système d’exploitation de l’hôte peut être endommagé.
`TCP no flag`	Utilisez l’option TCP tcp no flag IDS pour supprimer les paquets TCP illégaux avec un champ flag manquant ou mal formé. La valeur de seuil définit le nombre d’en-têtes TCP sans drapeaux définis. Un en-tête de segment TCP normal a au moins un indicateur de contrôle défini.
`TCP SYN FIN`	Utilisez l’option TCP SYN FIN IDS pour détecter une combinaison illégale d’indicateurs que les attaquants peuvent utiliser pour consommer des sessions sur l’équipement cible, entraînant ainsi une condition de déni de service (DoS).
`TCP land`	Activez ou désactivez l’option IDS d’attaque terrestre TCP. Les attaques terrestres se produisent lorsqu’un attaquant envoie des paquets SYN usurpés contenant l’adresse IP de la victime à la fois comme adresse IP de destination et comme adresse IP source.
`TCP FIN no ACK`	Utilisez l’option IDS du bit FIN sans bit ACK pour détecter une combinaison illégale d’indicateurs et rejeter les paquets qui ont cette combinaison.
`ICMP ping of death`	Utilisez l’option ping of death IDS pour détecter et rejeter les paquets ICMP surdimensionnés et irréguliers. Bien que la spécification TCP/IP exige une taille de paquet spécifique, de nombreuses implémentations ping autorisent des tailles de paquet plus importantes. Des paquets plus volumineux peuvent déclencher toute une série d’effets indésirables du système, notamment des plantages, des blocages et des redémarrages. Le ping de la mort se produit lorsque des paquets IP sont envoyés qui dépassent la longueur maximale légale (65 535 octets).
`ICMP fragment`	Utilisez l’option IDS de fragment ICMP pour détecter et supprimer n’importe quelle trame ICMP avec l’indicateur Plus de fragments défini ou avec un décalage indiqué dans le `offset` champ.
`ICMP large`	Utilisez l’option ICMP grand IDS pour détecter et supprimer toute trame ICMP dont la longueur IP est supérieure à 1024 octets.
`IP unknown protocol`	Utilisez l’option IDS de protocole IP inconnu pour ignorer toutes les trames IP reçues avec des numéros de protocole supérieurs à 137 pour IPv4 et 139 pour IPv6. Ces numéros de protocole ne sont ni définis ni réservés.
`IP bad option`	Utilisez l’option IP bad IDS pour détecter et supprimer tout paquet avec une option IP mal formatée dans l’en-tête du paquet IP. L’appareil enregistre l’événement dans la liste des compteurs d’écran de l’interface d’entrée. Cette option d’écran s’applique aux protocoles IPv4 et IPv6.
`IP strict source route option`	Utilisez l’option IP strict source route IDS pour détecter les paquets dont l’option IP est 9 (routage source strict) et enregistrer l’événement dans la liste des compteurs d’écran de l’interface entrante. Cette option spécifie la liste complète des routes qu’un paquet doit emprunter pour son voyage de la source à la destination. La dernière adresse de la liste remplace l’adresse dans le champ de destination. Actuellement, cette option d’écran ne s’applique qu’à IPv4.
`IP loose source route option`	Utilisez l’option IP loose source route IDS pour détecter les paquets dont l’option IP est 3 (routage source lâche) et enregistrer l’événement dans la liste des compteurs d’écran de l’interface entrante. Cette option spécifie une liste partielle de routes pour qu’un paquet effectue son voyage de la source à la destination. Le paquet doit se dérouler dans l’ordre des adresses spécifié, mais il est autorisé à passer par d’autres périphériques entre ceux spécifiés. L’en-tête de routage de type 0 de l’option de route source lâche est le seul en-tête associé défini en IPv6.
`IP source route option`	Utilisez l’option IDS de la route source IP pour détecter les paquets et enregistrer l’événement dans la liste des compteurs d’écran de l’interface entrante.
`IP stream option`	Utilisez l’option IP stream IDS pour détecter les paquets où l’option IP est 8 (stream ID) et enregistrez l’événement dans la liste des compteurs d’écran de l’interface entrante. Cette option permet à l’identificateur de flux SATNET 16 bits d’être acheminé sur des réseaux qui ne prennent pas en charge les flux. Actuellement, cette option d’écran ne s’applique qu’à IPv4.
`IP block fragment`	Activez ou désactivez le blocage de la fragmentation des paquets IP. Lorsque cette fonctionnalité est activée, Junos OS refuse les fragments IP sur une zone de sécurité et bloque tous les fragments de paquets IP reçus au niveau des interfaces liées à cette zone.
`IP record route option`	Utilisez l’option IP record route IDS pour détecter les paquets pour lesquels l’option IP est 7 (route d’enregistrement) et enregistrez l’événement dans la liste des compteurs d’écran de l’interface entrante. Cette option enregistre les adresses IP des périphériques réseau le long du chemin parcouru par le paquet IP. Actuellement, cette option d’écran ne s’applique qu’à IPv4.
`IP timestamp option`	Utilisez l’option IDS d’horodatage IP pour détecter les paquets pour lesquels la liste d’options IP inclut l’option 4 (horodatage Internet) et enregistrer l’événement dans la liste des compteurs d’écran de l’interface entrante. Cette option enregistre l’heure (en temps universel) à laquelle chaque équipement réseau reçoit le paquet au cours de son trajet du point d’origine à sa destination. Actuellement, cette option d’écran ne s’applique qu’à IPv4.
`IP security option`	Utilisez l’option IP security IDS pour détecter les paquets pour lesquels l’option IP est 2 (sécurité) et enregistrez l’événement dans la liste des compteurs d’écran pour l’interface entrante. Actuellement, cette option d’écran ne s’applique qu’à IPv4.
`IP spoofing`	Utilisez l’option IDS d’usurpation d’adresse IP pour empêcher les attaques par usurpation d’identité. L’usurpation d’adresse IP se produit lorsqu’une adresse source non valide est insérée dans l’en-tête du paquet pour faire croire que le paquet provient d’une source fiable.
`IP tear drop`	Utilisez l’option IP tear drop IDS pour bloquer les attaques en teardrop. Les attaques en goutte d’eau se produisent lorsque des paquets IP fragmentés se chevauchent et provoquent le plantage de l’hôte qui tente de les réassembler. L’option de goutte d’eau indique à l’appareil d’abandonner tous les paquets qui présentent une telle divergence. Les attaques en goutte-d’eau exploitent le réassemblage de paquets IP fragmentés.

Comprendre les améliorations apportées à l’architecture des points centraux pour les écrans

À partir de Junos OS version 15.1X49-D30 et de Junos OS version 17.3R1, sur les équipements SRX5400, SRX5600 et SRX5800, l’architecture du point central a été améliorée pour obtenir un nombre plus élevé de connexions par seconde (CPS). En raison de ces améliorations, la session du point central et le traitement des paquets du point central ont été déplacés du point central vers l’unité de traitement des services (SPU).

Auparavant, le point central avait une limite de session et si aucune ressource (entrée de limite de session) n’était disponible, le paquet était toujours autorisé par la limite de session. Désormais, le point central et l’USP ont tous deux des limites de session. S’il n’y a pas de ressources disponibles dans le point central, mais que des ressources sont disponibles dans le SPU, le point central ne peut pas limiter les sessions, mais l’USP peut limiter les sessions.

Les scénarios suivants décrivent quand le point central et l’unité SPU déterminent s’il faut autoriser ou abandonner un paquet.

Lorsque le point central n’a pas d’entrée de limite de session et que l’USP a une entrée de limite de session :
1. Si le compteur de limite de session de l’USP est supérieur à la valeur seuil, le paquet est abandonné.
2. Si le compteur de limite de session de l’USP n’est pas supérieur à la valeur seuil, le paquet est autorisé.
Lorsque le SPU n’a pas d’entrée de limite de session :
1. Si le compteur de limite de session de l’USP est supérieur à la valeur seuil, le paquet est autorisé.
2. Si le compteur de limite de session de l’USP n’est pas supérieur à ththreshold, le paquet est autorisé.

Note:

L’envoi d’un message supplémentaire au point central pour maintenir l’exactitude du nombre de sessions peut avoir un impact sur le nombre de connexions par seconde (CPS) pour les écrans. Cela a un impact sur la limite de sessions source ou de destination.

Les statistiques de trafic global dépourvues d’un point central peuvent avoir un impact sur certains écrans d’affichage globaux. Seul le cookie SYN n’a pas de vue globale, et les statistiques globales de trafic sont gérées par le SPU, de sorte que le compteur peut ne pas être aussi précis qu’auparavant. Pour d’autres écrans basés sur des statistiques, gérés à la fois par le point central et par le SPU, les compteurs sont précis.

Auparavant, les écrans basés sur les statistiques n’étaient gérés que par le point central et le journal et l’interruption SNMP pouvaient être strictement limités en débit. Désormais, le point central et le SPU peuvent générer le journal et l’interruption SNMP indépendamment. Par conséquent, le journal et l’interruption SNMP peuvent être plus volumineux qu’auparavant.

Implémentation des options d’écran sur les équipements SRX Series

Le tableau ci-dessous répertorie toutes les options d’écran implémentées sur les pare-feu SRX Series et sont prises en charge sur tous les pare-feu SRX Series.

Tableau 3 : options d’écran implémentées sur les équipements SRX Series
Écrans	Implémenté sur NP/CP/SPU	Prise en charge en mode Hash	Prise en charge en mode SOF
`icmp-flood`	NP	Oui	Oui
`udp-flood`	NP	Oui	Oui
`winnuke`	NP	Oui	Oui
`tcp-port-scan`	CP+SPU	Oui	Oui
`udp-port-scan`	CP+SPU	Oui	Oui
`address-sweep`	CP+SPU	Oui	Oui
`tcp-sweep`	CP+SPU	Oui	Oui
`udp-sweep`	CP+SPU	Oui	Oui
`tear-drop`	SPU	Oui	NON
`syn-flood`	SPU	Oui	Oui
`syn-flood-src`	NP	Oui	Oui
`syn-flood-dst`	NP	Oui	Oui
`ip-spoofing`	SPU	Oui	Oui
`ping-of-death`	NP	Oui	Oui
`ip-option-src-route`	NP	Oui	Oui
`land`	NP	Oui	Oui
`syn-fragment`	NP	Oui	Oui
`tcp-no-flag`	NP	Oui	Oui
`unknown-protocol`	NP	Oui	Oui
`ip-option-bad`	NP	Oui	Oui
`ip-option-record-route`	NP	Oui	Oui
`ip-option-timestamp`	NP	Oui	Oui
`ip-option-security`	NP	Oui	Oui
`ip-option-loose-src-route`	NP	Oui	Oui
`ip-option-strict-src-route`	NP	Oui	Oui
`ip-option-stream`	NP	Oui	Oui
`icmp-fragment`	NP	Oui	Oui
`icmp-large-pkt`	NP	Oui	Oui
`syn-fin`	NP	Oui	Oui
`fin-no-ack`	NP	Oui	Oui
`src-session-limit`	CP+SPU	Oui	Oui
`syn-ack-ack-proxy`	SPU	Oui	Oui
`block-fragment`	NP	Oui	Oui
`dst-session-limit`	CP+SPU	Oui	Oui
`ipv6-ext-header`	SPU	Oui	Non
`ipv6-ext-hbyh-option`	SPU	Oui	Non
`ipv6-ext-dst-option`	SPU	Oui	Non
`ipv6-ext-header-limit`	SPU	Oui	Non
`ipv6-malformed-header`	SPU	Oui	Non
`icmpv6-malformed-packet`	SPU	Oui	Non
`ip-tunnel-summary`	SPU	Oui	Non

Note:

Toutes les fonctionnalités d’écran prises en charge sur la carte IOC1 sont prises en charge sur les cartes IOC2 et IOC3. Sur le Gamme SRX5000 des périphériques et sur le périphérique SRX4600, l’unité de processeur réseau (NPU) d’une carte IOC2 est remplacée par l’unité de recherche (LU).

Exemple : Configuration de plusieurs options de filtrage

Cet exemple montre comment créer un profil de service de détection d’intrusion (IDS) pour plusieurs options de filtrage.

Exigences
Aperçu
Configuration
Vérification

Exigences

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cette fonctionnalité.

Aperçu

Dans une zone de sécurité, vous pouvez appliquer un profil IDS à plusieurs options de filtrage. Dans cet exemple, nous configurons les options de filtrage suivantes :

Dépistage ICMP
Filtrage IP
Criblage TCP
Criblage UDP

Ces options de filtrage sont affectées à une zone de méfiance.

Configuration

Configuration rapide de l’interface de ligne de commande
Procédure

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Entrez commit à partir du mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, reportez-vous Using the CLI Editor in Configuration Mode à la Junos OS CLI User Guidesection .

Pour configurer un profil IDS pour plusieurs options de filtrage :

Configurez les options de filtrage ICMP.

Configurez les options de filtrage IP.

Configurez les options de filtrage TCP.

Configurez les options de filtrage UDP.

Attachez le profil IDS à la zone.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show security screen ids-option screen-config commandes et show security zones . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Vérification

Vérification du profil IDS pour plusieurs options de filtrage

But
Action

But

Vérifiez que le profil IDS pour les différentes options de filtrage est correctement configuré.

Action

Entrez la show security screen ids-option screen-config Screen object status commande et show security zones à partir du mode opérationnel.

Note:

Sur tous les pare-feu SRX Series, la valeur du seuil d’alarme d’inondation de synchronisation TCP n’indique pas le nombre de paquets abandonnés, mais affiche les informations sur les paquets une fois le seuil d’alarme atteint.

Le cookie de synchronisation ou le proxy ne supprime jamais de paquets ; Par conséquent, l’action alarm-without-drop (not drop) est affichée dans le journal système.

Présentation des options d’écran du concentrateur de ports du module SRX5000

Le concentrateur de ports de module de la gamme SRX5000 (SRX5K-MPC) prend en charge les options d’écran de Junos OS. Les options d’écran sécurisent une zone en inspectant, puis en autorisant ou en refusant toutes les tentatives de connexion qui nécessitent de traverser une interface liée à cette zone.

À l’aide des options d’écran, votre dispositif de sécurité peut vous protéger contre différentes attaques internes et externes, notamment les attaques SYN flood, les attaques UDP flood et les attaques port scan. Junos OS applique des vérifications d’écran au trafic avant le traitement de la stratégie de sécurité, ce qui réduit l’utilisation des ressources.

Les options d’écran sont divisées en deux catégories :

Écrans basés sur des statistiques
Écrans basés sur les signatures

Ecrans basés sur des statistiques
Différences entre IOC1 et IOC2
Écrans basés sur les signatures

Ecrans basés sur des statistiques

Toutes les fonctions d’écran implémentées sur un SRX5K-MPC sont indépendantes du mode Couche 2 ou Couche 3. Les protections contre les inondations sont utilisées pour se défendre contre les attaques SYN Flood, les attaques par saturation des tables de session, les attaques par déni de service (DoS) de pare-feu et les attaques DoS réseau.

Les quatre types suivants de protection contre les inondations basées sur des seuils sont exécutés sur chaque processeur pour IPv4 et IPv6 :

Protection contre les inondations basée sur UDP
Protection contre les inondations basée sur ICMP
Protection contre les inondations SYN basée sur la source TCP
Protection contre le flood SYN basée sur la destination TCP

Note:

Si l’un des deux types de protection contre les inondations TCP SYN est configuré sur une zone, le second type de protection contre les inondations TCP SYN est automatiquement activé sur la même zone. Ces deux types de protections fonctionnent toujours ensemble.

Chaque type de protection contre les inondations est basé sur un seuil, et le seuil est calculé par zone sur chaque microprocesseur. Si le flooding est détecté sur une puce de microprocesseur, ce microprocesseur particulier prend des mesures contre les paquets incriminés en fonction de la configuration :

Action par défaut (report and drop) : la journalisation d’écran et la création de rapports sont effectuées sur un SPU, de sorte que les paquets incriminés doivent être transférés au point central ou au SPU à cette fin. Pour protéger les SPU contre les inondations, seul le premier paquet incriminé pour chaque écran d’une zone est envoyé à l’USP pour journalisation et génération de rapports chaque seconde. Le reste des paquets incriminés est compté et déposé dans un microprocesseur.

Par exemple, supposons que le flooding UDP est configuré au niveau d’une interface logique avec un seuil défini sur 5 000 paquets par seconde. Si les paquets UDP arrivent à un rythme de 20 000 par seconde, environ 5 000 paquets UDP sont transférés chaque seconde au point central ou SPU et les paquets restants sont détectés comme étant en cours d’inondation. Cependant, un seul paquet d’inondation UDP est envoyé à l’USP pour la journalisation et la création de rapports chaque seconde. Les paquets restants sont déposés dans le microprocesseur.
Alarm only (alarm-without-drop) : un paquet incriminé détecté par la protection d’écran n’est pas abandonné. Il ignore le reste des vérifications d’écran et est transféré au point central ou SPU avec le résultat de l’écran copié dans son méta-en-tête. Il n’est pas comptabilisé comme un paquet abandonné.

Différences entre IOC1 et IOC2

Le comportement des écrans est le même, que l’appareil dispose d’une carte IOC1 ou IOC2. Cependant, il existe des différences dans les valeurs seuils pour les écrans basés sur les statistiques. Le Tableau 4 répertorie les options d’écran basées sur des statistiques et le comportement des écrans selon que l’appareil est équipé d’une carte IOC1 ou IOC2.

Tableau 4 : Options d’écran basées sur les statistiques
Nom de l’option d’écran	Description	IOC1	IOC2
`ICMP flood`	Définit la valeur du seuil d’inondation ICMP. L’option d’écran d’inondation ICMP est utilisée pour se protéger contre les attaques d’inondation ICMP. Une attaque par saturation ICMP se produit généralement lorsque les demandes d’écho ICMP utilisent toutes les ressources pour répondre, de sorte que le trafic réseau valide ne peut plus être traité. La valeur de seuil définit le nombre de paquets ICMP par seconde autorisés à envoyer une requête ping à la même adresse de destination avant que l’équipement ne rejette d’autres paquets ICMP.	Si le trafic entrant dépasse le seuil pps, soit les paquets sont abandonnés, soit une alarme est déclenchée.	Sur les équipements de la gamme SRX5000 avec carte IOC2, la configuration de l’écran pour les puces de recherche (LU) a changé. Il y a quatre puces LU dans chaque carte IOC2. Si le trafic entrant dépasse la valeur seuil pps, les paquets sont abandonnés. Par exemple, si l’utilisateur spécifie la valeur seuil de 1000 pps, nous configurons 250 pps sur chaque puce LU en interne, de sorte que la valeur seuil de 1000 pps soit répartie uniformément entre les 4 puces LU. Comme résultat attendu, l’utilisateur obtient la valeur seuil globale de 1000 pps. Sur les équipements de la gamme SRX5000, lorsque la carte IOC2 est en mode de déchargement des services, une seule puce LU fonctionne. Si le débit de trafic entrant dépasse la valeur seuil, les paquets sont abandonnés en raison du comportement attendu.
`UDP flood`	Définit la valeur du seuil de saturation UDP. L’option d’écran d’inondation UDP est utilisée pour se protéger contre les attaques d’inondation UDP. L’attaque par saturation UDP se produit lorsqu’un attaquant envoie des paquets IP contenant des datagrammes UDP dans le but de ralentir les ressources, de sorte que les connexions valides ne peuvent plus être gérées. La valeur de seuil définit le nombre de pps UDP autorisés à envoyer une requête ping à la même paire adresse IP/port de destination. Lorsque le nombre de paquets dépasse cette valeur au cours d’une période de 1 seconde, l’équipement génère une alarme et abandonne les paquets suivants pour le reste de cette seconde.	Si le trafic entrant dépasse le seuil pps, soit les paquets sont abandonnés, soit une alarme est déclenchée.	Sur les équipements de la gamme SRX5000 avec carte IOC2, la configuration de l’écran pour les puces de recherche (LU) a changé. Il y a quatre puces LU dans chaque carte IOC2. Si le trafic entrant dépasse la valeur seuil pps, les paquets sont abandonnés. Par exemple, si l’utilisateur spécifie la valeur seuil de 1000 pps, nous configurons 250 pps sur chaque puce LU en interne, de sorte que la valeur seuil de 1000 pps soit répartie uniformément entre les 4 puces LU. Comme résultat attendu, l’utilisateur obtient la valeur seuil globale de 1000 pps. Sur les équipements de la gamme SRX5000, lorsque la carte IOC2 est en mode de déchargement des services, une seule puce LU fonctionne. Si le débit de trafic entrant dépasse la valeur seuil, les paquets sont abandonnés en raison du comportement attendu.
`TCP SYN flood source`	Définit la valeur seuil de la source d’inondation TCP SYN. La valeur de seuil définit le nombre de segments SYN à recevoir par seconde avant que l’équipement ne commence à abandonner les demandes de connexion. La plage applicable est de 4 à 500 000 SYN pps.	Si le trafic entrant dépasse le seuil pps, soit les paquets sont abandonnés, soit une alarme est déclenchée.	Sur les équipements de la gamme SRX5000 avec carte IOC2, la configuration de l’écran pour les puces de recherche (LU) a changé. Il y a quatre puces LU dans chaque carte IOC2. Si le trafic entrant dépasse la valeur seuil pps, les paquets sont abandonnés. Par exemple, si l’utilisateur spécifie la valeur seuil de 1000 pps, nous configurons 250 pps sur chaque puce LU en interne, de sorte que la valeur seuil de 1000 pps soit répartie uniformément entre les 4 puces LU. Comme résultat attendu, l’utilisateur obtient la valeur seuil globale de 1000 pps. Sur les équipements de la gamme SRX5000, lorsque la carte IOC2 est en mode de déchargement des services, une seule puce LU fonctionne. Si le débit de trafic entrant dépasse la valeur seuil, les paquets sont abandonnés en raison du comportement attendu.
`TCP SYN flood destination`	Définit la valeur seuil de destination TCP SYN flood. La valeur de seuil définit le nombre de segments SYN reçus par seconde avant que l’équipement ne commence à abandonner les demandes de connexion. La plage applicable est de 4 à 500 000 SYN pps.	Si le trafic entrant dépasse le seuil pps, soit les paquets sont abandonnés, soit une alarme est déclenchée.	Sur les équipements de la gamme SRX5000 avec carte IOC2, la configuration de l’écran pour les puces de recherche (LU) a changé. Il y a quatre puces LU dans chaque carte IOC2. Si le trafic entrant dépasse la valeur seuil pps, les paquets sont abandonnés. Par exemple, si l’utilisateur spécifie la valeur seuil de 1000 pps, nous configurons 250 pps sur chaque puce LU en interne, de sorte que la valeur seuil de 1000 pps soit répartie uniformément entre les 4 puces LU. Comme résultat attendu, l’utilisateur obtient la valeur seuil globale de 1000 pps. Sur les équipements de la gamme SRX5000, lorsque la carte IOC2 est en mode de déchargement des services, une seule puce LU fonctionne. Si le débit de trafic entrant dépasse la valeur seuil, les paquets sont abandonnés en raison du comportement attendu.

Note:

Sur les appareils SRX5400, SRX5600 et SRX5800, la valeur seuil d’écran est définie pour chaque IOC dans le DUT pour les liaisons enfants LAG/LACP et RLAG/RETH. Lorsque vous avez des interfaces enfants d’IOC croisés dans le cadre d’interfaces LAG/LACP ou RETH/RLAG et que le trafic entrant traverse également plusieurs liaisons enfants à travers des IOC, définissez la valeur de seuil pour qu’elle corresponde au nombre total de paquets transmis à l’écran à partir de plusieurs IOC avec le nombre total attendu de paquets par seconde (pps) à l’interface de sortie.

Écrans basés sur les signatures

Le SRX5K-MPC fournit des options d’écran basées sur les signatures ainsi que des contrôles d’intégrité sur le paquet reçu.

Parfois, les paquets reçus par l’équipement sont mal formés ou non valides, et peuvent endommager l’appareil et le réseau. Ces paquets doivent être abandonnés au cours des étapes initiales du traitement.

Pour les options d’écran basées sur les signatures et les vérifications d’intégrité, le contenu du paquet, y compris l’en-tête du paquet, les bits d’état et de contrôle, et les en-têtes d’extension (pour IPv6), est examiné. Vous pouvez configurer les écrans en fonction de vos besoins, tandis que les vérifications d’intégrité des paquets sont effectuées par défaut.

Les contrôles d’intégrité des paquets et les options d’écran sont effectués sur les paquets reçus sur les interfaces entrantes.

Le processeur effectue des vérifications d’intégrité et exécute certaines fonctions d’écran pour détecter les paquets d’entrée malveillants et mal formés reçus des interfaces physiques. Les paquets qui échouent à un contrôle d’intégrité sont comptés et abandonnés.

Les vérifications d’intégrité des paquets suivantes sont prises en charge :

Vérification de l’intégrité IPv4
Vérification de l’intégrité IPv6

Les fonctionnalités d’écran suivantes sont prises en charge :

Écran basé sur IP
Écran basé sur UDP
Écran basé sur TCP
Écran basé sur ICMP

Les fonctionnalités d’écran s’appliquent aux paquets IPv4 et IPv6, à l’exception des écrans d’options IP, qui ne s’appliquent qu’aux paquets IPv4. Si un paquet est détecté par une option d’écran, il ignore le reste des vérifications d’écran et est transféré au point central ou à l’unité de traitement des services (SPU) pour la journalisation et la collecte des statistiques.

Note:

Sur les appareils SRX5400, SRX5600 et SRX5800, le premier écran de signature de chemin est exécuté en premier, suivi de l’écran de chemin bad-inner-header rapide.

Comprendre la prise en charge d’IPv6 pour les écrans

Juniper Networks fournit divers mécanismes de détection et de défense au niveau des zones et des stratégies pour lutter contre les exploits à tous les stades de leur exécution. Les options d’écran se trouvent au niveau de la zone. Les options d’écran de Junos OS sécurisent une zone en l’inspectant, puis en autorisant ou en refusant toutes les tentatives de connexion nécessitant de traverser une interface liée à cette zone.

Vous pouvez configurer des options d’écran pour vérifier et filtrer les paquets en fonction des en-têtes d’extension IPv6, des en-têtes de paquets et du trafic ICMPv6. En fonction de votre configuration, l’écran peut supprimer des paquets, créer des journaux et fournir des statistiques plus élevées sur le trafic IPv6.

Vérification et filtrage des en-têtes d’extension IPv6
Nombre maximal d’en-têtes d’extension
En-têtes d’extension de mauvaise option
Vérification et filtrage ICMPv6
Vérification et filtrage des en-têtes de paquets IPv6

Vérification et filtrage des en-têtes d’extension IPv6

Vous pouvez utiliser l’instruction ipv6-extension-header pour filtrer de manière sélective un ou plusieurs en-têtes d’extension. Le Tableau 5 répertorie les en-têtes d’extension IPv6 courants et leurs valeurs de type.

Tableau 5 : en-têtes d’extension IPv6 et valeurs de type
Nom de l’en-tête	Valeur du type d’en-tête	Normes de l’Internet
Authentification	51	RFC 2460 (en anglais)
Encapsulation de la charge utile de sécurité	50	RFC 2460 (en anglais)
Protocole d’identification de l’hôte	139	RFC 5201
Destination Options Option de nonce ILNP Option d’adresse du domicile Option d’identification de ligne Option de limite d’encapsulation de tunnel	60	RFC 2460 (en anglais)
Fragment	44	RFC 2460 (en anglais)
Options saut par saut L’option CALIPSO Option RPL Option SFM DPD Option de charge utile Jumbo Option de démarrage rapide Option d’alerte de routeur	0	RFC 2460 (en anglais)
Mobilité	135	RFC 6275
Pas de suivant	59	RFC 2460 (en anglais)
Routage	43	RFC 2460 (en anglais)
Par Shim6	140	RFC 5533

Nombre maximal d’en-têtes d’extension

Vous pouvez spécifier le nombre maximal d’en-têtes d’extension autorisés dans un paquet à l’aide de l’instruction ipv6-extension-header-limit . Bien que le nombre maximal d’en-têtes d’extension dans un paquet ne soit pas explicitement spécifié, l’ordre des en-têtes d’extension est recommandé dans la RFC 2460 :

En-tête Options saut par saut
En-tête Options de destination
En-tête de routage
En-tête d’extension de fragment
En-tête d’authentification
En-tête d’encapsulation de la charge utile de sécurité
En-tête Options de destination

Chaque en-tête d’extension doit apparaître au plus une fois, à l’exception de l’en-tête des options de destination, qui doit apparaître au maximum deux fois (une fois avant un en-tête de routage et une fois avant l’en-tête de protocole de couche supérieure).

Le numéro maximal d’en-tête d’extension basé sur la RFC 2460 est 7. D’autres en-têtes d’extension ont été définis par des RFC ultérieurs. Il est recommandé que le nombre maximal d’en-têtes d’extension soit compris entre 0 et 32.

En-têtes d’extension de mauvaise option

Vous pouvez configurer des écrans pour détecter et abandonner tout paquet avec une option IP mal formatée dans l’en-tête du paquet IP (IPv4 ou IPv6). L’appareil enregistre l’événement dans la liste des compteurs d’écran de l’interface d’entrée. Le Tableau 6 répertorie les critères clés utilisés par l’équipement pour filtrer les paquets à la recherche d’options incorrectes.

Tableau 6 : Critères de sélection des en-têtes d’extension de mauvaise option
Critères de sélection	Normes de l’Internet	Description
L’en-tête de l’extension de routage se trouve après l’en-tête du fragment	RFC 2460 (en anglais)	L’ordre des en-têtes d’extension dans un paquet est défini ; Par conséquent, l’en-tête Fragment Extension doit se trouver après l’en-tête de routage.
Paramètre d’alerte routeur incorrect	RFC 2711 (en anglais)	Cette option se trouve dans l’en-tête saut par saut et dans l’implémentation de Junos OS : Il ne peut y avoir qu’une seule option de ce type par en-tête saut par saut La longueur de l’en-tête doit être égale à 2. Il ne peut y avoir qu’une seule option d’alerte de routeur dans un en-tête d’extension.
Plus d’une option de tampon dos à dos	brouillon-krishnan-ipv6-hopbyhop-00	Ce type de trafic est filtré sous forme de paquets d’erreur.
Charge utile non nulle dans l’option PadN	RFC 4942 (en anglais)	Le système vérifie que le PadN n’a que zéro octet dans sa charge utile.
Remplissage au-delà de la limite des huit octets suivants	RFC 4942 (en anglais)	Le système vérifie s’il y a un remplissage au-delà de la limite des huit octets suivants. Il n’y a aucune raison légitime de remplir au-delà de la limite des huit octets suivants.
Charge utile Jumbo avec charge utile d’en-tête IPv6 non nulle	RFC 2675 (en anglais)	Le champ de longueur de la charge utile dans l’en-tête IPv6 doit être mis à zéro dans chaque paquet porteur de l’option de charge utile jumbo.

Vérification et filtrage ICMPv6

Vous pouvez activer la vérification et le filtrage ICMPv6. Le système vérifie ensuite si le paquet ICMPv6 reçu correspond aux critères définis et effectue l’action spécifiée sur les paquets correspondants. Voici quelques-uns des principaux critères définis :

Message d’information de type inconnu : de nombreux types de messages d’information ICMPv6 sont définis, tels que la demande d’écho (valeur 128), la réponse d’écho (valeur 129) et la sollicitation de routeur (valeur 133). La définition de type maximale est 149. Toute valeur supérieure à 149 est traitée comme un type inconnu et filtrée en conséquence.
Ne répond pas aux règles de format de paquet ND ICMPv6 (RFC 4861) : il existe des règles standard, telles que le champ Limite de saut IP a une valeur de 255, la somme de contrôle ICMP doit être valide, le code ICMP doit être égal à 0, etc.
Filtrage de paquets ICMPv6 mal formé : par exemple, le paquet ICMPv6 est trop volumineux (type de message 2), l’en-tête suivant est défini sur routage (43) et l’en-tête de routage est défini sur saut par saut.

Vérification et filtrage des en-têtes de paquets IPv6

Vous pouvez activer la vérification et le filtrage des en-têtes de paquets IPv6 à l’aide de l’instruction ipv6-malformed-header . Une fois activé, le système vérifie tout paquet IPv6 entrant pour vérifier s’il correspond à l’un des critères définis. Le système effectue ensuite l’action spécifiée (drop ou alarm-without-drop) sur les paquets correspondants. Le Tableau 7 répertorie les critères clés utilisés par l’équipement pour filtrer les paquets.

Tableau 7 : critères de filtrage des en-têtes de paquets IPv6
Critères de sélection	Normes de l’Internet	Description
Adresses source et de destination locales obsolètes	RFC 3879 (en anglais)	Le préfixe unicast IPv6 local du site (binaire 1111111011 ou FEC0 ::/10) n’est pas pris en charge.
Valeurs d’étendue d’adresse multicast illégales	RFC 4291 (en anglais)	Les valeurs d’étendue d’adresse multicast non affectées sont considérées comme illégales.
Préfixe de documentation uniquement (2001 :DB8 ::/32)	RFC 3849 (en anglais)	L’IANA doit enregistrer l’attribution du préfixe d’adresse unicast globale IPv6 (2001 :DB8 ::/32) en tant que préfixe de documentation uniquement dans le registre d’adresses IPv6. Aucune fin ne doit se voir attribuer cette adresse.
Adresses source et de destination IPv6 compatibles IPv4 obsolètes ( ::/96)	RFC 4291 (en anglais)	L’adresse IPv6 compatible IPv4 est obsolète et n’est plus prise en charge.
Adresses source et de destination ORCHID (2001 :10 ::/28)	RFC 5156 (en anglais)	Les adresses des identificateurs de hachage cryptographique routables superposés (2001 :10 ::/28) sont utilisées comme identificateurs et ne peuvent pas être utilisées pour le routage au niveau de la couche IP. Les adresses à l’intérieur de ce bloc ne doivent pas apparaître sur l’Internet public.
Une adresse IPv4 intégrée à l’intérieur de l’adresse IPv6 (64 :ff9b ::/96) est une adresse IPv4 illégale et inacceptable	RFC 6052	L’adresse IPv6, 64 :ff9b ::/96, est réservée en tant que « préfixe bien connu » pour une utilisation dans la cartographie algorithmique.

Comprendre le contrôle des tunnels IPv6 à l’écran

Plusieurs méthodologies de transition IPv6 sont proposées pour tunneliser les paquets IPv6 sur des réseaux IPv4 qui ne prennent pas en charge IPv6. Pour cette raison, ces méthodes utilisent des passerelles publiques et contournent les stratégies de l’opérateur.

La sécurité des paquets tunnelisés est une préoccupation majeure pour les fournisseurs de services, car les attaquants y accèdent facilement. De nombreuses méthodologies de transition IPv6 ont évolué pour envoyer des paquets tunnelisés à travers un réseau ; Cependant, comme certains d’entre eux fonctionnent sur des passerelles publiques, ils contournent les politiques de l’opérateur. Cela signifie que la transmission de paquets est exposée aux attaquants. Pour surmonter et sécuriser le transfert de paquets, les nuds d’extrémité IPv6 sont tenus de décapsuler les paquets de données encapsulés. Screen est l’une des dernières technologies disponibles pour bloquer ou autoriser le trafic de tunnelisation en fonction des préférences de l’utilisateur.

Vous pouvez configurer les options d’écran suivantes pour vérifier et filtrer les paquets en fonction des en-têtes d’extension IPv6, des en-têtes de paquets et de la validation d’adresse IPv6 ou IPv4 d’en-tête interne incorrect. En fonction de votre configuration, l’écran peut supprimer des paquets, créer des journaux et fournir des statistiques plus élevées pour le tunneling IP.

Tunnel GRE 4in4 : L’écran Tunnel GRE 4in4 correspond à la signature suivante : | IPv4 outer header | GRE header | IPv4 inner header

Un en-tête IPv4 externe doit correspondre à l’encapsulation GRE du protocole 47. Un en-tête GRE doit avoir le protocole de type E 0x0800 IPv4. Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel GRE 4-en-4.
Tunnel GRE 4in6 : l’écran Tunnel GRE 4in6 correspond à la signature suivante : IPv6 outer main header | IPv6 extension header(s) | GRE header | IPv4 inner header

Un en-tête principal IPv6 externe ou un en-tête d’extension IPv6 doit avoir un en-tête suivant de valeur 47 pour GRE. Un en-tête GRE doit avoir le protocole de type E 0x0800 IPv4. Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel GRE 4in6.
Tunnel GRE 6in4 : L’écran GRE 6in4 Tunnel correspond à la signature suivante : IPv4 outer header | GRE header | IPv6 inner header

Un en-tête IPv4 externe doit correspondre à l’encapsulation GRE du protocole 47. Un en-tête GRE doit avoir un protocole de type E 0x086DD IPv6 . Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel GRE 6in4.
Tunnel GRE 6in6 : L’écran GRE 6in6 Tunnel correspond à la signature suivante :IPv6 outer main header | IPv6 extension header(s) | GRE header | IPv6 inner header

Un en-tête principal IPv6 externe ou un en-tête d’extension IPv6 doit avoir un en-tête suivant de valeur 47 pour GRE. Un en-tête GRE doit avoir le protocole IPv6 de type E 0x086DD'. Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel GRE 6in6.
Tunnel IPinIP 6to4relay : L’écran IPinIP 6to4relay Tunnel correspond à la signature suivante : | IPv4 outer header | IPv6 inner header

Un en-tête IPv4 externe doit correspondre à l’encapsulation IPv6 du protocole 41. L’adresse source ou l’adresse de destination d’un en-tête externe doit se trouver dans le réseau 192.88.99.0/24. L’adresse source ou l’adresse de destination d’un en-tête IPv6 interne doit se trouver dans le réseau 2002 :/16. Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel IPinIP 6to4relay.
Tunnel IPinIP 6in4 : L’écran Tunnel IPinIP 6in4 correspond à la signature suivante : | IPv4 outer header | IPv6 inner header

Un en-tête IPv4 externe doit correspondre à l’encapsulation IPv6 du protocole 41. Si cette condition est remplie, ce paquet est classé comme signature de tunnel IPinIP 6in4.

Note:
En règle générale, lorsque des paquets IPv6 doivent être transportés dans un réseau IPv4 complet, ils utilisent un tunnel 6 en 4 point à point.
Tunnel IPinIP 6over4 : L’écran du tunnel IPinIP 6over4 correspond à la signature suivante : | IPv4 outer header | IPv6 inner header

Un en-tête IPv4 externe doit être Protocol 41 IPv6 Encapsulation :W. Une adresse source ou une adresse de destination de l’en-tête interne doit être dans fe80 ::/64 network. Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel IPinIP 6over4.
Tunnel IPinIP 4in6 : L’écran Tunnel IPinIP 4in6 correspond à la signature suivante : | IPv6 outer main header | IPv6 extension header(s) | IPv4 inner header

Un en-tête IPv6 externe ou un en-tête d’extension IPv6 doit avoir un en-tête suivant de valeur 04 pour IPv4. Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel IPinIP 4in6.
Tunnel ISATAP IPinIP : l’écran Tunnel ISATAP IPinIP correspond à la signature suivante :| IPv6 outer main header | IPv6 inner header

Un en-tête IPv4 externe doit correspondre à l’encapsulation IPv6 du protocole 41. L’adresse source ou l’adresse de destination d’un en-tête IPv6 interne doit se trouver dans le réseau fe80 :: 200 :5efe/96 ou fe80 ::5efe/96 . Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel ISATAP IPinIP.
Tunnel IPinIP DS-Lite : l’écran du tunnel IPinIP DS-Lite correspond à la signature suivante :| IPv6 outer main header | IPv6 extension header(s) | IPv4 inner header

Un en-tête IPv6 externe ou un en-tête d’extension IPv6 doit avoir un en-tête suivant de valeur 04 pour IPv4. Une adresse source ou de destination IPv4 interne doit se trouver dans le réseau 192.0.0.0/29. Si ces conditions sont remplies, ce paquet est classé comme signature de tunnel IPinIP DS-Lite.
Tunnel IPinIP 6in6 : l’écran Tunnel IPinIP 6in6 correspond à la signature suivante :| IPv6 outer main header | IPv6 extension header(s) | IPv6 inner main header

Un en-tête principal IPv6 externe ou un en-tête d’extension IPv6 doit avoir un en-tête suivant de valeur 41 pour IPv6. Un en-tête principal IPv6 interne doit être la version 6. Si ces deux conditions sont remplies, ce paquet est classé comme signature de tunnel IPinIP 6in6.
Tunnel IPinIP 4in4 : L’écran Tunnel IPinIP 4in4 correspond à la signature suivante : | IPv6 outer header | IPv4 inner header . Un en-tête IPv4 externe doit avoir un protocole de valeur 04 pour IPv4. Un en-tête IPv4 interne doit être la version 4.
Tunnel IPinUDP Teredo : le tunnel IPinUDP Teredo correspond à la signature suivante : IPv4 outer header | UDP header | IPv6 inner header

Un en-tête IPv4 externe doit avoir un protocole de 17 pour la charge utile UDP. Un port source ou de destination d’en-tête UDP doit être 3544. L’adresse source ou l’adresse de destination d’un en-tête IPv6 interne doit se trouver dans network 2001 :0000 :/32.
Vérification de l’en-tête interne incorrect du tunnel IP : l’écran Tunnel d’en-tête interne défectueux vérifie la cohérence des informations d’en-tête interne du trafic du tunnel. Le paquet est abandonné lorsque l’une des situations suivantes est détectée :
- L’en-tête intérieur ne correspond pas à l’en-tête externe.
- La TTL ou la limite de saut de l’en-tête interne ne doit pas être égale à 0 ou 255.
- Vérification de l’adresse IPv6 de l’en-tête interne.
- Vérification de l’adresse IPv4 de l’en-tête interne.
- Vérifications de la longueur de l’en-tête extérieur et intérieur :
- Vérification de la longueur de l’en-tête interne IPv4 et IPv6 TCP/UDP/ICMP :
  
  La longueur de l’en-tête TCP/UDP/ICMP doit tenir à l’intérieur de la longueur de l’en-tête interne IPv4/IPv6/EH6 lorsque l’adresse IP interne (v4/v6) n’est pas un premier, un suivant ou un dernier fragment.
- TCP : la taille minimale de l’en-tête TCP doit correspondre à la longueur d’encapsulation précédente.
- ICMP : la taille minimale de l’en-tête ICMP doit correspondre à la longueur d’encapsulation précédente.
- Paquets fragmentés : pour les paquets fragmentés, si les informations du tunnel doivent être vérifiées pour un écran et ne se trouvent pas dans le premier fragment, la vérification n’est pas effectuée, à l’exception des parties de l’encapsulation du tunnel qui sont incluses dans le premier fragment. Les vérifications de longueur sont effectuées sur les paquets du premier fragment en utilisant la longueur réelle de la mémoire tampon du paquet, mais les vérifications de longueur sont ignorées car l’en-tête interne est plus grand que l’en-tête externe.
  - Lorsque l’en-tête externe est le premier fragment, n’examinez pas la longueur de paquet physique passée du fragment.
  - Lorsque l’en-tête interne est un premier fragment, n’examinez pas la longueur passée du fragment.
  Pour les paquets qui ne sont pas du premier fragment, la vérification n’est pas effectuée dans l’écran Bad Inner Header Tunnel (Tunnel d’en-tête interne incorrect).
- Lorsque l’en-tête externe n’est pas un premier fragment, examinez le paquet à la recherche d’écrans qui n’utilisent que des signatures d’en-tête IP, car la charge utile ne peut pas être examinée.
- Lorsque l’en-tête interne n’est pas un premier fragment, n’examinez pas le paquet suivant.
- L’en-tête interne IPv4 vérifie que l’en-tête IPv4 est compris entre 20 et 50 octets.

Note:

Sur tous les pare-feu SRX Series, lorsqu’une session d’autorisation ou d’abandon de paquets est établie, l’écran d’en-tête interne incorrect est effectué sur chaque paquet, car cet écran est un écran de chemin rapide.

Sur les équipements SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX4100, SRX4200 et les instances Pare-feu virtuel vSRX., l’écran d’en-tête interne incorrect à accès rapide est toujours exécuté en premier, suivi de l’écran de signature du premier chemin.

À partir de Junos OS version 12.3X48-D10 et de Junos OS version 17.3R1, les messages RT_SCREEN_IP syslog et RT_SCREEN_IP_LS l’écran de tunnelisation IP ont été mis à jour. Les messages mis à jour incluent les attaques par écran de tunnel et les critères de journalisation sans interruption. La liste suivante illustre quelques exemples de ces nouveaux messages de journal système pour chacun des types de tunnel :

RT_SCREEN_IP: Tunnel GRE 6in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: alarm-without-drop
RT_SCREEN_IP: Tunnel GRE 6in6! source: 1212::12, destination: 1111::11, zone name: untrust, interface name: ge-0/0/1.0, action: drop
RT_SCREEN_IP: Tunnel GRE 4in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: drop
RT_SCREEN_IP_LS: [lsys: LSYS1] Tunnel GRE 6in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: alarm-without-drop
RT_SCREEN_IP_LS: [lsys: LSYS1] Tunnel GRE 6in6! source: 1212::12, destination: 1111::11, zone name: untrust, interface name: ge-0/0/1.0, action: drop
RT_SCREEN_IP_LS: [lsys: LSYS1] Tunnel GRE 4in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: drop

Exemple : Amélioration de la sécurité du trafic de tunnel avec les options de l’écran de tunnelisation IP

Cet exemple montre comment configurer les écrans de tunnel pour leur permettre de contrôler, d’autoriser ou de bloquer le transit du trafic tunnelisé.

Exigences
Aperçu
Configuration
Vérification

Exigences

Cet exemple utilise les composants matériels et logiciels suivants :

Un pare-feu SRX Series
Junos OS version 12.3X48-D10 et ultérieures

Avant de commencer :

Comprendre le contrôle de tunnelisation IPv6. Reportez-vous à la section Présentation du contrôle de tunnelisation IPv6 de l’écran.

Aperçu

Vous pouvez configurer les options d’écran de tunnelisation IP suivantes pour vérifier et filtrer les paquets, en fonction des en-têtes d’extension IPv6, des en-têtes de paquets et de la validation des adresses IPv6 ou IPv4 d’en-tête interne incorrect. En fonction de votre configuration, l’écran peut supprimer des paquets, créer des journaux et fournir des statistiques plus élevées pour le tunneling IP. Les options d’écran de tunnelisation suivantes sont affectées à une zone non approuvée.

Tunnel GRE 4 en 4
Tunnel GRE 4 en 6
Tunnel GRE 6 en 4
Tunnel GRE 6 en 6
IPinUDP Teredo Tunnel
Tunnel IPinIP 4-en-4
Tunnel IPinIP 4 en 6
Tunnel IPinIP 6 en 4
Tunnel IPinIP 6 en 6
IPinIP 6over4 Tunnel
IPinIP 6to4relay Tunnel
IPinIP ISATAP Tunnel
IPinIP DS-Lite Tunnel
Tunnel d’en-tête interne défectueux

Configuration

Pour configurer les options de l’écran de tunnelisation IP, effectuez les tâches suivantes :

Configuration des écrans de tunnel GRE
Configuration d’un écran de tunnel Teredo IPinUDP
Configuration d’un écran de tunnel IPinIP
Configuration d’un écran de tunnel d’en-tête interne incorrect
Résultats

Configuration des écrans de tunnel GRE

Configuration rapide de l’interface de ligne de commande
Procédure étape par étape

Configuration rapide de l’interface de ligne de commande

Procédure étape par étape

Pour configurer l’écran d’un tunnel GRE :

Configurez un écran de tunnel GRE pour vérifier la cohérence des informations d’en-tête interne du trafic du tunnel et valider l’écran de type de signature.

Configurez les écrans dans les zones de sécurité.

Configuration d’un écran de tunnel Teredo IPinUDP

Configuration rapide de l’interface de ligne de commande
Procédure étape par étape

Configuration rapide de l’interface de ligne de commande

Procédure étape par étape

Pour configurer l’écran d’un tunnel Teredo IPinUDP :

Configurez un écran de tunnel Teredo IPinUDP pour vérifier la cohérence des informations d’en-tête interne du trafic du tunnel et valider l’écran de type de signature.

Configurez les écrans dans les zones de sécurité.

Configuration d’un écran de tunnel IPinIP

Configuration rapide de l’interface de ligne de commande
Procédure étape par étape

Configuration rapide de l’interface de ligne de commande

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer l’écran d’un tunnel IPinIP :

Configurez un écran de tunnel IPinIP pour vérifier la cohérence des informations d’en-tête interne du trafic du tunnel et valider l’écran de type de signature.

Configurez les écrans dans les zones de sécurité.

Configuration d’un écran de tunnel d’en-tête interne incorrect

Configuration rapide de l’interface de ligne de commande
Procédure étape par étape

Configuration rapide de l’interface de ligne de commande

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration.

Pour configurer un écran de tunnel d’en-tête interne incorrect :

Configurez un écran de tunnel d’en-tête interne incorrect pour vérifier la cohérence des informations d’en-tête interne du trafic du tunnel.

Configurez les écrans dans les zones de sécurité.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show security screen commandes et show security screen statistics zone untrust ip tunnel . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.

Par souci de concision, cette show sortie inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de la configuration de l’écran de sécurité
Vérification des écrans des tunnels IP dans les zones de sécurité

Vérification de la configuration de l’écran de sécurité

But
Action
Sens

But

Affichez les informations de configuration sur l’écran de sécurité.

Action

À partir du mode opérationnel, entrez la show security screen ids-option screen1 commande.

Sens

La show security screen ids-option screen1 commande affiche l’état de l’objet à l’écran comme étant activé.

Vérification des écrans des tunnels IP dans les zones de sécurité

But
Action
Sens

But

Vérifiez que les options de l’écran de tunnelisation IP sont correctement configurées dans les zones de sécurité.

Action

À partir du mode opérationnel, entrez la show security screen statistics zone untrust ip tunnel commande.

Sens

La show security screen statistics zone untrust ip tunnel commande affiche le récapitulatif des statistiques de l’écran du tunnel IP.

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plate-forme et la version que vous utilisez. Utilisez l’Explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération

Description

15.1X49-D30

15.1X49-D20

12.3X48-D10

À partir de Junos OS version 12.3X48-D10 et de Junos OS version 17.3R1, les messages RT_SCREEN_IP syslog et RT_SCREEN_IP_LS l’écran de tunnelisation IP ont été mis à jour.