What a difference a Deny makes

[reaper]

I had an interesting discussion with @soporteseguridad the other day where we tried to figure out some unexpected packets he was seeing on his external router.

The security policy was set to block all SMB packets, based on their service port, rather than the application. The external router, however, was still picking up packets with destination port 445 so we wanted to figure out why.

Security policy with action Deny

The firewall will treat sessions differently depending on how the security policy has been set up and which decissions have been made in favor of alternatives: When a policy is created to block a specific application, the only way for the firewall to find out which application is used in a specific session, is to let packets tricke through and a session to be established. Once the session has been established, the firewall will be able to identify an application based on the payload of the packets and how the session behaves. For example if the server sends a response 220 and the client replies with an ack, the application will be FTP, if the client sends out an HTTP GET, it's going to be web-browsing.

For this stage to be reached, however, the TCP handshake needs to be allowed through, even though the security policy eventually is set to block the application.

TCP handshake will need to be allowed for this policy to match and Deny to be applied

If the security policy is set to 'any' application and has only services (or another 'any' in the services) with the action set to drop, the SYN packets will be immediately dropped upon receipt because there is no need to identify the application,

Packets will immediately be discarded by this security policy, no handshake required

One exception to this last policy behavior is when the securtity policy action is set to 'Deny'. This is where 'the devil is in the details':

The drop action simply drops all packets silently, the Deny action implies a reset action, which may be desirable in some scenarios, but there are also separate reset actions for each direction:

Security Policy Reset Actions

So what makes 'Deny' so special?

The 'Deny' action applies an action that is preferred per specific application. Some applications can be silently dropped after being identified while others may be better served by being sent a reset to terminate the session.

The Deny action refers to the applications' Deny Action

So, choose wisely when deciding which actions to apply to your security policies; several different ones are available to allow you more control over how to handle specific applications.

You can follow the original discussion here: PA SMB deny behaviour

Last year I had a similar discussion about the other options in the firewall action, you can check it here: reset-client vs. reset-server

Reaper out

[jyates]

Nice post, well-written.

[epeeler]

So in the very top example with application set to any and the service identified but with action set to deny, the firewall is still having to ID the app to determine what the correct "deny" action is.  Is that correct?

[reaper]

@epeeler that's correct

'Deny' is app dependent whereas 'Drop' is not

[epeeler]

Great info. Excellent post, thank you!

[pteixeira]

Afternoon, could you further describe what the drop-reset "Deny Action" is under the application?

Is it any of the known actions from the policy action settings as follows:

• Drop
• Reset Client
• Reset Server
• Reset Both

Or is it describing what action it takes on server followed by the client?

Is it a reset packet to the client, and a drop/nothing to the server?

drop-reset to me isn't as clear as the policy actions, would appriciate any clarifiaction. 

[MP18]

Very good post.

Thanks for creating this.

[DaMonk]

I am doing some testing with this at the moment, and I am finding even with a drop rule the SYN is being transmitted.  The firewal is even logging the action as allow, on a rule that has an action of drop

Edit..

With a little more testing it appears to be related to the position of the Drop rule in the policy.  If the rule is First then I get the SYN dropped, however if the Rule is at the end then the SYN's are allowed.

I suspect this is done as the policy also has rules to allow specific applications, and there may be an allowed application in the rules above.  However if I set a Drop Rule for a destination port (service) I expect the to policy will drop it no matter where the rule lies, if it is the first match based on SRC DST PORT then it should drop.

[smarcyes]

The below mentioned line brings up an interesting notion though...

"When a policy is created to block a specific application, the only way for the firewall to find out which application is used in a specific session, is to let packets tricke through and a session to be established. Once the session has been established, the firewall will be able to identify an application based on the payload of the packets and how the session behaves"

PA documentation seems to always recommends to configure policies based on "application" rather than service port. This makes sense for an "allow" rule because you want to make sure the traffic is legitimately the application that should be allowed through and not just simply "other" traffic that is using the same port as legitimate traffic.  But it would seem that in the case of a "blocking" rule, it would seem best to block on port rather than application with a drop action as the syn packet would be blocked immediately vs allowing some packets to trickle in to determine the application with say a deny action?  The rule based on application/deny is effectively potentially allowing a single or few packet based attack. 

Take an example of blocking ssh to a server.  It would seem better to create a rule to match on port 22 with action of drop vs a rule that matches based on application=SSH and especially set to a deny action.  However, even an application=ssh and an action of drop would still seem vulnerable in that the firewall will have to allow some packets through to determine its the SSH application.

[BPry]

@smarcyes,

I think this really depends on what you're trying to do. For instance, when I block QUIC traffic outbound to my untrust zone I may not want to just outright drop UDP/443 traffic at the very top of my rulebase. While that's usually going to be QUIC, it is used for other traffic that I might actually want to allow through. In that instance, doing it off of the QUIC app-id signature might be preferred. Keeping in mind that as soon as QUIC is identified after the traffic is going to get dropped. So while you're allowing some traffic to proceed, the firewall does a very good job of identifying the traffic quickly and dropping it. 

When you're talking about something like tcp/22 in the case of SSH, depending on the zone and my intent I might not have that same concern. I might actually want to block any tcp/22 traffic to my untrust zone regardless of app-id. In that case, just dropping it from a service aspect means I don't have to allow any traffic to traverse that port. Same thing for port 445 across the untrust zone regardless of TCP or UDP, I might just want to drop all of that traffic outright. 

Just to bring up as well, I don't see a general need for deny rules in most well-kept rulebases. You need to have something that would otherwise allow the traffic to be processed anyways. So in the case of SSH, that's something that I would actively have to allow, and where it is allowed in the rulebase I ensure that it's very targeted to include utilizing user-id to lock it down to specific people (or groups) to very targeted destinations. Same with the SMB example utilized in these examples; I'd argue that anything allowing SMB across zones should be heavily targeted and defined.

I see some people unknowingly allowing access to applications to their untrust zone when doing audits. Generally, this is because they created a rule that essentially says anything from trust to untrust with application any with service application-default action allow. This is pretty poor way to build outside access from a security aspect, but it's where more of these deny rules off of app-id come into play for people. I'd argue that you should be maintaining application-groups based off of set criteria when allowing outbound untrust traffic. That would be the more "secure" way of allowing internet access, and it does away with the vast majority of deny entries in a rulebase. 

[smarcyes]

@BPry 

Good example of where the blocking based on service might not always apply.  Yea, I dont think in the outbound direction, I would be concerned as much.  It would be more of less "untrusted" zone to a more "trusted" zone that would seem to make more sense as you mentioned.