Yes, 1 Click. So we have a goog / perfect Solution. THX

@SteveITS said in Using the same whitelist in pfB and Snort:

I'm not aware of hosts in Suricata_Trusted_Hosts being blocked so I assume it's working anyway...?

That's the bottom line. If the hosts you do not want to get blocked are not getting blocked, then all is good.

I don't recall specifically testing with nested aliases back when I wrote the new alias functionality into the custom blocking plugin. I was mainly going after FQDNs (fully qualified domain names) at the time.

But the plugin is not digging into the alias to resolve it. It simply looks in the same pf tables that are listed under DIAGNOSTICS > TABLES. If the alias is there and is populated, then the plugin can test for IP addresses in the alias. If the alias is not listed under DIAGNOSTICS > TABLES, then Suricata is not using it even though it may show up in the View List dialog when viewing a Pass List.

I built a sort of fail-safe error handling feature into the custom code so that it will silently ignore an alias that is not found during run time. The operating assumption there is the admin might have removed the alias and I didn't want the running Suricata process to abort if that happened.

There may be more to this than PFBLOCKERING/PFSENSE. Remember that browsers offer the ability to use DNS over HTTPS. Basically Firefox, Chrome, Edge... can use HTTPS to forward DNS requests straight out to the internet, not leaving it to your router to do. It's encrypted as well on port 443 so your router can't stop it. You have to go into the settings of the browsers you use and turn it off.
Your DHCP settings can also be providing an internet DNS server IP to your computer's network settings so make sure that DHCP is providing your PFSense IP or the IP of your internal DNS server if you have one other than PFSense. I do, and have my DNS server forward to my PFSense box, which then takes over.
In either of these cases, If DNS queries are direct from the browser to the internet, or to an internet DNS IP provided to the desktop via DHCP, PFSense/PFBlocker is 'out of the loop' at that point.

@CreationGuy

https://docs.netgate.com/pfsense/en/latest/recipes/block-websites.html

Use firewall rules seems to be the easiest for your situation.

@bartkus05 said in DNSBL Top1M TLD Inclusions not Saving / Restoring:

Got it fully working now

👍

My files also got auto updated after I've left work.

f3940fb8-86dc-4761-9931-3dbc5cdb0cb6-image.png

Be ware that "Alexo" might be gone soon, as it isnt' maintained anymore.

I guess this "TOP1M Whitelist" option isn't used a lot .... so not well tested against "all possible usage modes".

@fenichelar said in Null blocking SERVFAIL:

So just to confirm, you have null blocking with logging?

well .. you got me there.
I did use, since yesterday 11/02, switch my two DNSBL feeds to :

5c7ae6be-e1c5-45f8-af95-0b3a3aa2acb8-image.png

as I wanted to test with these settings for a while. And of course forgot about it already.
Btw : I didn't saw the pfBlockerng Blocked DNSBL page.
I nearly never visit web sites that are loaded with adds and stuff like that. So, pfBlockerng has nothing to do if it was just. I'm also sharing my connection with an entire hotel, loaded with clients (they are the real testers ^^) . Dono what they do, what they saw. If things went bad, they would have come to the reception to complain about the free service ^^
I know they do, as they also yell that there is nothing worth watching on the TV in their room (the 30 or so national channels - it's all publicity 24/24h and I don't block that (yet)).

I'm back at :

7dc95f9a-79d6-4a6c-9b62-7598cd9c01c9-image.png

@fenichelar said in Null blocking SERVFAIL:

but it is an option that should work

It does.
It woks well for we browser requests that are made with "http".
It can't - and you don't want to - work for https requests.
Added to what I've said above : let's do the test, and I propose this fact check method :
a new LAN pass rule :

85dd531f-1830-49ad-8e04-5049d72ca15d-image.png

Now I can see over time how often port 80 is used.
I'm curious ....

If most web server requests are https, which presume, then the "DNSBL-Webserver-log" can't work. It won't show up. At best, an browser error page shows up : as the "DNSBL-Webserver-log" certificate wasn't the one that the browser was waiting for.
Nothing is broken, imho, all is by design ^^ TLS (=https) behavior can't be patched easily.

One note for the difference between Alias Deny and Alias Native is that, IIRC, if deduplication is enabled, pfB will dedupe across lists, which may give unexpected results if one has overlaps.

Here’s some baseline settings that I use with our IP phones that you can use for comparison. No complaints about call quality.

I’m going to bring it up because things are in transition, but we are using ISC as the backend.

Running PF blocker 3.2.0_16 in python mode with all IP phones listed in python group policy to bypass DNSBL.

All IP phones are given a static IP address along with static ports.

Currently, we are running firewall optimization on normal, but if you’re still having problems, you may need to change that to conservative.

@Gertjan i'm aware of all of that, thanks. the thread was about a bug in the pfB, not about the right usage

@Gertjan Thanks got it

@JHplusUser Does it still let you rerun the upgrade? I believe it’s possible to do so via command line but an actual reinstall is arguably cleaner.

@Waqar-UK I would just copy paste into custom

custom.jpg

You can always do the kludge and put a copy into /var/db/pfblockerng.

@SteveITS Thanks. I meant to put in the original post that I forced an update after I made the change.

A couple of days later, the white list appears to be working.

Thanks,
Dave

My only concern was that I generated a lot of entries during testing and I wanted to clean them up.
However, the idea with the SSD is good to reduce the load on the system.

I'll find out the best way to do this.

@jrey turns out i also had to update , i feel so silly thx for the troubleshoot