Comment la détection de travail BitTorrent sur le pare-feu de Palo Alto Networks?

Détails

En raison de la façon dont le pare-feu Palo Alto Networks gère la détection des applications P2P, l'utilisateur peut voir une confusion STARTLOG indiquant que BitTorrent est autorisé, même si une règle de refus est en place et le trafic est effectivement nié.  Voici une explication de la façon dont fonctionne la détection.

Pour beaucoup d'apps de P2P et de Skype nous employons le prévision-écoulement pour prévoir quelques sessions basées sur d'autres sessions.  Avec BitTorrent par exemple, nous prédiction de nombreuses sessions TCP basées sur les sessions UDP, et pour eMule, une session UDP prédit de nombreuses autres sessions eMule UDP.  La prédiction se produit dans le cadre du décodeur pour l'application.

Le flux pour BitTorrent est le suivant:

1. Les sessions UDP entre le pare-feu de Palo Alto Networks.
2. ID App détecte qu'il est BitTorrent.
3. Le soft devient BitTorrent.
4. Le décodeur BitTorrent fonctionne.
5. Le flux de prévision pour la session TCP est défini.
6. Session TCP arrive, et il devient BitTorrent, comme prévu.

Tout fonctionne très bien lorsque nous autorisons ce trafic.  Toutefois, si l'utilisateur configure BitTorrent à refuser, ce qui suit se produira:

1. La session UDP entre dans le pare-feu de Palo Alto Networks.
2. ID App détecte qu'il est BitTorrent.
3. Le soft devient BitTorrent, et il est nié.
4. Le décodeur BitTorrent ne fonctionne pas et aucun prédiction-Flow n'est défini.
5. La session TCP arrive, et comme aucun flux de prédiction n'a été défini, il devient «inconnu».

Pour surmonter l'enregistrement "inconnu", nous avons introduit quelques applications internes (par exemple bit-Internal). Ce $ $ etAPP est signalé comme BitTorrent sur l'UI. C'est ce qui va se passer pour BitTorrent:

1. La session UDP entre dans le pare-feu de Palo Alto Networks.
2. App ID détecte qu'il est bit-Internal. Il est rapporté comme BitTorrent sur l'INTERFACE utilisateur (mais l'action est toujours autoriser).
3. L'Application devient bit-Internal.
4. Le décodeur bit-Internal s'exécute.
5. Le flux de prévision pour la session TCP est défini.
6. L'application est réglée sur BitTorrent.
7. La session est bloquée si l'action est Deny pour BitTorrent.
8. Session TCP arrive, et il devient BitTorrent, comme prévu.

Alors que le trafic est identifié comme BitTorrent, si l'utilisateur a le journal de démarrage activé et que l'action est définie sur refuser pour BitTorrent, deux journaux s'afficheront pour ces sessions UDP.  Un log disant BitTorrent, permettre (celui qui est rapporté pour bit-interne), et L'autre en disant BitTorrent, Drop.

Le trafic est effectivement supprimé, bien que l'Entrée de journal "Autoriser" initiale peut être confuse.

Onwer: panagent