pfBlockerNG-devel Not Blocking Malvertizing on LAN

SteveITS

@Gertjan
Per an above post 127.0.0.53 is:

Linux systemd "DNS Resolver daemon"

Hence I had suggested using "nslookup site_name 192.168.1.1" to test a particular site that should be blocked.

If it works (is the blocked IP) while forcing the use of 192.168.1.1, then pfBlocker is working as designed.

If it does not work using 127.0.0.53 then that daemon is apparently not using 192.168.1.1.

Gertjan

@newuser2pfsense

Linux host ?
Type in the magic command that shows what name server it is using :

cat /etc/resolv.conf

It probably tells you
127.0.0.1

so you have a process listeing on port 127.0.0.1:53 that handles DNS for your host.
This could be, for example, bind, or dnsmasq, or, why not, unbound.
This bind, or dnsmasq, or, unbound can
For unbound and bind : resolve - thus complely bypassing pfSense.
Or, for bind, or dnsmasq, or, unbound : forward to your upstream pfSense = 192.168.1.1, or to 8.8.8.8, or whatever. ask the administrator of your Linux host what he has decided.

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

If I unchecked Enable Forwarding Mode, is it resolving?

Yes, that's the pfSense default setting, resolving.

newUser2pfSense

@gertjan
On pfSense, cat /etc/resolv.conf :

Shell Output - cat /etc/resolv.conf
nameserver 127.0.0.1
nameserver 1.1.1.1
nameserver 1.0.0.1

On a Linux host on my LAN, cat /etc/resolv.conf :

nameserver 127.0.0.53

It's good to know that I'm now resolving.

Gertjan

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

hell Output - cat /etc/resolv.conf
That file doesn't tell you if you resolve, or forward.
It informs the system about the IP addresses where DNS requests can be send.

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

It's good to know that I'm now resolving

So you can remove these : 1.1.1.1 1.0.0.1 from System >General Setup > DNS Server Settings

On your Linux host : who listens on 127.0.0.53 ?
If it is a process called dnsmasq then it forwards to some [ see dnsmasq settings ]
If it is bind, then it could do what does bind best : it resolves, which means it bypasses completely pfSense. bind can also be set up to forward to .... who ever you want. Could be pfSense, or some Alfabet company.
If it is unbound, .... same thing, look at the settings.

newUser2pfSense

@gertjan I removed the Cloudflare DNS server IP addresses. I also followed the instructions from this site [https://b3n.org/hijacked-slow-dns-unbound-pfsense/] for setting up unbound on pfSense. It states "Under Services > DHCP Server, set your DNS Server to your pfSense’s LAN IP. As your DHCP clients renew their lease they’ll start using pfSense for DNS." Seeing I have a LAN and WLAN in Services > DHCP Server, do I set each one respectively to each of their DHCP Server adddress as below?

LAN
LAN DNS Server IP Address.png

WLAN
WLAN DNS Server IP Address.png

I remember when I very first configured pfSense when I knew nothing at all about it and was learning, I had searched for internet access rules because at the time I couldn't reach the internet (I did the search on my cell phone at the time as I recall). For my LAN and WLAN, I read a post from the search and I created 2 rules on both my LAN and WLAN (the image is for my LAN but it's the same on my WLAN):
Internet Access Rules.png
I'm wondering if these 2 rules have anyting to do with the 127.0.0.53?

I'm reading on this page [https://medium.com/@davetempleton/setting-up-dns-over-tls-on-pfsense-bd96912c2416] that I should be blocking port 53. I tried doing that by disabling the rule in the image above and I couldn't get to the internet so I had to re-enable it.

Interestingly, the DNS resolver listen port is 53:
Listen Port.png

Now I'm wondering by following the 2 sites I listed above, something may not be configured correctly. I haven't seen any malvertizing blocked using my iPhone's mail app where it was doing it before.

@SteveITS I haven't overlooked your response to this being the Linux systemd "DNS Resolver daemon".

Gertjan

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

I'm reading on this page [https://medium.com/@davetempleton/setting-up-dns-over-tls-on-pfsense-bd96912c2416] that I should be blocking port 53
Several conditions mus be valid when you want to use TLS over DNS.

TLS over DNS to a "TLS over DNS capable server (resolver) ": unbound must be in forwarding mode.
Select a TLS over DNS capable server, like 1.1.1.1.

First, set :

Set these two options :

And test, using https://1.1.1.1/help

Done

To use TLS over DNS on your local network :

Activate :

and now visit each device on your network, and make it use DNS over TLS using port 853.

For example, out of the box : Windows 10 can't do "TLS over DNS" (you need to install extra software). I've 'heard' that Windows 11 Pro can do it.
My iPhone : dono, I should look that up. Other pHones : never used them.

Great !

You've considered using this rule :

it always works, for everything.

About DJCP server settings :

For example, my WLAN network (my captive portal network) :
I'm using 192.168.2.1 as a DNS server, like you.

I've set 192.168.2.1 for good manners, but I presume We don't even need to do this.
As the DHCP server is set up to run on the 192.168.2.x network, it will include it's own IP as the DNS server, as my resolver listens to 192.168.2.1 (I've select 'All' interfaces on the resolver settings page)

newUser2pfSense

@gertjan Ok. So I have everything configured for unbound resolving now -
In System > General Setup > DNS Server Settings, I've removed all DNS server IP addresses.
In Services > DHCP Server > LAN & WLAN tabs > Servers > DNS Servers, I've removed the .1.1 and .2.1 DNS server IP addresses that I listed previously.
In Services > DNS Resolver > General Settings, I have set the below, however, I did not intentionally enable the Python Module - I don't know how it was checkmarked unless pfSense somehow checkmarked it for me for some reason. I'm not sure it should even be checkmarked. Any ideas???
Resolver General Settings.png

When all of these settings were initially set and applied, pfBlockerNG wasn't blocking any iPhone mail app email malvertizing. A pfSense reboot solved that issue. This is back to normal.

For my LAN using Firefox, there must be some setting I'm missing that's allowing the malvertizing through. I'm not sure what that setting would be though.

The one thing I didn't want to do was use my ISP's DNS servers or the Google's DNS servers. That's why I was using Cloudflare DNS servers and forwarding. Cloudflare seems more secure to me. I don't know what Verizon can see with my internet traffic using unbound resolving???

Gertjan

@newuser2pfsense

Resolver settings :
Clear also the second one :

But harmless as firawarings want activated.

Set this one :

As static leases don't influence unbound, they are read in when the system boots, or when you you add a static lease, which is rare.

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

The one thing I didn't want to do was use my ISP's DNS servers

Normally, you don't use the DNS obtained by a WAN DHCP lease, as this settings is unchecked :

If the DHCP WAN lease from an upstream ISP router, or if the your ISP gives you a WAN DHCP lease, unchecking this option will pfSEnse discard DNS servers.

Are you sue ? pool with a dash ? ( pool- )

Use the default : Select "All".

newUser2pfSense

@gertjan The pool with a dash (pool-) was me redacting my WAN IP address right after the dash.

I've checked all of my settings we've discussed for unbound resolver in pfSense. My pfSense should be good now.

I'm not sure what Firefox settings should be enabled/disabled for malvertizing to be blocked on my LAN. I may just have to live with it.

I'm still not sure how the Python Module was enabled in the Services > DNS Resolver > General Settings. I didn't enable it. What should I do with this setting?
Python Module.png

Gertjan

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

I'm still not sure how the Python Module was enabled in the Services > DNS Resolver > General Settings. I didn't enable it. What should I do with this setting?

It should be set to 'active' (checked).
pfBlockerNG-devel works 'better' when using Python mode.

SteveITS

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

not sure what Firefox settings should be enabled/disabled for malvertizing to be blocked on my LAN

For Firefox specifically see https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_will-users-be-able-to-disable-doh but since nslookup using 127.0.0.53 bypasses the block it would seem that's not Firefox related, and DNS on the computer is bypassing pfSense.

There are also feeds in pfBlocker to block DoH, and a choice on its "DNSBL SafeSearch" tab. I used a feed because I found out the Dish (satellite TV) "on demand" feature uses only DoH even though the rest of the DVR uses DNS, so I had to allow that device out.

newUser2pfSense

@Gertjan
Firewall > pfBlockerNG > DNSBL
Unbound python mode.png

Services > DNS Resolver > General Settings
Enable Python Module.png

@SteveITS
Thanks for the response. A little further research has found that my Linux Mint 21 Cinnamon OS has the 127.0.0.53 in the resolv.conf file for whatever reason. I'm trying a fix I found on the interwebs from this URL and it worked:
https://askubuntu.com/questions/1012641/dns-set-to-systemds-127-0-0-53-how-to-change-permanently
I'm now able to get my 192.168.1.1 DNS server IP when running an nslookup. However, it hasn't resovled the issue of removing malvertizing images from my LAN gmail emails.

Gertjan

@newuser2pfsense said in pfBlockerNG-devel Not Blocking Malvertizing on LAN:

my Linux Mint 21 Cinnamon OS has the 127.0.0.53 in the resolv.conf file for whatever reason. I'm trying a fix I found on the interwebs from this URL and it worked:

If the OS you use has a /etc/resolv.conf file that point to 127.0.0.53, then that wrong per se.
You PS could use a dnsforwarder (like dnsmasq) or a reslover like unboudn or famous bind. These two can resolver (thus bypassing pfSense), or any other upstream router like pfSense (so the resolver actually forwards to them).

When you see /etc/resolv.conf file that point to 127.0.0.53 : check who listens on 127.0.0.53
You'll have the process name.
Check the config of that process = you know how it works, what is is set told to do.
Now you can change it's behavior if needed.

What https://askubuntu.com/questions/1012641/dns-set-to-systemds-127-0-0-53-how-to-change-permanently is understandable.
As a plain vanilla "PC owner with whatever OS", you want a good and solid DNS, not necessary using the upstream router that some other guy is controlling. As this guy will see your DNS requests, and he would be able to 'intercept' them. And that's actually what you are doing as you are that other guy, the guy that also maintains pfSense.
So, it's like always :
Know how things are interconnected, and what choices you have.
Take your choices based on the options you have.

https://askubuntu.com/questions/1012641/dns-set-to-systemds-127-0-0-53-how-to-change-permanently is understandable. shows clearly what happened over time : need a DNS, point to 8.8.8.8.
As 8.8.8.8 works as good as your Internet connection : if you have a connection, you have DNS (8.8.8.8 doesn't go down often) ;)

But, when you consider controlling and using your own router/firewall, like pfSense, you should (normally) say goodby to 8.8.8.8 as you have the tools now to do you own DNS and DNS caching ( ! ) and why not, DNS interception, and control what site you want to block.

I'm not against 8.8.8.8 or comparable, they have their reasons to exist. On of them is : easy to set up.
But "pfBlockerNG-devel" and "8.8.8.8" won't work together.
I hope you get the picture know.

newUser2pfSense

@gertjan & @SteveITS Thank you both for your assistance. It doesn't go unnoticed.