Symptom An Internal DNS server causing the original source IP reference of an infected host to be lost.
Environment Palo Alto Networks firewall.
Cause DNS sinkhole can be used to identify infected hosts on a network where there is an internal DNS Server in-route to the firewall that causes the reference of the original source IP address of the host that first originated the query to be lost (the query is received by the Internal DNS Server, and the internal DNS Server sources a new query if the name-to-IP resolution is not locally cached).
This causes the firewall to report observations of malicious DNS queries in the Threat logs where the source IP of the malicious DNS query is the Internal DNS server, which would force the administrator to look into the DNS Server logs to try to trace down what was the infected host that originally sourced the malicious DNS query.
The DNS Sinkhole feature enables the Palo Alto Networks firewall to forge an A/AAAA DNS response to a DNS query for a known malicious domain and causes the malicious domain name to resolve to a definable IP address (Sinkhole IP) that is injected as a response. The assumption is that malware is resolving a malicious domain because it will initiate subsequent traffic (be it TCP, UDP, or other). By means of this mechanism, the infected host can then be identified by querying the Traffic logs for any traffic sent to the Sinkhole IP.
Important! 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.
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 IPv4 (sinkhole.paloaltonetworks.com) or a different IP 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.
If the default sinkhole.paloaltonetworks.com Sinkhole IP 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.
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.