Back to chapter II: Initial setup

The firewall ruleset – a closer look at the most interesting rules

Now, let’s take a closer look at the firewall rules making up the ruleset, I ended up with 20 rules in my ruleset, plus the two default rules that the firewall automatically adds to the end of the ruleset.

The first two rules are geo-block rules that simply block IP-communication to a couple of countries that I found were constantly trying to break in: Russia, China, Belarus and North Korea.

I eventually got tired of investigating odd inbound connection attempts from these guys, so now I simply drop all incoming and outgoing connections to these countries. But this was done, well knowing, that any serious hacking attempts from any of them would be much more sophisticated than these direct connection attempts. Most likely all advanced attacks would be channelized via jump servers in other countries, very effectively circumventing these geo-blocks.

Also notice the 2. column “tags” that permit you to “tag” your rules for easier classification. I have created a couple of color-coded tags that permit me to quickly spot inbound and outbound rules, as well as “block-rules”. This is a great help when I need to find the rule that blocks a specific type of traffic.

The next two rules block traffic based on dynamically updated lists of network destinations. These lists were mentioned above, and this is how the rules using these lists look like:

The list of lists to block traffic from is long, so long that not all are shown in the main ruleset GUI. Note that some of the lists are named “OpenDBL-xxx”, these lists of risky network locations can be downloaded free-of-charge from https://opendbl.net/. On this site, it is also explained how to install these lists on various firewall platforms, including Palo Alto. A great help!

If we take a closer look at the first rule, we can see that the list also contain lists from Palo Alto (these entries were not visible in the main ruleset GUI because the list was too long):

The setup required to download these lists is very intuitive and can be found in the Objects -> External Dynamic Lists section of the GUI.

This is what that setup looks like:

Notice that the OpenDBL lists are updated every hour. If you click on one of the lists, you can inspect it with respect to which entries it contains at a certain point in time:

A quick side note here: OpenDBL recommends that their lists are implemented in inbound rules only, but as you can see, I have implemented both an inbound and an outbound block rule for these lists. I see hits for both rules, possibly because I have chosen to merge all the lists, both the OpenDBL and the Palo Alto lists, into the same two rules.

The next two firewall rules control DNS-traffic. I have chosen to limit DNS-access from my internal networks the freely available Cisco Umbrella / OpenDNS servers, as using these servers adds an extra layer of protection to all internet related communications. If you are unfamiliar with the Cisco Umbrella / OpenDNS servers, I strongly encourage you to take a closer look. Compared to standard DNS servers, these DNS servers block DNS-responses to known dangerous DNS-domains, which implicitly prevents you from connecting to such sites in the first place.

The first rule permits DNS, DNS-over-https and DNS-over-tls to the Umbrella DNS servers, while the next rule denies the same types of DNS-requests to all other DNS-servers. You may think that you have the DNS-servers used in your network under control, because you have set up a local DHCP-scope that controls the DNS-servers that IP-clients on your network use? Sorry, no, lots of applications and games use their own hardcoded DNS-servers and completely ignore the DNS-servers pointed to by the local DHCP scope.

The rules shown above here deal with that, and the hit counts for rule 6 show the need for this block.

Notice the destination addresses in the rule, they are named “HST xxx”, which are object names defined in the Object -> Addresses part of the GUI. This is what the setup of these objects looks like:

The next rule blocks the quic-protocol, as per recommended best practice. There are several articles about this protocol on the Internet, and Palo Alto has an article that explains their recommendation to block it here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC

Another sidenote, I see that Palo Alto recommends blocking outbound UDP connections to port 80 and 443 also, in addition to the quic protocol. I used to have a separate rule doing that, following rule 7, but that rule never got any hits and was consequently not doing anything. So I removed it. I have not investigated this further, but I suspect that Palo Alto may have improved their “quic” application filter to include this traffic, consequently catching this traffic as part of rule 7.

The next two rules are related to my internal Plex-server. Now, for those that don’t know what a Plex-server is, it’s a movie streaming server that can stream both locally stored movies (ripped DVDs for example) as well as movies from various streaming services on the Internet. I use it for streaming all my DVDs that I have ripped, and I now enjoy not having to get out of the sofa every time I want to put on a new DVD-movie. I consider the many, many, hours spend ripping these DVDs, setting up the Plex-server, implementing FW-rules, including NAT rules from hell, a good investment of my time. Yes, I am sick, I know (LOL)!

Well, this is how the two Plex-related FW-rules look:

The first rule permits inbound TCP-connections to port 32400 from Internet addresses in Norway to my internal Plex-server. This is what permits me to share access to my movie-collection with friends, as long as they also have a PLEX-server and as long as they live in Norway. I have deliberately limited this inbound rule to Norwegian IP addresses, as I saw the number of incoming connection attempts from other parts of the world to be surprisingly high. Notice a small detail in rule 8: This rule actually permits incoming TCP-connections to the outside interface of the firewall, not to the internal IP-address of my PLEX-server. When we look closer at the NAT rules below, I will show you how this traffic gets forwarded to the PLEX-server.

The second rule permits access to the local Plex-server from the PC-Private, PC-Work and IOT networks. Here, access from the IOT-network is the rule that is used the most, as this is the rule that permits my TVs, AppleTV-boxes etc. to stream movies from the Plex-server locally. There is yet another fancy NAT-rule that works in conjunction with this firewall rule, as I said, I will walk you through them later.

The next 5 rules are not very exiting so I will skip the detailed explanations for them and proceed directly to rule 15 and 16 which limit Internet access for my QNAP NAS.

You may recall what I said earlier, that I have made an effort to lock down this beast to only the services that I use? Rule 15 and 16 are designed to limit access from the NAS to the Internet to only a few approved URLs:

Rule 15 allows outgoing TCP connections on ports 80 and 443 (http and https communication), but only to a specific list of QNAP URLs, that are referenced in the Whitelist. The setup of this whitelist is controlled in the GUI via Objects -> URL Category and looks like this:

The three listed URLs are what is needed for the NAS to be able to download firmware and to update a DDNS-entry that I have registered for the Internet facing IP address of the firewall.

Rule 16 blocks all other outgoing connection attempts towards the Internet from the NAS, no matter what type of communication it is. I see that this rule gets a lot of hits, so as suspected the NAS is still trying to reach numerous other services and destinations.

The next two rules are outgoing permit rules that control the few exceptions I have been forced to implement, in order to make a couple of network applications we use work.

Rule 17 permits a couple of URLs that by Palo Alto are categorized as gaming or high-risk, and which therefore gets blocked by the last two rules in the ruleset (see below). The first exception permits access to “Norsk Tipping” which is a Norwegian state controlled gaming service. In my own defense, I am not a gambler (except for when I am, which is when the winner pot raises to over 1 billion NOK). OK, I admit it, I am a gambler!

The nest exception is needed in order to be able to update a game I use (a plugin for Microsoft Flight Simulator called GSX, in case anyone is interested).

Rule 18 permits 4 network applications that we use that are also categorized as high-risk, WEB-access to Google-drive, Jabber (a Cisco collaboration application), Microsoft Update and the Ubisoft Update Service that some of the games used by the children rely on.

So, to wrap up, whenever a network application does not work because the firewall blocks it, I adjust the ruleset by adding an exception for that specific application into one of these two firewall rules. In this way, it’s easy to maintain an overview of the exceptions I have made along the way.

Which – finally – brings us to the last two custom rules that I have in my ruleset:

Rule 19 is a block rule that blocks all network applications that Palo Alto has categorized as High-Risk-Level-5. In addition, I have added two applications that are banned in our house, TikTok and Telegram. The “High-Risk-5” category is a category that I have defined myself based in Palo Alto’s dynamically updated list of Network Applications.

This category matches all Network Applications that Palo Alto categorizes as “High-Risk”. These custom categories are configured via the Objects -> Application Filters in the GUI and look like this:

At the time of writing this article, the list of categorized applications is 5164 in number (wow!), and this list is automatically maintained via the periodic downloads that the firewall performs, consequently automatically adding new applications into the appropriate categories and from there on into my ruleset. Of these 5164 Network Applications, 143 are currently categorized as “High-Risk”.

This functionality is one of the strongest and most impressive features of Palo Alto firewalls, and it is again a real testament to the well designed and intuitive GUI of these firewall that a novice user was able to set this up and get it to work with so little effort.

Obviously, the settings in the previous rule (rule 19) greatly affects the general level of access to the Internet. If I, as an experiment, was to add Network Applications that by Palo Alto are categorized as risk level 4 also to this rule, 415 additional applications would have been denied access to the Internet. While this increases the general Network Security level significantly, it also greatly increases the need for fine-tuning the list of exceptions in rule 17 and 18, as explained above.

This is a delicate balance where one must choose carefully. I have found that the setup presented above works well for me, combined with the initially explained segmentation of our network.

The last rule, rule 20, permits all other access to the Internet, if the traffic has not been blocked further up in the ruleset.

Security Profiles:

Now, there is a small, but important, wrinkle to rule 20, if you look carefully:

The Palo Alto firewall permits you to enable “Profiles” for each rule in the ruleset. These profiles add a further level of control to the traffic passing through and are designed to catch and stop traffic that imposes security risks of various types. Take this firewall as an example; we have made an effort to prevent access to high-risk APPs (rule 19), and then we permit the rest of the APPs, those categorized with security level 4 down to 1. But let’s assume that you attempt to access a WEB-site that is known for spreading viruses or malware? The APP-filtering settings will not prevent that.

Enabling these profiles is what controls this aspect of the filtering, as they are applied to traffic that your firewall rules initially permit.

Let’s take a look at how you configure them: If you click in the profiles’ column for one of the firewall rules, this menu pops up: 

As you can see, several types of profiles can be enabled for each firewall rule, the URL profile is just one of them. You can finetune how strict your default permit-rule should be by creating your own custom profiles, which is what I have done for the URL-filtering function.

Let’s take a closer look at that one:

Defining a custom profile for URL-filtering is done via Objects -> Security Profiles -> URL-filtering in the GUI and looks like this:

Here you see some of the pre-defined URL-categories that Palo Alto maintains, and how I have set up the firewall to treat connections attempts to sites within each category. BTW, remember that I had an exception for access to “Norsk Tipping” in my URL whitelist? The reason this exception is necessary is that I have a general block for access to gambling sites in the URL profile you see here, which causes access to that WEB-site to otherwise be blocked.

Chapter IV: What types of traffic is the firewall able to inspect