How Does Detection of Bittorrent Work on the Palo Alto Networks Firewall?

Details

Due to the way the Palo Alto Networks firewall handles detection of p2p apps, the user may see a confusing startlog indicating that bittorrent is allowed, even though a deny rule is in place and the traffic is actually denied.  The following is an explanation of how the detection works.

For many of the p2p apps and skype we use predict-flow to predict some sessions based on other sessions.  With bittorrent for example, we predict many of the TCP sessions based on the UDP sessions, and for emule, one UDP session predicts many other emule UDP sessions.  The predict happens as part of the decoder for the app.

The flow for bittorrent is as follows:

1. The UDP sessions enters the Palo Alto Networks firewall.
2. App id detects that it is bittorrent.
3. The app becomes bittorrent.
4. The bittorrent decoder runs.
5. The predict flow for the TCP session is set.
6. TCP session arrives, and it becomes bittorrent, as expected.

Everything works great when we are allowing that traffic.  However, if the user configures bittorrent to be denied, the following will happen:

1. The UDP session enters the Palo Alto Networks firewall.
2. App id detects that it is bittorrent.
3. The app becomes bittorrent, and it gets denied.
4. Bittorrent decoder does not run and no predict-flow is set.
5. The TCP session arrives, and since no predict-flow has been set, it becomes "unknown".

To overcome the "unknown" logging, we introduced some internal apps (e.g. bit-internal). This app is reported as bittorrent on the UI. This is what is going to happen for bittorrent:

1. The UDP session enters the Palo Alto Networks firewall.
2. App id detects that it is bit-internal. It gets reported as bittorrent on UI (but the action is still allow).
3. The App becomes bit-internal.
4. The Bit-internal decoder runs.
5. The predict flow for the TCP session is set.
6. The app is set to bittorrent.
7. The session gets blocked if the action is deny for bittorrent.
8. TCP session arrives, and it becomes bittorrent, as expected.

While the traffic is identified as bittorrent, if the user has start log enabled and the action is set to deny for bittorrent, two logs will show up for those UDP sessions.  One log saying bittorrent, allow (the one that is getting reported for bit-internal), and the other one saying bittorrent, drop.

The traffic actually gets dropped, though the initial "allow" log entry may be confusing.

onwer: panagent