Optimize Your Security Policy

Let's cover some best practices to keep in mind when building or reviewing your security policy. Consider these tips to ensure the optimal experience from your configuration, but not mandatory or required for the Palo Alto Networks firewall to function properly. These are practices I've seen in my years as a support engineer, where administrators were faced with  unexpected issues that could have been prevented by sticking to a few of the guidelines.

Zones

A common infraction against best practice is the use of 'any' in the source or destination zone. In many cases, an administrator will start by setting an 'any-any' rule when first connecting the firewall into the network in the default VWire configuration. Doing so allows for traffic in both directions without needing to create two distinct rules, one for each direction of traffic.

The use of 'any' in a zone opens the possibility for the policy  to unintentionally allow sessions that were not accounted for, including, for example, intrazone traffic or zones that are added in a later stage while the policy was not updated to account for the additional zone.

There is, however, a little trick that will allow for a single rule to control traffic in specific directions between zones:

The policy type can be changed from universal to interzone or intrazone, to limit all zones in a policy to communicate only with each other but not with the same zone, or only with the same zone but not with the other zones.

Policies 2 and 3 in the picture below are identical (one is, in fact, a clone of the other) in every way except the 'type,' but they will behave completely differently, as rule #2 is set to intrazone and will only permit sessions from local to local, and remote to remote, but not local to remote, or remote to local. Rule #3 does the opposite; it will only allow sessions from local to remote and vise versa, but not between local and local, or remote and remote. Applying this little setting instead of using the dreaded 'any' will allow for simplicity but still provide security and prevent oversights.

Service

Since PAN-OS 6.0, the default setting of the service when creating a new policy is set to application-default, but will only enforce the default application ports when applications are also added to the rule's application tab. Starting from PAN-OS 7.1, having application-default set in a policy will enforce default application ports to be used even with no applications in the policy's application tab. It is, however, still fairly common to see policies where the services have been set to 'any.' This too, can lead to unexpected side effects in allowing unwanted or unnecessary connections.

Any session handled by the Palo Alto Networks firewall will, at the least, have passed through the security policy twice: when the initial SYN packet is received, the firewall policy is checked to see if a rule matches the source zone, source subnet/IP, destination zone, destination subnet/IP, and destination port. If a rule is created with the intention to allow web browsing, but with the service set to 'any,' this policy is going to allow the handshake for an FTP connection on port 21 through. This session is then going to take up resources on the firewall as a session is created in the state table, NAT may be applied etc. The session will only be blocked after the TCP handshake, when App-ID was able to identify this as 'not' an allowed application. In the meanwhile, unnecessary resources were spent on a session that could have been blocked from the first SYN.

Application

Many times, the application tab is left as 'any' because an administrator may not have a full overview of applications that must be allowed. This can also be remedied by leveraging behavioral characteristics to create a permissive or restrictive policy for certain application traits when exact applications are not known yet.

The blocked-apps-filter lists a series of behaviors that can be considered bad in many corporate networks, so while an administrator may not be aware of all the applications that could be bad, he can create a security policy to block any application that behaves in an undesirable way. Each weekly content update will also update the application filter with new or updated applications, so new applications are added automatically without the need for the administartor to update his or her policy.

The allowed-app-filter, in turn, lists a series of 'good' traits that are to be expected for business-relevant applications.

Security Profiles

If you do not have a Threat Prevention or WildFire subscription, please consider investing in these offerings as security profiles make the Palo Alto Firewall truly Next Generation (due to parallel processing architecture scanning for threats/viruses with far less of an impact on throughput, compared to traditional firewall products with an additional scanning module). A closer look at security profiles will show how to get the most from the best.

Although the default security profiles that come preloaded are useful to set up a system in a very short time, I would recommend every administrator create new security policies.

There are several advantages to creating new profiles, as some features can only be enabled in a custom profile: you will be able to enable packet capture for vulnerabilities that will allow for forensic analysis. DNS sinkhole can be enabled in anti-spyware that will prevent malicious outbound connections by changing the DNS IP address associated to a hostname, not only preventing the connection but also making tracking down the infected/suspicious host easier for the administrator.

More strict policies can be enabled to block all types of threats and more logging can be set for URL filtering (default URL filtering will not log allowed browsing sessions, for example).

I'll highlight a couple of example profiles below:

A custom AntiVirus profile allows an administrator to enable packet captures and also comes with WildFire enabled (the default profile does not include WildFire settings).

The custom Anti-Spyware profile enables the administrator to set a more aggressive approach for hosts sending out spyware. This is also where the DNS settings can be configured: the sinkhole will make sure malicious domains are poisoned with a mock IP address that will prevent C&C communication or downloading of malicious payload.

Further action will also make tracking the infected client easier. As the malicious DNS query may originate from an internal DNS server, the C&C connection will originate from the original requestor (infected host).

If you have any external dynamic blocking lists, these can also be added to the profile and set to sinkhole or a different action.

In a custom vulnerability profile, an administrator can opt to block an IP address for a certain amount of time and include low and informational severity threats, which are not included in the default profile.

In URL filtering, all allowed categories can be set to 'alert' which ensures logs are stored for both blocked and allowed browsing sessions. The additional settings like 'Safe Search Enforcement' can also be enabled from a custom URL filtering profile.

I've covered some interesting filetypes to block and why in a different article and video: Tips from the Field: File blocking profile.

I hope this information was helpful. Feel free to leave any and all comments below.

Best regards,

Reaper