DNS rebind protection not working

cw

Hi.

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:

nslookup net192.rebindtest.com
Name: net192.rebindtest.com
Address: 192.168.0.1

nslookup net4.rebindtest.com (this should work)
Name: net4.rebindtest.com
Addresses: 4.4.4.4
4.4.4.4

nslookup net127.rebindtest.com
Addresses: 127.0.0.1
127.0.0.1

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.

TIA.
!cw

MikeV7896

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.

cw

@virgiliomi said in DNS rebind protection not working:

::ffff:c0a8:0/112

Good work!

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?

Thanks

MikeV7896

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.

cw

Confirmed that this fix is working.

I just went to the web interface and put this into 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

johnpoz

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.

johnpoz

Looks like already got a fix out
https://redmine.pfsense.org/issues/8750#change-37534

MikeV7896

Thanks @jimp!

war59312

I noticed this myself, thanks for work-around until officially fixed.

Just got my Netgate SG-3100 today.

Sadly not working for me though.

On Services > DNS Forwarder, "General DNS Forwarder Options" page "services_dnsmasq.php", under "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

Save button and get:

The following input errors were detected:

Invalid custom options

Log page @ status_logs.php?logfile=resolver, shows:

Aug 29 23:03:46	dnsmasq	10949	bad command line options: try --help
Aug 29 23:03:46	dnsmasq	10949	FAILED to start up

johnpoz

Those options are for using the resolver (unbound) which is default - not the forwarder dnsmasq..

war59312

@johnpoz Thanks for that. Success. :)