How to Deal with Conficker using DNS Sinkhole

by ialeksov on ‎01-28-2014 03:33 PM (22,458 Views)

PAN-OS 6.0, 6.1

Overview

Conficker was first detected in November 2008, and is one of the most widespread worms that infects machines running Windows OS. Palo Alto Networks has created signatures that can detect and block the Conficker worm. Among them are Anti-Virus/Anti-Spyware signatures that detect the DNS domains used by Conficker variants. These domains are updated as soon as Conficker variants are discovered. If a WildFire license is used, the newly discovered domains are pushed to the Palo Alto Networks firewall every hour through the WildFire signatures. If a license is not used, the signatures are pushed every 24 hours and downloaded by dynamic updates to for all Palo Alto Networks devices. Updates will also be implemented in the new AV signatures in the next update interval. This protection detects when a user in the network is requesting “bad” domains. When an analysis of the logs is completed, it can be reviewed and determined that the request for the infected domain came from the local DNS server. This is possible because of the hierarchical nature of DNS.

Details

All Palo Alto Networks platforms have an implementation of sinkhole action for queries towards malicious domains. Using this capability, the Palo Alto Networks firewall can detect the infected host in the network and send notification to the security administrator. This enables the infected workstation to be removed from the network.

How it works:

  1. The infected machine asks for a DNS resolution of an infected domain from the local DNS server.
  2. The local DNS forwards the query to the public DNS server.
  3. The Palo Alto Networks device sees the query and detects the malicious domain using the newest signatures.
  4. It overrides the DNS response with an IP address that the administrator dedicates, (sinkhole address) and sends the spoofed response to the client.
  5. The client attempts a connection to the sinkhole IP address.
  6. The Palo Alto Networks blocks the traffic and logs the attempt.
  7. The firewall administrator receives a notification about the event.
  8. The malicious client is removed from the network and cleaned.

Steps

To  configure the DNS sinkhole action, see: How to Configure DNS Sinkholing on PAN-OS 6.0

Using a Palo Alto Networks device that is dedicated to an L3 interface as a sinkhole interface, (the loopback interface can be used) perform the following steps:

  1. Add the interface to a virtual router and to a security zone, as shown in the example. This zone is different because it is where users are initiating connections. A best practice is to create a new sinkhole zone for this interface, as it is never certain where the malicious machines will send traffic.
    Screen Shot 2014-01-28 at 12.52.12 AM.png
    The creation of the new "sinkhole" zone places the created loopback interface as loopback.222.
    Screen Shot 2014-01-28 at 12.55.17 AM.png
  2. Add an IP address to the interface that is not currently being used and that is well known to the administrator.
  3. If IPv6 is used throughout the company, also assign an IPv6 address to the interface.
    Screen Shot 2014-01-28 at 12.52.53 AM.png
  4. Go to Objects > Security Profiles > Anti-Spyware, choose (or create) the Profile that will be assigned to the internet user.
  5. Under DNS Signatures, select sinkhole as an action on DNS queries. If block is chosen, it will block the queries to the malicious domains. In the logs, only the local DNS will be shown as an attacker. Choose the sinkhole IP address that was generated before (222.222.222.222). Choose the IPv6 IP address for the IPv6 DNS queries.
  6. Select extended-capture in packet capture to allow more packets to be captured than only the one that triggered the signature. This value is defined under Device > Setup > Content-ID > Threat Detection Settings.
    Screen Shot 2014-01-28 at 12.57.58 AM.png
  7. Apply the Anti-Spyware Profile to a security rule and enable log at session end.
  8. Commit the configuration.

Testing

After the configuration is complete, validate if the traffic is captured and identify the malicious workstation.

  1. Open a test machine behind the firewall.
  2. Initiate DNS traffic for one of the Conficker domains (for this test fetyeq.net will be used).
    Note: To check for more Conficker domains, open the Antivirus Release Notes of the dynamic updates that have been installed on the Palo Alto Networks devices. Palo Alto Networks updates these domains on a regular basis and they can be found in the Release Notes for the Antivirus signatures.
  3. Go to Devices > Dynamic-Updates > Antivirus > Release Notes and search for “conficker." There should be around 1,000 domains to review.
  4. Check the threat logs for any logs with action sinkhole.
    Screen Shot 2014-01-28 at 1.16.27 AM.png
  5. If needed, check the packet capture.
    Screen Shot 2014-01-28 at 1.17.19 AM.png
  6. Generate a custom report using the "sinkhole action" as a filter in the query builder and schedule it to run daily.
    Screen Shot 2014-01-28 at 1.19.38 AM.png
  7. Check the report the following day to confirm it's collecting and displaying data.
    Screen Shot 2014-01-28 at 1.21.10 AM.png

Following the steps above tracks and isolates malicious workstations in the designated network.

owner: ialeksov

Comments
by CHammock
on ‎02-27-2014 04:51 AM

Is this article complete?  I have not configured sinkholing yet but doesn't step 4, 5 and 7 only show data regarding the internal DNS server requesting resolution to conficker sites?  The real value in the feature is to run a traffic report for all hosts accessing 222.222.222.222 assuming there is a policy configures to DST Zone sinkhole and DST Address 222.222.222.222 this will show infected hosts.

Please correct me if this is wrong as when I do have to use this I will need to know.

Thanks

by ialeksov
on ‎02-27-2014 04:04 PM

Basically you can do it also with the traffic logs if needed. It works both ways.

In the case you want to look at a traffic report, you would like to filter according to the sinkhole destination address (in this case: addr.dst in 222.222.222.222). But, because confikr is actually a threat, this example was shown with the power of the threat logs. This way you have the ability to generate this report with the attacker filed attached to the source of the communication and show this report to the top management as a part of the threat reports and make a point that there is a threat in the company and a more strict policy can be enforced. Bear in mind that the traffic reports do not show you an attacker, but show you only source, and sometimes the subtile details like that can make the whole difference.

As for the internal DNS requesting a resolution for the confikr sites goes, that is what is triggering the signature and actually in the report you can see the end user that requested the resolution (10.193.17.29), using 3 different DNS servers: the one in the 10.0.0.0 network, the one in the 192.168.1.0 network and the public 8.8.8.8 DNS server too. You can guess that the real attacker is the 10.193.17.29 and he needs to be isolated form the network.

Hope this helps you understand and implement this.

by CHammock
on ‎03-03-2014 05:16 AM

Ah I see, so in this example the Client is 10.193.17.29 and he has to traverse the firewall to resolve any DNS hence the threat logs show the Attacker correctly as the internal client.  In this scenario the action of sinkhole is maybe used as 222.222.222.222 is an actual ip address with a server on it logging connections that can then be reported against otherwise if you where to use Block in the DNS Signature action then you would get the same output from the palo threat reports and logs but the server on 222.222.222.222 would not see any traffic.

Where I can really see the sinkhole feature come into its own is when the clients don't traverse the Palo to resolve DNS, in this scenario the threat report would show the DNS server as the attacker but a traffic report would show the acual infected hosts accessing 222.222.222.222.  I can see the value in the reports showing Attacker in the report itself.  Maybe in future releases the palo could forward any traffic logs with a destination of the sinkhole address to the threat log so a similar scary report could be run showing infected hosts based on there attempted connections to the sinkhole server.

Thanks for the clarification.

by ialeksov
on ‎03-05-2014 01:23 PM

Actually the 222.222.222.222 is not a server but is a loopback address on the firewall it self, and what the firewall does is, when he sees a request for an infected domain he is actually replacing the ip address of that domain with the 222.222.222.222.

After that, the client is sending traffic to the 222.222.222.222, which is "backholed" by the firewall and a traffic and threat log is generated.

From these logs the infected host is found and can be removed from the network until it is des-infected.

Bear in mind that for this to work, the firewall needs to see the initial nslookup for the infected cokfikr domain, so that he is able to forge the response.

In the example, three types of DNS servers are used (public dns, private dns, and a chain of private dns's which are sending the query to an external dns), so that it is demonstrated that even if an internal DNS is used, or a chain of internal DNS servers are used the traffic will be captured.

This is possible because the reply for the nslookup is forged by the firewall, and the client will than try to establish a "real" connection to a server in the infected domain (which is actually 222.222.222.222).

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 for confikr, but now, thanks to the possibility of the PA device to 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.

I hope this helps you even more.

by indup089
on ‎06-04-2014 03:21 AM

In my opinion the major point is what "CHammock" described very well:

CHammock 03.03.2014 13:16 (als Antwort auf ialeksov)

Where I can really see the sinkhole feature come into its own is when the clients don't traverse the Palo to resolve DNS, in this scenario the threat report would show the DNS server as the attacker but a traffic report would show the acual infected hosts accessing 222.222.222.222.  I can see the value in the reports showing Attacker in the report itself.  Maybe in future releases the palo could forward any traffic logs with a destination of the sinkhole address to the threat log so a similar scary report could be run showing infected hosts based on there attempted connections to the sinkhole server.

This log-merge from traffic-log to threat-log would make the sinkhole-feature definitely more complete. Most customers will use the sinkhole feature even because the client DNS traffic is not traversing the PAN

Anyone knows about plans to implement this feature?

CU

by Painyc
on ‎12-13-2014 06:35 PM

+1 for this feature

by RyanF
on ‎01-24-2015 07:03 PM

Another +1 for this feature

by QLogicAdmin
on ‎04-21-2015 09:39 AM
This log-merge from traffic-log to threat-log would make the sinkhole-feature definitely more complete.

YES, YES, YES....  Currently can't tell the difference between a Conficker threat and a generic "Suspicious DNS Request" using the sinkhole, as all "Suspicious DNS Requests" go there.

by CHammock
on ‎05-06-2015 06:36 AM

I have just had a thought (so haven't tested yet) but you could use the DoS policy with a destination of the DNS sinkhole address and an action of deny.  This should generate a threat log when users access the sinkhole address.

It isn't descriptive maybe the Dos rulename shows in the logs I am not sure at this point but it would get your sinkhole traffic into the threat log.

by n.barria
on ‎02-17-2016 09:52 PM

If i implement the DNS sinkhole feature, will it impact the network performance?

Ask Questions Get Answers Join the Live Community
Contributors