blocking apps on non-default ports

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

blocking apps on non-default ports

L3 Networker

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?

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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.

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.

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...

  • 1 accepted solution
  • 3128 Views
  • 4 replies
  • 0 Likes
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!