Back to chapter III: The firewall ruleset
What types of traffic is the firewall able to inspect – the elephant in the room:
Wouldn’t it be nice if you could just purchase a firewall, install it in you network and route all traffic through it, and then inspect all traffic that your heart desired?
Unfortunately, being able to do that is far from the reality of what is possible, and this is due to the fact that more and more application traffic today is encrypted. As an example, when a user on your network starts their WEB-browser and opens a connection to a WEB-site on the internet, most likely that connection will be transmitted over the HTTPS-protocol, meaning that all the WEB-traffic will be encrypted, and therefore impossible for the firewall to analyze.
The firewall dashboard gives you a picture of which applications seen on the network that impose the greatest risk, and as you can see; SSL-traffic clearly imposes by far the greatest risk. This is simply because the firewall cannot see what’s transported over these encrypted SSL-sessions.
The firewall does have functionality that permits it to decrypt SSL-traffic so it can inspect it, however explaining how you enable this functionality is beyond the scope of this article. It should also be noted that far from all types of encrypted traffic can be successfully decrypted and inspected. This is simply because the applications using encryption actively attempt to prevent such decryption by using newer encryption technology that is not vulnerable to “man-in-the-middle” decryption or by using techniques such as “certificate pining”.
NAT-rules:
Before wrapping up this article, I promised to take a closer look at the NAT-rules that I have implemented to make general Internet Access work, and to make my internal PLEX-server work.
Referring to the start of this article, I explained which IPv4 addresses I have chosen to use in my home network. And since they are all RFC1918-addresses (“private IPv4 addresses”), NAT is needed to be able to access services on the Internet.
I have 3 NAT-rules, and they look like this:
Let’s start with the simplest rule first, rule 3:
This general NAT-rule simply causes the IPv4 source address for all outgoing Internet Traffic to be NAT-translated to the “official” IPv4 address assigned to the firewalls outside interface. If that IPv4 address changes, for example if the firewall is reloaded, the NAT-rule automatically uses the new IPv4 address, as it simply applies the NAT-rule to whatever IPv4-address the firewall is assigned at any point in time.
Rules 1 and 2 are related to my PLEX-server and are a bit more complex: Rule 1 is definitely the most interesting one as that rule is what makes it possible to access the PLEX-server from the three internal networks “PC-Private”, “PC-Work” and “IOT”.
In case you wonder why such a complicated setup is needed, let’s take a closer look:
If the PLEX-server, and the clients using it, had all been connected to the same internal IP network, and provided that P2P (i.e. direct) IP communication was allowed on that network, there would not have been any need for this NAT rule, the PLEX-clients could simply have connected directly to the PLEX-server.
But in my setup, the clients are connected to three different internal networks, and the server to a fourth network (the “Server” network), so additional measures are needed for the clients to be able resolve the IP-address of the PLEX-server. They accomplish this via the Internet hosted PLEX-services, which registers all PLEX-servers in a central register. As soon as I start my PLEX-server, it gets registered in this central register via the IP address that PLEX sees, which is the outside IP-address of the firewall. I.e. the central PLEX register thinks that the IP-address of my PLEX server has that IP address, while it in reality it is assigned a private RFC-1918 address on my internal “Server” network.
Whenever an internal PLEX-client wants to connect to my internal PLEX-server, the client communicates with the Internet hosted PLEX-Services and learns that the IP-address of my PLEX-server, which the PLEX-services (incorrectly) believes is the outside IP-address of the firewall. The PLEX-client subsequently initiates a TCP-connection on destination port 32400 towards this IP-address, and this communication is what is intercepted by NAT rule #1, which redirects this traffic towards the real internal IP-address of the PLEX-server on the “Server” network.
The definitions for rule #1 are shown here:
Also note the “Enable DNS Rewrite” option that is enabled: This option enables the firewall to intercept and re-write cleartext DNS-responses and works like this: If the packet is a DNS response that matches the translated destination address in the NAT-rule, the firewall translates the DNS response using the reverse translation that the rule uses. In this case, if a DNS-request from a client results in a DNS-reply pointing to the outside IP-address of the firewall, the firewall changes the DNS-response (before it is delivered to the client) to the real IP-address of the PLEX-server on the internal “server” network. This is indeed a very clever and powerful feature.
Rule #2 is an inbound NAT translation rule that forwards incoming TCP-connections to port 32400 from the Internet to the IP-address of the PLEX-server on the internal “Server” network. Do you remember the previous discussion related to this (rule #8), that this type of incoming communication was permitted, but only from IP-addresses in Norway? This NAT rule is what stitches the final bits together so it works.
Wrap-up and final thoughts and impressions:
After having tested an advanced technical product, such as this Palo Alto firewall, there are lots of elements that go into the final impression that one is left with.
The overall behavior of the firewall, how easy or difficult it is to find one’s way around in the GUI and setup functionality, how responsive it is during daily operations, how stable it is as a technical device, and of course (most importantly) how well it serves its main purpose, which is to protect the users of the network.
I must say that testing this firewall have been a real joy from the very start! The product works well, it has a well-designed and intuitive GUI, it is fast, stable and reliable in daily operations, and it’s easy and quick to implement rules and new functionality. At no point in time has the firewall “got stuck” or gone into a “hang”, requiring me to restart it to be able to move on. It has simply been rock stable throughout all my testing.
Also, everything that I have needed to do, I have been able to accomplish via the GUI. I have never needed to log in via the CLI in order to enable or disable special features that “are not yet controllable via the GUI”. It’s all there in the GUI, and it’s all there, where you expect to find it. Other firewall vendors have something to learn here(!)
While I have been using this firewall to protect our home-network, we have had no security incidents due to inadvertently accessing WEB-sites that spread viruses or malware for example. And, whenever one of us inadvertently has tried to access such a site, the connection attempt has effectively been stopped before it even happened. So, all in all, this has been a really successful test.
I realize that I have only scratched the surface of all the functionality that is available in this firewall product, but I hope you have found this article interesting and instructive. I also hope that you find the explanations of the thought-process behind the firewall rule design I ended up with to be useful. As stated earlier in the article, the approach I chose for this implementation is heavily biased towards its intended use (protecting a home network), and it is just one of many ways in which you can implement a firewall. The main point is to choose an approach, and then implement the chosen method consistently throughout your ruleset.