Check DNS Requests — but only if you’re not using DNS over HTTPS

How to determine if your machine is contacting something it shouldn’t be

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: DNS Security | Network Security | Cybersecurity

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a quick post to reiterate that if you are using DNS over HTTPS you won’t be able to inspect traffic (at least not easily) and see what your devices are requesting and to which domains they are connecting.

Now on the one hand, in some environments, you may want DNS over HTTPS. You don’t want your ISP to see what you’re connecting to, for instance. Or a government. Or your employer if you’re using a personal device on their network — but then why do you need to do that and why do they allow it?

But on my home network, I want to see what my devices are trying to connect to by looking at the domain names they request. I wrote about reverse engineering what a UDM pro connects to here:

I did that by inspecting DNS traffic to see what DNS queries were going through my firewall and the DNS responses coming back. What IP addresses were those domain names responding to?

I also wrote why a VPN is helpful in this post (and yes I am aware of — and testing — alternative options). It basically puts ALL your traffic in a tunnel if it is an IPSEC VPN (not so much with an SSL VPN):

The thing is, a VPN will encrypt your traffic so spying eyes can’t see it, but it will still protect your DNS requests in transit over external networks to a point. You need to think about where the encryption starts and stops and if it protects all or some of the data (as is the case with a split tunnel VPN) to fully understand what is and is not protected.

But your DNS requests can still be visible to your network security appliances in that case, which allows you to block traffic to known bad domain names that are serving up maliciousness.

By denying DNS over HTTPS you can also eliminate attacks like this one, where Chinese hackers disguised their dirty work with it:

For extra DNS security, use free DNS services that block bad domains such as this CloudFlare service:

When the service doesn’t return a valid response for a domain it could be the site is down, or it is serving up something you don’t want.

Beware that some application (and malware) will try to bypass your DNS settings, so you won’t get the above protections. Like Google Chrome.

In that case you can use a firewall and NAT to make sure your DNS requests are directed to your preferred DNS servers at the network layer, instead of relying on hosts and insecure things.

This is just one more reason why network security matters. You can’t always rely on the host (or the network). You need a multi-layered approach.

When you’re looking at your network traffic you will commonly see DNS requests to the following IP addresses from various devices and software:

8.8.8.8
8.8.4.4
1.1.1.1
1.0.0.1

You may see traffic to odd ports like:

853
53 TCP
443 + DNS Server

These may all be an indication of an attmept to use DNS over HTTPS. You can block all that to and from the Internet, do a reject for devices on the local network, or possibly redirect it but the redirect likely won’t work.

There are some reasons to use 53 + TCP for zone transfers but that is not something you want exposed to the Internet or even random servers on your network. Use a zero-trust network model for that and make sure the traffic is what you think it is.

There may be some way to MITM (man in the middle or monkey in the middle if you prefer) the DNS over HTTPS traffic somehow so you can continue to inspect it. Hmm. A quick look is not yielding answers but it seems like that should be possible. Something to explore later. But blocking it works fine for me.

By the way I also noticed Facebook trying to send DoH queries to their own DNS servers. They were piloting something with CloudFlare a while back — not sure where this stands now.

You can find all these lovely insights if you take control of your DNS requests — what goes were, what breaks, and what gets blocked when you start forcing all the devices to use the DNS servers you want them to use. When you see something odd you can try to inspect the DNS queries if you can, or just block it if you can’t. If you see a request to some strange domain name you can do some detective work to see if the traffic is legitimate or if you have a compromised device.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab