How to Verify DNS Sinkhole
Resolution
If you'd like to verify that the DNS Sinkhole function is working properly through a Palo Alto Networks firewall, you'll want to watch this video.
Video Tutorial Transcript: How to Verify DNS Sinkhole
This is a Palo Alto Networks Video Tutorial, How to Verify DNS Sinkhole.
My name is Joe Delio and I am a Solutions Engineer from the Palo Alto Networks Community team.
This video helps verify if the DNS Sinkhole function is working properly through a Palo Alto Networks firewall.
For simplicity, I'll be talking about verifying a client using an external DNS Server.
Note: Also, we're assuming that you already have configured the DNS Sinkhole feature, and want to make sure it's working properly.
If you would like to read about verifying both Internal and External DNS server with DNS Sinkhole, please see:
How to Verify DNS Sinkhole Function is Working
I have talked about how to configure DNS Sinkhole in a previous video:
Video Tutorial: How to Configure DNS Sinkhole
For a document about configuring DNS Sinkhole, please see:
How does the DNS Sinkhole feature work?
I will be talking with you today about a client using an external DNS Server making a malicious DNS request.
Here is an overview about how the DNS Sinkhole protection works:
1. The suspicious DNS request is seen by the firewall.
2. The firewall blocks this request and sends a fake IP to answer the DNS request.
3. The infected client gets your fake DNS answer and trys to reach its Command and Control server by making the http/https call to the Sinkhole IP.
4. If you are blocking access to this fake IP, then that is how we can determine which client is infected.
Note: The Palo Alto Networks firewall must be in the path of the DNS request to a suspicious URL and also in the same path the infected machine tries to access the DNS Sinkhole IP.
Now with a little more detail—
When the client system is accessing a known malicious URL using an external DNS server, the DNS query goes from the client, through the Palo Alto Networks firewall, then to the external DNS server. The firewall hijacks the DNS query and responds as the DNS server with the DNS sinkhole IP address to the client. In this example, 1.1.1.1 is being used as the fake DNS sinkhole IP. Inside the threat logs, you should be able to see the client IP address as a source when the suspicious DNS request is made.
The next step would be looking for the client attempting to access the DNS sinkhole IP 1.1.1.1. If you have configured your firewall properly, then you should be blocking all access, or at a minimum Service port 80 (http) or port 443 (HTTPS). Inside the traffic logs, you'll see dropped traffic to 1.1.1.1.
Now, let's take a look at this from a client perspective.
We know that the following domain is considered a 'Suspicious Domain.'
gdcqia.com
When we have the DNS Sinkhole configured properly, and someone resolves that domain, the fake DNS Sinkhole IP should resolve instead of the real domain's IP address.
See how 1.1.1.1 is showing up.
By manually performing this lookup with a suspicious URL, you can now see firsthand that the DNS Sinkhole is working to provide the fake IP.
The second part of this is to pretend that you are an infected host, open a web browser and try to visit the suspicious URL with the given IP - 1.1.1.1.
Access to the site will not work, as that is a fake IP, which is OK. In a minute, you'll see how this is important for the traffic logs .
Now, If you look inside the threat logs—
Back inside the WebGUI, select Monitor > Threat Logs. I look for the client IP address I am using, which is 172.16.77.209. The threat logs show the Suspicious DNS Request and you see the client IP address 172.16.77.209 as the attacker.
Click the magnifying glass to get more details—
Notice how the Action is Sinkhole, Application is DNS and the Source is 172.16.77.209, because my client itself is trying to go out to 8.8.8.8 and resolve this URL.
We know this is the client making this DNS request. But, If you had an internal DNS server, that IP would show up instead of the client IP (as long as the DNS traffic went through this firewall). In that case, we can skip to the next step.
Also, inside the details section, you see 'spyware' as the threat type, and 'Suspicious DNS Query' as the Threat Name.
Then we can take a look at the traffic logs for destination IP of 1.1.1.1, and we can see the traffic is being dropped, if you configured your blocking rules correctly. This is how we can determine who the infected clients are. Since 1.1.1.1 is a fake IP, only the machines making these suspicious DNS requests are going to try to access these sites, and then in turn, be denied. You can search your traffic logs, or perform simple reporting on this rule to get a list of the machines you need to restrict or visit.
That concludes this video tutorial. We hoped you enjoyed this video, and thanks for watching.