An Internal DNS server causing the original source IP reference of an infected host to be lost.
Environment
Palo Alto Networks firewall.
Cause
A DNS sinkhole can be utilized to identify compromised hosts within a network where an internal DNS server is present in the path towards the firewall. In this scenario, the original source IP address of the host initiating the query is lost due to the internal DNS server intercepting the query. The internal DNS server initiates a new query if the name-to-IP resolution is not stored locally.
Consequently, this leads to the firewall registering instances of suspicious DNS queries in the Threat logs, with the source IP being that of the internal DNS server. This necessitates the administrator to delve into the DNS server logs in an attempt to trace the infected host that originally triggered the malicious DNS query.
Resolution
Overview
The DNS Sinkhole feature empowers the Palo Alto Networks firewall to fabricate a DNS response for a DNS query targeting a recognized malicious domain. This manipulation directs the resolution of the malicious domain name to a CNAME (sinkhole.paloaltonetworks.com) or a specific IP address (referred to as the Sinkhole IP), which is embedded as the response. The underlying presumption is that malware triggers resolution of a malicious domain, as it sets off subsequent traffic, whether TCP, UDP, or otherwise.
Through this mechanism, the infected host can subsequently be pinpointed by examining the Traffic logs for any activity directed towards the Sinkhole IP.
Important Notes: 1. When choosing a "Sinkhole IP", make sure that the IP address is a fictitious RFC1918 IP address that does not exist anywhere inside of the network (unless you intend to steer malicious traffic purposely to a given secured IP address to provide response pages , or for any other threat research purpose). 2. If the default CNAME (sinkhole.paloaltonetworks.com) configuration is used, then there must be an internal DNS server in between your hosts and the firewall. The internal DNS server must support and have recursion enabled to subsequently resolve the sinkhole.paloaltonetworks.com CNAME record to an IP address. After recursive resolution, the internal DNS Server will provide a CNAME+A record response to the originating host. This is important as hosts or internal DNS servers without recursion enabled won't generally trigger resolution of the injected CNAME record to an IP address. If your internal DNS server doesn't support recursion, configure an IP address to inject an A record response, and override the default CNAME configuration. 3. If the DNS Server is external, then the sinkhole action configuration (versus a block action) will only help stop hosts from re-trying DNS resolution to malicious domains. In the case that the default CNAME configuration is used, then there won't generally be a resulting Traffic log entry, and the original source IP address of the host originating the malicious queries can be identified directly in the Threat logs.
Steps
Make sure the latest Antivirus and WildFire 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 Antivirus and WildFire packages are current. It is recommended to download-and-install for Antivirus hourly (set a random number of minutes after hour to even out the load to the Palo Alto Networks update servers and increase the chance of a successful check, in this example 14 minutes after the hour is used), and for WildFire every minute, or Real-time in PAN-OS >= 10.0.
Note: DNS Sinkhole can be applied to firewalls with an active Threat Prevention or DNS Security license. EDL of type Domain is also supported and does not require a license. Custom Anti-Spyware DNS Signatures are not supported for a Sinkhole action.
Configure the DNS Sinkhole action in the Anti-Spyware profile. Click on the Objects > Anti-Spyware under Security Profiles. Use either an existing profile or create a new profile. In the example below the "Anti-Spyware" profile is being used. Access the DNS Policies tab to define a sinkhole action on Custom EDL of type Domain, Palo Alto Networks Content-delivered malicious domains, and DNS Security Categories.
Click in the Sinkhole IPv4 field either select the default Palo Alto Networks Sinkhole CNAME (sinkhole.paloaltonetworks.com) or a different IP address of your choosing. If you opt to use your own IP, ensure the IP is not used inside your network and preferably not routable over the internet (RFC1918). Click on Sinkhole IPv6 and enter a Sinkhole IPv6. If IPv6 is not defined, the default ::1 IPv6 address will be used. The Anti-Spyware profile has to be attached to a security policy which is in use for DNS traffic.
If the default sinkhole.paloaltonetworks.com Sinkhole configuration is used, the firewall will inject it as a CNAME response record. The sinkhole IP is constantly rotating. This means that when the Sinkhole IP needs to be queried in the traffic logs for infected host identification, there wont't be a single IP to query for, and you can't query the traffic logs by FQDN. To properly complete this configuration define a new Security Policy and place it to precede any rule currently matching DNS traffic. The new Security Policy can be named "Sinkhole", and it needs to be configured to match Destination Address (FQDN Address object: sinkhole.paloaltonetworks.com).
The action is irrelevant since the Palo Alto Networks resolved IP does not use received packets for any type of telemetry (they are dropped) and we therefore recommend the action on the Sinkhole policy to be set to action: Deny.
Once this has been configured, and when it is time to identify infected hosts, access the Traffic logs and query for any traffic matching the "Sinkhole" rule. This will help to identify the infected source hosts, regardless of what IP address the Sinkhole FQDN resolves to over time.
Note that for the CNAME record to be resolved to an IP address, your internal DNS server must support and have recursion enabled.
Regular hosts won't generally initiate a subsequent query to resolve a CNAME record to an IP address.
If a custom Sinkhole IPv4 was used, the "Sinkhole" Security Policy can simply be defined to match the Custom Sinkhole IPv4 as the destination address. For infected host identification, simply query for connections where the destination IPv4 is your Custom Sinkhole IPv4.