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 😉