DNS rebind protection not working
I am running pfSense 2.3.4-RELEASE-p1 (i386) on a relatively uncomplicated setup, multi-LAN / single-WAN to a cable modem, and running Unbound as DNS resolver. It seems that my setup does not block DNS rebind attacks, meaning that I can successfully resolve DNS entries that contain RFC1918 addresses.
Tested from my Windows machine:
I have confirmed the same above results with pfSense command prompt.
pfSense DHCP server is configured so all adapters point DNS towards it, and I have confirmed that my Win machine only points to pfSense for DNS.
from System/Advanced/Admin Access I have confirmed:
Disable DNS Rebinding Checks = off
Just to make sure I have even toggled it on and off and restarted the service.
FYI, other DNS settings are as follows:
Enable DNSSEC Support = on
Enable Forwarding Mode = off
Register DHCP leases in the DNS Resolver = on
Register DHCP static mappings in the DNS Resolver = on
Any insight into how I can protect this system would be appreciated.
I dug through the forums before posting but most of the complaints about DNS rebinding has to do with how to turn off false alarms.
virgiliomi last edited by virgiliomi
SO... interesting thing here...
I found this doing a DNS lookup through the pfSense webgui... the IPv4 result being returned is blocked... but there is also an IPv6 version of the IPv4 address that isn't being blocked. Many regular DNS clients will show the IPv6 result here as the IPv4 address, but it shows as a AAAA record in the lookup details through pfSense.
The unbound.conf man page shows in the private-address section that blocking ::ffff:0:0/96 would block the IPv6 representation of IPv4 addresses... though you could get more granular to just block the specific IPv4 blocks in their IPv6 representations (there may be legitimate instances where using an IPv6 version of an IPv4 address might be necessary). These ranges would be...
- ::ffff:a00:0/104 (aka 10.0.0.0/8)
- ::ffff:a9fe:0/112 (aka 169.254.0.0/16)
- ::ffff:ac10:0/108 (aka 172.16.0.0/12)
- ::ffff:c0a8:0/112 (aka 192.168.0.0/16)
Maybe to fully ensure rebinding protection is effective, these should be added to the unbound config as well?
Edit to add: I added those through the custom options box for Unbound and it's now failing to return results for the rebind test hostnames.
I see "access-control: <IP netblock> <action>" in the documentation for unbound, but that says "The action deny stops queries from hosts from that netblock." Which isn't really what we are looking for since we want to strip those IP ranges from the responses rather than block queries.
Can you tell me what exactly you added to the unbound custom options box in order to set this up?
virgiliomi last edited by virgiliomi
The private-address option is what you want to use. With it, you can specify IP address ranges that should be considered private, and Unbound will strip the address from any result that might otherwise return it.
Here's what I added to the custom options...
server: private-address: ::ffff:a00:0/104 private-address: ::ffff:a9fe:0/112 private-address: ::ffff:ac10:0/108 private-address: ::ffff:c0a8:0/112
If you already have a
server:line for other options, you can omit that... otherwise, this should do the job. The IPv4 blocks are all using the same option.
Also created bug 8750 in Redmine for this.
Confirmed that this fix is working.
I just went to the web interface and put this into custom options:
I updated the redmine link with this thread.. Should be an easy fix.. And your work around should be fine.. Have added it to my options as well and set the redmine to watched.
Looks like already got a fix out
virgiliomi last edited by