DNS query to RBL blacklists return no answer



  • Hello everyone.
    After update from 2.4.2 to 2.4.5 query to RBL dns blacklists return no answer.

    I use dns resolver (unbound) with enable forwarding mode query to Google public dns servers (pfsense local ip 192.168.100.2.).

    Testing query on local server machine (dns resolver set to pfsense).

    dig 2.0.0.127.b.barracudacentral.org         
    
    ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> 2.0.0.127.b.barracudacentral.org
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;2.0.0.127.b.barracudacentral.org. IN	A
    
    ;; Query time: 44 msec
    ;; SERVER: 192.168.100.2#53(192.168.100.2)
    ;; WHEN: Sat Apr 18 11:32:37 CEST 2020
    ;; MSG SIZE  rcvd: 61
    

    result dns query direct to google

    dig @8.8.8.8 2.0.0.127.b.barracudacentral.org
    
    ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @8.8.8.8 2.0.0.127.b.barracudacentral.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32216
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;2.0.0.127.b.barracudacentral.org. IN	A
    
    ;; ANSWER SECTION:
    2.0.0.127.b.barracudacentral.org. 22 IN	A	127.0.0.2
    
    ;; Query time: 21 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Sat Apr 18 11:32:43 CEST 2020
    ;; MSG SIZE  rcvd: 77
    

    result with disabled forwarding mode in pfsense

    dig 2.0.0.127.b.barracudacentral.org         
    
    ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> 2.0.0.127.b.barracudacentral.org
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40069
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;2.0.0.127.b.barracudacentral.org. IN	A
    
    ;; AUTHORITY SECTION:
    b.barracudacentral.org.	900	IN	NS	blacklist-ns-az2.bci.aws.cudaops.com.
    b.barracudacentral.org.	900	IN	NS	blacklist-ns-az3.bci.aws.cudaops.com.
    b.barracudacentral.org.	900	IN	NS	blacklist-ns-az1.bci.aws.cudaops.com.
    
    ;; Query time: 450 msec
    ;; SERVER: 192.168.100.2#53(192.168.100.2)
    ;; WHEN: Sat Apr 18 11:01:13 CEST 2020
    ;; MSG SIZE  rcvd: 173
    

    Any advice? Thanks!



  • Hi Milan,

    I'm having the same problem, did you find a way to resolve this?



  • Hi,
    I did not find... Unbound has a issue with resolving rDNS. So far I use dns forwarder (dnsmasq).



  • @Milan Thanks for the response. Do you also have issues with TXT records?



  • 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.



  • 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.



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



  • @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





  • 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.



  • @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?



  • 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/



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



  • @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.)



  • @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.



  • @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)



  • @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



  • 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



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



  • @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.



  • 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



  • @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?


  • Rebel Alliance Developer Netgate

    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.



  • @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?


Log in to reply