How Does DNS Sinkholing Work?

[mario11584]

Can anybody offer a detailed explanation of how DNS Sinkholing works and possibly a real world example of it?

I can only find this documenation: How to Configure DNS Sinkholing on PAN-OS 6.0 and it doesn't provide a lot of details on how it works.

It seems like the DNS request is allowed but when traffic starts to flow the firewall notices the destination is a malicious URL and re-routes to the configured loopback.

Please correct and enlighten me.

[mario11584]

I think I found the answer I was looking for in the 6.0 Web Interface Ref Guide. (Why not in the Admin Guide?) It says the following:

"The following is the sequence of events that will occur when the sinkhole

feature is enabled:

1. Malicious software on an infected client computer sends a DNS

query to resolve a malicious host on the Internet.

2. The client's DNS query is sent to an internal DNS server, which then

queries a public DNS server on the other side of the firewall.

3. The DNS query matches a DNS entry in the DNS signatures

database, so the sinkhole action will be performed on the query.

4. The infected client then attempts to start a session with the host, but

uses the forged IP address instead. The forged IP address is the

address defined in the Anti-Spyware profile DNS Signatures tab

when the sinkhole action is selected.

5. The administrator is alerted of a malicious DNS query in the threat

log, and can then search the traffic logs for the sinkhole IP address

and can easily locate the client IP address that is trying to start a

session with the sinkhole IP address."

So if I can configure whatever IP I want, in theory I could build a simple website that informs the user what happened and inform them to contact desktop support?

[dmaynard7]

So if I can configure whatever IP I want, in theory I could build a simple website that informs the user what happened and inform them to contact desktop support?

Hello mario,

Building a simple website would not work to inform end users in the event of malicious software. The malicious software would generally make background calls either for command and control or for payload delivery and the end user would not see this (unless they were browsing to a malicious site) traffic.

A DNS sinkhole works by 'spoofing' the DNS servers response for malicious or unwanted hosts/domains. You configure to return a false IP for these request. When a users machine request to resolve a malicious address the sinkhole returns a non-routable address. This would deny the client a connection. Logs would then indicate source and destination of sinkhole address.

[mario11584]

Awesome! Thanks!

[HITSSEC]

Hello Mario,

Here are a couple more points: You can just add the IP address you use for your sinkhole to a custom block URL category and for web requests you will deliver the block page you may already have  (providing your network will route that IP address to the firewall) and thus you don't need to have a webserver.  The caveat is that some of the sinkhole traffic may be client based and thus the user will not see the web page.  You would still have a specific rule blocking non browser application traffic.  You would use this to assist you in easily identifying a problematic host.

Another point to remember is that the sinkhole response applies to Palo Alto defined malicious dns signatures only.  I have not found a way to add your own malicious dns entries.

Phil

[BobW]

Thank you for that explanation.  I kept seeing the DNS records being marked as bad, but never crossed my mind to search the logs for the other traffic to the sinkhole address!

"can then search the traffic logs for the sinkhole IP address

and can easily locate the client IP address that is trying to start a

session with the sinkhole IP address."

Bob

[resuna]

I am testing using an internal IP that runs netsink. Netsink basically emulates DNS,HTTP, HTTPS,SMTP,SMTPS,FTP and has functionality to redirect any tcp connection to a listener which then determines which of the above protocols the request is for and emulates it. 

The reason we do this is to allow for more detailed analysis of the client and the malware.  Having the headers from an HTTP/S request (yes netsink will strip the SSL as it servers its own cert) or the SMTP headers improves your situational awareness around these incidents.

So far so good.