topic Re: How packets match security policy when when application are incomplete or insufficient in General Topics

How packets match security policy when when application are incomplete or insufficient

nattapong_thi — Sun, 10 Jan 2021 09:14:35 GMT

For an example, I have 2 security policies

ruleA) source ip: any, source zone: any, destination ip: any, destination zone: any, application: dns, service: any, action allow

ruleB) source ip: any, source zone: any, destination ip: any, destination zone: any, application: any, service: any, action allow

and traffic initiate from client is DNS request port53, my question is when Paloalto still not know the application yet (or application is incomplete), which policy will apply for the traffic?

Pls share me a reference guide also, Thank you in advance

Re: How packets match security policy when when application are incomplete or insufficient

BPry — Sun, 10 Jan 2021 21:58:19 GMT

@nattapong_thi,

You would expect traffic to hit Rule A in your example. The reason for this is that the firewall needs to allow enough traffic to actually identify the application, so when you specify an app-id of 'dns' and use service of 'any', you are effectively telling the firewall to allow traffic across any port until it's able to identify the application. As soon as the application is identified, then the traffic would be re-analyzed to see what rulebase entry matches the newly identified traffic, if any.

Re: How packets match security policy when when application are incomplete or insufficient

reaper — Mon, 11 Jan 2021 12:11:18 GMT

This is why 'application-default' is very important in the service of a security rule

when the firewall accepts the very first packet of a session, it will only be able to identify the '6-tuple'

source subnet, source zone, destination subnet, destination zone, destination port and protocol

it will then go look for a security rule that matches those criteria; so in your case ruleA will be hit by everything,even a SYN packet for port 80

once App-ID is able to identify the session is in fact http (by packet 4 due to the HTTP GET), it will re-evaluate the security rules and match ruleB

if the syn is never responded to (incomplete), the session will die on ruleA as there will not be a reason to re-evaluate security rules until a new application is identified

if you set application-default, ruleA will be limited to port53 TCP/UDP, so connections on port80 will automatically drop to ruleB

one step further: if, for example, ruleA is dns and ruleB is ssl, both with service application-default: a SYN packet for port 80 will automatically be discarded on the implied interzone drop rule, since only ports that match one of the defined applications will be allowed through so a session can be created.