Séquence de flux de paquets dans PAN-OS

Created On 09/25/18 19:10 PM - Last Modified 06/04/21 21:44 PM

Resolution

Ce document décrit la séquence de traitement des paquets dans PAN-OS .

Jour dans la vie d’un paquet

PAN-OSSéquence de flux de paquets. Depuis PAN-OS 7.0.2 et 6.1.7 PAN-48644 (), DOS la protection de veille est effectuée avant la veille de policy sécurité. Ce document a été mis à jour pour refléter ce changement de comportement :

Contenu:
SECTION1: OVERVIEW

SECTION 2: INGRESS STAGE

2.1 PACKET PARSING
2.2 TUNNEL DECAPSULATION
2.3 IP DEFRAGMENTATION

SECTION 3: FIREWALLSESSION LOOKUP

3.1. ZONE PROTECTION CHECKS
3.2. TCP STATE CHECK
3.3. FORWARDING SETUP
3.4. NAT POLICY LOOKUP
3.5. USER - ID
3.6. DOS PROTECTION POLICY LOOKUP
3.7. SECURITY POLICY LOOKUP
3,8. SESSION ALLOCATION

SECTION 4: FIREWALL SESSION FAST PATH

SECURITY PROCESSING
CAPTIVE PORTAL

SECTION 5: APPLICATION IDENTIFICATION( APP - ID)

SECTION 6: CONTENT INSPECTION

SECTION 7: FORWARDING EGRESS /

SECTION 8: SUMMARY

Section 1 : Vue d’ensemble

Ce document décrit la séquence de traitement des paquets à l’intérieur PAN-OS des périphériques. Les étapes d’entrée et de réédité/évacuation gèrent les fonctions réseau et prennent des décisions de révocation de paquets sur une base par paquet. Les étapes restantes sont des modules de sécurité basés sur des sessions mis en évidence par ID App- et Content- ID . Ce découplage offre des fonctions de sécurité étatiques à la couche d’application, ainsi que la résilience de l’adage par paquet et la flexibilité des topologies de déploiement.

Section 2 : Étape de l’entrée

L’étape d’entrée reçoit les paquets de l’interface réseau, analyse ces paquets, puis détermine si un paquet donné fait l’objet d’une inspection plus approfondie. Si le paquet fait l’objet d’une inspection plus approfondie, firewall le paquet continue avec une étude de session et le paquet entre dans l’étape de traitement de sécurité. Dans le cas contraire, firewall les avants du paquet à l’étape de l’évacuation.La section 3 résume les cas où firewall les paquets avants sans inspection, selon le type de paquet et le mode opérationnel de l’interface.

Remarque : Pendant le traitement des paquets, le paquet peut être rejeté en raison firewall d’une violation du protocole. Dans certains cas, en raison de firewall fonctionnalités de prévention des attaques, il rejette les paquets sans options configurables. L’article 2.1 énumère de tels cas lorsque les firewall paquets de rejets à ce stade .

Le diagramme de flux de paquets qui a chaque étape (Entrée, FW Configuration de session/Slowpath, FW Fastpath, Identification d’application, Fowarding/Egress) de la firewall

Procédure pas à pas de flux de paquets

Cliquez HERE pour l’image High-res

2.1 Parsing de paquets

L’en-tête de paquet commence par l’en-tête Ethernet (Couche-2) du paquet reçu du fil.
Le port d’entrée, 802.1q tag , et l’adresse de destination MAC sont utilisés comme clés pour rechercher l’interface logique d’entrée. Si l’interface n’est pas trouvée, le paquet est rejeté. Le hardware compteur d’interface « recevoir l’erreur » et le compteur global « flow_rcv_dot1q_tag_err » sont incrémentés.

Ensuite, IP l’en-tête est paré (Couche-3).

IPv4: Le firewall va jeter le paquet pour l’une des raisons suivantes:

Inadéquation du type et de la version Ethernet IP
En-tête IP tronqué
IP protocole numéro 0
TTL Zéro
Attaque terrestre
Ping de la mort
Adresse IP martienne
IP erreurs checksum

IPv6: Le firewall va jeter le paquet pour l’une des raisons suivantes:

Inadéquation du type et de la version Ethernet IP
En-tête IPv6 tronqué
Paquet IP tronqué IP (longueur tampon de charge utile inférieure au champ IP de charge utile)
Extension JumboGram ( RFC 2675)
En-tête d’extension tronquée

Ensuite, l’en-tête Layer-4 TCP ( / ) est UDP paré, le cas échéant.

TCP: La firewall volonté de jeter le paquet pour l’une des raisons suivantes:

TCP l’en-tête est tronqué.
Données - champ offset est inférieur à 5
Erreur de somme de contrôle
Le port est nul
Combinaison invalide de TCP drapeaux

UDP: La firewall volonté de jeter le paquet pour l’une des raisons suivantes:

UDP en-tête tronqué
UDP charge utile tronquée (pas IP fragment et longueur tampon inférieure au champ de UDP UDP longueur)
Erreur de somme de contrôle

2.2 Décapsulation du tunnel

Le firewall effectue la décapsulation / décryptage à l’étape de l’échage. Après avoir parsing le paquet, si le firewall détermine qu’il correspond à un tunnel, c’est-à-dire IPSec, SSL-VPN avec le SSL transport, alors il effectue la séquence suivante:

Le firewall décapule d’abord le paquet et le rejette s’il y a des erreurs.
L’interface de tunnel associé avec le tunnel est assigné au paquet comme sa nouvelle interface d’entrée et ensuite le paquet est alimenté à travers le processus d’analyse, à partir de l’en-tête du paquet défini par le type de tunnel. Actuellement, les types de tunnel pris en charge sont IP tunneling couche, donc l’parsage des paquets (pour un paquet tunnelé) commence par IP l’en-tête.

2.3 IP Défragmentation

Les firewall parses IP fragmentent, se rassemblent à l’aide du processus de défragmentation, puis alimentent le paquet vers le parser en commençant par IP l’en-tête.À ce stade, un fragment peut être jeté en raison d’une attaque de larme (fragments qui se chevauchent), d’erreurs de fragmentation ou si firewall le système frappe des limites sur les fragments tampons (atteint le seuil de paquet maximum).

Section 3: Recherche de Firewallsession

A le paquet est sujet au firewall traitement en fonction du type de paquet et du mode interface. Le tableau suivant résume le comportement de traitement des paquets pour un mode de fonctionnement d’interface donné et le type de paquet :

Type de paquet	Interface modes opérationnels
Type de paquet	Layer-3	Couche-2	Virtuel-fil	taper
IPv4 unicast	inspecter et transmettre	inspecter et transmettre	inspecter et transmettre	inspecter & drop
Multidiffusion IPv4 (224.0.0.1 - 239.255.255.255)	inspecter et transmettre	vers l’avant seulement (inondation)	vers l’avant, mais inspecter seulement si multicast pare-feu est sur	inspecter & drop
IP diffuser (255.255.255.255)	laisser tomber	avant seulement (inondation)	vers l’avant, mais inspecter seulement si multicast pare-feu est sur	laisser tomber
IP diffusion locale	laisser tomber	avant seulement (inondation)	vers l’avant, mais inspecter seulement si multicast pare-feu est sur	laisser tomber
IPv6 (en)	inspecter et faire parvenir si activée	en avant, mais ne vérifiez que si le pare-feu IPv6 est activé (par défaut)	en avant, mais ne vérifiez que si le pare-feu IPv6 est activé (par défaut)	baisse, mais l’inspecter seulement si le pare-feu IPv6 est activé (par défaut)
Non-IP	processus si il y a lieu, pas avant	vers l’avant seulement	vers l’avant seulement	laisser tomber

Si le paquet fait l’objet firewall d’une inspection, il effectue une recherchez le flux sur le paquet. A firewall se compose de deux flux unidirectionnels, chacun identifié de façon unique. Dans PAN-OS la mise en œuvre, le identifie le flux à firewall l’aide d’une clé de 6 tuple:

Adresses source et destination : IP adresses du IP paquet.
Ports de source et de destination : Numéros de port à partir TCP UDP /en-têtes de protocole.Pour les champs de protocole non/ , différents TCP sont utilisés UDP (par exemple pour l’identificateur et les numéros de séquence ICMP sont ICMP utilisés, pour IPSec se terminant sur l’appareil l’indice de paramètres de sécurité ( ) est utilisé, et SPI pour inconnu, une valeur réservée constante est utilisée pour sauter layer-4 match).
Protocole : Le numéro IP de protocole de IP l’en-tête est utilisé pour tirer la clé d’écoulement.
Zone de sécurité : Ce champ est dérivé de l’interface d’entrée à laquelle un paquet arrive.

Les firewall magasins flux actifs dans la table de recherche de flux. Lorsqu’un paquet est déterminé comme éligible pour firewall l’inspection, firewall les extraits de la clé de flux de 6 tuples du paquet, puis effectue une recherche de flux pour correspondre au paquet avec un flux existant. Chaque flux a un composant client et serveur, où le client est l’expéditeur du premier paquet de la session du firewall point de vue de 's, et le serveur est le récepteur de ce premier paquet.

Note: La distinction entre le client et le serveur est du point de vue du client et peut firewall ou non être la même du point de vue des hôtes finants. Sur la base de la définition ci-dessus du client et du serveur, il y aura un flux client-serveur (C2S) et serveur-client (S2C), où tous les paquets client-serveur devraient contenir la même clé que celle du flux C2S, et ainsi de suite pour le flux S2C.

Firewall Configuration de la session

firewallL’effectue les étapes suivantes pour mettre en place une session firewall :

3.1. Contrôles de protection des zones

Une fois le paquet arrivé sur une firewall interface, les informations de l’interface d’entrée sont utilisées pour déterminer la zone d’entrée. Si les profils de protection zone existent pour cette zone, le paquet est soumis à l’évaluation selon la configuration du profil.

3.2. TCP State Check

Si le premier paquet d’une session est un TCP paquet et qu’il n’a SYN pas le bit défini, les firewall rejets (par défaut).Si SYN les paramètres d’inondation sont configurés dans le profil de protection de zone et que l’action est définie SYN sur les cookies, TCP SYN le cookie est déclenché si le nombre correspond au seuil SYN d’activation. SYN fonctions de mise en œuvre des cookies comme suit :

La graine pour coder le cookie est générée via un générateur de nombres aléatoires chaque fois que le plan de données démarre.
Si un ACK paquet reçu du client ne correspond pas à l’encodage des cookies, il traite le paquet comme non-paquet. SYN
A session qui passe le SYN processus de cookie est soumis à la traduction du numéro de séquence parce que l’a TCP agi comme un proxy pour la poignée de main à firewall TCP 3 sens.

Si SYN l’action de protection contre les inondations est définie sur Random Early Drop RED () au lieu de cela, qui est la valeur par défaut, alors le firewall goutte simplement tous les messages qui sont reçus après avoir atteint SYN le seuil. SYN Les cookies sont préférés lorsque vous souhaitez permettre à un trafic plus légitime de passer tout en étant en mesure de distinguer les SYN paquets d’inondation et de les laisser tomber à la place. RED, d’autre part, va déposer des SYN paquets au hasard et peut avoir un impact sur le trafic légitime également.

Remarque : Vous pouvez configurer le firewall premier TCP paquet, même s’il n’a pas SYN de jeu de bits.Modifier le comportement par défaut et autoriser les SYN TCP non-paquets à travers pose un risque de sécurité en ouvrant les Firewall paquets malveillants ne faisant pas partie d’une séquence TCP de connexion valide. Bien que ce n’est pas un paramètre recommandé, il peut être requis pour les scénarios avec des flux asymétriques. Vous devez configurer le firewall rejet TCP non- SYN lorsque les SYN cookies sont activés.

3.3. Transmettre Sl’etup

Cette étape détermine le chemin de transfert de paquets. Transfert de paquet dépend de la configuration de l’interface. Le tableau suivant résume le comportement de transfert de paquets :

Mode d’interface	Action de redirection
taper	L’interface/zone d’évacuation est la même que l’interface/zone d’entrée d’un policy point de vue. Le firewall jetez le paquet.
Fil virtuel	Sortie est l’interface homologue configuré dans le fil virtuel
Couche - 2	L’interface d’évacuation pour MAC la destination est récupérée à partir de MAC la table. Si l’information n’est pas présente, le cadre est inondé à toutes les interfaces dans le domaine VLAN de diffusion associé, à l’exception de l’interface d’entrée .
Couche - 3	firewallL’utilise la table de rechercher l’itinéraire pour déterminer le saut suivant, ou jette le paquet s’il n’y a pas de correspondance.

3.4. NAT P Lolicy ookup

Ceci est applicable uniquement aux couche-3 ou en mode virtuel fil. À ce stade, l’information sur la zone d’entrée et d’évacuation est disponible. firewall L’évaluation des règles pour le paquet NAT d’origine.

Pour la NAT destination, firewall l’effectue une deuxième recherche d’itinéraire pour l’adresse traduite pour déterminer l’interface/zone d’évacuation.
Pour la source NAT , firewall l’évalue la règle NAT pour l’allocation à IP la source. Si la vérification d’allocation échoue, firewall le jetez le paquet.

3.5. Utilisateur-ID

firewallL’utilise IP l’adresse du paquet pour interroger la table de IP cartographie utilisateur (maintenue par ) VSYS . Les informations utilisateur correspondante sont lue. La suivante prend ces informations utilisateur pour interroger la table de cartographie firewall utilisateur-groupe et va chercher la cartographie de groupe associée à cet utilisateur (il renvoie tous les groupes de l’utilisateur appartient à).

Il y a une chance que les informations utilisateur ne sont pas disponibles à ce stade. Dans ce cas, si le portail captif policy est configuré, firewall le va tenter de trouver les informations de l’utilisateur via l’authentification portail captif (discuté dans la section 4) .

3.6. Recherchez la protection PolicyDoS

Ensuite, les firewall contrôles de la protection DoS (Déni de service) pour les policy seuils de trafic basés sur le profil de protection DoS.Si l’action de protection DoS policy est définie sur « Protéger », firewall les contrôles des seuils spécifiés et s’il y a une correspondance (attaque DoS détectée), elle rejette le paquet.

Si policy l’action est soit autoriser ou refuser, l’action a préséance indépendamment des limites de seuil fixées dans le profil DoS.

3.7. Sécurité Policy Lookup

À ce stade, les informations de fuseau de passage des occupants sont disponibles.firewallL’application ANY utilise l’application pour effectuer la recherche et vérifier une correspondance de règles.Dans le cas d’une correspondance de règles, si policy l’action est définie pour « nier », firewall les gouttes du paquet.Le nie firewall le trafic s’il n’y a pas de règle de sécurité match. Le firewall permet le trafic intra-zone par défaut. Vous pouvez modifier ce comportement par défaut pour le trafic intra-zone et inter-zone à partir de la base de règles des stratégies de sécurité.

Remarque : Les règles de sécurité firewall s’appliquent au contenu du paquet d’origine, même s’il existe des NAT règles configurées.

3.8. ALlocation de session

firewallL’attribution d’une nouvelle entrée de session à partir du pool gratuit après toutes les étapes ci-dessus sont complétés avec succès. Échec d’allocation de session peut-être survenir à ce stade en raison de contraintes de ressources :

VSYS session maximale atteinte, ou
firewallL’alloue toutes les sessions disponibles.

Après le succès de l’allocation de session :

Le firewall remplissage du contenu de la session avec des touches de flux extraites du paquet et de l’adage/ policy résultats .
L’état de session INIT change de (pré-allocation) OPENING à (post-allocation) .
Si l’application n’a pas été identifiée, les valeurs de délai d’expiration de session sont définies avec la valeur par défaut du protocole de transport. Vous pouvez configurer ces valeurs de délai d’attente globales à partir Firewall des paramètres de l’appareil.Les valeurs de délai d’attente spécifiques à l’application l’emportent sur les paramètres mondiaux et seront les valeurs de délai d’attente efficaces pour la session une fois l’application identifiée.

Après la configuration, l’installation de session a lieu :

Firewall interroge la table de recherche de flux pour voir si une correspondance existe pour les touches de flux correspondant à la session.Si une correspondance de rechercher le flux est trouvée (session avec le même tuple existe déjà), alors cette instance de session est rejetée car la session existe déjà, sinon
La session est ajoutée à la table de recherche de flux pour les flux C2S et S2C et firewall modifie l’état de la session de OPENING ACTIVE .

firewallL’envoie ensuite le paquet dans la phase de chemin rapide de session pour le traitement de sécurité.

Section 4 : Firewall Parcours rapide de la session

A paquet qui correspond à une session existante entrera dans le chemin rapide. Cette étape commence par le traitement de la couche 2 à la couche firewall 4 :

Si la session est dans l’état de rejet, firewall alors le jetez le paquet.Le firewall peut marquer une session comme étant dans l’état de rejet en raison d’un changement policy d’action à nier, ou la détection des menaces .
Si la session est active, actualisez le délai d’attente de la session.
Si le paquet est un TCP FIN / , la session RST TCP mi-temps fermée est démarré s’il s’agit du FIN premier paquet reçu (session à moitié fermée) ou TCP la time wait timer est démarré s’il s’agit du deuxième FIN paquet ou RST paquet. La session est fermée dès l’expiration de l’une ou l’autre de ces délais.
Le NAT cas échéant, traduisez l’en-tête L3/L4 le cas échéant.

Si une application utilise TCP comme transport, le processus firewall par le module de TCP remontage avant qu’il envoie le flux de données dans le module de traitement de sécurité. Le TCP module de remontage effectuera également la vérification des fenêtres, tamponnera les données hors de l’ordre tout en sautant TCP la retransmission. Les firewall gouttes des paquets s’il ya une erreur de remontage ou si elle reçoit trop de fragments hors de l’ordre, ce qui entraîne le remontage tampons de remplissage.

4.1. Traitement de la sécurité

A paquet correspondant à une session existante est soumis à un traitement ultérieur (identification des demandes et / ou l’inspection du contenu) si le TCP paquet a / données UDP (charge utile), ou il s’agit d’un non- TCP / paquet UDP .

Si firewall l’application ne détecte pas l’application de session, elle effectue une ID recherchez l’application. Si la recherche ID d’applications n’est pas concluante, le module d’inspection du contenu exécute les vérifications connues du décodeur de protocole et l’heuristique pour aider à identifier l’application.

Si firewall l’application détecte l’application, la session est soumise à une inspection du contenu si l’un des éléments suivants s’applique :

Application Layer Gateway ( ALG ) est impliqué .
Application est par tunnel.
La règle de sécurité a un profil de sécurité associé.

Les étapes de l’identification des demandes ID (app- ) et de l’inspection du contenu sont examinées en détail dans les sections ultérieures (section 5 et 6).

4.2. Portail captif

Si les informations utilisateur wa s ne sont pas disponibles pour l’adresse source extraite du paquet, et que le paquet est IP destiné TCP à /80, le portail effectue une recherche de règle de firewall portail captif pour voir si le paquet est soumis à l’authentification captive du portail. Si le portail captif est applicable, le paquet est redirigé vers le démon du portail captif.

Remarque : Étant donné que le portail captif s’applique au trafic http et prend également en charge une recherche basée sur la catégorie, cela ne URL policy peut être lancé TCP qu’une fois la poignée de main terminée et que les en-têtes http host sont disponibles dans l’échange de session.

Section 5 : IDentification des applications (App-ID)

Le firewall premier effectue une recherchez de substitution d’application pour voir policy s’il y a une correspondance de règle. Si c’est le cas, l’application est connue et l’inspection du contenu est ignorée pour cette session.

S’il n’y a aucune règle d’application-override, signatures d’application sont utilisés pour identifier l’application.Le firewall protocole utilise le décodage du protocole à l’étape de l’inspection du contenu pour déterminer si une application change d’une application à l’autre.

Après firewall l’identification de l’application de session, le contrôle d’accès, l’inspection du contenu, la gestion du trafic et l’enregistrement seront configurés comme configurés.

Recherche policy de sécurité : L’application identifiée ainsi que IP /port/protocole/zone/utilisateur/catégorie URL dans la session est utilisée comme clé pour trouver la correspondance des règles.
Si la sécurité policy a activé la journalisation au début de la session, firewall le génère un journal de trafic, chaque fois que l’application change ID tout au long de la durée de la session.
Si policy l’action de sécurité est définie pour permettre et qu’elle a le profil et/ou l’application associés est sujette à l’inspection du contenu, alors elle transmet tout le contenu par le contenu- ID .
Si policy l’action de sécurité est définie pour permettre, firewall l’effectue une recherche QoS policy et attribue une classe QoS basée sur l’appariement policy .
Si policy l’action de sécurité est définie pour autoriser et l’application SSL est ou , effectuer une recherchez de SSH décryptage et configurer policy des contextes proxy s’il ya une règle de décryptage correspondant .

Section 6 : Inspection du contenu

firewallL’effectue l’inspection du contenu, le cas échéant, lorsque les décodeurs de protocole décodent le flux et les analyse et identifie les applications de firewall tunnelage connues (celles qui comportent régulièrement d’autres applications comme la navigation sur le Web).

Si l’application identifiée change pour cette raison, les firewall consultations les politiques de sécurité une fois de plus pour déterminer si la session devrait être autorisée à se poursuivre.

Si l’application ne change pas, firewall l’inspection du contenu selon tous les profils de sécurité attachés à la règle d’appariement d’origine. S’il en résulte une détection des menaces, les mesures de profil de sécurité correspondantes sont prises.

firewallL’avant du paquet à l’étape de l’adage si l’une des conditions est vraie:

Si l’inspection entraîne une action de « détection » et de profil de sécurité est définie pour permettre, ou
Content inspection ne renvoie aucune « détection ».

Le firewall puis recrypte le paquet avant d’entrer dans l’étape de l’aération, le cas échéant SSL (décryptage proxy avant SSH et décryptage).

Article 7 : Transfert/évacuation

Le firewall identifie un domaine de forwarding pour le paquet, basé sur la configuration de forwarding (discuté précédemment).

Le firewall QoS effectue la mise en forme applicable dans le processus d’évacuation. En outre, basé sur MTU l’interface d’évacuation et les paramètres de bit fragment sur le paquet, firewall le effectue la fragmentation si nécessaire.

Si l’interface d’évacuation est une interface tunnel, alors le chiffrement IPSec/tunnel SSL-VPN est effectué et le réédage des paquets est réévalué.

Enfin, le paquet est transmis depuis l’interface de sortie physique.

Section 8 : Résumé

Pare-feu de prochaine génération de Palo Alto Networks utilisent une Architecture unique de Single Pass Parallel Processing (SP3) – qui permet la sécurité des réseaux haut débit et faible latence, tout en intégrant des technologies et des fonctionnalités sans précédent. Palo Alto Networks résout les problèmes de performances qui affligent l’infrastructure de sécurité d’aujourd’hui avec l’architecture SP3, qui combine deux composants complémentaires - logiciel Single Pass, Traitement parallèle hardware . Le résultat est un excellent mélange de débit brut, traitement, des transactions et sécurité des réseaux réseaux de haute performance qui aujourd'hui exigent.