Differences

This shows you the differences between two versions of the page.

--- computing:dnshijacks [2026/09/06 13:57] – oemb1905
+++ computing:dnshijacks [2026/09/08 04:37] (current) – oemb1905
@@ Line 11: / Line 11: @@
 -------------------------------------------
-This tutorial is for owner's of cameras and/or OIT devices that want to monitor/secure their network from the device. As is well known, these devices 'phone home' and/or use built-in DNS to ensure connectivity but in so doing, bypass LAN policies and/or security. This tutorial assumes you already have a functioning openWRT-based LAN or equivalent. [[https://wiki.haacksnetworking.org/doku.php?id=computing:openwrt|In my case]], I use a pair of Flint 2 GL.Inet routers, with one routing and the other acting as a dump AP.
+This tutorial is for owner's of cameras and/or IoT devices that want to monitor/secure their network from the device. As is well known, these devices 'phone home' and/or use built-in DNS to ensure connectivity but in so doing, bypass LAN policies and/or security. This tutorial assumes you already have a functioning openWRT-based LAN or equivalent. [[https://wiki.haacksnetworking.org/doku.php?id=computing:openwrt|In my case]], I use a pair of Flint 2 GL.Inet routers, with one routing and the other acting as a dump AP. Once you have that in place, the first thing to do is identify the cameras and assign them static IPS. You can do this in LuCI > Network > DHCP > Static Leases. Although I prefer using the MAC addresses for the remaining openWRT rules, the static addresses are indispensable for using tcpdump to monitor traffic during setup.
-LuCI → Network → DHCP and DNS → Static Leases. Establish statics for each camera or OIT device, which helps for tcpdump tracking later.
 {{ :computing:dhcp.png?direct&1000 |}}
-**2. Port 53/853 intercept for direct udp on either port**
+After your statics are set, the next task is to stop the cameras or IoT devices from directly querying external DNS servers. Most devices that do this directly contact the upstream DNS IP on either port 53 or port 853. It is true that 853 can be used for DoT - but that's not what we are stopping right now. Here, we are stopping alternate port direct udp DNS queries which can also use 853. To stop outgoing packets on 53 and 853, we use openWRT's port forward logic in the firewall. To get there, navigate to LuCI > Network > Firewall > Port Forwards. Once in that section, click Add and enter something like the following:
-LuCI → Network → Firewall → Port Forwards / Incoming.
+  * Name: Camera1
+  * Restrict to address family: ipv4 #use what your devices use
+  * Protocol: TCP + UDP
+  * Source zone: res #pick your zone/subnet/vlan, ideally dedicated for cams/IoT devices
+  * External port: 53
+  * Destination zone: Any
+  * Internal IP address: 172.66.66.150 (ns5.haacksnetworking.org) #redirects traffic to my DNS server, a pihole + unbound
+  * Internal port: 53
+  * Advanced Settings
+  * Source MAC address: 80:48:2C:44:C7:7D 80:48:2C:41:71:78 80:48:2C:41:69:FF 80:48:2C:46:0E:C4
-<code>
+Once this is done, duplicate the rule and change the external port to 853. If your devices listen on ipv6, make a separate ipv6 rule with a separate ipv6 DNS target. In my case, the v4 Wyze cameras I used only accepted ipv4 addresses. I checked on the router to be sure with ''ip -6 neigh show dev br-lan.179''. Once you have built your port forwards, you should have something similar to the following:
-- Name: Camera1
-- Restrict to address family: IPv4 only
-- Protocol: TCP + UDP
-- Source zone: res
-- External port: 53
-- Destination zone: res
-- Internal IP address: 172.66.66.150 (ns5.haacksnetworking.org)
-- Internal port: 53
-Advanced Settings
-- Source MAC address:
-:48:2C:44:C7:7D
-:48:2C:41:71:78
-:48:2C:41:69:FF
-:48:2C:46:0E:C4
-</code>
 {{ :computing:udp2.png?direct&1000 |}}
-I decided to give the first two cams/OIT devices back to ns5 and the other two cams/OIT devices back to ns6.
+In the openWRT tutorial linked at the top, you will see that I use two nameservers for each vlan/subnet. Each of those nameservers is a pihole+unbound and each has an ipv4 and ipv6 address that I assign in openWRT and which get pushed to clients for DNS. This means each vlan/subnet has 4 DNS IP addresses pushed out. Having two is helpful if you are updating one and/or one of them goes down for a backup, etc. Normally the secondary nameserver gets few hits, only backing up the other when/if needed. Since we are hijacking DNS packets, however, I figured why not split up the load, so in the picture above, you will see that I sent two cameras packets to ns5 .150 and the other two cameras to ns6 .160. When I first placed the cameras on the vlan/subnet, there were no urls in the pihole's dashboard from the cameras. After putting these rules in place, you immediately saw the time servers, APIs for logging in, and all other requests populating nicely. Okay, now that we are hijacking outgoing udp53 and udp853, let's ensure that there's not an embedded DNS over https, or DoH that can bypass those forwards. To do that, we setup a traffic rule. Let's go to LuCI > Network > Firewall > Traffic Rules. In there, let's set up something like the following:
-**3. DoH / DoT drop**
+  * Name: `Camera DoH`
+  * Family: IPv4 and IPv6
+  * From: zone `res`
+  * Specify the MACs: 80:48:2C:41:69:FF 80:48:2C:41:71:78 80:48:2C:44:C7:7D 80:48:2C:46:0E:C4
+  * To: zone `wan`
+  * IPs to block: 1.1.1.1 1.0.0.1 8.8.8.8 8.8.4.4 9.9.9.9 149.112.112.112 94.140.14.14 94.140.15.15 208.67.222.222 208.67.220.220 185.228.168.9 185.228.169.9 76.76.2.0 76.76.10.0 45.90.28.0 45.90.30.0 2001:4860:4860::8888 2001:4860:4860::8844 2606:4700:4700::1111 2606:4700:4700::1001 2620:fe::fe 2620:fe::9 2a10:50c0::ad1:ff 2a10:50c0::ad2:ff 2620:119:35::35 2620:119:53::53 2a0d:2a00:1::1 2a0d:2a00:2::1 2606:1a40:: 2606:1a40:1:: 2a07:a8c0:: 2a07:a8c1::
+  * Ports: 443 853
+  * Action: Drop #or Reject
-LuCI → Network → Firewall → Traffic Rules.
+The rule above includes both port 443 and 853. The inclusion of 853 is not for DoH, rather, it is included as an extra pre-caution for DoT. It's harmless to include and just in case a port forward for 853 DoT fails to work, this drop rule ensures that cams / IoT devices can't contact any of these IPs for DoT. The DoH is covered by 443 and the IPs specified are just the most common (Google, Cloudflare, etc.). One can and should monitor this list and include others; consult online sources for a comprehensive list and/or dedicated repository. Once that's done, you should have a rule that looks something like this:
-<code>
+{{ :computing:doh-revised.png?direct&1000 |}}
-- Name: `Camera DoH`
-- Family: IPv4 and IPv6
-- From: zone `res`
-- Specify the MACs:
-:48:2C:41:69:FF
-:48:2C:41:71:78
-:48:2C:44:C7:7D
-:48:2C:46:0E:C4
-- To: zone `wan`
+Now that everything is setup, you need to ensure that there are no leaks. This is easily done with tcpdump on the router. There's many different tests we can run, for example, we can tcpdump the static IPs to see what requests they are making on port 53/853. This is helpful during initial setup because it can help you see what requests the cams/IoT device is making so you know which approach to take and/or which ports/IPs to block. You do this by:
-# Specify that these IPs are blocked (add as needed):
-.1.1.1
+  tcpdump -ni br-lan.179 host 172.66.66.105 or host 172.66.66.106 or host 172.66.66.107 or host 172.66.66.108 | egrep '(\.53 |\.853 )'
-.0.0.1
-.8.8.8
+This command above will pull out all 53 or 853 outgoing packets and you can see what upstream DNS the cams/IoT device is using. When I began this tutorial, I ran this command first and you could clearly confirm that online reports were correct and the Wyze v4 cams were sending outgoing udp/53 requests to 8.8.8.8 and 8.8.4.4, which are Google's public DNS servers. Nevertheless, once everything is setup, you want to make sure there are no leaks. The way to do that is by running tcpdump on the wan/wan6 interface to see if anything we hijacked or dropped is sneaking out. First, confirm the wan/wan6 interface name by running ''uci get network.wan.device'' and ''uci get network.wan6.device''. On the Flint 2, these are both eth1. First, I wanted to make sure that there were no leaks on 53/853, which was the request I initially spotted, so I sniffed the wan interface to see if any udp53 or udp853 requests were getting out.
-.8.4.4
-.9.9.9
-.112.112.112
-.140.14.14
-.140.15.15
-.67.222.222
-.67.220.220
-.228.168.9
-.228.169.9
-.76.2.0
-.76.10.0
-.90.28.0
-.90.30.0
-- Ports: `443`, `853`
+  tcpdump -ni eth1 '(udp port 53 or udp port 853)' and '( host 8.8.8.8 or host 8.8.4.4 )'
-- Action: Drop
+  tcpdump -ni eth1 ip6 and '(udp port 53 or udp port 853)' and '( host 2001:4860:4860::8888 or host 2001:4860:4860::8844 )'
-</code>
-{{ :computing:doh.png?direct&1000 |}}
+To be clear, the above command is checking both 53 and 853 for plain text udp requests. Although rare, you can do this on port 853 but do not confuse that with DNS over TLS, which I tested next. To my surprise, I initially saw requests sneaking out. As it turns out, this was because I had wrongly set the destination zone on the hijack to the same zone as the origin. This, however, is wrong because obviously these external IPs are not within the source zone. So, I removed the destination zone and left it as "Any," which creates an outgoing wildcard of sorts, allowing openWRT to forward those packets regardless of where it is heading. I adjusted the forward and then sniffed while rebooting the cameras and nothing got by. It should also be noted that the port forward rules for 53/853 above were careful to specify both udp and tcp in the logic. This is because cams/IoT devices can use port 853 for either plain text udp requests and/or for DNS over TLS, or DoT requests. By having both tcp/udp specified, openWRT will also catch any outgoing DoT requests. To test for DoT leaks, I ran the following commands:
-Then, once these are setup, confirm using tcpdump on your openWRT router. The basic tcpdump commands to check wan interface (eth1) for leaks:
+  tcpdump -ni eth1 tcp port 853 and '( host 8.8.8.8 or host 8.8.4.4 )'
+  tcpdump -ni eth1 ip6 and tcp port 853 and '( host 2001:4860:4860::8888 or host 2001:4860:4860::8844 )'
-  tcpdump -ni eth1 udp port 53 and '( host 8.8.8.8 or host 8.8.4.4 or host 1.1.1.1 or host 1.0.0.1 or host 9.9.9.9 )'
+I only ran these commands for port 853 because it is impossible to do DoT on port 53. After rebooting the devices a few times and waiting five minutes, I confirmed that there were no DoT requests sneaking out. I had not seen any during initial testing, nor did online sources state that v4 cams were known to do this, but it's harmless to set the logic and better safe than sorry. Now that those leaks were stopped and/or confirmed not happening, it was time to test DoH. Similarly, there were no reports online that Wyze cams using DoH, but there's no reason to let a firmware update add that feature down the road and then have no prohibition. Better to set the rule now instead of being sorry later. To confirm no DoH requests were getting out, I ran the following:
-  tcpdump -ni eth1 '(tcp port 443 or tcp port 853 or udp port 853)' and '(host 8.8.8.8 or host 8.8.4.4 or host 1.1.1.1 or host 1.0.0.1 or host 9.9.9.9 )'
-  tcpdump -ni eth1 ip6 and udp port 53 and '( host 2001:4860:4860::8888 or host 2001:4860:4860::8844 or host 2606:4700:4700::1111 or host 2606:4700:4700::1001 or host 2620:fe::fe )'
-  tcpdump -ni eth1 ip6 and '(tcp port 443 or tcp port 853 or udp port 853)' and '( host 2001:4860:4860::8888 or host 2001:4860:4860::8844 or host 2606:4700:4700::1111 or host 2606:4700:4700::1001 or host 2620:fe::fe )'
-Or, run all at once:
+  tcpdump -ni eth1 tcp port 443 and '( host 8.8.8.8 or host 8.8.4.4 )'
-<code>
+  tcpdump -ni eth1 ip6 and tcp port 443 and '( host 2001:4860:4860::8888 or host 2001:4860:4860::8844 )'
-tcpdump -ni eth1 '
-  (
+If the cams/IoT devices are sending out DoH requests, these commands will spot those leaks. Since I had not seen the Wyze v4 cams ping anything besides Google in testing, I restricted the commands to Google's DNS servers. If needed, however, you can adjust the IPs above to include all of the blocked IPs in the traffic rule above. Here are the more inclusive commands:
-    udp port 53 or
-    tcp port 443 or
-    tcp port 853 or
-    udp port 853
-  ) and (
-    host 8.8.8.8 or host 8.8.4.4 or
-    host 1.1.1.1 or host 1.0.0.1 or
-    host 9.9.9.9 or
-    host 2001:4860:4860::8888 or host 2001:4860:4860::8844 or
-    host 2606:4700:4700::1111 or host 2606:4700:4700::1001 or
-    host 2620:fe::fe
-  )
-'
-</code>
-Or, to just check the cameras (use static ips on the restricted zone) traffic in entirety:
+  tcpdump -ni eth1 tcp port 443 and '(host 8.8.8.8 or host 8.8.4.4 or host 1.1.1.1 or host 1.0.0.1 or host 9.9.9.9 or host 149.112.112.112 or host 94.140.14.14 or host 94.140.15.15 or host 208.67.222.222 or host 208.67.220.220 or host 185.228.168.9 or host 185.228.169.9)'
+  tcpdump -ni eth1 ip6 and tcp port 443 and '(host 2001:4860:4860::8888 or host 2001:4860:4860::8844 or host 2606:4700:4700::1111 or host 2606:4700:4700::1001 or host 2620:fe::fe or host 2620:fe::9 or host 2a10:50c0::ad1:ff or host 2a10:50c0::ad2:ff or host 2620:119:35::35 or host 2620:119:53::53 or host 2a0d:2a00:1::1 or host 2a0d:2a00:2::1)'
+Once everything is set up and you've confirmed you have no leaks, you can return to your pihole dashboard and start evaluating urls that the cameras/IoT devices are contacting. Prior to this, the dashboard was empty, but now that direct udp on 53/853, DoT on 853, and DoH on 443 are all either hijacked or dropped, you should see it fill up nicely. Here's a shot from each pihole, ns5 and ns6, after a few minutes.
-  tcpdump -i br-lan.179 host 172.66.66.105 or host 172.66.66.106 or host 172.66.66.107 or host 172.66.66.108 -n
+{{ :computing:150.png?direct&400 |}}
+{{ :computing:160.png?direct&400 |}}
-Or, just check outbound 53 / 853, direct udp:
+For whatever reason, the cams are using FOUR timeservers! Also, despite turning off all cloud-based features, the Wyze cameras continually ping home to ''c1ybkrkbr1j10x.credentials.iot.us-west-2.amazonaws.com''. Not only do they ping home still, they do so at an alarming rate. Next, I used pihole's domain-level blocking to add a deny rule for the extra time servers and the cloud domain that I was not using. I left the .gov timeserver so I could get proper timestamps, but I saw no reason why they needed the other 4 servers, especially one called ''time.windows.com'' lol. This home network is not pinging any ''windows.com'' domain on principle. The point, however, is that now that you've properly secured your gateway leaks, you can easily use a DNS tool like the pihole to visually inspect what your cams/IoT devices are doing and block accordingly. Additionally, I looked online and forum hunted for any other potential "phone home" urls, and blocked the following pre-emptively:
-  tcpdump -i br-lan.179 host 172.66.66.105 or host 172.66.66.106 or host 172.66.66.107 or host 172.66.66.108 -n | egrep '(\.53 |\.853 )'
+{{ :computing:forum.png?direct&1000 |}}
-Or, check 443 and 853 while stripping the okay stun/turn they need for the app:
-  tcpdump -i br-lan.179 host 172.66.66.105 or host 172.66.66.106 or host 172.66.66.107 or host 172.66.66.108 -n | egrep -v '(\.443|\.3478|\.8883|ARP)'
+So far, the piholes have not caught the v4s phoning home to any of these domains, but better safe than sorry. I also left four different tabs open in Terminator all night to confirm that nothing was sneaking out the wan interface that shouldn't be. All clean. I will note that most of this tutorial was already setup in beta form, however, it was kludgy and incomplete. After some discussions in the [[https://element.gnulinux.club|GNU/Linux Club]] about DoH, I decided to brush up my openWRT logic. I also made another vlan/subnet just for the cameras/IoT devices so I could more easily spot their traffic. To be clear, they were previously on a highly restricted subnet/vlan, but/and it was multi-purpose and included all the trashy platforms my kids use as well (Discord, Insta, etc.) thus making it hard to distinguish Wyze-originated or IoT-originated packets with ease. I also never wrote this up. Lastly, I need to give credit to [[https://jasonschaefer.com|Jason Schaefer]] who first taught me how to drop unwanted traffic on openWRT, tighten up LANs, and verify desired results with tcpdump. Lastly, I dedicate this tutorial to Bender.
-After catching some leaks due to destination zone being set on 53/853 direct udp, revised this command to monitor WAN with time stamps to see what gets by and when:
-<code>
+-------------------------------------------
-tcpdump -ni eth1 -vvv -tttt '
-  (host 172.66.66.105 or host 172.66.66.106 or host 172.66.66.107 or host 172.66.66.108)
-  and not (
-    udp port 123 or
-    (udp portrange 10000-65535 and not udp port 53 and not udp port 853)
-  )
-'
-</code>
-You have to run tcpdump and bird's eye look at the pihole dashboard initially. You will suddenly see that the direct DNS udp/53 it runs to 8.8.8.8 and 8.8.4.4 that are widely reported are now being intercepted. You confirm on tcpdump by checking the wan outgoing ... to see if anything gets by. You can tell on the piholes because initially you won't see any domains, but as soon as you set up the forwards correctly, you will get a slew of domains popping off:
+=== Updates ===
-{{ :computing:150.png?direct&400 |}}
+  * Installed conntrack on openWRT in order to confirm forwards and drops via kernel DRAFT
-{{ :computing:160.png?direct&400 |}}
+  * forthcoming
-For whatever reason, the cams are using FOUR timeservers. I left the .gov one and blocked the rest. No issues. You block those in the domain section of the piholes. Also, before I began, I blocked the following in pihole's domain section. I got these from forums / online resources. So far, the cams have not pinged any of these, but better safe than sorry:
+The simplest command is to see what is happening on the ''172.66.66.0/24'' subnet/vlan:
-{{ :computing:forum.png?direct&1000 |}}
+  conntrack -L -f ipv4 | grep 172.66.66
-Alright, this is an improved version of my prior setup, dedicated to Bender.
+To confirm direct udp 53/853 hijacks:
-Notes:
+  conntrack -L -f ipv4 -p udp --orig-port-dst 53
-  * Noticed that openWRT was missing some direct outgoing due to des zone being set, removed
+  conntrack -L -f ipv4 -p udp --orig-port-dst 853
-  * Added ''c1ybkrkbr1j10x.credentials.iot.us-west-2.amazonaws.com'' to blocklist
+  conntrack -L -f ipv6 -p udp --orig-port-dst 53
-  * Experimenting with changing the des zone to wan instead - nevermind, blank better (includes wan)
+  conntrack -L -f ipv6 -p udp --orig-port-dst 853
+To confirm hijacks of DoT:
+  conntrack -L -f ipv4 -p tcp --orig-port-dst 853
+  conntrack -L -f ipv6 -p tcp --orig-port-dst 853
+To confirm drops of DoH requests:
+  conntrack -L -f ipv4 -p tcp --orig-port-dst 443 | grep -E '8\.8\.8\.8|8\.8\.4\.4\.'
+  conntrack -L -f ipv6 -p tcp --orig-port-dst 443 | grep -Ei '2001:4860:4860::|2606:4700:4700::|2620:fe::|2a10:50c0::|2620:119:'
+Or, query the kernel directly:
+  grep -E 'dport=53 |dport=853 |dport=443 ' /proc/net/nf_conntrack
+Also, one can layer 7 domain block these common DoH domains. This won't stop cams / IoT devices from using IPs, but it stops them from using domains:
+<code>
+`doh.dns.apple.com mask.icloud.com mask-h2.icloud.com dns.google dns.google.com google.dns dns64.dns.google cloudflare-dns.com mozilla.cloudflare-dns.com security.cloudflare-dns.com family.cloudflare-dns.com one.one.one.one 1dot1dot1dot1.cloudflare-dns.com dns.quad9.net dns10.quad9.net dns11.quad9.net dns.adguard.com dns-family.adguard.com dns.adguard-dns.com unfiltered.adguard-dns.com family.adguard-dns.com doh.opendns.com doh.familyshield.opendns.com doh.sandbox.opendns.com dns.nextdns.io firefox.dns.nextdns.io anycast.dns.nextdns.io dns.mullvad.net adblock.dns.mullvad.net base.dns.mullvad.net family.dns.mullvad.net unfiltered.dns.mullvad.net freedns.controld.com p0.freedns.controld.com p1.freedns.controld.com p2.freedns.controld.com p3.freedns.controld.com dns.sb doh.dns.sb doh.cleanbrowsing.org security-filter-dns.cleanbrowsing.org family-filter-dns.cleanbrowsing.org adult-filter-dns.cleanbrowsing.org dns.switch.ch doh.pi-dns.com doh.appliedprivacy.net odoh.cloudflare-dns.com`
+</code>
- --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/09/06 02:56//
+ --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/09/06 19:13//

Haack's Wiki

User Tools

Site Tools

Differences

Page Tools