Firewall requests to suspect dns domain names

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Firewall requests to suspect dns domain names

L1 Bithead

Starting this morning (6:20AM CST), we are seeing threat notifications of suspicious dns requsts going to a group of domains that have been named in the Solarwinds Sunburst hack.

 

avsvmcloud[.]com

websitetheme[.]com

zupertech[.]com

etc

 

We've been trying to backtrack these all day.  Our internal dns servers tell us that the requests are coming from the management interfaces of our HA palo alto firewalls.  Palo Alto support tells us the firewalls are doing this to double check requests made by an internal machine.  I've enabled dns logging and gone through those logs repeatedly, and the only requests are from the firewalls themselves.

 

This feels like something that changed with the update we downloaded at 5:30am this morning.  Anyone else seeing suspicious dns queries that just started occuring today, especially for these domains?

 

Thanks.

1 accepted solution

Accepted Solutions

L4 Transporter

Hello @jstrubberg 

 

In case you have created an address object( FQDN) on PAN and intended to use it as blacklist,  in that case the PAN management interface will try to resolve it and you will see in logs.

 

I hope this helps.

 

respectfully

Himani

Himani Singh

View solution in original post

12 REPLIES 12

L2 Linker

There was a malicious update to SolarWinds’ Orion platform blamed for global hacks.

 

It has been reported In a statement, "SolarWinds said it had just discovered its systems experienced, “a highly sophisticated, manual supply chain attack on Orion software builds for versions 2019.4 through 2020.2.1, released between March and June.

“We have been advised this attack was likely conducted by an outside nation-state and intended to be a narrow, extremely targeted, and manually executed attack, as opposed to a broad, system-wide attack.” Administrators are urged to upgrade to Orion Platform version 2020.2.1 HF 1 (Hot Fix). A follow-up Hot Fix will be released Tuesday.”

 

Now Unit42 has released the blog https://unit42.paloaltonetworks.com/fireeye-solarstorm-sunburst/

All related coverages for SolarStorm and SUNBURST are covered on this Unit42 blog as of 15 Dec 2020. 

Yes, thank you.  We have followed all the mitigation advice.

 

The issue is that we are seeing our firewall management interface IPs requesting DNS for those malicious domains, but we cannot find a requesting device asking for them in the first place.  

 

Just wondering if anyone else has seen the same behavior.

L1 Bithead

And we have a solution.  We built a blacklist rule for the domains in question. The dns queries ARE from the firewall, it is confirming the IP addresses of those URL objects every few minutes.

 

Thanks Palo Alto support.

We are seeing the same behavior.  We have a support ticket open with Palo Alto as to why all of the sudden the PA's management interfaces are making these DNS queries causing our security monitoring tools to alert us.  Is this an official response as to why the Palo Alto devices are making these DNS queries?

L4 Transporter

Hello @jstrubberg 

 

In case you have created an address object( FQDN) on PAN and intended to use it as blacklist,  in that case the PAN management interface will try to resolve it and you will see in logs.

 

I hope this helps.

 

respectfully

Himani

Himani Singh

As @hisingh indicates, this typically happens when IoC domains are incorrectly being configured as FQDN Address Objects and used in the Destination Address in Security Policies. (There is another possibility which is related to the reporting engine picking up blocked websites or blocked domains to populate IP addresses in pre-defined threat reports).

 

This will cause the firewall to attempt DNS resolution on the FQDN Address Object, and populate an IP Address for Security Policy match. If the firewall's own DNS traffic is inspected by the firewall, it will trigger the associated Anti-spyware DNS signatures.

 

Using IoC domains in FQDN Address Objects is incorrect, or simply offers limited protection, since the resolved-ip for the domain from the firewall can be completely different than the resolved-ip from a host for the same domain.

 

The correct way to block IoC domains is to block them using Anti-spyware DNS. (If you instead did it on a Custom URL profile, you would only be protecting from HTTP based connections. Always keep in mind, when you talk IoC domains, you talk DNS traffic, not HTTP).

 

To populate custom entries into Anti-spyware DNS you need an EDL of type 'Domain List', pulling in a text file with the list of domains from a web-server. Make sure to set the new EDL of type 'Domain List' to a sinkhole or block action in the DNS Policies tab of the Anti-Spyware profile.

Screen Shot 2021-01-05 at 12.24.06 PM.png

 

If you want to double-up for HTTP based traffic, that's fine and recommended, and the source text file with the list of domains used for the EDL of type 'Domain List' (i.e named 'ioc-domains-dns') can be repurposed on a separate EDL of type 'URL List' (i.e. named 'ioc-domains-url'), and *also* set it to block in the URL Filtering profile, or directly under the 'Service/URL Category' tab of a Security Policy with a configured Deny action.

 

And yes, you can triple-up by adding FQDN Address objects as a Destination Address in Security Policies, but just be aware of the hit-and-miss detection capability, and that DNS signatures sourced from the firewall will fire-up. You can find a way to except them by dedicating a Security Policy with the source IP of the firewall and no Anti-Spyware profile attached, or attached to an Anti-Spyware profile configured with specific Anti-Spyware DNS exceptions (the later being the best option since you can still detect other malicious DNS requests sourced from the firewall which may help detect the unlikely case of a compromised Firewall, but of course, not if the firewall is compromised *and* the threat actor is using the threat being excepted).

 

Furthermore, while you can create independent entries in a Custom URL FIltering profile, these can be used for URL Filtering or the Service/URL Category tab of a Security Policy but cannot be used to feed domains into the Anti-Spyware DNS profile. If you tried creating custom DNS Spyware signatures for the domains, these will be considered 'spyware' signatures and not 'spyware-dns' signatures, which will only allow you to configure a block action, (action 'sinkhole' is not configurable for custom DNS signatures). If you need to sinkhole, your only option with custom Domains is an EDL of type 'Domain List'. If blocking the DNS request is good enough, you can avoid having to host an external list, and you can instead create a custom Spyware signature for the domain. An example is available in this Tech Note (Page 20). If there are multiple domains to cover, they can be created using an OR in the custom signature definitions, or simply create one custom signature per domain.

 

After everything is configured, commit the configuration and test from a protected Host using the 'nslookup <domain>' command in a system terminal window.

I only got 3 stars by @laurence64, so I decided to add more info. 🙂

Edited my last post with additional information. I hope it is useful.

@mivaldi 

 

Hi

 

Crikey, I didn't even realise! the only only reason you got 3 stars was because of a dodgy tracking pad on my laptop and me not checking before I hit post sir!

 

Apologies I did think that your answer was more than correct.

PCCSA PCNSA PCNSE PCSAE

L2 Linker

HI Team.. We are also getting the same issue management interface to generate Suspicious DNS Query .

from PA management interface to images.gistatic.org( Suspicious DNS Query) and we did not get any received any threat logs on palo alto device but these logs we were getting on DNS server.

We have already applied DNS sinkhole but why suspicious DNS query has been generated from the management interface.

@CarlosSantos what was Palo alto tac gave a solution about this issue.

@jstrubberg 

@CarlosSantos 

@mivaldi 

any response will be highly appropriated. 

Hello @bit_byte 

 

Please see above in this thread for the detailed answer.

You will see FW management port sending such query because one of the following reason:

1. FQDN Address Objects: When IoC domains are configured to use in the Destination Address in Security Policies.

2. IP addresses in pre-defined threat report where reporting engine picking up blocked websites or blocked domains to populate IP addresses.

In the above two cases firewall to attempt DNS resolution on the FQDN Address Object, and populate an IP Address for Security Policy match. If you want to make a black-list, please use spyware profile or EDLs. The custom Domain EDLs can have a list of your custom domains.

3. DNS security is enabled. 

4. DNS proxy is enabled

 

Best

Himani

 

 

Himani Singh

Bit_Byte;

 

Look at your firewall.  If you have a defined object for the URL images.gistatic.org, you will see "suspicious dns query" hits with your firewall management interface as the source.  That's your firewall checking to match an IP address with that URL for blocking purposes.

 

Working as intended.

Woow.. That explains a lot.. 

Can you also please let us know, at what intervals these attempts to resolve the FQDN object could happen. In our environment we are seeing these kind of attempts several times a day.. Is there a specific interval for this behaviour..

  • 1 accepted solution
  • 11614 Views
  • 12 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!