Need to convene the brain trust on DNS rebinding issue
-
@sensewolf so you have this?
where is the rebind happening exactly?
Where it resolves server2.example.com to your public IP.. I don't see how why that would cause a rebind. I do that in a sense when I access my service being hosted to public via haproxy from my PC on the same lan. I don't see how that would be a rebind.
What would be a rebind if you went to server2 and hit the web gui, and the pfsense name was not server2.example.com
-
@johnpoz
Yes, that is my setup.About the rebind:
From time to time I, when I reconnect to the pfSense web gui from my local PC after a while, (I can't say exactly what the situation is) I get a red warning screen about a possible DNS rebinding attack that pfSense prevented.
When server1 tries to connect to server2.example.com, the connection times out, but if it connects to 192.168.1.2 it gets through. So I assumed this was because of the rebind protection (but as I said in my OP, it does not fit exactly the description in the docs because in my case pfSense would have to filter out my public IP addresse because this is what the DNS would serve, if I understand it correctly).
So it is my working hypothesis that my problem is with the DNS rebinding attack protection. But I can't be any more specific because this is the extent of my understanding so far...
-
@sensewolf there is nothing wrong with that setup.
You would get a rebind if you try and access the webgui with a name that is not pfsense.
So example. If I hit a fqdn that resolves my public IP, that haproxy is not set to forward to a backend.. That is a rebind.
The fqdn I hit resolves to my public IP, and I put the port the gui listens on it - pfsense says hey wait a min here.. That is not my name! Attempt at a rebind.
If I hit a fqdn that haproxy forwards.. I get my service.
If I had to "guess" your hitting your some fqdn that is not actually configured for haproxy to forward, and your hitting the gui. Or haproxy just errored or crashed or whatever and is not forwarding it.. So your being served pfsense gui - with that different name, ie rebind.
edit: so your guessing its a rebind? When really its just haproxy wasn't able to forward you to your service (ie timeout).
edit2: If you forward or resolve something externally that returns a rfc1918, that would be a rebind. If you attempt to hit pfsense gui via a fqdn that it doesn't know is its - that would be a rebind. Be it a public IP or a rfc1918 IP.
Trying to hit a fqdn that resolves to your public IP that is suppose to be forwarded by haproxy and you get a timeout. That just points to something wrong with haproxy, or your backend. Not really a rebind.
-
hmm
HAProxy is not configured to forward mail.example.com -- that is true. But mail.example.com points to example.com and I do forward (i.a.) port 587 to my mail server. And from outside my network I (or rather my email client) can connect to mail.example.com.
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
HAProxy is not configured to forward mail.example.com
Well if a client on your own network tries to go mail.example.com that resolves to your public IP, and you don't have haproxy setup to forward it, but you have a normal port forward setup for port 587 that could work externally.
But internally no that wouldn't work - for that to work you would need to setup nat reflection. Or internally your client would need to resolve mail.example.com to your local IP directly. Or you would need to setup haproxy to do the ssl offload for that fqdn and port.
If you don't have a cert setup on your mail server, you wouldn't be using tls with 587, unless the mail server was using some selfsigned cert, etc.
edit: A rebind happens when pfsense dns (unbound or dnsmasq) asks another dns for some fqdn either say forwarding to some ns 8.8.8.8 for example, or actually resolves the fqdn (unbound) and the answer is rfc1918. That is a rebind and would not actually be handed back to the client.
Or when you attempt to hit pfsense IP (webgui) via a fqdn that is not pfsense name, be that pfsense wan IP (public) or some local IP (lan IP)..
From what your saying I do not think your actually hitting a rebind issue.
-
Yes, so currently, I have -- what I believe to be called -- split DNS: I configured a host override in the pfSense DNS resolver that directs mail.example.com to 192.168.1.2
And I have copied over the LE certificate to mail server so that it has a certificate to present to its peers. (But this certificate is only relevant once the connection is established in the first place. Without it, I expect I would be getting an error about a missing certificate, not a timeout.)
And my pfSense DNS resolver would (but for the override) resolve to an rfc1918 address, would it not? The way you describe it, it does sound to me like it is a rebind after all.
Well, I guess that now brings us to my initial question: what is the best way to deal with this issue?
I did try b) in the meantime but it doesn't help. So I guess that leaves d) Are there any risks with this that I should be aware of?
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
And my pfSense DNS resolver would (but for the override) resolve to an rfc1918 address, would it not?
Mail.example.com (public) wouldn't resolve to rfc1918 unless you put that into the public record.
A host override pointing to rfc1918 is not a rebind. Because you resolved it locally - you didn't ask some other NS for that record.
The best solution is always split dns.. The only time that nat reflection makes sense is if you are forced to use a hard coded IP that is your public wan IP. Or your forced by the client to use some external dns that resolves your fqdn to your public.
There is little reason to ever bounce off pfsense to access something that is local unless that is the only way you can get it to work.
Public can resolve something.publicdomain.tld - so when your out and about you hit your pfsense wan. But if your local, why would you want to bounce off pfsense to just hit something that is local. So just resolve something.publicdomain.tld to your local IP via a host override. That is not a rebind concern.
it does sound to me like it is a rebind after all.
How is that - I gave you the 2 scenarios that are rebind.. None of which seem to match your scenario.. Your not accessing the gui with a different name than what it thinks is its name. And your not resolving a public fqdn externally that returns a rfc1918.. If I ask say 8.8.8.8 for mail.example.com does it return rfc1918 address? 10.x.x.x, 172.16-31.x.x or 192.168.x.x ?? If that was the case it would never work when your out and about outside your own network.
A rebind is not if you ask unbound running on pfsense for mail.example.com and it says - oh I have a local record here (host override) for that 192.168.1.1 - that is not a rebind. A rebind is if you ask some external name server via forwarding to it, or resolving directly and get back a rfc1918..
Or you ask for something.whatever.tld and end up on the pfsense gui, when pfsense knows its name is pfsense.somethingelse.tld - its says wait a minute.. How did you end up here, that is not my name - must be a rebind attempt.
-
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
A rebind happens when pfsense dns (unbound or dnsmasq) asks another dns for some fqdn either say forwarding to some ns 8.8.8.8 for example, or actually resolves the fqdn (unbound) and the answer is rfc1918. That is a rebind and would not actually be handed back to the client.
Okay, apparently my understanding of how this works is still lacking: When mail.example.com points to example.com then pfSense should resolve mail.example.com to my public IP, right? (just did an nslookup from my PC and that's what happens.) And you are saying that is not a rebind yet that pfSense prevents. Okay.
But does it not further resolve from my public IP to my internal rfc1918 addresse? I was assuming that this is the rebind that pfSense prevents. Because this step does not seem to work. With the host override I am just filling in the gap. If I remove the override, the connection request just times out.
So what does cause the timeout then, if it is not a rebind issue prevented (I am happy to accept that it is not but I have no other theory what it could be)? And it should not have to do with HAProxy, because the connection does not go through HAProxy but just through port forwarding.
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
But does it not further resolve from my public IP to my internal rfc1918 addresse?
Did it ask a public name server for that?? If not then it is not a rebind.. You created a local host override for it.. That is not asking some other NS - so it is NOT a rebind.
If you resolve mail.example.com to some local IP 192.168.1.100 for example and you get a timeout.. Then that has nothing to do with pfsense, because has nothing to do with client 192.168.1.99 talking to 192.168.1.100
Pfsense is only involved in conversations between a client and some IP that is not local, ie local client to the internet, or if client 192.168.1.99 wants to talk to another network say 192.168.2/24 that is routed through pfsense.
If client A is talking to client B on the same network - pfsense has nothing to do with that conversation..
-
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
Did it ask a public name server for that?? If not then it is not a rebind.. You created a local host override for it.. That is not asking some other NS - so it is NOT a rebind.
Understood. A rebind is only when the information comes from a public DNS server, not from a local DNS resolver. Got it.
I just want to emphasize that yes, I did create a host override but I only created that because otherwise server1 cannot connect to server2.example.com (it can connect to 192.168.1.2). I am not saying that the host override is a rebind, what I am saying is that the host override is just a means to achieve that server1 receives the information that it can contact server2 at 192.168.1.2. pfSense DNS resolver does not seem to deliver this info without the host override.
And that is how I came to believe that I am having a rebind issue. It has to have something to do with differences between my local network and some other public network (because from there it does work). And the name resolution would be an explanation.
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
If you resolve mail.example.com to some local IP 192.168.1.100 for example and you get a timeout.. Then that has nothing to do with pfsense, because has nothing to do with client 192.168.1.99 talking to 192.168.1.100
Okay, but pfSense (DNS resolver) is the one responsible for telling server1 that server2.example.com can be reached at 192.168.1.2. And it fails to do so - for whatever reason - unless I override the host. Once server1 knows where to reach server2, pfSense is out of the picture but until then, it is (or it should be) very much involved (I think).
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
A rebind is only when the information comes from a public DNS server, not from a local DNS resolver. Got it.
Not exactly... If you created a domain override to some other local name server, that would also be considered a rebind if rfc1918 came back.. Because unbound didn't get the info from itself. When you do something like that - you have to tell unbound hey, that is ok to get back a rfc1918 address via the private domain setting in unbound.
Once server1 knows where to reach server2, pfSense is out of the picture but until then, it is (or it should be) very much involved (I think).
Why would you think pfsense should be involved. If 192.168.1.99 is talking to 192.168.1.100, pfsense has nothing to do with that.. A client says oh 192.168.1.100 is on my network 192.168.1/24 - I will arp for it, and then send my traffic to that mac address.
The only time pfsense is involved is when either its the IP the client wants to talk to.. Or the IP is not local network of the client. If say 192.168.1.99 wanted to talk to 8.8.8.8... It would say oh that is not on my 192.168.1/24 network - need to send that to my gateway (pfsense). Ah that IP is 192.168.1.1 for example... Let me arp for 192.168.1.1, ah there is the mac of my gateway. Send the traffic to that mac address with destination IP of 8.8.8.8.. Pfsense being a router says oh you want to go to 8.8.8.8, let me route that for you - and would send it to its gateway, or to some other gateway via its routing table, or if that destination IP is on a network connected to pfsense... It would say oh, Im connected to that network, let me arp for that destination IP on that network - and then send that traffic to that mac address.
Sure pfsense might be involved in resolving some fqdn to the IP, but once it hands the actual IP of that fqdn to the client that asked - it has nothing more to do with that client talking to the other IP on the clients network.
-
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
Sure pfsense might be involved in resolving some fqdn to the IP, but once it hands the actual IP of that fqdn to the client that asked - it has nothing more to do with that client talking to the other IP on the clients network.
Yes, we agree on this.
But that is my point: pfSense does not resolve the FQDN to the IP in the first place - unless I override the host. And I believe the solution to my question is: Why does it not resolve the FQDN?
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
If you created a domain override to some other local name server, that would also be considered a rebind if rfc1918 came back.. Because unbound didn't get the info from itself. When you do something like that - you have to tell unbound hey, that is ok to get back a rfc1918 address via the private domain setting in unbound.
Okay, but I did not create an override to some other local name server, I just override the host with its local IP (and I only do that because pfSense otherwise won't resolve the FQDN).
And I did try registering the domain as private domain in unbound. But it does not make a difference.
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
And I did try registering the domain as private domain in unbound. But it does not make a difference.
Well, I guess that is another argument against the rebind theory -- because the private domain exception should cure a rebind protection problem, right?
But what the heck is left then?
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
And I did try registering the domain as private domain in unbound. But it does not make a difference.
Well no it wouldn't - because that has nothing to do with anything. If you create a host override for the fqdn your wanting to resolve to a local IP.
But what the heck is left then?
You server not answering... So lets go over this yet again..
You resolve something mail.example.com to 192.168.1.100 for example.. And your trying to talk to it from 192.168.1.99..
Pfsense is NOT involved in the other than resolving mail.example.com to 192.168.1.100.. So look to your .100 box or VM or whatever it is to why you can not talk to it. Sniff on .99 do you see it sending traffic.. Sniff on .100 does it see the traffic - pfsense is not involved in this converation once it has hand client the IP via dns query.
-
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
Well no it wouldn't - because that has nothing to do with anything.
Sorry, I still don't get it...
The pfSense docs state:
Individual domains can be excluded from DNS rebinding protection using the Custom Options box in the DNS resolver settings.I thought that means that if I exclude a domain from DNS rebinding protection, pfSense will allow a DNS rebind that relates to such domain.
And the conclusion I drew was that if I exclude my domain from DNS rebinding protection but the problem persists, then my problem might not be a rebinding problem after all (as you suggested).
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
You server not answering... So lets go over this yet again..
You resolve something mail.example.com to 192.168.1.100 for example.. And your trying to talk to it from 192.168.1.99..
Pfsense is NOT involved in the other than resolving mail.example.com to 192.168.1.100.. So look to your .100 box or VM or whatever it is to why you can not talk to it. Sniff on .99 do you see it sending traffic.. Sniff on .100 does it see the traffic - pfsense is not involved in this converation once it has hand client the IP via dns query.Right, so in my view the issue is that pfSense does not tell server1 under which local IP it can reach server2.
Server2 is happy to talk to server1, if server1 connects directly to server2's IP (that is when I tell server1 to connect to the IP rather than to the FQDN). And server2 is also happy to talk to whomever, if they connect from the outside world (via server2's FQDN).
The only situation in which server2 won't respond is when server1 tries to connect to server2.example.com. And this is when pfSense should tell server1 where it can find server2 but doesn't.
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
Individual domains can be excluded from DNS rebinding protection using the Custom Options box in the DNS resolver settings.
I not sure how I can make this more clear.. That is ONLY required if unbound or dnsmasq is going to ask some other Name server. If the record is local, IE a host override you do not need to set that domain to allow for rfc1918..
On your client if you do a nslookup or dig for your host override - do you get the answer you want.. 192.168.1.100?
Here I created a host override for zzz.testdomain.tld
Pfsense now has nothing to do with 192.168.1.99 now wanting to talk to 192.168.1.100
It resolved it to the IP I set in my host override.. What .99 does trying talk to .100 has ZERO to do with pfsense ZERO!!
If your having issues talking to 192.168.1.100 from 192.168.1.99 PFSENSE is not the reason. Period - done, end of story Pfsense is not involved with devices on the same network talking to each other.. If what you resolve is not resolving, then you have something wrong with your host override, or your client not actually asking pfsense for dns.
But once pfsense resolve the fqdn to the IP you want it to resolve too - and its on the same network as the client, pfsense is not involved in the any conversations they might have between themselves. Pfense is the router to get OFF a network.. it has nothing to do with devices on the same network from talking to each other.
So unless you have setup a bridge in pfsense, and .99 is on 1 side of the bridge and .100 is on other side of this bridge you setup in pfsense... Pfsense would never even see this traffic between them.
-
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
I not sure how I can make this more clear.. That is ONLY required if unbound or dnsmasq is going to ask some other Name server. If the record is local, IE a host override you do not need to set that domain to allow for rfc1918..
Oh, now I get where the confusion is: I did try the private domain exception without the host override, of course. And it didn't help.
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
On your client if you do a nslookup or dig for your host override - do you get the answer you want.. 192.168.1.100?
When I override the host, I get the local IP, when I don't override the host I get the public IP.
@johnpoz said in Need to convene the brain trust on DNS rebinding issue:
It resolved it to the IP I set in my host override.. What .99 does trying talk to .100 has ZERO to do with pfsense ZERO!!
Yes, I absolutely agree. That is totally clear and has been from the start.
What I am saying is that pfSense should tell server1 server2's private IP when server1 looks for server2.example.com. But pfSense doesn't. And that's why server1 can't talk to server2. Because server1 doesn't find server2 under server2's FQDN.
When I tell server1 server2's private IP, server1 can connect to server2 without issues.
So how can this not be pfSense's doing?
-
Anyone who has had this issue and resolved it successfully?
I have come across so many instances in other forums where this has become a problem with one service or another - there has to be a solution...
Unfortunately, designating the domain private in the DNS resolver has not helped. From what I understand it should, but it doesn't.
So the last resort would be to disable pfSense's DNS rebinding check. But I am reluctant to do that.
So if anyone has another solution...?
Thanks
-
@sensewolf said in Need to convene the brain trust on DNS rebinding issue:
What I am saying is that pfSense should tell server1 server2's private IP when server1 looks for server2.example.com. But pfSense doesn't.
Huh??
If you setup a host override for server2, any client that asks pfsense would get that response..
As already stated if your unbound is getting that address from some other NS, and its rfc1918 then it would be a rebind.. You can set the domain example.com to be set as private, and then it would hand the client the rfc1918 just fine..
example of this plex uses a special fqdn to find the IPs of your server, be it public address and its local rfc1918 address..
So you set this domain as private in unbound custom option box
private-domain: "plex.direct"And now it can find the rfc1918 address. That it got from public NSers out on the internet
