Action configurées dans les règles de sécurité et vu dans le journal de trafic sont incohérent

Action configurées dans les règles de sécurité et vu dans le journal de trafic sont incohérent

29863
Created On 09/26/18 13:49 PM - Last Modified 06/13/23 02:48 AM


Resolution


Symptôme

Dans certaines situations il peut être une entrée de journal de trafic pour une session, où l’application est reconnue comme insuffisant, connecté comme « autoriser » tout en correspondant à une règle de goutte.

Par exemple :

Prendre le trafic FTP d’une zone de « replay_eth2 » à une zone « replay_eth3 ».

Ce trafic FTP sera incomplet ; un paquet RST sera envoyé par le client au début de la session de commande (dport 21).

Cette transaction FTP incomplète permettra à la session d'être reconnue comme des données insuffisantes.

Le décodeur associé à l’application FTP n’a pas reçu assez de données pour réaliser des contrôles de conformité et de valider l’application FTP.

Note: FTP n'est pas obligatoire, il peut arriver pour toutes les applications avec un décodeur.

Les modules de sécurité du pare-feu de Palo Alto Networks est illustrée dans l’exemple ci-dessous :

Capture d’écran + + 2014-06-11 + au + 13.32.40.png

Dans les modules de sécurité, il est important de disposer des éléments suivants :

  • Une règle interdisant de trafic pour « tout » application
  • Une seule règle ci-dessus permettant le trafic pour une application spécifique
    • Flux de tuples (sip, szone, dip, dzone) pour le trafic FTP devront correspondre à cette règle. Il permettra aux App-ID de coup de pied.
    • S’il n’y a pas de telle règle, le trafic sera abandonné avant le début de App-ID

Dans ces conditions, si le trafic FTP est généré à partir de zone « replay_eth2 » à la zone « replay_eth3 », il sera bloqué à l’entrée de journal suivante :

Capture d’écran + + 2014-06-11 + au + 14.24.21.png

Cause

Ce comportement peut s’expliquer de la façon suivante :

  • Dans ce scénario très spécifique, pare-feu de Palo Alto Networks n’a pas toutes les informations nécessaires à la prise de décision finale configurée en règle « Tout refuser » (refuser)
  • La décision finale est prise une fois que l’application décodeur sera ont validé l’application (en cours d’exécution des tests de conformité contre transaction)
  • La correspondance de la règle finale et l’action seront différées après cette validation

Lorsque le paquet RST est reçu, la session se termine par ces États :

  • La session FTP de données insuffisante
    est incomplète et non validée
  • La règle «Deny All» correspondant à l'action «allow»
    a été temporairement définie sur «autoriser» pour que l'application-ID soit atteinte (dans 4 paquets de données ou 2000 octets de charge utile), et la règle «Deny All» était la meilleure correspondance potentielle.

propriétaire : nbilly



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClrUCAS&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language