Wildcard(*) imbriqués dans une URL peut gravement affecter la Performance
Resolution
Détails
Message d'avertissement Commit
L'avertissement suivant s'affiche lors d'une validation si une liste Block ou allow contient une entrée utilisant plusieurs caractères génériques:
AVERTISSEMENT : Wildcard(*) imbriquées dans les URL peuvent gravement impact sur les performances.
Il est recommandé d’utiliser un caractère générique unique pour couvrir plusieurs jetons ou un caret(^) pour cibler un jeton unique.
Raison du message d'avertissement
Le caractère astérisque (*) est utilisé en guise de générique dans le nom de domaine complet et le chemin pour le filtrage d’URL personnalisée. Le pare-feu de Palo Alto Networks accepte plusieurs jetons générique dans le domaine (ex. *. *. domaine.com) et les traite de manière appropriée.
Toutefois, à mesure que le nombre de jetons génériques augmente, la charge sur l'UC du système augmente de façon exponentielle (par exemple, *. *. *. domain.com, ou simplement *. *. domain.com). Par conséquent, nous vous conseillons d'éviter les astérisques imbriqués (*) pour une utilisation pratique.
Ci-dessous est l'utilisation de caractères génériques et son exemple
| Caractère générique | Utilisation | Exemple |
| "*" astérisque | correspondance avec un ou plusieurs sous-domaines | Le caractère générique astérisque (*) ne respecte pas le point (.) comme séparateur et se poursuit en tant que caractère générique jusqu'à ce qu'un sous-domaine, un domaine ou un domaine de niveau supérieur soit apparié.
Sub1. *. *. com correspondra à Sub1.sub2.SUB3.com et *. *. SUB3.com correspondra à Sub1.sub2.SUB3.com. Cependant, cela devrait être évité comme une pratique exemplaire car les astérisques imbriqués peuvent créer un impact sur le périphérique.
Au lieu de cela, comme une pratique exemplaire, vous pouvez utiliser: Sub1. *. com ou *. SUB3.com. Cela va correspondre Sub1.sub2.SUB3.com
|
| "^" caret | correspondent à un seul sous-domaine. | Le caractère générique Caret (^) respecte la période (.) en tant que delimliter et arrêtera la correspondance en tant que caractère générique une fois qu'une correspondance s'est produite.
Sub1. ^. ^. com et ↑. ^. SUB3.com sont en mesure de correspondre avec Sub1.sub2.SUB3.com
Par conséquent, ^. SUB3.com et Sub1. ^. com ne sont pas en mesure de correspondre avec Sub1.sub2.SUB3.com, puisque "^" caret ne correspond qu'à un seul sous-domaine.
Si vous souhaitez remplacer "*" par "^", les remplacements suivants sont requis:
x. *. NET est partically google's couvert par ce qui suit: x. ^ .net x. ^. ^ .net x. ^. ^. ^ .net (suite...)
Les carets imbriquées ont une limite pratique de 9 carets pour la même raison d'utilisation des ressources DP ci-dessus. |
Même limitation pour le chemin
Cette limitation est appliquée au modèle correspondant au chemin d'accès après FQDN. (i.e. http://<FQDN>/<path>), bien que nous ne lançions pas le message d'avertissement de Commit ci-dessus pour Path.</path> </FQDN>
La limite pratique pour l'astérisque imbriqué dans le chemin est 2. Mais nous recommandons fortement d'utiliser le nombre minimum d'astérisque pour une meilleure utilisation DP (charge CPU/utilisation de la mémoire).
Note latérale:
Actuellement, nous avons la limitation que Asterisk et caret ne doit pas être utilisé dans la même configuration. Comme mentionné ci-dessus, caret ne peut pas être entièrement remplacé par Asterisk. Par conséquent, remplacer les astérisques imbriqués par un astérisque unique est considéré comme la meilleure solution pour la plupart des clients pratiquement.
"2" pour l'astérisque imbriqué dans le chemin et "9" pour les caret imbriqués sont le nombre pratique que nous suggérons. S'il vous plaît envisager d'utiliser le plus petit nombre possible pour une meilleure charge DP (c.-à-plate-forme inférieure).