pfBlockerNG not working
-
Hi, I have a similar problem and setup.
I'm using DNSBL with a few block lists. I followed this setup guide.
My main concern is blocking porn as I have kids at home.
In my tests yesterday, some websites were blocked and some that are clearly in the lists were not.
Today I enabled DNSBL again without really making any changes (apart for the daily pfSense reboot) and now porn sites are blocked.
I'll shed more details on the problem and my setup:
An example site is porn(h)ub. It is in the block list but I could still browse it.
Here are screenshots of my setup:
https://imgur.com/a/P3ADnd8 -
@UWLane said in pfBlockerNG not working:
I am having an issue where my local machine is not redirecting all dns traffic to local host. I have the firewall rules in place as per instructions to catch all other outbound dns requests other than local dns but it doesn't block. Just wondering if you can assist?
What's that to do with pfBlocker? If your local machine is not "redirecting" all dns traffic to localhost(? what do you mean by that?) - there's nothing pfsense or pfblocker can do.
You can catch DNS and DoT requests with the firewall and redirect it to pfsense so unbound is used but if your client uses some sort of DoH (DNS over HTTPS) there's nothing pfsense, pfblocker or anyone can do besides you stop your client using that application/setting.
-
This :
conflicts with this :
Please read again the "fine print" :
Also :
which opens the way to :
A DNS request that exists on ("in") pfSEnse can go to 127.0.0.1 - Unbound or Dnsmas (the forwarder), who ever is servering DNS,
Or
to 185............. (why did you hide this IP ?)
or
to 195............. (why did you hide this IP ?)185........ and 195...... do also DNSBL for you ? If so, do you control 'them' ?
@malf0rmedZ said in pfBlockerNG not working:
I followed this setup guide.
Re read this :
I guess you understand know what this means ;)
@malf0rmedZ said in pfBlockerNG not working:In my tests yesterday, some websites were blocked and some that are clearly in the lists were not.
What web sites ?
Which feeds ?No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@Gertjan, thanks for pointing out my misconfigurations, do note that my DNS clients are pointing to the domain controller which uses pfSense as the DNS forwarder (see Windows DNS server screenshot).
I guess I don't fully understand what I should do so if you could please advise that would be much appreciated. Thanks!
-
Check your DHCP sever.
Does it hand out the correct DNS info to the (your) LAN network clients ?
If needed, check all these clients, see what DNS they use.Read this : Home > pfSense
Software > DHCP and DNS the very first thread "Be aware of Trusted Recursive Resolver (TRR) in Firefox" knowing that it's not only Firefox that can do "DoT" .... most browser - and other applications (!) can do DoT these days.
Which means that "the phone of your kid" can have Apps that don't bother with your "pfBlockerNG - DNSBL", they surpass it completely.
It's like https traffic that can not be intercepted,. This includes the CIA, NSA and KGB (or what ever they call themselves these days).
Blocking outgoing port 853, TCP and UDP might help here, and even forcing to use your DNS ** - not some one else's DNS.** see them pfSense manual.
-
Yes my DHCP clients are getting the correct DNS server address (domain controller with pfSense as the forwarder).
From your response I still don’t understand what I need to correct in my settings. I sent detailed screenshots so all the configuration information is there. “Do 1...2...3....” type instructions would be ideal, I can’t be that far off from the correct settings I would think.
If someone could please assist that would be much appreciated :)
-
@malf0rmedZ said in pfBlockerNG not working:
https://i.imgur.com/FOf0DWd.png
You should click on the Infoblock to get the right settings : The " + " isn't allowed in group name
-
Thanks RonpfS
@bmeeks your unique explanation abilities will be mightily appreciated - if you can assist in distilling the above comments into clear steps I need to take that will be a huge help. Thanks in advance
-
@Gertjan said in pfBlockerNG not working:
This :
conflicts with this :
Please read again the "fine print" :Can you please explain how these settings conflict? To me having both enabled makes total sense since this enables query forwarding which is required.
Also :
which opens the way to :
A DNS request that exists on ("in") pfSEnse can go to 127.0.0.1 - Unbound or Dnsmas (the forwarder), who ever is servering DNS,
Or
to 185............. (why did you hide this IP ?)
or
to 195............. (why did you hide this IP ?)185........ and 195...... do also DNSBL for you ? If so, do you control 'them' ?
Can you please explain here what your recommendation is?
@malf0rmedZ said in pfBlockerNG not working:
I followed this setup guide.
Re read this :
I guess you understand know what this means ;)
As mentioned, my clients point to the domain controller which has pfsense configured as the only forwarder, therefore this requirement is satisifed.
@malf0rmedZ said in pfBlockerNG not working:
In my tests yesterday, some websites were blocked and some that are clearly in the lists were not.
What web sites ?
Which feeds ?The websites in these tests were pornhub and reddit. Please note the screenshots I provided are post this problem (i.e., at that point it was suddenly working as you'll see in the dnsbl log screenshot)
-
@malf0rmedZ said in pfBlockerNG not working:
these settings conflict?
Unbound should work as a resolver, not a forwarder. You are forwarding.
@malf0rmedZ said in pfBlockerNG not working:
recommendation
Remove 185.... and 195 ....
-
@Gertjan
Thank you, but if I remove those servers from System/General which upstream forwarders will Unbound use? -
Ready to learn what a resolver actually is ? ;)
See here https://en.wikipedia.org/wiki/Domain_Name_System#DNS_resolvers - the last phrase..... For example, a possible resolution of www.example.com would query a global root server, then a "com" server, and finally an "example.com" server.
Internet uses IP's and doesn't know anything about domain names.
When humans use endless lists of numbers, things bcome messy, so domain names and host names are invented.These 13 servers https://en.wikipedia.org/wiki/Root_name_server are hardcoded in each resolvers. One of them is used, and the host name is resolved as shown.
A resolver can look up zone details without the need to ask some other DNS system.
For example, you could forward all your DNS request to 8.8.8.8 - 8.8.8.8 is a resolver. -
Thank you, I'm always ready to learn :) In this case I know exactly what a resolver is. Please note using root hints as resolvers is not recommended, using ISP DNS servers is the best choice as this provides caching and reduces the load on root hints. Also, using Google DNS servers equals totally giving up on your privacy which defeats the whole purpose of this exercise...
Therefore, I am wondering if there's a way to use my ISP servers and not root hints with this setup?
-
@malf0rmedZ said in pfBlockerNG not working:
Please note using root hints as resolvers is not recommended, using ISP DNS servers is the best choice as this provides caching and reduces the load on root hints
That was in the old days.
These days, DNSSEC exists, which only works while resolving from top to bottom.
ISP DNS servers still exists, their usage isn't mandatory any more. -
@malf0rmedZ said in pfBlockerNG not working:
Please note using root hints as resolvers is not recommended, using ISP DNS servers is the best choice as this provides caching and reduces the load on root hints.
Nope you explained what a forwarder will do. It will forward to another system and use that for caching etc.
A resolver "resolves" the domain like @Gertjan describes by resolving it from back (tld) to front. Also a resolver includes caching itself, validates DNSSEC and is able to still goes on functioning for 99% of all domains when those forwarders others use are down again - like many of those cited ISP servers are multiple times a year. I'd never use my ISPs DNS as they have a history of "redirecting" you to other "helpful" sites instead of delivering NXDOMAIN answers. A resolver protects against such acts. -
@JeGr
Thanks but sadly this is a semantics argument. As part of the DNS name resolution process, the DNS server forwards queries to domains whose zones it doesn't host (or for which it is non-authoritative). I would like to use my ISP DNS servers as the forwarders, not root hints, so I'm wondering how this can be achieved with this setup. Thanks again. -
@malf0rmedZ said in pfBlockerNG not working:
Thanks but sadly this is a semantics argument.
No it isn't. It's a function. There are DNS forwarders - like DNSmasq - that do forwarding to other resolvers. They simply can't do any other work. Or there are resolvers - like unbound - that (can) do the full resolution process of DNS. That one doesn't use unbound in resolving mode doesn't change the fact, that it is a resolver. Also it IS another process to simply forward a query to another DNS resolver (e.g. your providers DNS) OR actually querying it as an resolver and interpreting the response, checking DNSSEC and caching the result. That's how those services work.
That doesn't change the fact, that you can use a resolver like unbound in forwarding mode. AFAIR pfBlockerNG only states that you have to use the "DNS resolver" (aka unbound) as it only works together with unbound and it's API/python module, it isn't stated that you need it set to resolving itself. So if you absolutely need/want forwarding, switching it to forwarding mode shouldn't affect the outcome of DNS blocking by pfBlocker. You can always check that by querying it directly with a domain it should have blocked. It should return you with either the VIP you configured (10.10.10.x) or (better IMHO) reply with a DNS error/notfound when configured without the logging/reporting page.
Just wanted to add I was not here to argue about semantics but explain functionality as with DNS there's quite often consusion about what does what ;)
-
@JeGr, thank you very much for the excellent explanation :)
In other words, would you say I can leave my configuration as is since it achieves what I'm after? Or is there anything I should change? (please see screenshots above)
-
TL;DR: I for myself would configure logging in DNSBL to "disabled".
What it did in the past is that it redirected a query that was blocked to the VIP configured in pfB to a small site that stated "DNS address was blocked". Nice! But: with SSL everywhere and without doing something like SSL interception/injection and rolling out your own CA and installing it in every client, most connections today try to use HTTPS or SSL/TLS connections anyway. So you'd try e.g.
https://badsite.local
but even if pfBlocker's DNSBL blocks that site, the "logging" feature would then hand out the configured VIP to the client (e.g. 10.10.10.1). So your client would try to access the URL above with the URL resolved to 10.10.10.1. But as the mini-webserver that pfBlocker runs can't simply answer any domain via SSL - as it doesn't posess a certificate for it - you run into you typical browser SSL error message. And if you click that away you'll be greeted by the "this was blocked" page.
Sounds time consuming? Yes. Also it leaves your client "knowing" (incorrectly) that badsite.local is 10.10.10.1.
That process has 2 points, that I find "not that great":- You hand out false DNS records to your client (OK maybe acceptible) but that still takes a little time (in ms, sure, but it takes time) and make it try to access a site that only says "Nope!" - which again takes time for the browser to resolve, access, display the error and the site
- It makes client users "immune" to the 'dangers' of SSL/TLS interception and wrong/bad certificates. If you've seen the "blah blah SSL Error" of your browser that much, you simply dismiss it without further thought. So in case of a really bad site (phishing etc.) there's no "Oh wait, there is an error with the connection! Something smells fishy..." moment but a "Oh that again, I just have to dismiss it and the site will open anyway" effect.
Especially don't like the second one (for clients) and don't like the added overhead and time from the first one. That's why other projects like Pi-Hole report 0.0.0.0 as the DNS answer to a blocklisted domain query. That is even better as the old alias (localhost / 127.0.0.1 that many howtos recommend) because localhost will make the service at least once try a connection. And if you're a developer and have a local webservice running, that's not what you want ^^ Even if you're not it is another few ms added to a lookup that will fail. You want it to fail. So nowadays they use 0.0.0.0 -
https://discourse.pi-hole.net/t/use-0-0-0-0-instead-of-dns-ip-in-blocklists/5412 - as that will end up returning an error immediatly (in windows that's error_invalid_netname) without any connection attempt. So it's the fastes way (and 0.0.0.0 is valid in a DNS return) to get an "error" so your connection attempt will be blocked the fastest without any detours.\jens
-
@JeGr, thanks for your valuable insights, will certainly consider. If you're feeling bored, I changed the screenshots above to a single page so it's easier to view.
At any rate, dnsbl seems to work as expected for now.
Thanks everyone for your assistance.
