DNS Rebind Attacks from Internal Domain Controller

Installing and Using OpenWrt
1

I just switched from an older DavidC build to the latest OpenWRT available to me (OpenWrt 19.07.2, r10947-65030d81f3) and I've been getting all kinds of strange issues. I'll make separate topics for them for clarity.

For one, I keep getting DNS rebind notifications for my internal Windows domain. I set these options (the first two are default):

dhcp.dnsmasq.rebind_protection='1'
dhcp.dnsmasq.rebind_localhost='1'
dhcp.dnsmasq.local='/domain.local/'
dhcp.dnsmasq.domain='domain.local'
dhcp.dnsmasq.server='/ad.domain.local/172.25.227.27'
dhcp.dnsmasq.rebind_domain='ad.domain.local'

In this case, the 172.25.227.27 is my downstream DNS/Domain Controller. It has OpenWRT as a forwarder.

I do also notice my domain connectivity is very sketchy. Before my clients could find their domain controller from OpenWRT, now I need to specifically give them a DHCP option making the downstream server their DNS. And I'm getting some strange errors on my DC in the DNS section. Plus, my clients won't register themselves in the Windows DNS anymore, even with the DHCP option setting it as their primary DNS.

The one difference I see between the old and new configurations is that in the old configuration local was set to its default of /lan/.

If it matters, I did change the IP from 192.168.160.x/24 to 172.22.227.x/24 (which I came to painfully regret, Windows DC's really don't like having their IP changed). They are both private ranges, so it should make no difference IMHO.

I'm getting a bunch of other rebind log notifications, but those I can accept as legitimate, even though I didn't get them before. Maybe DavidC had/has a different log setting, maybe the newer DNSMASQ logs more.

2

Try put the following into your /etc/dnsmasq.conf

rebind-domain-ok=yourdomain.name
3

If that is the correct option (I have some trouble understanding exactly what rebind protection does, especially what it means by "upstream") then the corresponding UCI option is dhcp.dnsmasq.rebind_domain='ad.domain.local'

Reading the user guide:
List of domains to allow RFC1918 responses for, only takes effect if rebind protection is enabled. The correct syntax is: list rebind_domain '/example/'
I have no idea what that asterisk is doing there after the single quote, but so be it. I see I have made two mistakes.

First, I used uci set dhcp.dnsmasq.rebind_domain='ad.domain.local' instead of uci add_list dhcp.dnsmasq.rebind_domain='ad.domain.local' (does that really matter when there is only one entry?)

Second, I didn't use the forward slashes (didn't do that in the old config either).

I'll try that first (after work), see what it does. If it does nothing, I will use the dnsmasq.conf option. Without slashes?

PS Thanks!

4

Well, I had to try it a bit sooner, since I was suddenly spammed with:
Maximum number of concurrent DNS queries reached (max: 150)
resulting in no DNS resolution anymore. Something else that is new.

So far, so good. At least as far as the log is concerned.

5

If you are running a DNS server on a domain controller (which it sounds like you are) why are you bothering with DNS on your router? Unless there's some specific reason you need to do it that way it sounds like it's overcomplicating the situation?

6

A Windows domain controller needs to create all its service records in a separate DNS zone. It can theoretically be done manually as long as nothing changes between the domain controllers, but the preferred way is to allow the DC's to update those records themselves.

As a result, when you install the first Domain Controller, it will offer to create its own DNS server to host those records. Best practice is then to create it as a child DNS domain to the main DNS server. You then set it to forward everything outside of its own domain to the "parent"-server. And you set the parent-server to forward requests for the child-domain to it. Essentially, all it does is host the domain's service records.

Domain clients are then able to query either DNS server to find both the internet and the domain services.

I could - theoretically - research how to pre-stage the necessary records in dnsmasq. I would love that, even though it means a lot (and I mean a LOT) of manual work and maintenance. But that might be super complicated.

Alternatively, I don't even want to think about the complexity of disabling dnsmasq on the router and use only the Windows machine, especially since the router has a much higher uptime and availability and forms the hub of my entire network, both for DNS and DHCP.

One day, I even hope to implement VLANs. When you're in IT, you gotta try everything at home.

In other news, still no rebind error from the internal domain. Although the other ones still pop up. Stupid people with their 0.0.0.0 requests. How does that even make it to my server? I'll need to find a blocklist or something for those.

I will do some more testing tonight.

PS If you already knew all that about Windows domains, know that I didn't mean to sound patronizing. I have never tried to do a manual configure of the SRV records, nor have I ever come across such a configuration in any of the places I worked at, including the ones using appliance-solutions. I guess I don't know any different than this is how it is done.

7

I wasn't suggesting manually configuring SRV records in dnsmasq. You're right it would be a ridiculous approach to take and probably would end up either not working outright or fail pretty quickly. I was wondering why not just use the Windows DNS server to resolve all DNS requests, rather than try and have it resolve some addresses and dnsmasq resolve other addresses.

Admittedly my domain controllers are available 24/7 and are rarely restarted, certainly far less than my router, so it made sense to me to have them provide DNS and DHCP (mostly) services to my internal network. I do use DHCP on the router for some VLANs, but the DNS is still provided by my DCs.

8

I see. For one, I wouldn't know how to configure OpenWRT for that scenario, really. I suppose if I disable its DHCP and use Windows only, I could pass the Windows DNS as the primary, which then still uses OpenWRT as a forwarder (to ensure it always knows when to go through wan and when to go through vpn).

I guess the first main reason is that my Windows domain is mostly a lab environment, although I use it to have some measure of control over Windows 10's independent nature. But I should be able to take it down at any time.

Second, I believe in offloading stuff to whichever system is specialized in it. If I have a central network appliance that can serve DHCP and DNS, I prefer that over my domain controller (which, according to Hyper-V has an average overall load of 0% :slightly_smiling_face: ). Utilizing the resources I have in the most efficient manner by installing only the bare necessities on the DC (which got me into a lot of trouble yesterday trying to reconfigure the IP and DNS server without an actual GUI).

Anyways, we're drifting off-topic. Thank you for the talk though, my current job isn't in infrastructure management, I miss thinking like that.

The log is still clear, nothing but TLS handshakes and that one stupid rebinder. The internal domain is no longer mentioned. I will do more tests on the clients and servers, but if it all works I will mark di12345's very fast reply as the answer, since he pointed me to where I should look.

9

These dns rebind log messages just mean that your upstream dns is giving out private IP addresses for these hosts. This can be used in an attack. You can read about dns rebinding attacks here: https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325

This line in dnsmasq.conf simply tells it that it's ok to serve private addresses for the specified domain.

1 Like
10

My consfusion probably comes from the word "upstream". I mean, logically the server that was giving me issues was downstream as it was "under" OpenWRT.

By now I have a decent grasp of what it means. That will have to do. The issues have not returned after changing the uci setting to the correct value.