I can’t click apply before save.
Without looking into the sources, I suppose there is a property modified in the settings. This is cleared by apply button which changes to grey.
I closed the browser and restarted it.
After restarting the browser, the apply button is inactive.
Hi @tphz
Sorry for the confusion. Here are the steps for the Custom lists:
- Apply button is normally inactive (greyed out)
- make a change to one or both Custom lists
- click the Save button
- wait ~2 seconds and the Apply button is now active
- click the Apply button
allow.rpzfile is updated.- Wait ~20 seconds for screen to refresh…
Does this help?
When I tested the button was active. (I don’t know why)
After @bbitsch’s post
Does it look like it works ok.
In the outer space, namely Windows, an Apply button saves previously made changes without leaving the current settings.
A Save button, saves the settings, too, but closes the current Window.
Basically both buttons are enabled at the same time but with slightly different meaning.
So, the actual implementation of the Apply and Save button in RPZ is a bit confusing, IMO.
Any clicking of save makes the apply active…
Therefore an edit should be done with
- if not greyed out, click Apply to activate pending changes.
Successfully updated to v.16
# NAME=rpz ./update.sh
Extracting backup includes...
var/ipfire/backup/addons/includes/
var/ipfire/backup/addons/includes/rpz
...Finished.
Stopping Unbound DNS Proxy... [ OK ]
Creating Backup...
tar: Removing leading `//' from member names
//etc/unbound/local.d/00-rpz.conf
tar: Removing leading `//' from hard link targets
//etc/unbound/local.d/light.rpz.conf
//etc/unbound/local.d/nsfw.rpz.conf
//etc/unbound/local.d/urlhaus.rpz.conf
//etc/unbound/zonefiles/allow.rpz
//etc/unbound/zonefiles/block.rpz
//var/ipfire/dns/rpz/allowlist
//var/ipfire/dns/rpz/blocklist
...Finished.
Removing files...
removed '/etc/unbound/local.d/00-rpz.conf'
removed '/etc/unbound/zonefiles/nsfw.rpz'
removed '/etc/unbound/zonefiles/allow.rpz'
removed '/etc/unbound/zonefiles/light.rpz'
removed '/etc/unbound/zonefiles/block.urlhaus.rpz.zone'
removed '/etc/unbound/zonefiles/urlhaus.rpz'
removed '/etc/unbound/zonefiles/doh.rpz'
removed '/etc/unbound/zonefiles/block.threatfox.rpz.zone'
removed '/etc/unbound/zonefiles/block.doh.rpz.zone'
removed '/etc/unbound/zonefiles/block.rpz'
removed directory '/etc/unbound/zonefiles'
removed '/usr/sbin/rpz-config'
removed '/usr/sbin/rpz-metrics'
removed '/usr/sbin/rpz-sleep'
removed '/var/ipfire/backup/addons/includes/rpz'
removed '/var/ipfire/dns/rpz/blocklist'
removed '/var/ipfire/dns/rpz/allowlist'
removed directory '/var/ipfire/dns/rpz'
...Finished.
removed '/etc/unbound/local.d/light.rpz.conf'
removed '/etc/unbound/local.d/nsfw.rpz.conf'
removed '/etc/unbound/local.d/urlhaus.rpz.conf'
Extracting files...
./
var/
var/ipfire/
var/ipfire/menu.d/
var/ipfire/menu.d/EX-rpz.menu
var/ipfire/dns/
var/ipfire/dns/rpz/
var/ipfire/dns/rpz/blocklist
var/ipfire/dns/rpz/allowlist
var/ipfire/backup/
var/ipfire/backup/addons/
var/ipfire/backup/addons/includes/
var/ipfire/backup/addons/includes/rpz
var/ipfire/addon-lang/
var/ipfire/addon-lang/rpz.tr.pl
var/ipfire/addon-lang/rpz.it.pl
var/ipfire/addon-lang/rpz.fr.pl
var/ipfire/addon-lang/rpz.es.pl
var/ipfire/addon-lang/rpz.en.pl
var/ipfire/addon-lang/rpz.de.pl
usr/
usr/sbin/
usr/sbin/rpz-sleep
usr/sbin/rpz-metrics
usr/sbin/rpz-make
usr/sbin/rpz-functions
usr/sbin/rpz-config
srv/
srv/web/
srv/web/ipfire/
srv/web/ipfire/cgi-bin/
srv/web/ipfire/cgi-bin/rpz.cgi
etc/
etc/unbound/
etc/unbound/zonefiles/
etc/unbound/zonefiles/allow.rpz
etc/unbound/local.d/
etc/unbound/local.d/00-rpz.conf
...Finished.
Restoring Backup...
etc/unbound/local.d/00-rpz.conf
etc/unbound/local.d/light.rpz.conf
etc/unbound/local.d/nsfw.rpz.conf
etc/unbound/local.d/urlhaus.rpz.conf
etc/unbound/zonefiles/allow.rpz
etc/unbound/zonefiles/block.rpz
var/ipfire/dns/rpz/allowlist
var/ipfire/dns/rpz/blocklist
...Finished.
changed ownership of '/var/ipfire/dns/rpz/blocklist' from root:root to nobody:nobody
changed ownership of '/var/ipfire/dns/rpz/allowlist' from root:root to nobody:nobody
ownership of '/var/ipfire/dns/rpz' retained as nobody:nobody
changed ownership of '/etc/unbound/zonefiles/allow.rpz' from root:root to nobody:nobody
changed ownership of '/etc/unbound/zonefiles/block.rpz' from root:root to nobody:nobody
ownership of '/etc/unbound/zonefiles' retained as nobody:nobody
changed ownership of '/etc/unbound/local.d/00-rpz.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/urlhaus.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/nsfw.rpz.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/backup/threatfox.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/backup/doh.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/backup/dohBACKUp' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/backup' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/threatfox.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/doh.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/urlhaus.rpz.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/dohBACKUp' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d/light.rpz.conf' from root:root to nobody:nobody
changed ownership of '/etc/unbound/local.d' from root:root to nobody:nobody
Starting Unbound DNS Proxy...
2 Likes
After uninstalling the old version and installing the new version, the add-on starts.
However, I still have the problem that I receive a message from the unbound log, but a blocked address is still loaded.
I had posted the reason for this elsewhere in this forum but didn’t find a real solution, or rather, no one addressed it. It also had a different context, but here I see the problem.
My Squid proxy uses an upstream http proxy that is also used as a DNS server and the DNS query reaches this server despite the blocklist. Unfortunately, I don’t know why this is the case.
If I disable the upstream proxy, everything is blocked correctly.
I think this is a ‘little’ problem in web access.
If the proxy in IPFire is used only, the name resolution is done in IPFire and RPZ is in use.
If IPFire’s proxy passes requests to an upstream proxy, name resolution is done there. Unbound/RPZ in IPFire has no chance to interfere. 
But how is it enforced that the query reaches the upstream proxy?
Because both unbound and the upstream proxy receive the query; I can see that when I do a DNS leak test and in the unbound log the block can also be seen.
The browser send the HTTP(S) request for www.example.com to the proxy.
Without upstream proxy Squid resolves the name www.example.com to an IP, using unbound, and sends the request to the IP. If RPZ is active this resolution fails, if www.example.com is in the list of blocked URLs.
WIth an upstream proxy Squid sends the request to the upstream proxy, where name resolution and HTTP request are realized. Unbound in local system is not involved.
And why this is in my log ?
12:24:27 unbound: [2325:0] info: validation failure : key for validation cisco .com. is marked as invalid because of a previous 12:24:25 unbound: [2325:0] info: validation failure : key for validation cisco.co m. is marked as invalid because of a previous 12:24:25 unbound: [2325:0] info: validation failure : key for validation cisco.co m. is marked as invalid because of a previous 12:24:23 unbound: [2325:0] info: validation failure : key for validation cisco.com . is marked as invalid because of a previous 12:24:23 unbound: [2325:0] info: validation failure : key for validation cisco.com. i s marked as invalid because of a previous 12:24:22 unbound: [2325:0] info: validation failure : key for validation cisco.com . is marked as invalid because of a previous 12:24:22 unbound: [2325:0] info: validation failure : no DNSSEC records for DS cisco. com. while building chain of trust 12:24:22 unbound: [2325:0] info: rpz: applied [block] cisco.com. rpz-nxdomain cisco.com. DS IN
Both get the query and website is loaded.
To reproduce this situation, it is necessary to know the unbound ( DNS ) settings and the upstream proxy settings.
The unbound errors show some other problem with DNS, IMO.
EDIT: I’ve put cisco.com in RPZ’s blocklist. If I do a HTTP request I get 4 block messages ( one for my PC; 3 for 127.0.0.1, the proxy I suppose ) in the first access, each further try produces 2 messages.
2 Likes
hi
i have test rpz-beta-0.1.6-16.ipfire on 2024-11-18
in the list of whites or in the blacklists
domaine.com = ok
*.domaine.com = no good
ty
@gw-ipfire - this might help…
If I add this to the Custom block list:
domaine.com
and click Save and then Apply then RPZ will only block that exact domain. And RPZ will not block www.domaine.com, or blog.domaine.com or wiki.domaine.com.
If I add this to the Custom block list:
domaine.com
*.domaine.com
and click Save and then Apply then RPZ will block all domains and sub-domains.
This will block domaine.com AND it will block www.domaine.com, blog.domaine.com and wiki.domaine.com (and any other sub-domains).
There are two different lines to block two different items. First line blocks a domain only and the second blocks all of its sub-domains.
3 Likes
1 Like
This is an error in /usr/sbin/rpz-make program.
Lines 135ff should read
bad_lines=$( sed --regexp-extended \
'/^(\*\.)?([a-zA-Z0-9](([a-zA-Z0-9\-]){0,61}[a-zA-Z0-9])?\.)+([a-zA-Z]{2,}|xn--[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])$/d ;
/^$/d ; /^;/d' "${theList}" )
1 Like
sory i have same message
1 Like
@gw-ipfire , @mumpitz , @jon :
See my post above.
Could you please test it?
1 Like