blocking apps on non-default ports

[nikoo]

Hi,

Sadly don't have PA to play around at the moment, so have to pass this question for all you out there as I'm sure I cannot be first one with such an idea.

What is the best way to block apps on their non-default ports?

Basically, allow apps ONLY on their application-default ports. My first thought was like:

Rule1 - src: trust, dst: untrust, application: any, service: application-default, allow

Rule2 - src: trust, dst: untrust, application: any, service: any, deny

But this way, due to rule processing sequence, as soon as PA seens Rule2 for new traffic, it does not go futher to App-ID, but block the traffic based on service.

At the moment there is "permit all/catch all" rule before the default intra/inter-zone rules, but if that was not there, how would the default inter-zone rule (from trust to untrust for example) block the non-default port traffic for any app or would it still catch all based on the service before the App-ID and would not allow anything further?

[reaper · Accepted solution]

Hi @nikoo

your policy will work perfectly

rule processing hits on 'first match' and then stops

this means that in the stage where app-id is not known yet, app-default will already have all ports open for the apps you defined in the application field

- if you allow all applications on their default ports, in this stage all ports will be open (so in your case all tcp handshakes will be created into a session and App-ID becomes responsible for blocking applications)

- if you only allow a handfull of apps, those ports will be open and the rest will be closed (already preventing tcp handshakes if the ports don't match)

once the port matches the first rule, the session is accepted and app-id will kick in

if then app-id identifies an application on a non-default port, the session will be discarded as it will not match the first rule anymore and the second one dictates a discard

if your second rule were to be allow, this session, that was initially allowed to start on rule 1 (possibly due to port overlap, eg. smtp on tcp 80) would now be switched to rule 2

hope this helps

[nikoo]

Hi, @reaper

Ok, thanks for assuring me, will look into why it is acting the way it is, because it seems like not hitting the correct rule then with the current deployment.

[nikoo]

Long story short, reason for my doubt was SSL, becuse decryption was done.

Basically, when SSL decryption succeeded, instead of seeing application ssl at TCP/443 as initially, Palo Alto saw application web-browsing at TCP/443 which is not the application-default port and due do that was blocking it, which is pretty much expected with this configuration.

[bradk14]

good you got it figured out. one of the well documented banes of AppID and web browsing.

for future reference:

https://live.paloaltonetworks.com/t5/Configuration-Articles/After-Configuring-SSL-Decryption-Web-Bro...