Traffic logs - 104.16.249.249

We are starting to see logs in our web proxy UTM indicating traffic sourced from various client devices, with destination IP of 104.16.249.249, which resolves to cloudflare-dns.com.

We do not use the Cloudflare service for our DNS. We also confirm that the browsers (Chrome and Edge) that are the source of this traffic do not have custom DNS settings installed or configured.

Can anyone advise why this traffic is occuring?

Because you are not rewriting/restoring IP addresses. Please use the search for that topic, as that has been addressed a gazillion times. There even is a dedicate #Tutorials article.

Thank you Sandro. I could not find any relevant articles or posts in the Tutorials area regarding this issue.

Can you elaborate perhaps on “rewriting/restoring IP addresses” or point me to a specific article?

https://support.cloudflare.com/hc/en-us/sections/200805497-Restoring-Visitor-IPs

Sandro…

I had seen those articles. I don’t think they apply to our scenario. To clarify, we don’t use the Cloudflare service in any capacity, DNS or otherwise.

What I am trying to understand is why we have recently seen a spike in outbound web traffic from our client workstation network, with a destination of “cloudflare-dns.com”, in the course of normal web surfing activity. The traffic is classified as DNS over HTTPS, which means the contents cannot be inspected.

We don’t allow client workstations to use or configure their own DNS resolvers, so we are trying to trace the source of this traffic and activity.

That’s an internal issue for your company. Your IT department should be able to see which devices are the source of that outbound traffic.

Agreed, and I am part of IT. We traced the traffic to client workstations and can see the events associated with the Chrome or Edge browser. When we inspect the actual web traffic, there is no consistent pattern that would indicate why the browser attempted to connect to that specific URL (cloudflare-dns.com). We see those entries scattered randomly in the normal course of typical web browsing.

That is a completely different scenario then though and something your own network administrators have to clarify. Most likely someone configured custom DNS resolvers.

1 Like

We can absolutely confirm the client devices in scope have not configured custom DNS resolvers. The only relevant information is the traffic to “cloudflare-dns.com” URL seems to occur when the clients are browsing a Yahoo web site.

How come you can confirm this with absolute certainty? How would you prevent someone from doing so? It could be even a Firefox install.

You would have to trace it to a machine and then to the application in question. The DNS part makes a DNS resolver most likely but that’s something you will have to analyse eventually.

Because I can recreate on a test device we own and manage, that certainly has not been modified to use any DNS resolver other than our enterprise standard. The device has Chrome and EDGE only, not Firefox.

In that case it should be easy to trace, as you simple need to check which application on your device sends these requests.

Agreed. We can trace the traffic to the chrome.exe application.

We are going to add the Cloudflare URL and IP ranges to our Enterprise Blocked List in our proxy and determine if any negative impact.

Thank you…

Chrome supports DoH only in development builds so far and even then you need to activate it, which you probably didnt do. So unless you have some extensions installed it is not clear why it would send requests to Cloudflare, but thats something best to clarify on Chrome’s forum.

In the future, it is advised to use endpoint security, group policies, MDM profiles, etc. to manage machines instead of monitoring the network.

The future of the web is encryption from the client to the server, with eSNI and encrypted DNS so that anyone in the middle can’t control the websites or services people use. This is mainly intended to stop ISPs from throttling certain websites and to thwart malicious totalitarian governments, but unfortunately enterprise networks often use the same methods as these bad actors to achieve the same results. The only thing that enterprises can do, but the bad actors can’t, is to manage the device itself. If you must use your existing network hardware, MDM profiles can/soon will be able to block encrypted DNS from being used and block the use of eSNI. [for example, Chrome will prevent DoH from being use whatsoever if any policies at all are set up.].

1 Like

Thank you for the reply…

We do in fact manage our endpoints with all the suggested you make. We also confirmed with certainty that none of the endpoints or browsers on the endpoints have
any DNS configuration related to Cloudflare.

That is what confused us. How and why were we seeing traffic from these managed endpoints to the
https://cloudflare-dns[.]com destination.

At first we suspected malware possibly trying to hide C&C traffic via encrypted DNS, but that was ruled out. So we are still trying to determine the source of
these URL connections.

image001.jpg

1 Like

A Chrome forum is your best bet at this point.

I didn’t get anything from yahoo.com but it’s possible for websites themselves to make requests to the domain, eg.

fetch('https://cloudflare-dns.com/dns-query?name=google.com&type=MX&ct=application/dns-json').then(async (res) => {
  let json = await res.json();
  let mxdata = json['Answer'][0]['data'];
})

Could you link the yahoo site if you see it hit the CF IP again?

Yes we will setup sniffer and try to capture relevant traffic for analysis. Unfortunately, the pattern is consistent, so will be hit or miss, thx…

image001.jpg

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.