unknown-tcp / udp - please explain

[cryptochrome]

Hi,

I know that these two applications stand for unrecognized traffic. It worries me though that for some of the other applications to work, I have to add unknown-tcp/udp to the firewall rule. Example for this would be Bittorrent traffic. To allow Bittorrent, I also have to allow web-browsing and unknown-tcp and unknown-udp.

Can someone please elaborate on this? If I only want to allow Bittorrent, but also add web-browsing and unknown-tcp, I will open up the firewall for unwanted traffic. I really have a hard time understand this concept.

Thanks

[NGS_SOC]

From PAN-EDU-201 v.5 rev A MOD 4 APP-Id slide 26

PAN-OS implicitly allows parent applications for a set of commonly used applications

Requiring that dependencies be allowed in order to enable an application can often allow more traffic than intended. For example, enabling access to web-browsing just to allow facebook-base allows users to browse other sites, requiring the administrator to configure other policies to regulate this access.
PAN-OS addresses this concern by implicitly allowing dependencies for a set of commonly used applications to streamline the security policy process. Implicit permissions of a parent application are only handled if there is no match with an explicit rule. 
The complete list of implicitly allowed applications can be found in Appendix B of this manual.

Appendix B

Allowed Application

• software-update apps
• business-systems apps (e.g., erp-crm, storage-backup, sharepoint)
• web-mail apps, IMs, social-networking
Implicit >> web-browsing

Apps identified in rpc decoder with a specific program ID (e.g., mount, nfs, portmapper, ibm-clearcase)
Implicit >> rpc

Apps identified in msrpc decoder with specific UUID (e.g., ms-exchange, active-directory, arcserve)
Implicit >> msrpc

msrpc
Implicit >> ms-ds-smb

ms-ds-smb
Implicit >> netbios-ss

Apps identified in rtsp decoder based on uri path in first request message (including custom apps)
Implicit >> rtsp

Apps identified in rtmp decoder based on uri path in the first request packet (e.g., bbc-iplayer)
Implicit >> rtmp, rtmpt

Media streaming apps (e.g., napster, megavideo)
Implicit >> flash

ms-rdp, msn-remote-desktop
Implicit >> t.120

Apps identified based on SSL hello or certificate in the response.
Ssh can remain in both uses-apps and implicit-uses-apps
Implicit >> ssl

yahoo-voice, gtalk-voice, msn-voice, msn-video, facetime
Implicit >> stun

several IM apps
Implicit >> jabber

gotomeeting, gotomypc, gotoassist
Customer is not expected to understand internals about Citrix ICA/Jedi
Implicit >> citrix/citrix-jedi

Never allowed unknown udp/tcp, I hope this could hlep

[jvalentine]

So yes, the original poster (cryptochrome) was correct in saying that for certain App-IDs, 'unknown-tcp' needs to be turned on. And I completely agree with him that "that's messed up" - I have to turn on 'unknown-tcp' for certain App-IDs to work? Say what?

This is an uncommon case.  Reading-up on Share-P2P, it looks like it's all encrypted traffic - which probably makes it impossible to create a signature-based App-ID.  I'm guessing the heuristics engine is what eventually detects this app, but until then it's identified as unknown-tcp.  I'm not aware of any "business"-class apps that require unknown-tcp to also be allowed. 

If you really must use this in your environment, then it would probably be a good idea to limit its use to specific users/computers/zones. 

[ericgearhart]

jvalentine wrote:
If you really must use this in your environment, then it would probably be a good idea to limit its use to specific users/computers/zones.  

Honestly you're right, I don't have a business use case for this one. It was just an observation (I happened to be building an App-ID filter for Breaking Point testing I'm doing and I noticed that warning when I pushed the commit job)

[cryptochrome]

Thanks . What I still don't understand after reading this:

Say I have a rule base that does not allow web-browsing at all. Now I add a rule that allows facebook-base. Since facebook-base also needs web-browsing, it resolves this dependency and invisibly adds we-browsing to the facebook-base rule. So I now have a rule that allows web-browsing plus facebook-base. Does that mean that any web-browsing to any destination is now allowed? Or ist it smart enough to actually only allow web-browsing to facebook?

[jvalentine]

Say I have a rule base that does not allow web-browsing at all. Now I add a rule that allows facebook-base. Since facebook-base also needs web-browsing, it resolves this dependency and invisibly adds we-browsing to the facebook-base rule. So I now have a rule that allows web-browsing plus facebook-base. Does that mean that any web-browsing to any destination is now allowed? Or ist it smart enough to actually only allow web-browsing to facebook?

With 5.0, PAN-OS only allows just enough web-browsing in order to enable facebook-base.  It won't permit other non-facebook web-browsing activities.

This type of rule was also possible with 4.1, but was a major pain.  You had to create a custom URL category that contained things like facebook.com, *.facebook.com, fbcdn.com, etc. etc.  Then you needed two firewall rules:

- from trust to untrust application=web-browsing SERVICE/URL CATEGORY="new custom FB category" action=allow

- from trust to untrust application=facebook-base action=allow

The first rule allowed web-browsing only to domains listed in that custom category, which would be enough to let the App-ID shift into facebook-base.  The 5.0 code does the same thing, but without the complexity.

(Coincidently, this is one of those few times where it is extremely useful to use URL CATEGORY as match criteria in the firewall rule.)

[cryptochrome]

Thanks. So if I understand correctly, the facebook-base "app" also knows the destination URLs for Facebook and dynamically opens them through the web-browsing dependency?

So I can be sure that opening facebook-app (and the implicit web-browsing dependency) will only allow traffic to Facebook.

More questions: What if Facebook adds new servers/URLs that are no yet implemented in AppID signatures? In that case I would have to revert to the PanOS 4.x way of doing things and add a custom URL category with those new URLs and put them in a rule like you explained above?

[jvalentine]

Thanks. So if I understand correctly, the facebook-base "app" also knows the destination URLs for Facebook and dynamically opens them through the web-browsing dependency?

So I can be sure that opening facebook-app (and the implicit web-browsing dependency) will only allow traffic to Facebook.

More questions: What if Facebook adds new servers/URLs that are no yet implemented in AppID signatures? In that case I would have to revert to the PanOS 4.x way of doing things and add a custom URL category with those new URLs and put them in a rule like you explained above?

You're welcome!  Yes, the facebook-base app-id signature knows how much/which URL(s) of web-browsing are required in order to enable the facebook-base app - so you won't be allowing other web-browsing traffic. 

"Back in the day" when I last did this with 4.1, I probably over-engineered (read: shotgunned) the custom URL category - but hey, it worked!  It could have worked with just *.facebook.com.  (Note to self, try this out in the lab sometime). 

IF Facebook changes the way their app works and IF it breaks the implicit dependency functionality, then yes, you could add an explicit dependency allow rule just for a custom URL category that has those new domains/URLs.  An explicit "allow web-browsing to FB-custom-category" rule will trump the implicit dependency functionality.  Not sure that this will ever happen, especially if it only needs *.facebook.com, but handy to have in your back pocket just in case. 

[cryptochrome]

Awesome. I think I got the hang of it now. No more worries for me now. Thanks!