Tips & Tricks: Using DNS Sinkhole to find Malicious Clients

by on ‎04-22-2015 08:23 AM - last edited on ‎05-09-2017 05:45 PM by (15,550 Views)


Hello again, Joe Delio from the Community team here, Today I will be introducing another new Community Feature:

Tips & Tricks


Inside Tips & Tricks, we will be talking about a specific Palo Alto Networks Firewall or Panorama feature, explaining what it is, how to configure it and how to use that feature. It is intended to teach you new features easily.

Today I will be talking about DNS Sinkhole.


What is DNS Sinkhole? Why do I want to enable this feature?

Starting with Pan-OS 6.0, a new feature called DNS Sinkhole was added to help battle malicious software (malware and spyware) in networks. This feature works by monitoring DNS requests for malicious DNS requests passing through the Firewall. If one is found, then the Palo Alto Networks device can forge a response causing the malicious domain name to resolve to a customer defined IP address (bogus IP). This will prevent the Malicious DNS request from working, stopping the Malware or Spyware from communicating to the Internet, as well as recording this information in the logs.


How do I configure DNS Sinkhole?

Please refer to the following document for instructions on configuring DNS Sinkhole:


Tips & Tricks using DNS Sinkhole to find malicious clients

The following is the sequence of events that will occur when the sinkhole feature is enabled with bogus IP

  1. Malicious software on an infected host sends a DNS query to resolve a malicious DNS request on the Internet.
  2. If the infected internal hosts's DNS query is sent to an internal DNS server(the firewall will never see the host make this request, and is essentially hidden), that internal DNS server then queries a public DNS server on the other side of the firewall.
  3. If the DNS query matches a DNS entry in the DNS signatures database, the sinkhole action will be performed on the query, and the forged IP ( is given in response, and a log in the threat logs for "Suspicious DNS request" will be recorded.
  4. The infected client then attempts to start a session with the host, but uses the forged IP ( address instead.  If a policy blocks access to that forged (bogus) IP, then that will show up in the traffic logs.
  5. All the administrator needs to do is look for "malicious DNS" query in the threat log, and can then search the traffic logs for the forged sinkhole IP address and can easily locate the client IP address that is trying to start a malicious session with the sinkhole IP address. Since all traffic is stopped, it will ensure a secure network.


NOTE: If the request is made from an internal device making the DNS request directly, through the firewall, you will see the same IP address make the Initial DNS request as well as seeing the HTTP(S) request to the bogus IP ( Most of the time this is NOT the case.


Previous to the sinkhole action it was impossible to tell who is the end user (the infected machine) and in the logs you could only see the internal DNS server as a part of the communication that is triggering this signature, but now, the Palo Alto Networks device can forge the response for the infected domains to a locally significant address we is able to capture the traffic afterwards and get the real infected machine.


Thanks for reading.

Stay secure,

Joe Delio


Tips & Tricks 4-21-2015

on ‎04-25-2015 02:02 PM

For those of you who use a vpn client (other than Global Protect) quite often you are delivering DNS services to the vpn client device. If you allow the sinkhole traffic through the vpn connection (set as a default or global rule) then you will be able to identify vpn endpoints with spyware / malware present.  Using the IP addresses identified as going to the sinkhole you can go to your VPN console and look at the logs to find the user / endpoint involved.

by jlinkowsky
on ‎05-05-2015 02:42 PM

I'm a bit confused.  In the line above it states: "The infected client then attempts to start a session with the host, but uses the forged IP ( address instead.  "  However, the screen shot shows the traffic being ALLOWED.  Is this a typo or an incorrect screen shot?


on ‎05-05-2015 03:55 PM


Since the sinkhole IP address has nothing physically associated with it the action is irrelevant. The important thing is that the malware / spyware infected host is attempting to go to the destination and the traffic attempt is being logged.  An action of "allowed" does not introduce any risk as there is normally nothing assigned to the sinkhole IP address.  In our case it is a 10.x.x.x IP address that gets routed out to the internet in our case.  I hope this explaination adds sone clarity.


by mivaldi
on ‎05-05-2015 04:00 PM

It actually says:

" If a policy blocks access to that forged (bogus) IP, then that will show up in the traffic logs. "

So it looks like in the screenshot example, a policy does *not* block the access to the sinkhole IP.

In reality, it wouldn't really matter if the traffic was allowed or blocked, since it's going to the sinkhole IP, and there's nothing listening there. The main thing is having a security policy that will "log" the event at session end, so that you can track which client computers are infected. Whether its a block or an allow, -not very important-. (Though yes, we can argue a block makes sessions age out faster, so it would result in a slightly more efficient memory utilization on the Firewall).

by jlinkowsky
on ‎05-06-2015 07:21 AM

Thank you both HITSSEC & mivaldi for your comments.  They totally make sense.  It was just confusing as the screenshot is showing "allow" and the statement was saying "If a policy blocks access to that forged (bogus) IP, then that will show up in the traffic logs."

I agree, the action really doesn't matter, as the IP is bogus.  In our case we DO want to see who is attempting to go out, and address them.

Thanks again!

John L.

on ‎05-06-2015 08:54 AM


I am sorry for the confusion, the screenshot should have been showing the access to those sites being blocked.  And I will fix that.

But mivaldi is correct, because this is a bogus/fake IP, the site will NOT work. Access just needs to be recorded, allow or block.  But it would be easier to just block this traffic.

on ‎05-08-2015 10:54 AM

The image is fixed now, and it should make more sense.

Ask Questions Get Answers Join the Live Community