Potential DNS Rebind attack: how to solve

alfredino

My network has a fortinet fortigate 200F firewall and active directory running windows server 2019 (DHCP and DNS) and is connected to the Internet via two different ISPs (A and B) with their respective routers/modems configured for load balancing. There is also an external web server connected to the firewall (not in DMZ) and served by a static IP address provided by one of the ISPs (A). The ISP A router/modem is a netgate pfsense configured to use public IP1 for external connections and private IP2 for internal connections.
The network worked fine until a few months ago, when ISP A replaced its router/modem and the error started to appear: Potential DNS Rebind attack detected. Nothing was changed on my side except the software update, but the configuration remained the same. The problem is always present from the internal network (LAN) regardless of the operating system or browser used, but does not exist from the external network. In fact, if I use a VPN from the internal network, the problem disappears.
The strange thing is that the problem occurs randomly, i.e. it works fine for a few hours and then stops working for a few minutes, sometimes it works intermittently for a few minutes. When the network is not working properly, I found out via nslookup that the DNS is not resolving the URL properly: it provides the public IP IP1 instead of the private IP2.
Unfortunately, I do not have access to ISP A's router/modem configuration. So I have limited ability to solve the problem. According to the documentation, the problem could be solved in several ways. The simplest:
Add your FQDN to the configuration.
System->Advanced
Alternate Hostnames
Probably, the best one.
After contacting ISP A and reporting the problem, they replied that I have to make sure that I use their DNS as the main one so that the clients receive the private IP2 of the web server: URL -> private IP 2, not public IP 1.
I have rechecked my configuration (fortinet, active dsirectory, DNS, web server and client) several times, but have been unable to solve the problem. What can I do? I think there is a configuration error on ISP A router/modem.
Thank you

johnpoz

@alfredino are you running pfsense on this fortigate?

A rebind is if you forward dns to something other than then the local name server, and rfc1918 is returned.

If your local dns doesn't have to go ask another ns, be it forwarding the query or resolving then there would be no rebind.

You should not be putting rfc1918 address in any sort of public ns, ie your isp dns for example

If a client directly access your isp dns and it gets back rfc1918 that is not a rebind. if you ask your local dns and it goes and asks your isp or some other name server and answer is rfc1918 - then that is a rebind.

Putting rfc1918 in public name servers is bad idea.

You could either disable rebind protection completely - or you could setup up your domain to be a private domain, so that it would allow for rfc1918 answers when it asks a different name server.

https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html

alfredino

@johnpoz No, the psfense is managed by ISP1. I am aware of its presence because of the rebind attack.
The clients use DHCP and DNS from windows active directory machines configured with ISP1 DNS.
Unfortunately, I do not have access to the pfsense configuration and therefore cannot disable the rebind attack protection or use split mode as stated in the first post.
What I am asking is if there is anything I can do on my end to solve the problem, as I cannot act on the other end.
Thank you

johnpoz

@alfredino no there is nothing you can do on your end - rebind protection is the feature of the nameserver doing the query.

windows active directory machines configured with ISP1 DNS.

Why would your clients be pointing to anything but your AD for dns? That is always going to be problematic.

Have your clients use your AD nameserver, this AD name server would then forward to for stuff it is not authoritative for.

If your clients ask nameserver running on pfsense - and it then forwards to your ad for your ad domain - and rfc1918 is return, that is by definition a rebind.

Clients pointing to more than 1 name server, that could return different things is always problematic because you really have no idea which ns a client might ask. Clients should only ever point to your AD dns if you are running AD.

alfredino

@johnpoz said in Potential DNS Rebind attack: how to solve:

Why would your clients be pointing to anything but your AD for dns? That is always going to be problematic.

Have your clients use your AD nameserver, this AD name server would then forward to for stuff it is not authoritative for.

If your clients ask nameserver running on pfsense - and it then forwards to your ad for your ad domain - and rfc1918 is return, that is by definition a rebind.

I probably badly explained myself. Clients use DHCP and DNS from active directory which in turn are configured with two non-authoritative DNS (the first from ISP1 and the backup from one of the famous DNS servers, cloudflare).
If I only had the DNS provided by ISP1, I would risk losing the connection in the event of a malfunction (I have a redundancy of two ISPs for this).

Clients pointing to more than 1 name server, that could return different things is always problematic because you really have no idea which ns a client might ask. Clients should only ever point to your AD dns if you are running AD.

That's right, it is configured that way. It is the local DNS of active directory that has two DNS entries as explained above.

johnpoz

@alfredino It would be much easier to help you if gave examples of what is being returned.

AD dns should never have to go ask anything for records that are are in the AD domain. Since they would be authoritative for anything.youraddomain.tld

This makes no sense..

make sure that I use their DNS as the main one so that the clients receive the private IP2 of the web server:

Again some public dns, ie your your ISP or any other ns on the public internet should never be setup to return a rfc1918 address.

Lets call your AD domain addomain.tld

Public domain would be say publicdomain.tld

What are you trying to resolve? host.addomain.tld, or host.publicdomain.tld

SteveITS

@alfredino I am confused, are you seeing this when connecting to the ISP’s pfSense? If so then https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html and it’s expected in certain conditions.

Seems like you already found:
https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html#dns-rebind-check
https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html#alternate-hostnames

If you are accessing some other web site and ending up connecting to pfSense that’s a different issue and the error is just a symptom.

johnpoz

@SteveITS true - maybe he is hitting pfsense gui via invalid fqdn or something.

@alfredino could you post up what your actually seeing for the rebind error. You might be resolving something that ends you up on the pfsense IP when it shouldn't

alfredino

@johnpoz I am trying to resolve host.publicdomain.tld. The domain is resolved correctly from any external network (public IP), while sometimes it is resolved correctly and sometimes not from the internal network (private IP).
The clients receive their DHCP and DNS configuration from AD, which is configured with DNS of ISP1 (for redundancy it has also a DNS from famous DNS resolver).

alfredino

@SteveITS said in Potential DNS Rebind attack: how to solve:

@alfredino I am confused, are you seeing this when connecting to the ISP’s pfSense? If so then https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html and it’s expected in certain conditions.

Exactly, I am receiving this from firefox.

Seems like you already found:
https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html#dns-rebind-check
https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html#alternate-hostnames

The problem is that the configuration of the pfsense machine can only be done by the ISP. They told me that they have implemented the split DNS solution. However, sometimes it works fine and other times it stops working and we cannot understand why. According to them, there is a misconfiguration on my part regarding the DNS server (which must be their DNS). However, I don't know what I can do because I have already double checked all my configurations and they all seem to be correct. Also, the problem appeared after they changed their router/modem.

If you are accessing some other web site and ending up connecting to pfSense that’s a different issue and the error is just a symptom.

No, I do not have this problem.

alfredino

@johnpoz said in Potential DNS Rebind attack: how to solve:

@alfredino could you post up what your actually seeing for the rebind error. You might be resolving something that ends you up on the pfsense IP when it shouldn't

johnpoz

@alfredino that is a error you get when you access pfsense gui via the wrong name..

example if I create a dns entry to point to my pfsense IP of say test.home.arpa

;; QUESTION SECTION:
;test.home.arpa.                        IN      A

;; ANSWER SECTION:
test.home.arpa.         0       IN      A       192.168.9.253

If I then go there - I do get error about the cert not matching, etc. but if accept that then get that error

Your problem is you have something resolving to pfsense IP address that is not suppose to be pfsense.

SteveITS

@alfredino Browsers nowadays often use DNS over HTTPS (or DoT) and bypass local DNS. That can be turned off in the browser, or blocked using the pfBlocker add-in package.

Also if your AD DNS is not configured to forward to pfSense then the AD DNS will never see the split DNS override. Also of note, especially if IPv6 is in use, our normal process is to set a domain override in DNS, for the AD domain name, pointing to the AD DNS server(s).

If you are trying to connect to an internal web server and are hitting the pfSense GUI then the NAT rule likely needs NAT reflection enabled.

alfredino

@johnpoz said in Potential DNS Rebind attack: how to solve:

@alfredino that is a error you get when you access pfsense gui via the wrong name..

example if I create a dns entry to point to my pfsense IP of say test.home.arpa
;; QUESTION SECTION:
;test.home.arpa.                        IN      A

;; ANSWER SECTION:
test.home.arpa.         0       IN      A       192.168.9.253
If I then go there - I do get error about the cert not matching, etc. but if accept that then get that error

Your problem is you have something resolving to pfsense IP address that is not suppose to be pfsense.

This error only appears to me from my local network and not always, but occasionally when I try to access host.publicdomain.tld. From any external network it always works. What could be the cause? Why only sometimes and not constantly? On my side no configuration has changed, that's why I can't understand.

alfredino

@SteveITS said in Potential DNS Rebind attack: how to solve:

@alfredino Browsers nowadays often use DNS over HTTPS (or DoT) and bypass local DNS. That can be turned off in the browser, or blocked using the pfBlocker add-in package.

Also if your AD DNS is not configured to forward to pfSense then the AD DNS will never see the split DNS override. Also of note, especially if IPv6 is in use, our normal process is to set a domain override in DNS, for the AD domain name, pointing to the AD DNS server(s).

I already tried manually disabling the DoH via the browser and also via the operating system (also DoT). Unfortunately, the behaviour is the same.
My DNS AD is configured with the DNS provided by ISP1 (ISP A) as required by the provider. IPv6 should not be in use, but I will check.

If you are trying to connect to an internal web server and are hitting the pfSense GUI then the NAT rule likely needs NAT reflection enabled.

Interesting. That could be the cause, but according to my ISP, they have already configured NAT reflection via split DNS. How can I figure out why the configuration works at certain times and not at others?

johnpoz

@alfredino what is the fqdn you are using? And what does it resolve to - is it suppose to resolve to a public IP or a private IP?

what is this fqdn? Send it to me via DM if you don't want to post it public.. And I can check what it resolves to on the enternet..

SteveITS

@alfredino

Why only sometimes

I expect you are experiencing different answers from different DNS servers. pfSense isn’t randomly changing it’s behavior, you’re only connecting to it sometimes. Try “nslookup” against all the ones you have access to and see what they return.

johnpoz

I would concur with @SteveITS - part of the reason you don't point clients to more than 1 name server, unless both will return the same results.

You never know what name server a client will use when you list more than 1.. So if you point to more than 1 they should return the same results.

If you have client that points to say public dns, and a local ns (that resolves your fqdn to rfc1918).. Your client might sometimes get the public IP and hit your pfsense wan IP, which yup would return such an error if hitting its gui port.

But sometimes it might resolve the local IP and directly access your local server by its rfc1918 IP.

If you are using split dns and resolving some fqdn locally to rfc1918, then your client should only have a local dns set so it never resolves the public IP.

If you are going to resolve to public IP of this fqdn, and hit your pfsense wan IP to be reflected back in - then you need to correctly setup nat reflection and need to make sure the web gui is not listening on the port as well.. If your wanting to use 443 for this fqdn, then make sure you change pfsense https port to something different. I use 8443 for example for pfsense https port.

alfredino

@johnpoz said in Potential DNS Rebind attack: how to solve:

@alfredino what is the fqdn you are using? And what does it resolve to - is it suppose to resolve to a public IP or a private IP?

what is this fqdn? Send it to me via DM if you don't want to post it public.. And I can check what it resolves to on the enternet..

Unfortunately, I cannot share the FQDN. However, I can provided you the following diagram:
From any external network and from the internal network + VPN: myhost.example.com->public IP provided by ISP1
From the internal network (LAN+WLAN): myhost.example.com->private IP provided by ISP1

Network diagram.jpeg

alfredino

@SteveITS said in Potential DNS Rebind attack: how to solve:

I expect you are experiencing different answers from different DNS servers. pfSense isn’t randomly changing it’s behavior, you’re only connecting to it sometimes. Try “nslookup” against all the ones you have access to and see what they return.

Exactly. I already tried nslookup. DNS resolution from the internal network is correct (private IP) when there is no problem, but incorrect when the rebind attack error occurs (public IP). I cannot understand what causes the change. It seems that DNS resolution occurs via the ISP DNS server and, at certain times, via another DNS server that returns the wrong IP (public one).