Differences

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

--- computing:dnshijacks [2026/09/06 16:02] – 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. 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.
+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.
 {{ :computing:dhcp.png?direct&1000 |}}
-After your statics are set, the next task is to stop the cameras or OIT 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:
+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:
   * 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/OIT devices
+  * Source zone: res #pick your zone/subnet/vlan, ideally dedicated for cams/IoT devices
   * External port: 53
   * Destination zone: Any
@@ Line 43: / Line 43: @@
   * Action: Drop #or Reject
-Once that's done, you should have a rule that looks something like this:
+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:
 {{ :computing:doh-revised.png?direct&1000 |}}
-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/OIT device is making so you know which approach to take and/or which ports/IPs to block. You do this by:
+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:
   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 )'
-This command above will pull out all 53 or 853 outgoing packets and you can see what upstream DNS the cams/OIT 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 no 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.
+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.
   tcpdump -ni eth1 '(udp port 53 or udp port 853)' and '( host 8.8.8.8 or host 8.8.4.4 )'
   tcpdump -ni eth1 ip6 and '(udp port 53 or udp port 853)' and '( host 2001:4860:4860::8888 or host 2001:4860:4860::8844 )'
-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/OIT 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:
+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:
   tcpdump -ni eth1 tcp port 853 and '( host 8.8.8.8 or host 8.8.4.4 )'
@@ Line 66: / Line 66: @@
   tcpdump -ni eth1 ip6 and tcp port 443 and '( host 2001:4860:4860::8888 or host 2001:4860:4860::8844 )'
-If the cams/OIT 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:
+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:
   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/OIT 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.
+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.
 {{ :computing:150.png?direct&400 |}}
 {{ :computing:160.png?direct&400 |}}
-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/OIT 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:
+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:
 {{ :computing:forum.png?direct&1000 |}}
-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/OIT 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 OIT-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.
+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.
 -------------------------------------------
-== **Updates** ==
+=== Updates ===
-One can
+  * Installed conntrack on openWRT in order to confirm forwards and drops via kernel DRAFT
+  * forthcoming
- --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/09/06 15:07//
+The simplest command is to see what is happening on the ''172.66.66.0/24'' subnet/vlan:
+  conntrack -L -f ipv4 | grep 172.66.66
+To confirm direct udp 53/853 hijacks:
+  conntrack -L -f ipv4 -p udp --orig-port-dst 53
+  conntrack -L -f ipv4 -p udp --orig-port-dst 853
+  conntrack -L -f ipv6 -p udp --orig-port-dst 53
+  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 19:13//

Haack's Wiki

User Tools

Site Tools

Differences

Page Tools