Security policy conflicts between the Application and Services?

[UXPSystems]

Hi all.  I am playing with security policy, and seeing a result that I am not expected.

Basically I would like to allow connection from the Local (trusted) zone to a specific server in the DMZ zone to allow port 443 (ssl) traffic only

In the Source section, to simplify things a bit, I set to "Any, Any" (all user in the Local zone is allowed to access the DMZ zone).  Then in the Destination section, I set the Application field to "ssl", and the "Service" field to "any" (default is application-default).  However, I notice users in the Local (trusted) zone is able to access the specific server in the DMZ zone over other ports, eg: 80, etc.  Now, once I've set the "Application" field to "ssl", and "Service" field to "application-default", it is giving me the desire result. 

Can anyone please give me an explanation on this?  Eg: the evaulation (relationship) between "Application" and "Service".  Do I need to configure both "Application" and "Service" field, or just configure one of them is fine?  Thank you. 

[davanderson · Accepted solution]

I would recommend setting up your rule as follows:
Src zone: inside
Src address: local subnet ip
Dst zone: dmz
Dest address: web server ip
Service:. <leave empty>
Application: SSL

[gwesson · Accepted solution]

To address your point as to why you're seeing port 80, it's because the firewall cannot determine in the first few packets if a request is going to be TLS or not. A SYN on port 80 doesn't necessarily mean it will be HTTP (web-browsing app), just as a SYN on port 443 does not necessarily mean it will be SSL/TLS.

The logs you see should indicate that there wasn't much more than 4 or 5 packets for anything that is not listed as the "ssl" application.

So you can leave the service as "any", and the firewall will still ensure that only sessions identified as the "ssl" application is allowed, but you will see some sessions that are initially allowed until app-id can determine that it's not SSL.

Using application-default (or setting the service to use only port 443) can prevent that, and if your DMZ doesn't serve any non-443 traffic anyway it makes sense to limit it. But I generally recommend keeping the service empty so that you can spin up other non-443 services in the future over TLS/SSL and won't have to adjust your rules later.

[UXPSystems]

Hi all.  So in general, the allow access is based on the "application" and "service" list, and if the applications and services isn't on the either of the Application and Service list, the PA firewall will accept the connection by then will drop it after the rule check?  I guess what confuse me is I am expecting the PA to block the port 80 access (in this example) rather than it accepts the connection, then do the rule check, then drop the connection.  In Cisco world, usually it simply blocks the port access if it is not on the allow list....  I still can telnet to port 80 from a windows laptop, and it simply give me a blank screen, which just means the port 80 is accessible ...

Thank you.

[BPry · Accepted solution]

@UXPSystems,

Depending on the rest of the configuration the firewall will need to allow access to the specified source ports long enough to determine what the app-id registers as, which is why I generally don't recommend you use the service 'any' within security policies if you can get away without it. Once the firewall can identify the traffic as something not allowed it will drop the connection, but it has to allow enough packets for you to actually get the proper app-id. 

There are of course downsides to this if you utilize 'any' in the service policies and the first few packets will get allowed to that destination until it can identify which app-id it's attempting to utilize; there are more than a few differentiations here that means that this isn't always true, but it's an easy enough rule to follow. 

[UXPSystems]

I see.  In my case, I should fill up the "Application" field, and then set the "Service" field to "application-default".  I was freaked out when I saw the telnet connection to those ports were sucessed even though I haven't allow the access on the PA.  Thank you all for the explanation.