Les ID d'application de couche 7 sont configurés dans le cadre d'un profil de contexte.

Un profil de contexte peut spécifier un ou plusieurs Attributs (ID d'application) et peut également inclure des sous-attributs, à utiliser dans des règles de pare-feu distribué (DFW) et des règles de pare-feu de passerelle. Lorsqu'un sous-attribut est défini (par exemple, TLS version 1.2), plusieurs attributs d'identité d'application ne sont pas pris en charge. En plus des attributs, DFW prend également en charge un nom de domaine complet (FQDN) ou une URL que vous pouvez spécifier dans un profil de contexte pour la mise sur liste d'autorisation ou sur liste de refus de noms de domaine complets. Pour plus d'informations, reportez-vous à la section Filtrage de domaines spécifiques (noms de domaine complets/URL). Des noms de domaine complets peuvent être configurés avec un attribut dans un profil de contexte ou chaque nom de domaine complet peut être défini dans différents profils de contexte. Une fois qu'un profil de contexte a été défini, il peut être appliqué à une ou plusieurs règles de pare-feu distribué.

Note :
  • Les règles de pare-feu de passerelle ne prennent pas en charge l'utilisation d'attributs de nom de domaine complet ou d'autres sous-attributs dans les profils de contexte.
  • Les profils de contexte ne sont pas pris en charge sur la stratégie de pare-feu de passerelle de niveau 0.

Lorsqu'un profil de contexte est utilisé dans une règle, tout le trafic provenant d'une machine virtuelle est comparé au tableau de règles basées sur les 5 tuples. Si la règle correspondant au flux inclut également un profil de contexte de couche 7, le paquet est redirigé vers un composant de l'espace utilisateur appelé le moteur vDPI. Les paquets suivants sont envoyés au moteur vDPI pour chaque flux. Une fois l'ID d'application déterminé, les informations sont stockées dans le tableau de contexte du noyau. Lorsque le paquet suivant pour le flux est fourni, les informations contenues dans le tableau de contexte sont de nouveau comparées au tableau de règles et sont mises en correspondance sur 5 tuples et sur l'ID d'application de couche 7. L'action appropriée selon la règle de correspondance totale est effectuée. En cas de règle d'autorisation, tous les paquets associés pour le flux sont traités dans le noyau et comparés au tableau de connexion. Pour des règles d'abandon totalement correspondante, un paquet de rejet est généré. Les journaux générés par le pare-feu incluent l'ID d'application de couche 7 et l'URL applicable, si ce flux a été envoyé vers le moteur DPI.

Traitement des règles pour un paquet entrant :
  1. Lorsque vous entrez un filtre de pare-feu distribué ou de passerelle, les paquets sont recherchés dans le tableau de flux basé sur 5 tuples.
  2. Si aucun flux/état n'est trouvé, le flux est comparé au tableau de règles basées sur 5 tuples et une entrée est créée dans le tableau de flux.
  3. Si le flux correspond à une règle avec un objet de service de couche 7, l'état du tableau de flux est marqué comme « DPI en cours ».
  4. Le trafic pointe ensuite vers le moteur DPI. Le moteur DPI détermine l'ID d'application.
  5. Une fois l'ID d'application déterminé, le moteur DPI renvoie l'attribut qui est inséré dans le tableau de contexte pour ce flux. L'indicateur « DPI en cours » est supprimé et le trafic ne pointe plus sur le moteur DPI.
  6. Le flux (maintenant avec l'ID d'application) est réévalué par rapport à toutes les règles qui correspondent à l'ID d'application, en commençant par la règle d'origine qui a été mise en correspondance en fonction des 5 tuples, puis la première règle L4/L7 totalement correspondante est sélectionnée. La mesure appropriée est prise (autoriser/refuser/rejeter) et l'entrée de tableau de flux est mise à jour en conséquence.