How to Configure DNS Sinkhole

by rvanderveken on ‎11-18-2013 01:28 AM - edited on ‎04-06-2017 01:58 PM by (102,156 Views)

Overview

Starting with PAN-OS 6.0, DNS sinkhole is an action that can be enabled in Anti-Spyware profiles. A DNS sinkhole can be used to identify infected hosts on a protected network using DNS traffic in environments where the firewall can see the DNS query to a malicious URL.

 

The DNS sinkhole enables the Palo Alto Networks device to forge a response to a DNS query for a known malicious domain/URL and causes the malicious domain name to resolve to a definable IP address (fake IP) that is given to the client. If the client attempts to access the fake IP address and there is a security rule in place that blocks traffic to this IP, the information is recorded in the logs.

This information is covered in detail in: How to Verify DNS Sinkhole Function is Working.

 

Important! When choosing a "fake IP", make sure that the IP address is a fictitious IP address that does not exist anywhere inside of the network. DNS and HTTP traffic must pass through the Palo Alto Networks firewall for the malicious URL to be detected and for the access to the fake IP to be stopped. If the fake IP is routed to a different location, and not through the firewall, this will not work properly.

 

Steps

  1. Make sure the latest Antivirus updates are installed on the Palo Alto Networks device.
    From the WebUI, go to Device > Dynamic Updates on the left. Click "Check Now" in the lower left, and make sure that the Anti-Virus updates are current. If they are now, please do that before proceeding. The Automatic Updates can be configured if they are not setup.
    doc-6220 du-av1.png
    Note: A paid Threat Prevention subscription for the DNS sinkhole is required to function properly.

  2. Configure the DNS Sinkhole Protection inside of an Anti-Spyware profile. Click on the Objects > Anti-Spyware under Security Profiles on the left.
    Use either an existing profile or create a new profile. In the example below the "alert-all" is being used:
    doc-6220 Anti-spyware.png

    Click the name of the profile - alert-all, click on the DNS Signatures tab.
    sinkhole.JPG

    Change the "Action on DNS queries" from to 'sinkhole'.
    Click in the Sinkhole IPv4 field and type in the fake IP. The example here shows using 1.1.1.1 for simplicity, but as long as this fake IP is not used inside of the network, then it should be Ok. Alternatively, you can also use either a Loopback IP (127.0.0.1) or Palo Alto Networks Sinkhole IP (71.19.152.112).
    Click on Sinkhole IPv6 and enter a fake IPv6 IP. Even if IPv6 is not used, something still needs to be entered. The example shows ::1 . Click OK. 

    Note: If nothing is entered for the Sinkhole IPv6 field, OK will remain grayed out.

  3. Apply the Anti-Spyware profile on the security policy that allows DNS traffic from the internal network (or internal DNS server) to the internet.
    Click on Policies > Security on the left side.
    Inside the rules, locate the rule that allows DNS traffic outbound, click on the name, go to the Actions tab, and make sure that the proper Anti-Spyware profile is selected. Click OK.
    doc-6220 rule1.png
    doc-6220 outbound-rule-profile.png

  4. The last thing needed is to have a security rule that will block all web-browsing and SSL access to the fake IP 1.1.1.1 and also :1 if using IPv6. This will ensure to deny traffic to the fake IP from any infected machines.
    doc-6220 rule3.png
  5. Commit the configuration

 

See Also

For instructions on testing and verifying the setup reference the following document:

How to Verify DNS Sinkhole Function is Working

 

For Video tutorials on DNS Sinkhole subject:

Video Tutorial: How to Configure DNS Sinkhole

Video Tutorial: How to Verify DNS Sinkhole

 

owner: rvanderveken

Comments
by KiCheon.Lee
on ‎02-05-2014 02:05 AM

Hello,

I have set up DNS sinkholing  configuration as above but there are no sinkhole action in threat detail logs.

DNS sinkholing must use only PAN-DB???

If not, What do I have to check?

Thanks.

by odin
on ‎03-27-2014 09:49 AM

I notice from the screenshot that you put the loopback on the untrust side.  Is that important to get this working?  Also, does it matter what IP the sinkhole IP is?

by Westcon2
on ‎06-14-2014 04:01 AM

It is not important to put the loopback in the untrust zone. You can configure an separate zone and assign an interface to it.

Regards

Aamir Khan

by jwolach
on ‎06-14-2014 04:37 AM

You also have to make sure you have a Security Policy that allows traffic to-and-from the Zone you assign to the Sinkhole interface.

Kind regards,

Jeff

by KKUNZLER
on ‎06-20-2014 06:34 PM

I have enabled DNS sinkholing but would like to be able to "sinkhole" certain dns calls as well as those matching spyware signatures, for example sinkhole sinkholeme.com

Is this possible?  If so, how?

by jwolach
on ‎06-21-2014 06:59 AM

Based on the way the Sinkhole action works, it will only sinkhole the DNS queries that are matched with the signatures. It would be a nice feature if the custom spyware or vulnerability signatures would have the Sinkhole action as an option. That way you could create a custom signature that would then sinkhole the request you create in the signature.  Maybe something for the future.

by scantwell
on ‎11-12-2014 08:24 AM

My question is... do we really even need a loopback address defined?

I mean.. why could we not just provide a sinkhole address of 1.1.1.1 (or whatever) and still have the security policy to block going to 1.1.1.1.

Not quite sure I completely understand the need for the loopback address.

What function does it serve.

I also thought that the sinkhole address was originally designed to be a syslog server or some DLP device (based on the ATC training classes), so that the syslog logs all the attempts.

This doc is good in theory and certainly does work, but not in the spirit that was originally attempted.  (or am I wrong...)

Please comment.

by Gun-Slinger
on ‎11-18-2014 11:50 AM

After talking with a PAN Engineer and the Engineer to design this feature, I have the following update to this thread and guidance for implementing the feature in a VWire environment:

Loopback is not needed , nor any L3 interface. For some reason many people keep saying that.

Here is how it works:

  • A DNS request flows through Vwire and we detect it as a malware domain
  • We block the request and send a fake answer with an IP that you chose to answer the requester.
  • If the requester is a DNS server then it transmits our fake answer to the original infected requester.
  • The infected client gets your fake answer and trys to reach its Command&Control server

Then in order to know which machine has been infected, all what you have to do is run a report and filter on the fake IP configured. Keep in mind one thing : that IP must be in the path of the firewall and the client so you can see logs from it. IE: if your PAN sits between infected client and data-center but doesn't see internet and you choose to DNS Sinkhole with an internet IP then your firewall will never see the infected client try to reach its command & control server.

Also don't forget to make a deny rule with destination of your DNS Sinkhole IP.

by panos
on ‎11-18-2014 11:56 AM

thanks Gun-Slinger , it's all clear now

by jgardner
on ‎05-11-2015 01:16 PM

This works great.  HOWEVER, is there a way to whitelist FQDNs?

We have an SMTP server we are trying to send mail to, but it is being sinkholed.  TIA!

by
on ‎05-15-2015 11:41 AM

For any URL's that need to be "Whitelisted", you can create a custom URL group, then place individual URL's in that group, then create a rule ABOVE where you would be performing the DNS Sinkhole protection, and place the new Custom URL Group into the Service/ URL Category tab and allow it, that should do it.

by _slv_
on ‎05-21-2015 03:23 AM

IMHO on picture 1 in point 3 rule 1 "block dns sinkhole ip" should have action BLOCK insted of ALLOW.

Please update pictures.

by
on ‎05-21-2015 10:07 AM

slv, I am sorry those images were not correct.  They are in the process of being updated as we speak.

by katavag
on ‎06-03-2015 04:32 AM

I configured this feature on version 6.0.4 months ago, but the issue with this is that there is no way to test it. The list of domains that are supposed to trigger the action is to be found in latest AV release notes, but none is triggering the policy.

by bbolovan
on ‎06-03-2015 09:03 AM

Also for testing you can use the domains in this list :

Malware Domain List

All the domains in the list are actively malicious.

by katavag
on ‎06-04-2015 06:53 AM

Thanks for the list. Found why I didn't see any trigger. There was one firewall standing before in the chain, which intercepted requests and dropped all packets. Somehow the outside firewall, where dns-sinkhole feature configured, still shows the session in the traffic log. That is what confused me. Why are the packets that seem to be droped on one firewall still visible in the next.

Tested this in my lab, when I perform nslookup for ektsqowk.biz my lab PC actually sends out 6 DNS queries:

A ektsqowk.biz.labdomain.lab.local

AAAA ektsqowk.biz.labdomain.lab.local

A ektsqowk.biz.lab.local

AAAA ektsqowk.biz.lab.local

A ektsqowk.biz

AAAA ektsqowk.biz

I guess it has to do with dns settings on my PC, adding dns suffix, IPv6 etc.

The firewall forwards the first four,  but drops/sinkholes the last two as expected.

by mivaldi
on ‎06-04-2015 03:07 PM

Suspicious DNS Signatures begin in Threat ID 4000001 and end in Threat ID 4999999.

This means that for testing you can consistently use the result you get from the CLI from this command:

========================================================

> show threat id 4000001

This DNS signature detects a DNS query to the domain fwlsnwxkzib.com.  Palo Alto Networks has observed this domain to be associated

with malware and malicious activity.  If multiple threat signatures from a single host are present, this may indicate that the host

is compromised.

medium

spyware

========================================================

In the above example, it results in "fwlsnwxkzib.com", so you can consistently use the output of this command for testing.

by herrmoss
on ‎01-29-2016 11:45 AM

My anti spyware profile with the sinkhole configured is used in other outbound security policies in addition to the DNS policy.

Is there a resason why I wouldn't want to do this, like extra overhead or something?

Would it be better to create a separate anti spyware profile  with the sinkhole configured that would be used only for the DNS policy?

 

by craig.brooker
on ‎07-13-2016 08:57 AM

Is there a way to access the list of domains that are going to be sinkholed by this procedure?

by
on ‎07-13-2016 11:08 AM

@craig.brooker, The domains that will be "sinkholed" are the ones that are classified as "suspicioius DNS" in the Apps and Threats DB  or "malware" by PAN-DB URL Classifications.

We do not maintain a "list" of those suspicious URL's , but you can go to either:

https://urlfiltering.paloaltonetworks.com/testasite.aspx 

or

https://threatvault.paloaltonetworks.com/

and type in any part of a domain to see the PAN-DB URL Classification if it is deemed Malware or not.

 

Also, in some of the release notes to the Apps and Threats updates, it lists Suspicious URL's that are added.

 

One more thing, Earlier in the comments, there is a link to 3rd party maintaineda Malware Domain list.

by RayHo2017
on ‎05-18-2017 08:08 PM

I configured the DNS sinkhole. Created separate Zone , and assigned the New Loopback interface to that Zone.

Also applied Policy to block that traffic to reach the Sinkhole Zone. And checked the Anti-Spyware is up to date.

And the " Security Profiles " , already cloned one as  " DNS Action > sinkhole " .

 

Into " Monitor " > " Threat " ,  I still can see the internal DNS server address to reach the public DNS log only.

Can not see the " real client devices " address,  Any configuration missed ?   is it related routing ?  Please help.

 

Thanks alot.

 

by ansharma
on ‎05-19-2017 05:19 PM

@RayHo2017 It depends who is making the DNS query. As per your logs, the client PC in your environment must have queried the DNS server, which in-turn went to public DNS server for response. Configure 8.8.8.8 as DNS server on your client PC and then test. Please refer to https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Verify-DNS-Sinkhole-Function-is-Work... for the use-case scenarios and implementations.

 

Regards,

Anurag

by RayHo2017
on ‎05-24-2017 08:29 PM

@ansharma   ,  Thanks.

Finally, it works now. I make a change to the security profile on the default outbound policy to sinkhole rather the separate Sinkhole policy.  So the traffic will be detected by the default outbround policy. Then will do the sinkhole action.

by telecored
on ‎06-15-2017 03:34 AM

Is step 4 necesary?. Can I let the traffic just flow throug FW to an unreachable IP?

 

Regards,

Guille.

by ansharma
on ‎06-15-2017 04:55 AM

@telecored

 

No, it's not necessary to do Step 4. It's basically a way to find out who is making those suspicious DNS queries, so we can find out the possible infected hosts. That's all.

 

Regards,

Anurag

by CBP-Network-Admin
on ‎08-25-2017 12:38 PM

I suppose this is just another method of implementing dynamic block lists?  Another protection in the "kill chain"?  Palo Alto could offer this as an external dynamic list to be used in a security policy (URL category block)?

by
on ‎08-25-2017 02:35 PM

Hi @CBP-Network-Admin

No, this is not simply a block list. Sinkhole dns actively intercepts and poisons DNS replies to malicious hostnames and replaces the A record with an IP of your choosing

After this, the I fected host will make outbound C&C connections to your sinkhole IP which will prevent connecting to the actual c&c and will make infected hosts highly visible. This is especially helpful if you have an internal DNS server which, logging wise, would make all infected lookups originate from your DNS rather than the compromised endpoint

 

Hope this helps

by FrankLi
an hour ago - last edited an hour ago

@reaper Is there possible to dns sinkhole a whole other URL category? for example, the whole adult web category? 

Ask Questions Get Answers Join the Live Community