Why are there Suspicious DNS Queries sourced from the Management IP of the Firewall or Panorama?

• Palo Alto Networks Firewall
• Palo Alto Networks Panorama
• All PAN-OS versions

Observing Malicious or Suspicious DNS queries sourced from the management IP's of the Firewall or Panorama can be pretty alarming. The immediate assumption is that the Firewall or Panorama may be compromised. However, other often overlooked and benign reasons exist for the observed activity. Some of these reasons could be:

1. An FQDN Address Object configured with the offending domain is currently applied as the Source or Destination Address of a Policy. The firewall will periodically attempt to resolve the FQDN Address Object for an IP to use during Session Matching or Security Policy Lookup.
2. There is an FQDN defined in the IP list of an EDL of type IP, and the EDL is currently applied as the Source or Destination Address of a Policy. This creates a dynamic FQDN Address object. The firewall will periodically attempt to resolve the FQDN Address Object for an IP to use during Session Matching or Security Policy Lookup, or
3. There was an observation of the malicious domain in the URL Filtering logs. The Firewall and Panorama have pre-defined reports enabled by default. The malicious domain often appears in a Botnet or a Blocked Sites report. The reporting engine will attempt to resolve the IP address of the domain to fill it out in the report.
4. Anti-spyware evasion signatures 14978 and/or 14984 are set to alert. The firewall will initiate DNS queries from the management interface to resolve observations of the Host header or SNIs.
5. The firewall is hosting the DNS Proxy feature, and hosts are querying DNS through it.
6. Monitor tab-> traffic-> Resolve hostname: is enabled

NOTE: Due to any of the above reasons, Firewall or Panorama can issue the DNS queries from the management port. You can either identify and mitigate the issues as it has described in the following sessions. Or if the above Firewall settings are necessary, you can change the DNS service route in the Firewall that will send the DNS queries from any data port in place of the Firewall management port. Here is the KB article that explains the setting. 


To identify if any of these are causing the observations:

For reasons 1 or 2:

• Use the Global Find option to search for the FQDN. The results will show if the FQDN in question is present in any configured FQDN Address object or in any EDL of Type IP.
  • Global Find can be used from the CLI with the command: request system external-list global-find string <FQDN>
  • Global Find can also be run from the WebUI using the magnifying glass icon at the top-right.
    • 

• Query your URL Filtering logs to see if any URL entries contain the FQDN in question.
• Check your recent Botnet and Blocked Sites reports for the presence of the FQDN in question.

• See: Palo Alto Networks DNS Signatures Get Triggered for Traffic from Management Interface

• Apply the Anti-spyware profile to DNS traffic from hosts to the DNS Proxy, but accept it for traffic from the DNS Proxy to upstream DNS servers. Please see Blocking Suspicious DNS Queries with DNS Proxy Enabled for additional information.

• Uncheck the Resolve hostname option.

• Question: Can we keep the configuration and suppress the DNS queries from Firewall or Panorama management interface? 

• Question: What is the most effective way to block malicious domain IoC's?
• Answer: The most effective way to block malicious domain IoCs is Custom EDLs, not FQDN Address Objects. For the custom EDLs, create a text file for the domains and host that text file on the web server. This custom EDL is domain type, and EDL can be used in Anti-Spyware profiles with blocking or sink-holing action. Here is an article that explains how to create and use custom EDLs.  This will help enact blocks based on the DNS query, not the DNS response. The reason why blocking malicious domain IoCs using FQDN objects is not the best option is as follows:

1. The firewall may resolve the domain to an IP, but DNS resolution may result in different resolved IP's due to load balancing techniques; therefore, hosts will resolve DNS independently of the firewall and may resolve the domain to a different IP, therefore bypassing the Security Policy that was configured to block it.
2. If DNS traffic sourced from the firewall traverses its own Anti-Spyware inspected data path or that of another firewall, it will observe its own DNS queries as malicious DNS detections.
3. Assuming that the action was to Sinkhole the malicious DNS query, another troubleshooting step to check for a potential Firewall or Panorama compromise is to verify if there is any traffic (after the DNS query) that is sent to the Sinkhole IP. If there is no subsequent traffic, that means that the activity was limited to DNS name resolution (which supports the possibility of an FQDN Address object or the query caused by reporting), and that there is no subsequent command-and-control activity that the Firewall or Panorama is engaging in