I blame DNS! Oh wait, that’s not what I am writing about. Domain Name Service (DNS) is a foundational piece to communication. Unless you know every IP address for every website you want to visit, you are going to need DNS. Users and services all over the world rely on DNS to seamlessly communicate. What a great opportunity for attackers to lead users to malicious destinations. DNS Security provides us a way to stop malicious requests from users’ devices from ever reaching those destinations. There multiple solutions out there to secure the DNS-layer. The focus of this entry is to explore Palo Alto’s solution to DNS Security.
Before proceeding, it is worth mentioning another solution to DNS-layer security: Cisco Umbrella. You can read a little about it in my other entry here. I am used to the deployment of Cisco Umbrella, however I have yet to deploy Palo Alto’s DNS Security. Let’s take this trip together! Check out Palo Alto’s excellent documentation on Enabling DNS Security. On my lab firewall, I happen to have the DNS Security license that is required. Yes, nothing is free. If someone says “free”, it’s probably just not itemized. If you are interested in DNS Security with Palo Alto, reach out to your sales team for licensing information.
Let’s start off by creating or cloning an Anti-Spyware profile under Objects > Security Profiles > Anti-Spyware. I am taking my existing DAVNET-AS profile, cloning it and calling it DAVNET-DNS-AS. The Anti-Spyware security profile allows for the detection of compromised clients who are attempting to send malicious traffic outbound.
We can probably spend another blog entry diving into the individual settings in the Anti-Spyware profile, but we are going to dive into my new profile’s DNS Security > Policy & Settings tab. I do not have DNS Security added, so I will click the Add button and add it in. It will show up as default-paloalto-cloud, but once added in the name will change to Palo Alto Networks DNS Security.
In the Action on DNS Queries column we will pick what we want to do with the malicious lookups. We will select sinkhole. This redirects the malicious queries caught by our security policy to a controlled address at Palo Alto Networks. A quick DNS lookup of the recommended address sinkhole.paloaltonetworks.com reveals the IP I have in the DNS Sinkhole Settings is correct, but I will still change it to sinkhole.paloaltonetworks.com in case the IP changes. I will then click OK.
The next step is to attach this newly created profile to a Security Policy. At home, I will attach this to my outbound internet access Security Policy and click OK. Like any other Palo Alto change, I’ll need to Commit.
OK, so that’s it! Now let’s go get infected. Well, I wouldn’t recommend that, but how do we know this is even working? Googling around reveals different test websites for that purpose; some are free and some sites are not. Palo Alto has a few test URLs to try in it’s DNS Security instructions. For some reason most of the URLs did not load. One of the URLs was blocked by Firefox. So I tried it on Microsoft Edge to much success. I navigated over the Monitor > Logs > Threats section on my firewall. We have some entries! One of them was my test using Palo Alto’s test URL. The other was most likely my negligent clicking all over the internet trying to break things.
As you can see in the above screenshot, the Action was sinkhole. I’d say the setup is a success, but I would feel a bit more comfortable with some additional tests. Obviously in a production environment there will be many more users browsing the internet and getting themselves into situations that will bring forth many more sinkhole moments. If you have any ideas for useful tools that can test DNS Security, feel free to leave them in the comments.