[OpenWrt University Question] DNS Hijacking

Installing and Using OpenWrt
1

How does DNS Hijacking actually work? Take, for example, the instructions here:

image
image1045×785 38.6 KB

I would really appreciate if a kind individual could describe the process starting from:

  1. 192.168.1.200.63621 -> 8.8.8.8.53

... and how is then then handled by the router?

2
  1. NAT PREROUTING: 192.168.1.200:63621 -> 192.168.1.1:53
  2. REPLY 192.168.1.1:53 -> 192.168.1.200:63621
  3. NAT POSTROUTING 8.8.8.8:53 -> 192.168.1.200:63621

I don't know if it works with the nftables.

2 Likes
3

Any chance you could expand on that for a dummy like me?

4

What part are you lost on?

  • Your client .200 make a DNS request to xxx.xxx.xxx.xxx - this is normal
  • Your firewall rule "hijacks" this request to the OpenWrt
  • Your OpenWrt receives and sends the request to 8.8.8.8 - this is normal
  • The reply is returned to the OpenWrt - this is normal
  • The OpenWrt replies to .200 - this is normal
5

Probably the NAT aspect. So when client makes the DNS request it does so to 8.8.8.8:53 via gateway 192.168.1.1:53, which explains the line:

The router then actually does:

192.168.1.1.[port?] -> hijack_destination_ip.53
hijack_destination_ip.53 -> 192.168.1.1.[port?]

And then replies with that result giving line:

Is that right? And it then makes it seem like this was sent from 8.8.8.8, explaining the line:

Is this about right?

6

Maybe I'm lost on what you think 8.8.8.8 is....

So I'll say:

  • The client can go to any DNS server...actually it doesn't have to exist anymore...why?
  • Because you then take the packet and the OpenWrt processes it - this is the DNS Hijack rule

OK, where is 8.8.8.8 (or whatever server you want to do DNS)?

Here:

config interface 'wan'            
... 
        list dns '8.8.8.8'

Your OpenWrt dnsmasq then handles the request and replies to .200 - as usual.

7

8.8.8.8 is just my own example of when I set a client to use 8.8.8.8 and I am expecting it to get hijacked and ultimately directed to my router set DNS:

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'
        option ip4table 'wan'
        option peerdns '0'
        list dns '185.228.168.168'
        list dns '185.228.169.168'

But I understand client still thinks it got response from 8.8.8.8, right?

1 Like
8

I have a related question: what is the significance of this option for WireGuard interface:

image
image1075×548 33.3 KB

9

:teacher:
:student:

Then our good DNS friend....

I think you got it:

  • Client goes to xxx.xxx.xxx.xxx:53/udp
  • Firewall Hijack
  • OpenWrt gets request from .200
  • OpenWrt sends to 18x.22x.168.168 18x.22x.169.xxx
  • OpenWrt gets reply
  • OpenWrt replies to client

Nothing really:

  • WG doesn't "advertise"
  • This DNS setting is only applicable to traffic initiating from the WG interface/IP
1 Like
10

Thanks so much for your responses @trendy and @lleachii.

Ah, so WireGuard doesn't actually have a facility for advertising DNS?

I find it confusing to think about how this would work. So device connects to OpenWrt via DHCP and gets sent 192.168.1.1 as DNS. How would the VPN DNS enter into this equation, if that makes sense?

Is it same as WAN only router sends DNS request through VPN interface? Or do those replace or add to the DNS servers set in WAN?

11

The packet is hijacked to the process listening to 53 on the router, typically dnsmasq. Then dnsmasq is resolving this query with its own rules and forwarders before sending back the reply to the lan host with the original address on the source field, so the lan host won't feel the packet was hijacked.

1 Like
12

Nope.

lol I find it confusing too...tbh, if I wanted to ensure a particular DNS server went up a particular tunnel, I'd make a /32 static route for it to take that tunnel.

The WAN is the interface that is allowed to make outbound requests...your allow traffic from LAN to WAN, remember (not related more so after the hijack tho) :wink:

Now you see where people have "DNS leaks" and they're so confused.

1 Like
13

Agreed, thanks!

Is is possible by the way to have hijacking in combination with DNS over TLS?

14

Only if you mean to hijack clients still making requests on 53/udp - then the OpenWrt uses DoT, then yes.

Otherwise, I think you're suggesting a man-in-the-middle attack for DoT...which the protocol is designed to prevent. Otherwise you [should] enable DoT on each client - at least, that's the point after all...

1 Like
15

So at the moment I have conditional hijacking in that requests from certain mac addresses go to 1.1.1.1:

image
image1195×648 48 KB

Would that also work with stubby?

I also wondered about sending everything to destination DNS IPs through VPN, but I think when I last tried that I got funky results (have TV's that need to bypass VPN) and it didn't work so well.

16

I've never used Stubby; but [in theory] you should be able to forward the 53/udp to any recursive DNS server that allows your OpenWrt SRC IP.

Yea...some DNS servers load geo-based results not identical to your current location.

2 Likes
17

@lleachii many thanks indeed for your helpful and informative counsel.

1 Like
18

Thanks to @trendy as well!

A scholar and a gentleman!

2 Likes
19

DoT and DoH cannot be hijacked, in the sense that the handshake will fail.
What you can do is to deny access to the DoT port or DoH servers on the wan and force the clients to roll back to using your own resources.

20

Ah, crap. I thought I could hijack as usual, sending either normal requests to my CleanBrowsing DNS or requests from televisions to CloudFlare DNS, but at the point of the router sending the request to either it includes the extra step of encrypting and sending via DNS over TLS. It sounds like that is not possible?

What would be the best way to achieve such selective DNS use depending on MAC address but in combination with encryption?