• One feature that makes Palo Alto a next generation firewall solution is its ability to identify network applications in the session stream

• using application-based traffic classification which determines the identity of applications. The name for this feature is "Application ID" aka "App-ID". Palo Alto provides their database of identified application signatures online here.
  
  This database is updated on the UW-Madison firewalls automatically on a daily basis or manually by the Office of Cybersecurity if an urgent release is announced, requiring an update prior to the daily scheduled update. Firewall administrators can view this database on their firewall instance using one of the following ways in Panorama:
  • Go to the Objects tab under Applications.
  
  
  
  • Under the Security Policies, within a firewall rule properties under the Application tab and selecting Add.
  
  
  
  • Go to the Policies tab under Applications. Then click on any of the cells in the Application column which will display an Application pop-up window. Click on the Browse button.
  
  

• Application Dependencies:
• Application dependencies, or "Depends on Applications" is a list of dependencies that are required by the application-id for it to work properly. (See image below)
•  
• If you don't allow the dependencies that are required by the application through the firewall security, then the connection can be seen as not established and the application will not be reached/connected.
• • There is a subset of dependencies described as "Implicitly Use Applications". Dependent applications can be allowed implicitly when the firewall is able to determine the correct application by a specific point in the session.
  
  
  • A common example used is the Facebook-base application
  • When the firewall identifies Facebook-base in use it implicitly knows web-browsing is needed and then web-browsing is allowed.
  
  

• Application-Shift:
  • Application-Shift is a session shifting from one application into another application. Whenever an application shift happens, the firewall performs a new security policy lookup to find the closest rule matching with the new application.
    
    Applications like Gotomeeting and YouTube are initially identified as SSL, web-browsing and Citrix. As more packets for these sessions pass through the firewall, more information is reviewed to identify the application to be allowed through or blocked by the firewall. The firewall then shifts the application to respective application-ids like Gotomeeting and Youtube.
    
    What happens to the session when the Application-ID changes in the middle of a session?
    • The firewall takes the session and checks it against the firewall rules to find the best match. If the application shifted away from an application specified by your security policy it will match on any rule matching with ANY in the application, or one of the catchall rules.

• Application-ID Non-Standards:
  • App-ID does not use signatures and decoders to identify applications in encrypted traffic. However, the firewall attempts to identify the encrypted application using two other methods. The first method relies on the Common Name field in a certificate, which typically contains either the FQDN of the server or its IP address. The second method relies on a TLS protocol extension named Server Name Indication, or SNI, that enables multiple hostnames to be served over HTTPS from the same IP address.
    
    There are times when the firewall may identify the application other than the actual application signature in use, some examples are:
    • Pre-policy check may drop the traffic in security logs. When this is done, Traffic logs will show the application as "not-applicable".
    • App-ID also labels traffic as not-applicable when the firewall discards the traffic because the Security policy does not allow it.
    • If the firewall cannot identify the traffic using either the CN field in the certificate or the SNI field in the TLS handshake, then the traffic is identified generically as the SSL Application-ID.
    
    Applications can be reached or connected on non-standard ports (TCP/UDP) aka Application-Default.
    • To accomplish this, create special services which call the specific ports and assign under the Service column section of the Policies tab (security policy properties).

• Service, "Application-Default":
  • Every application specifies the most common "default" service port used aka "Application-Default", i.e. tcp/3389 for ms-rdp (Microsoft Remote Desktop). If an Application-ID is specified with the standard port, the service object named application-default in the Security Policies should be used.
    
    It's important to note that any service other than Application-default will override the port used to identify the traffic for the used Application-ID. In the before used example, if ms-rdp was set with tcp/3390 (where the default port is tcp/3389) in the service tab, the rule specifying ms-rdp will not match for any RDP attempts other than those with tcp/3390 used in the connection. The firewall simply passes over the rule and does not apply the desired action.
    

• Application Override:
  • Application override forcibly bypasses the AppID process and sets a session to match a manually configured Application name. Any sessions processed like this will not be scanned by parallel processing and will be offloaded to the physical CPU, aka "fast path".
    
    For most use cases, we recommend creating a simple custom application with as few attributes as possible, as the app override will bypass scanning or signature detection. It will simply identify a session as the custom application and take no further action. This can be a very simple but powerful tool to help identify internal applications and improve throughput as the session is offloaded to hardware immediately, but please consider the security implications. The following example outline examples for how to setup an Application-override object:
    
    
    
    

If you come across any additional questions, please send them to cybersecurity@cio.wisc.edu.