Need help with logging in case of App-Id
cancel
Showing results for 
Search instead for 
Did you mean: 

Need help with logging in case of App-Id

L0 Member

Hi,

 

I have below rule in my Palo Alto and another default rules which are Intra-zone and Inter-zone.

Source: 10.0.0.0/8

Source Zone: Trust

Destination: Any

Destination Zone: Untrust

Application: ssl, web-browsing, dns, Facebook-base, YouTube-base, etc

Service: Application-default

Action: Allow

Log: At session end

I am trying to understand behaviour of Palo Alto in terms of Application-Id and traffic logs.

 

Let us suppose if someone tries to establish connection using for port udp/1194 or any other tcp port using nmap, which apps allowed in my explicit policy are not using. Which policy will this traffic be hitting when traffic is going from 10.0.0.0/8 network to Untrust zone for Any destination. What will be I seeing in logs.

3 REPLIES 3

L7 Applicator

in terms of establisghing a connection, the 'application-default' setting will populate the rule with all the ports associated with the applications you list, so in your case 53, 80 and 443

 

any connection coning in on a different port will drop down to the interzone rule and be discarded

 

any connection coming in on one of the allowed ports will be accepted and will cause a session to be created and packets to flow

at this point (typically tcp handshake) the app-id will not be known yet so for a tcp session at least 3 packets will be allowed to flow back and forward, for DNS there would be an immediate decission to allow or drop down to intraone as the first packet already contains identifiable payload

 

when tcp starts to talk payload, app-id will be able to identify if an app is alowed or not, so if at some point SQL is identified while communicating over port 443, the session will no longer match your rule and drop down to the interzone rule and be discarded mid-flow

Tom Piens - PANgurus.com
Like my answer? check out my book! amazon.com/dp/1789956374

Log1.JPGLog2.JPG

Hi @reaper ... Thanks for your quick response.

 

We have allowed application "app-discovery-request" in list of allowed applications when traffic going from Inside to Outside Zone. As per you, while trying to install session it considers destination ports which are being used applications allowed in policy. In my case, application "app-discovery-request" uses udp dynamic range which means it can use or allow any udp port.

 

Let us suppose if someone tries to make connection for an application which uses udp port 1194 (for example, open-vpn application), should the traffic for this application using udp port 1194 hitting this existing policy where I did not allow open-vpn but allowed "app-discovery-request" which uses dynamic udp ports and 1194 can also be a part of this.

 

I have also attached logs from my firewall which I can see for udp port 1194. As per you, if application is not allowed in explicit rule, then it should be hitting default deny policy after application identification is completed. However, I see this behavior in logging of traffic logs. Is the firewall logging correctly traffic logs or is there any issues with logging behavior of PALO ALTO. Let me know your thoughts as it will clear a lot of things and I will be able to plan it accordingly for future cases.

 

Will  be waiting for your kind response.

 

Thanks & Regards

This KB might help. Basically 4 packets or 2000 bytes are allowed for the appid engine to try to identify the app.

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClIgCAK

 

- DM

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!