DNS query to RBL blacklists return no answer

digdug3

Turned off pfBlockerNG, all non-default settings still the same problem, also when enabling DNS Query Forwarding to 8.8.8.8 or 9.9.9.9

A direct dig to 9.9.9.9 gives an answer

dig @9.9.9.9 81.173.198.114.b.barracudacentral.org

; <<>> DiG 9.14.12 <<>> @9.9.9.9 81.173.198.114.b.barracudacentral.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28686
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.173.198.114.b.barracudacentral.org. IN A

;; ANSWER SECTION:
81.173.198.114.b.barracudacentral.org. 900 IN A 127.0.0.2

;; Query time: 217 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Jul 01 17:36:06 CEST 2020
;; MSG SIZE  rcvd: 82

and v2.4.5-1 Unbound (no answer):

dig @127.0.0.1 81.173.198.114.b.barracudacentral.org

; <<>> DiG 9.14.12 <<>> @127.0.0.1 81.173.198.114.b.barracudacentral.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12449
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.173.198.114.b.barracudacentral.org. IN A

;; AUTHORITY SECTION:
b.barracudacentral.org. 777     IN      NS      blacklist-ns-az1.bci.aws.cudaops.com.
b.barracudacentral.org. 777     IN      NS      blacklist-ns-az2.bci.aws.cudaops.com.
b.barracudacentral.org. 777     IN      NS      blacklist-ns-az3.bci.aws.cudaops.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 01 17:36:19 CEST 2020
;; MSG SIZE  rcvd: 178

This looks like a bug.

digdug3

Ok, fixed it.

Looks like pfSense 2.4.5-p1 now sets the DNS Rebinding Attack in the Unbound config.
This will remove any IP address with 127.0.0.0/8 responses (RBL's).

Go to System -> Advanced and check "Disable DNS Rebinding checks"

Then go to Services -> DNS Resolver and if you still want some protection click "Display Custom Options" and add:

private-address: 127.0.0.1/32
private-address: 10.0.0.0/8
private-address: ::ffff:a00:0/104
private-address: 172.16.0.0/12
private-address: ::ffff:ac10:0/108
private-address: 169.254.0.0/16
private-address: ::ffff:a9fe:0/112
private-address: 192.168.0.0/16
private-address: ::ffff:c0a8:0/112
private-address: fd00::/8
private-address: fe80::/10

Maybe someone else has a better approach. If not then it would be nice if there was an option to disable the private-address "127.0.0.0/8" from this DNS-Rebinding check list.
Edit: Fixed typo in version and added 127.0.0.1/32 I have not seen that address being used by any RBL response.

netblues

@digdug3 Yes, this fixes the issue. However is a workaround. A proper bug report should be filed. Well done

digdug3

@Milan you can file a bug report at https://redmine.pfsense.org/projects/pfsense/issues and refer to this page.
@netblues It's not 100% a bug, when you want to proper block DNS Rebinding Attacks, 127.0.0.0/8 should also be in the list according to https://en.wikipedia.org/wiki/DNS_rebinding

serbus

Hello!

https://redmine.pfsense.org/issues/10685

John

netblues

Well, the workaround suggests to put specific sites to allow 127.0.0.0/8 replies.
Since dns rbl blacklists are used exclusively by mail servers, often it falls under quite different administrative domains, and in most cases it will either pass undetected, or public dns's would be configured as a workaround.

On the other hand, dnsrbl tend to use various servers, and keeping that in sync with pf allow settings is an issue.
How about an rbl exclude based on client ip? (and only for 127.0.0.0/8 replies)?
As a setting in advanced pf configuration.

digdug3

@serbus Thank you for the info, did not see that bug report before. But adding an extending/changing list of rbl servers to the allow list is not user friendly. We user multiple rbl lists to check against.
Removing 127.0.0.0/8 like in previous versions of pfSense is in my option a better approach. I already added only 127.0.0.1 as that could be the best between the recent changes. Also if we want to be "complete" ::1 should also be listed (and is not in the current default of pfSense).
@netblues I will have to dig deeper into Unbound's configuration options. Excluding on client ip could be another option and better approach. Another question of course is do you really need the full 127.0.0.0/8 blocked or only 127.0.0.1/32?

biggsy

May not be applicable here but probably worth noting that Spamhaus (and possibly others) block RBL queries from open public DNS servers run by the likes of Google, Cloudflare and IBM. https://www.spamhaus.org/returnc/pub/

netblues

@digdug3 Unfortunately 127.0.0.0/8 is needed.
see here for details
https://www.spamhaus.org/faq/section/Spamhaus%20DBL#291

netblues

@biggsy said in DNS query to RBL blacklists return no answer:

May not be applicable here but probably worth noting that Spamhaus (and possibly others) block RBL queries from open public DNS servers run by the likes of Google, Cloudflare and IBM. https://www.spamhaus.org/returnc/pub/

Well, its not that they block it, they just rate limit it. (which leads to the same effect)
In order to utilize any dnsbl practically means to use your own dns quering root servers.
Anything else tends to be problematic.
(thus the need to have pfsense do the job.)

biggsy

@netblues
I don't think "rate limit" really describes it. In the link provided:
"Spamhaus does not permit queries from such public DNS resolvers."

If you have pfSense use those public resolvers, on behalf of your mail server, you risk getting a 127.255.255.254 response. Better to have your mail server run its own resolver.

netblues

@biggsy I was referring to others too, but anyways, the problem remains the same
No forwarders can be used for dnsbl lookups in practice.

From a security point of view its better to have pf do the lookups instead of allowing outbound dns lookups to root servers for the mailserver.

Pushing this to the limit, forwarders for speedier responses and root server lookups for dnsbl is the best. (as a feature)

digdug3

@jimp Accoring to the bugrequest #10685 at redmine (https://redmine.pfsense.org/issues/10685) pfSense should only block 127.0.0.1 when "DNS Rebinding" is enabled, but now it blocks the whole 127.0.0.0/8 subnet

" Status changed from New to Not a Bug

This is due to the change in #9708 on 2.4.5 -- 127.0.0.1 is considered a private result now so you will need to tell the DNS Resolver it's OK to receive private address results from that domain.

https://docs.netgate.com/pfsense/en/latest/dns/dns-rebinding-protections.html#dns-resolver-unbound

If you still have issues, post on the forum."

This blocks resolving of dns blacklists. Is this a bug? See: https://forum.netgate.com/topic/152671/dns-query-to-rbl-blacklists-return-no-answer/16

serbus

Hello!

You should be able to edit unbound.inc and either modify or remove the :

private-address: 127.0.0.0/8

line.

You would good until the next reinstall or upgrade.

John

digdug3

Next upgrade that file will probably be overwritten and I think it should/could be:
private-address: 127.0.0.1/32

netblues

@digdug3 And all these

What do the 127...* Return Codes mean?
Spamhaus uses this general convention for return codes:

Return Code Description
127.0.0.0/24 Spamhaus IP Blocklists
127.0.1.0/24 Spamhaus Domain Blocklists
127.0.2.0/24 Spamhaus Zero Reputation Domains list
127.255.255.0/24 ERRORS (not implying a "listed" response)

Currently used return codes for Spamhaus public IP zones:

Return Code Zone Description
127.0.0.2 SBL Spamhaus SBL Data
127.0.0.3 SBL Spamhaus SBL CSS Data
127.0.0.4 XBL CBL Data
127.0.0.9 SBL Spamhaus DROP/EDROP Data (in addition to 127.0.0.2, since 01-Jun-2016)
127.0.0.10 PBL ISP Maintained
127.0.0.11 PBL Spamhaus Maintained

127.0.0.5-7 are allocated to XBL for possible future use; 127.0.0.8 is allocated to SBL for possible future use.

serbus

Hello!

You could convert the redmine issue into a feature request and ask that the gui provide more granular control in the nodnsrebindcheck option, such as the ability to exclude or modify some ranges.

It is interesting to see how our "friends" are approaching this...

https://github.com/opnsense/core/issues/3692

John

digdug3

@netblues Yes, exactly, and 127.0.0.1/32 (only localhost) isn't used. Even if they say "127.0.0.0/24".

If I check an IP-address at http://multirbl.valli.org/ (many blocklists). Also a return code of 127.0.0.1 isn't used by any blocklist.

DNS Rebinding attacks use local addresses, that's why Unbound blocks private IPv4 addresses (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16). Anything other then 127.0.0.1 (localhost) isn't normally used.

@serbus I think you are right, it should be a "feature". Could you change the report to a feature request?

jimp

Any address in 127/8 is loopback. Yes, 127.0.0.1 is the most common to find on a workstation but there may be others as well, anywhere in that range.

Only doing rebind protection for 127.0.0.1/32 is a bit of a dangerous/insecure assumption.

digdug3

@jimp said in DNS query to RBL blacklists return no answer:

Any address in 127/8 is loopback. Yes, 127.0.0.1 is the most common to find on a workstation but there may be others as well, anywhere in that range.

Only doing rebind protection for 127.0.0.1/32 is a bit of a dangerous/insecure assumption.

Thank you @jimp for the response. Is it possible to allow these 127.0.0.1/24 responses for one ip on the LAN and block it for all others?