Episode Transcript:
Hello everyone and welcome to today’s episode of PANCast. Today we’ll be talking about one of the most fundamental parts of your firewall’s configuration: the firewall security policy. I know what you're thinking — it’s pretty easy to configure a security policy, what can I really learn from this? Well I’m glad you asked. Firstly, in my years of supporting customers with Palo Alto Networks firewalls, I have seen a lot of instances where the way the security policy works was not clearly understood. This has therefore been the root cause of what sometimes looks like the firewall not working properly. And secondly, ultimately the traffic you allow or block, the traffic you choose to apply URL filtering on, and the traffic you need to inspect for threats — all of this is based on your security policy. So if it is not set up correctly then you are not securing your environment the way you think you are.
So let’s get into it.
John Arena is a Professional Services Consultant with a background in Technical Support for Palo Alto Networks and a passion for educating and sharing knowledge with customers.
The first thing I want to talk about is firewall security policy match. When creating a policy, there are multiple sections but these can be thought of as two distinct areas. One is the policy match and one is the action. So for example the source zone, or source IPs are a policy match. But this also includes a lot of other matching criteria such as users, user groups or even URL categories. All of this is what will determine whether that traffic matches this policy or not. The second area is the action and this is where you decide what happens to a session that matches that policy. The actions are for things like should I allow or deny that traffic? If allowed, should I inspect the traffic? Should I apply URL filtering and if so what categories are allowed and which are blocked? Should I log the session in the traffic logs or not?
One of the first things when troubleshooting traffic issues through the firewall is looking at the traffic logs and seeing if it is correctly matching the expected security policy or not.
Let me give you some real world examples of when you could see issues with the policy match.
If you remember from Episode 3: URL Filtering — Allowing and Blocking the Right Traffic where we talked about URL filtering, having a URL category match in the security policy could be one reason why traffic is not hitting the expected policy. If you missed episode 3, make sure you go back and have a listen.
If you have policies based on users or user groups, which is very common these days, then there is a reliance on userID being known and being correct for the traffic to match. If you see issues with traffic not matching the correct policy that is based on users or groups, then as a start check the userID logs to see if the user to IP mappings are ok. Depending on how comfortable you are with troubleshooting userID then you can continue to try and find the issue. As you at least know the issue is with userID matching, then at the very least you can perhaps apply a workaround if there is currently a critical impact. For example you could duplicate the security policy and remove the user or group matching temporarily just to get users working while you investigate the issue with userID.
Another common "gotcha" is when using either external dynamic lists (EDLs for short) or FQDNs in your matching. These are great ways to be able to use dynamic sources or destinations for your policies but again, you need to understand there is a reliance on the data being available and accurate. If you are using internal EDLs and the server that hosts the files is offline, the lists cannot be updated by the firewall.
Using FQDNs can also sometimes be the cause of matching issues. Instead of having a destination IP in your policy (or it could be source in some scenarios), you add an FQDN, for example www.google.com and the firewall will use DNS to resolve the FQDN and then allow traffic to whatever IP address or addresses that DNS returns.
Let’s look at an example of when an issue can happen. You are using an FQDN in a policy to allow some external services that use content delivery networks. You have a firewall in Australia that is configured to use public DNS so it is querying the FQDN name through its local ISP. Your users have internal DNS configured but in your organization, external DNS queries are all done from your primary DNS servers which happen to be in the US. As your firewall in Australia would get an Australian regional DNS response and your DNS server in the US would be getting a different IP then there is a mismatch in the IP the client is trying to connect to and what the firewall is allowing. In this scenario the traffic will not match the policy and would most likely be denied.
So that’s the policy match. Let’s have a quick look at the actions. The actions, as I mentioned, are where you specify what to do once traffic matches a particular policy and the most important thing is the security profiles. Having a policy configured and matching is great and your users will work fine but if you don’t have any security profiles applied then you may be letting that traffic through with no inspection being done. The key thing here is that you have security profiles configured on the policies that require it.
So you may have 100s of security policies configured and you also may have a large team of people making changes so I understand it can be difficult and time consuming to make sure your policies are configured correctly. I’ve got some good news for you. We at Palo Alto Networks understand the importance that your configuration is secure which is why have a Best Practice Assessment, or BPA for short. This can take your current configuration and provide you with a detailed report on your current configuration versus best practices. This covers the whole firewall config so is much more than just the security policy but it is a good way to check your security policy is up to scratch. For more information you can just search for Palo Alto Networks Best Practice Assessment.
While we are talking about security, there is another great feature available directly on your firewall or Panorama called Policy Optimizer. This lets you not only migrate any old port based rules but also check if you have policies with apps which are not actually used or that allow perhaps more than they should. This gets back to the importance of your security policies being configured as securely as possible.
And the last thing I want to mention today is about logging. This little gotcha is also pretty well known now but worth a mention in case you're new to Palo Alto Networks. There are two default rules at the bottom of every policy. One allowing intrazone traffic (that is traffic going to and from the same zone) and one denying interzone traffic, so traffic between different zones. These policies, by default, do not have logging enabled so for the default deny policy, there is no visibility of traffic being denied by the firewall. A lot of people will create their own default deny policy and add logging so this would cover it, otherwise you can override those two default policies and enable logging on them.
So let’s recap the four main points:
And that’s it for another round of PANCast. I know security policies seem straightforward and it is the thing we most often make changes to but I hope from today's discussion you got a few tips on ensuring you don’t have any gaps. Might be time to go and have a quick review or get that BPA done.
Remember to head to live.paloaltonetworks.com and look under the PANCast section for the transcript to this episode and links to relevant knowledge base articles.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
