RPZ PASSTRUE not reconnized

Question

RPZ PASSTRUE not reconnized

spirillen opened this issue a month ago · comments

Describe the bug
First of, this is 100% related to this comment #935 (comment)

To reproduce
Steps to reproduce the behaviour:

add a number of rpz zones/rules
in one zone you hold your own local rules, not imported from third party
You would expect your own rules to supersede any other rules that might be imported.
dig any PASSTRU record and receive NXDOMAIN

Expected behaviour
RPZ PASTHRU supersedes other rules, or having a weight system for the individual zones, whereof weight of null/zero/0 are weighting the highest as 0 comes first in line of the IT universe.

System:

Unbound version:
OS: Debian 12.6

/usr/sbin/unbound -V output:

Version 1.17.1

Configure line: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --enable-tfo-server
  Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.13 30 Jan 2024
  Linked modules: dns64 python subnetcache respip validator iterator
 TCP Fastopen feature available

 BSD licensed, see LICENSE in source package for details.
 Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

Additional information
Parsed from #395

I actually have a similar situation where is seems like any "Blocking" rule super seeds "permissive" rules like the passtrhu.

There can be a numerous good arguments for why this is, however, in my case I maintenance a local rpz zone that differs from my projects records *.mypdns.cloud", in my local RPZ zone I have a number of paastru` records for e.g. GitHub like these

avatars.githubusercontent.com.blacklist.matrix.lan,CNAME,rpz-passthru
private-user-images.githubusercontent.com.blacklist.matrix.lan,CNAME,rpz-passthru

Whereas the @matrix project have the following records

raw.githubusercontent.com.whitelist.mypdns.cloud,CNAME,rpz-passthru
*.githubusercontent.com.malicious.mypdns.cloud,CNAME,.
*.githubusercontent.com.tracking.mypdns.cloud,CNAME,.

Expected behaviour is to get the PASSTRUE = the IP for both avatars- private-user-images.githubusercontent.com

While the log for sure show what actually happens.

Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: 127.0.0.1 avatars.githubusercontent.com. A IN
Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: rpz: applied [malicious policy] *.githubusercontent.com. rpz-nxdomain 127.0.0.1@36385 avatars.githubusercontent.com. A IN
Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: 127.0.0.1 avatars.githubusercontent.com. A IN NXDOMAIN 0.000000 1 58

The question is now, how can the expected output be accommodated by using the RPZ standard rules? is this a request for a weight system, from where a list with the weight of 0 supersedes other lists? (As Zero is the first number in the IT universe and stays first in line)

Yorgos Thessalonikefs · Answer 1 · Wed Jul 24 2024 06:13:14 GMT+0800 (China Standard Time)

If I understand correctly you are using different rpz: clauses in the Unbound configuration.
Then the order of those matters. You should define your local policy first. From a quick test here it seems to work as you would like it to.

spirillen · Answer 2 · Wed Jul 24 2024 16:40:56 GMT+0800 (China Standard Time)

Hi @gthess I did test it with the logic of orders matters, As I used to from powerdns, however, as I recall it, I didn't get the spectated results. In the following conf you can see this reflected, in this case in reversed order for testing. moving blacklist.matrix.lan.rpz didn't give me the more permissive or tightened rules like blacklisting all asocial domains like *.google and fbcn.com

rpz:
  name: 'rpz.sslbl.abuse.ch'
  zonefile: '/var/lib/unbound/zones/rpz.sslbl.abuse.ch.zone'
  allow-notify: 0.0.0.0/0
  master:	54.36.110.62
  # url: https://sslbl.abuse.ch/blacklist/sslbl.rpz
  # url: https://www.mypdns.org/abuse_ch/sslbl.rpz
  # rpz-action-override: cname
  # rpz-cname-override: rpz.sslbl.abuse.ch
  rpz-log: yes
  rpz-log-name: 'sslbl.abuse.ch policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes
  # tags: 'sslbl_abuse_ch'

rpz:
  name: 'urlhaus.rpz'
  zonefile: '/var/lib/unbound/zones/urlhaus.rpz.zone'
  allow-notify: 0.0.0.0/0
  master:	54.36.110.62
  # url: https://www.mypdns.org/urlhaus_abuse_ch/index.html
  # url: https://urlhaus.abuse.ch/downloads/rpz/
  rpz-log: yes
  rpz-log-name: 'urlhaus policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'adult.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/adult.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'adult policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes
  rpz-action-override: disabled

rpz:
  name:	'adware.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/adware.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'adware policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'coinblocker.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/coinblocker.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'coinblocker policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'coinblocker.srv'
  zonefile: '/var/lib/unbound/zones/coinblocker.srv.zone'
  allow-notify: 0.0.0.0/0
  master:	54.36.110.62
  master: 35.156.219.71@53
  master:	34.194.195.25@53
  rpz-log: yes
  rpz-log-name: 'coinblocker.srv policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'drop.ip.dtq'
  zonefile: '/var/lib/unbound/zones/drop.ip.dtq.zone'
  allow-notify: 0.0.0.0/0
  master: 54.36.110.62
  master: 35.156.219.71@53
  master:	34.194.195.25@53
  rpz-log: yes
  rpz-log-name: 'drop.ip.dtq policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'malicious.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/malicious.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'malicious policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'phishing.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/phishing.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'phishing policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'pirated.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/pirated.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'pirated policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'rpz.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/rpz.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'rpz policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'spyware.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/spyware.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'spyware policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'tracking.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/tracking.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'tracking policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

rpz:
  name:	'typosquatting.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/typosquatting.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'typosquatting policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes


rpz:
  name:	'whitelist.mypdns.cloud'
  zonefile: '/var/lib/unbound/zones/.mypdns.cloud.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'whitelist policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes
  rpz-action-override: passthru

rpz:
  name:	'blacklist.matrix.lan.rpz'
  zonefile: '/var/lib/unbound/zones/blacklist.matrix.lan.zone'
  allow-notify: 0.0.0.0/0
  master: 192.168.1.2@5300
  master: 192.168.1.3@5300
  master: 192.168.1.4@5300
  master: 192.168.1.5@5300
  master:	54.36.110.62
  rpz-log: yes
  rpz-log-name: 'urlhaus policy'
  rpz-signal-nxdomain-ra: yes
  for-downstream: yes

Yorgos Thessalonikefs · Answer 3 · Thu Jul 25 2024 01:27:55 GMT+0800 (China Standard Time)

I am confused as to which domain is part of which RPZ feed, but for example, whatever is in whitelist.mypdns.cloud which has an explicit passthru action will terminate the RPZ lookup and allow that domain to pass through RPZ filtering. If the same entry happens to also be part of the subsequent blacklist.matrix.lan.rpz it will not be considered by Unbound.

I also understand that this issue is only about RPZ ordering and not passthru.

spirillen · Answer 4 · Fri Jul 26 2024 09:00:37 GMT+0800 (China Standard Time)

Was about to write a lot... I've found the "issue"

the problem is that I've gave the name the wrong info, and could need a little update in the docs

Problem line: name: 'blacklist.matrix.lan.rpz'
Solved line: name: 'blacklist.matrix.lan'

It turns out unbound didn't load the zone, because I've come to name the zone wrong, as I was unaware, this should have been a match to the actual zone-name rather than a internal name for eg: logs