Should I override the intrazone-default to deny?

[mb_equate]

TL;DR: yes, almost always.

We've had plenty of discussions on the behaviour of this default rule, and published Security Policy Rule Best Practices (paloaltonetworks.com) which provide guidance for logging. We've even discussed the results of these best practices, which often lead to the uninformed creating explicit policy to block what they now see as a potential risk - accepted Internet traffic to their public address space. But what's the actual risk, if any, of the default behaviour of this rule, and how do we know if we need to change it?

Firstly, if there is a requirement to deny all intrazone traffic e.g. firewall on a stick, the default intra-zone rule should be overridden to deny and log, never an explicit any/any/any/drop. Why? Because if the device is managed by Panorama, no rules in the parent post-rulebase will ever apply due to the order in which the rules are matched.

Where there is no requirement to deny intrazone traffic (e.g. no two interfaces share the same zone), is there any risk in keeping the default configuration i.e. allow, especially an untrusted zone? Does it permit anything that should be denied? 

Let's look at the possible use cases with the default configuration (intra-zone allow)

• Traffic between interfaces in the same zone
  • If by design, all systems within these zones are of equal trust and the firewall just routes between them, there is no risk
• Traffic to a firewall interface in the same zone
  • If using a management profile, is protected by the profile's ACL
  • When used in a dynamic routing protocol, a dataplane interface will listen on the protocol's services
    • BGP will only respond to a configured peer
  • When used in IPsec tunnels, portals or gateways will listen and respond on the relevant services
    • Protected by peer ID, strong keys and secrets
• Traffic to a NAT IP for which the route is via the same interface (e.g. inbound public NAT)
  • Requires policy to permit if destination is in a different zone

Any service exposed to untrusted data potentially increases the attack surface of that system, therefore when these services are in use there is a potential increase in risk - which must be appropriately compensated for by controls such as strong authentication. In some cases it is necessary to expose these services for them to function, as in the case of GlobalProtect.

I don't think there is a hard and fast rule - an Internet Gateway with the default policy and no dynamic routing or VPN would not look any different from the outside than one with the intrazone-default overridden to deny, and therefore would not benefit from any changes (despite inbound internet traffic being accepted in the logs).

The same device running BGP and GlobalProtect however exposes the additional services and therefore is at increased risk - however minimal. In this case, if we are to follow the principle of least privilege, i.e. only provide sufficient privilege needed to function, is it necessary to override the intrazone-default rule to deny and explicitly permit services? If BGP should only respond to a configured peer, it is still at risk of spoofed attacks for which authentication is a countermeasure. If GlobalProtect users are indeed global, it must be exposed to the Internet so again no deny is going to help you there either.

Take the same device, but you want to restrict GlobalProtect to your region. You can either override the intrazone-default to deny and allow regions to your GlobalProtect listener, or create the allow and block everything else (to the GlobalProtect listener).

Add IPsec, do you need to limit the peers in policy or leave it to the IPsec subsystem and keep the intrazone-default?

In any case it's a matter of weighing up the risks vs rewards. It's easier not to have to configure a policy for a feature to work, but is it worth the risk?  While I've previously taken an on-the-fence, risk-based approach to this question, in writing this I am becoming a fan of overriding the default behaviour to deny. Why? It doesn't expose services to unnecessary traffic should they otherwise discard. Even if those services are not enabled, you don't have to think about it when the CVE with a CVSS of 10 comes out against GP. It follows the principle of least privilege, and best practices for ingress filtering. It requires the administrator to consciously configure the device for their needs rather than accepting the defaults and encouraging a culture of complacency and ignorance.

I would also support a change in the default behaviour, for these very reasons, and more commonly cloud implementations which are often intrazone and require a default deny.

Such epiphany! Who's with me?

[reaper]

if the device is managed by panorama, there should be cleanup rules in the shared post policy to ensure all managed devices drop unwanted intra/interzone sessions and no local rules/overrides (you can still override the default rule in panorama, but for managed devices i prefer to have a set of cleanup rules)

for non-managed devices i fully agree, i usually set a rule to allow services (IPSec, GP, ...) and then drop everything else on the default intrazone with an override

[mb_equate]

I'm not a fan of explicit cleanup rules (anymore). Especially when people use them in child device groups 😉

I would probably take that approach in an Enterprise where requirements are common to all devices, but not all devices managed by a Panorama instance share the same trust model. In Professional Serices we try to standardise our deployments with tools like IronSkillet, but we don't get involved in the ongoing operation. In all cases we override the shared inter/intrazone-defaults to log (using a log forwarding profile called 'default', which everyone should use IMO). Following my recent epiphany, I'm going to set the shared intrazone-default rule in our code to deny and log, and encourage the use of explicit policy for everything, everywhere.

If PAN-OS has taught me one thing, that if the behaviour is built into the product and meets requirements, try to keep things as simple as possible and avoid unnecessary customisation - i.e. the KISS principle, unless best practice dictates an alternative.

[reaper]

makes perfect sense 🙂

90% convinced 😉

[S_Williams901]

I have always built explicit Deny clean up rules and never let it hit the default rules. Mostly due to auditors liking to see that implicit deny rule at the end of the policy list. 

[OtakarKlier]

Hello,

I respect your philosophy but disagree and we shouldnt use the default built in policies. In order to gain true granular control of the traffic, its best to just put in a DENY ALL policy at the bottom and then allow policies above it, etc. 

Just my thoughts.

Cheers!

[mb_equate]

The problem with this approach is you lose the ability to apply a shared post-rulebase policy across your fleet in Panorama, as your explicit deny will appear before any parent post rules in the resulting policy. When you override the default intra-zone rule in a child device group, the device will process this rule after any post rules defined in parent device groups in Panorama. It still performs the desired action (denies all traffic not explicitly permitted), it forms part of the effective configuration on the device and won't make any difference to an audit if you enable logging (use a log forwarding profile called 'default').

Your idea is good in principle but does not scale. This is why the default rules exist and allow overrides; I like the technology to work for me not the other way around.

[mb_equate]

I think you mean explicit deny. That said, when I audit such systems I rely on the effective policy being enforced - not just what some admins manually configure 🙂

[TomYoung]

Hi @mb_equate ,

I have traditionally sided with @reaper and @OtakarKlier on this one, but I like your idea for its simplicity and effectiveness.

I currently keep the intrazone-default rule for all of my trusted and semi-trusted interfaces to allow pings, etc.  So, I created rules to allow BGP from the peer only, GP from US only, IPsec from IPsec peers only, and then I drop all else on my untrusted interface.  I also needed to create outbound rules from the management interface.  These rules did not take that much time at all.  (My personal preference is not to log my drop rule which cleans up my logs big time, but I realize there are good arguments on both sides.)

I have this rule in the Panorama post-rulebase so that the local NGFW can create rules in front of it if necessary.

To move to your design would only require me to add one intrazone rule allowing ping, etc. to my trusted/semi-trusted interfaces which is actually better because their is no implicit allow.  In your design, the drop rule is at the very end, and is less prone to error.  (On another side note, I always select interzone or intrazone to make sure no traffic is allowed accidentally.  I do not leave it at universal unless intentional.)

Thanks,

Tom

PS On a side note, I have not seen much change in the best practices, Day 1 Config, etc.  I am not sure how much development is going on there nowadays.

[mb_equate]

Just stumbled upon a supporting reference - Azure Design Guide p28 (east-west in same vNet) - "then modify the default intrazone security policy to deny traffic".

[OtakarKlier]

Hello,

You make great points! Always do what is best for you an your environment. 

Cheers!