DNS Sinkholing
The DNS sinkhole action that you can enable in Anti-Spyware profiles enables the firewall to forge a response to a DNS query for a known malicious domain, causing the malicious domain name to resolve to an IP address that you define. This feature can be used to identify infected hosts on the protected network using DNS traffic in situations where the firewall cannot see the infected client's DNS query (that is, the firewall cannot see the originator of the DNS query). In a typical deployment where the firewall is north of the local DNS server, the threat log will identify the local DNS resolver as the source of the traffic rather than the actual infected host. Sinkholing malware DNS queries solves this visibility problem by forging responses to the client host queries directed at malicious domains, so that clients attempting to connect to malicious domains (for command-and- control, for example) will instead attempt to connect to a sinkhole IP address that you define. Infected hosts can then be easily identified in the traffic logs because any hosts that attempt to connect to the sinkhole IP address are most likely infected with malware.
DNS Sinkhole Workflow
The following illustration shows an example of how to identify client hosts that are attempting to communicate with known malicious domains:
Configure DNS Sinkholing
As described in the DNS Sinkhole Workflow, when a client host attempts to access a malicious domain, the DNS sinkhole option will forge the destination IP address using an IP address that the administrator defines. The following sections describe the procedure required to use this feature, how to configure the DNS sinkhole, and how to verify that the feature is functioning properly:
DNS Sinkhole Configuration Example
The steps that follow describes how to configure the DNS Sinkhole option in an Anti-Spyware profile and then attach the profile to a security rule.
Configure DNS sinkhole
Obtain an IPv4 and IPv6 address from your network administrator that will be used as the sinkhole IP address. The addresses must be in a different zone than the client hosts, so when the infected host attempts to start a session with the sinkhole IP, it will be routed through the firewall. The reason both IPv4 and IPv6 are needed is because malicious software may perform DNS queries using one or both of these protocols. Important: This sinkhole addresses must be reserved for this purpose and does not have to be assigned to a physical host. A honey-pot server could also be used as a physical host to further analyze the malicious traffic. In this example, the sinkhole IPv4 address is and the IPv6 address is fd97:3dec:4d27:e37c:5:5:5:5.
Configure the sinkhole zone if you do not have another zone that can be used. Traffic from the zone where the client hosts reside must route to the zone where the sinkhole IP address is defined, so traffic will be logged. It is recommended that you use a dedicated zone, because the infected host will be sending traffic to this zone. Select Network > Interfaces and choose an available Layer 3 interface to be assigned to the sinkhole zone. For this example, use ethernet1/3. In the Interface Type drop-down, select Layer3. In the Config tab Virtual Router drop-down, select the virtual router that is used for your firewall. For this example, use the default virtual router. To add an IPv4 address, select the IPv4 tab and select Static and then click Add. For this example, enter the IP address Select the IPv6 tab and click Static and then click Add. For this example, use the IP address fd97:3dec:4d27:e37c::/64. Click OK to save. To add a zone for the sinkhole, select Network > Zones and click Add. Enter a name in the Name field. For this example, use the name Sinkhole. In the Type drop-down menu select Layer3. In the Interfaces section, click Add and add an interface. For this example, add ethernet1/3. Click OK.
Enable DNS sinkholing on the Anti-Spyware profile. Select Objects > Security Profiles > Anti-Spyware. Modify an existing profile, or select one of the existing defaults and clone it. For this example, clone the strict profile and rename it to strict-dns-sinkhole. (Optional) Enter a description for the profile and select the DNS Signatures tab. In the Action on DNS queries drop-down, select sinkhole. In the Sinkhole IPv4 field enter a sinkhole IP address. For this example, IPv4 is and IPv6 is fd97:3dec:4d27:e37c:5:5:5:5. The default value is the loopback address. (Optional) In the Packet Capture drop-down, select single-packet or extended-capture. The single-packet option will capture the first packet of the session or you can select extended and set between 1-50 packets. You can then use the packet captures for further analysis. Click OK to save the profile. The default sinkhole IP address is the loopback address, which will resolve domains to the local host. When the loopback is selected, communication from the infected client to the malware system is cut off/sinkholed.
Ensure that the sinkhole zone and the zone where the client hosts reside can communicate and then attach the new Anti-Spyware profile to a security policy. This policy should be the policy that allows traffic for the client hosts in the Trust zone to the Untrust zone. Access from Trust to the new Sinkhole zone will also be configured to allow the client hosts to send queries to the sinkhole zone. Select the Policies tab and then click Security. Select an existing rule that allows traffic from the client host zone to the untrust zone. For this example, Rule1 was used. Add the Sinkhole zone to the rule, so client hosts can reach the zone. For this example, add the Sinkhole zone in the Destination tab. Select the Actions tab and select the Log at Session Start check box to enable it. This will ensure that traffic from client hosts in the Trust zone will be logged when accessing the Untrust or Sinkhole zones. In the Profile Setting section, select the Anti-Spyware drop-down and select the Anti-Spyware profile that you configured previously. For this example, use strict-dns-sinkhole. Click OK to save the security rule and then Commit. To verify the configuration, see Verify the Sinkhole Action and Reporting.
Verify the Sinkhole Action and Reporting
This section will describe the steps that can be performed to verify the DNS sinkhole feature. The values used are from the DNS Sinkhole Configuration Example. You can perform similar steps for your own configuration.
DNS Sinkhole Verification and Reporting
Verify that traffic is logged properly for traffic going from the client host in the Trust zone to the new Sinkhole zone. In this example, the infected client host is and the Sinkhole IPv4 address is From the client host, open a command prompt and run the following command: C:\>ping The following example output shows the ping request and the result, which is Request timed out because there is no physical host assigned to the sinkhole IP address. C:\>ping Pinging with 32 bytes of data:Request timed out. Request timed out. Ping statistics for Packets: Sent = 4, Received = 0, Lost = 4 (100% loss) On the firewall, select Monitor > Logs > Traffic and find the log entry with the Source and Destination This will confirm that the traffic to the sinkhole IP is traversing the firewall zones. Tip: You can search and/or filter the logs and only show logs with the destination To do this, click the IP address ( in the Destination column, which will add the filter (addr.dst in to the search field. Click the Apply Filter icon to the right of the search field to apply the filter. The following screenshot shows the log with the filter applied.
Now that the zones are configured properly, test that the DNS Signatures will perform the sinkhole action when a malware domain is accessed from the client host. This is similar to the action that would be performed if the client host was infected and the malicious application was attempting to reach a hacker server using DNS queries. In this example, the URL track.bidtrk.com will be used for testing. This is a domain that is listed in the DNS Signatures database and is identified as being malicious, but it is possible that your Antivirus signature DB does not have this domain. To find a valid malicious domain for testing, see the information that follows this step. From the client host, open a command prompt. Perform an NSLOOKUP on the URL, track.bidtrk.com . For example: C:\>nslookup track.bidtrk.com Server: my-local-dns.local Address: Non-authoritative answer: Name: track.bidtrk.com.org Addresses: fd97:3dec:4d27:e37c:5:5:5:5 In the above output, note that the NSLOOKUP to the malicious domain has been forged using the sinkhole IP addresses that were configured. Because the domain matched a malicious DNS signature, the sinkhole action was performed. View the threat log to see if the correct action was taken on the NSLOOKUP request. Select Monitor > Logs > Threat. Perform a ping to track.bidtrk.com , which will generate network traffic to the sinkhole address. This traffic will be used later in our example to generate a report to find infected hosts.
How to find a valid malicious domain for testing? This information will ensure that you are using a valid malicious domain, based on the current version of the antivirus signature database that is installed on your system. The DNS Signatures used to identify malicious domain is only part of the full antivirus signature database, which contains hundreds of thousands of signatures. Perform the following steps to find a malicious domain for testing: Navigate to Device > Dynamic Updates and in the Antivirus section click the Release Notes link for the current antivirus DB that is installed. You can also find the antivirus release notes on the support site in Dynamic Updates. In most cases, the signature update is an incremental update, so only new viruses and DNS signatures are listed. There are many antivirus signatures and DNS signatures that will already be installed on the firewall. In the second column of the release note, locate a line item with a domain extension (com, edu, net, and so on). The left column will show the domain name. For example, in Antivirus release 1117-1560, there is an item in the left column named "tbsbana" and the right column lists "net". To test, from a command prompt, run nslookup tbsbana.net . A sinkhole action should occur and the domain should resolve to the defined sinkhole address because the domain is verified in the antivirus DB that is installed on the firewall. The following shows the content in the release note for this line item: conficker:tbsbana 1 variants: net
To view reports, you can use App Scope to view infected client hosts, or create custom reports. To view from App Scope, select Monitor > App Scope and select Threat Monitor. Click the Show spyware button along the top of the display page. Select a time range. In this example, select Last 24 hours. The following screenshot shows three instances of Suspicious DNS queries, which were generated when the test client host performed an NSLOOKUP on a known malicious domain. Click the graph on the firewall to see more details about the event.
Configure a custom report that will identify all client hosts that have sent traffic to the sinkhole IP address, which is in this example. There are several ways to be alerted on these events, such as SNMP traps, sending to a Syslog server and/or Panorama. In this example, the infected client host performed an NSLOOKUP to a known malicious domain that is listed in the Palo Alto Networks DNS Signature database. When this occurred, the query was sent to the local DNS server, which then forwarded the request through the firewall to an external DNS server. The firewall security policy with the Anti-Spyware profile configured matched the query to the DNS Signature database, which then forged the reply using the sinkhole address of and fd97:3dec:4d27:e37c:5:5:5:5. The client attempts to start a session and the traffic log records the activity with the source host and the destination address, which is now directed to the forged sinkhole address. Viewing the traffic log on the firewall allows you to identify any client host that is sending traffic to the sinkhole address. In this example, the logs show that the source address sent the malicious DNS query. The host can then be found and cleaned. Without the DNS sinkhole option, the administrator would only see the local DNS server as the system that performed the query and would not see the client host that is infected. If you attempted to run a report on the threat log using the action “Sinkhole”, the log would show the local DNS server, not the infected host. Select Monitor > Manage Custom Reports. Click Add and name the report, for example my-sinkhole-report. Define the custom report. This example uses the following report definitions: Database —Choose the detailed threat log, which is displayed as Traffic Log. Scheduled —Enable Scheduled and the report will run every night. To view scheduled reports that have run, select Monitor > Reports. Time Frame —30 days Selected Columns —Source address, Source User, Destination address. The critical fields are Source address or Source User (if you have User-ID configured), which will identify the infected client host in the report, and Destination address, which will be the sinkhole address. In the section at the bottom of the screen, create a custom query for the action sinkhole. Either enter the following in the Query Builder window ( addr.dst in ), or select the following in each column and click Add: Connector = and, Attribute = Destination Address, Operator = in, and Value = Click Add to add the query.
Click Run Now to run the report. The report will show all client hosts that have sent traffic to the sinkhole address, which indicates that they are most likely infected. These hosts should be tracked down and checked for spyware.

Related Documentation