Wie funktioniert die Erkennung von BitTorrent auf der Palo Alto Networks Firewall?

Details

Aufgrund der Art und Weise, wie die Palo Alto Networks Firewall die Erkennung von P2P-apps übernimmt, kann der Benutzer ein verwirrendes startlog sehen, das anzeigt, dass BitTorrent erlaubt ist, obwohl eine Denial-Regel vorhanden ist und der Verkehr tatsächlich verweigert wird.  Im folgenden wird erläutert, wie die Detektion funktioniert.

Für viele der P2P-apps und Skype verwenden wir Vorhersage-Flow, um einige Sessions auf der Grundlage anderer Sessions vorherzusagen.  Mit BitTorrent zum Beispiel prognostizieren wir viele der TCP-Sessions, die auf den UDP-Sessions basieren, und für eMule prognostiziert eine UDP-Session viele andere eMule-UDP-Sessions.  Das Prädikat passiert als Teil des Decoders für die app.

Der Flow für BitTorrent ist wie folgt:

1. Die UDP-Sessions treten in die Palo Alto Networks Firewall ein.
2. APP ID erkennt, dass es BitTorrent ist.
3. Die APP wird BitTorrent.
4. Der BitTorrent-Decoder läuft.
5. Der Vorhersage Fluss für die TCP-Session ist gesetzt.
6. TCP-Session kommt, und es wird BitTorrent, wie erwartet.

Alles funktioniert toll, wenn wir diesen Verkehr zulassen.  Wenn der Benutzer BitTorrent jedoch so konfiguriert, dass er verweigert wird, wird Folgendes geschehen:

1. Die UDP-Session tritt in die Palo Alto Networks Firewall ein.
2. APP ID erkennt, dass es BitTorrent ist.
3. Die APP wird BitTorrent, und Sie wird verweigert.
4. BitTorrent-Decoder läuft nicht und es wird kein Vorhersage-Flow gesetzt.
5. Die TCP-Session kommt an, und da kein Vorhersage Fluss gesetzt wurde, wird Sie "unbekannt".

Um die "unbekannte" Protokollierung zu überwinden, haben wir einige interne Apps (z.b. Bit-intern) eingeführt. Diese APP wird als BitTorrent auf der UI berichtet. Das ist es, was für BitTorrent passieren wird:

1. Die UDP-Session tritt in die Palo Alto Networks Firewall ein.
2. APP ID erkennt, dass es Bit-intern ist. Es wird als BitTorrent auf UI gemeldet (aber die Aktion ist immer noch erlaubt).
3. Die APP wird Bit-intern.
4. Der Bit-interne Decoder läuft.
5. Der Vorhersage Fluss für die TCP-Session ist gesetzt.
6. Die APP ist auf BitTorrent eingestellt.
7. Die Sitzung wird blockiert, wenn die Aktion für BitTorrent verweigert wird.
8. TCP-Session kommt, und es wird BitTorrent, wie erwartet.

Während der Traffic als BitTorrent identifiziert wird, wenn der Benutzer das Start Protokoll aktiviert hat und die Aktion für BitTorrent verweigert wird, werden zwei Protokolle für diese UDP-Sitzungen angezeigt.  Ein Log, der BitTorrent sagt, erlaubt (derjenige, der für Bit-intern gemeldet wird), und der andere, der BitTorrent sagt, fallen.

Der Verkehr wird tatsächlich gelöscht, obwohl der anfängliche "Allow"-Log-Eintrag verwirrend sein kann.

onwer: panagent