pfBlockerNG-devel Not Blocking Malvertizing on LAN

bingo600

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

Server: 127.0.0.53
What is this IP? Usually anything 127.x.x.x is "localhost" or "myself" indicating your computer is asking itself.

Linux systemd "DNS Resolver daemon"
It usually forwards to the "Real DNS received via DHCP", but it "annoyingly" caches "unresolved" names too.

Ie. if you have a "local DNS server" , and try to ping server3 , and get unresolvable .... You then remember that you forgot to enter server3's A record in your DNS server , and does that now.

When you now ping server3 on "whatever" it resolves , except on the machine you pinged it from , before making the A record .. It still uses the "cached unresolvable" - You have to restart the DNS Daemon or flush the cache.

Or when hit enough times ... Kick that DNS daemon to He.. , and use settings from "good ole" resolv.conf

/Bingo

newUser2pfSense

@steveits For pfBlockerNG-devel, with my iPhone on my WLAN, many email images get blocked which is what pfBlockerNG-devel is designed to do when you choose the feeds you wish to use (I'm sure you already know this so please forgive me). I have pfBlockerNG-devel set for all of my interfaces, so with my desktop on my LAN, no email images get blocked which is not the way it's supposed to work. I can compare side-by-side emails displayed using my iPhone on my WLAN and my desktop on my LAN and they do not appear to be the same. My desktop LAN computer shows everything and my iPhone WLAN removes images (pictures).

I wonder if there is a setting in pfBlockerNG-devel that's causing this? Just a thought.

Gertjan

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

My desktop LAN computer shows everything and my iPhone WLAN removes images (pictures).
I wonder if there is a setting in pfBlockerNG-devel that's causing this?

What is the DNS your PC uses ?
On your PC, Windows I presume, what is the output of

ipconfig /all

?
If your PC is using 1.1.1.1 or 8.8.8.8 or who ever, it will by pass the pfSense DNS, so it will by pass pfblockerng-devel.

Typically, your Windows PC should show :

Carte Ethernet Ethernet :

Suffixe DNS propre à la connexion. . . : my-network.net
   Description. . . . . . . . . . . . . . : Intel(R) Ethernet Connection (11) I219-LM
   Adresse physique . . . . . . . . . . . : A4-BB-6D-BB-A6-A1
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6. . . . . . . . . . . . . .: 2001:470:1f13:dead:2::c7(préféré)
   Bail obtenu. . . . . . . . . . . . . . : mercredi 23 novembre 2022 08:26:39
   Bail expirant. . . . . . . . . . . . . : mercredi 23 novembre 2022 11:41:39
   Adresse IPv6 de liaison locale. . . . .: fe80::daa9:bcf8:99cd:717e%9(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.6(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : mardi 22 novembre 2022 14:45:44
   Bail expirant. . . . . . . . . . . . . : jeudi 24 novembre 2022 08:26:38
   Passerelle par défaut. . . . . . . . . : fe80::92ec:77ff:fe29:392c%9
                                       192.168.1.1
   Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1
   IAID DHCPv6 . . . . . . . . . . . : 346340205
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-26-59-DF-8D-BB-BB-6D-BA-16-A1
   Serveurs DNS. . .  . . . . . . . . . . : 192.168.1.1
                                       2001:470:dead:5c0:2::1
   NetBIOS sur Tcpip. . . . . . . . . . . : Activé

Sorry, french, but you'll get the picture.

so my DNS is 'pfSEnse' == 192.168.1.1 (of course) and 2001:470:dead:5c0:2::1, that's my pfSense LAN IPv6.
So pfblockerng-devel works fine for my PC.

edit :

And keep in mind : your PC is also DNS caching !
So, if you doubt, use and abuse this command a lot :

ipconfig /flushdns

newUser2pfSense

@Gertjan All of my desktop PCs, Linux flavors, have 192.168.1.1 hard set as their DNS server addresses which is my pfSense address. In pfSense, I've configured Cloudflare DNS servers 1.1.1.1, 1.0.0.1.

Gertjan

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

All of my desktop PCs, Linux flavors, have 192.168.1.1 hard set as their DNS server addresses which is my pfSense address.

In that case, any host name to be resolved on any of your LAN devices should wind up in the

== DNS Reply page.

Look also at the

where the red lines mean : host found in a DNSBL, so blocked.

Blocked, for me, means : let's take a listed "upu.samsungelectronics.com" (it's in the list) as an example :

C:\Users\Gauche>nslookup upu.samsungelectronics.com
Server :   pfSense.mynet.net
Address:  192.168.1.1

Name :    upu.samsungelectronics.com
Address:  0.0.0.0

so it got back 0.0.0.0 which means it was blocked.

newUser2pfSense

@gertjan In the pfBlockerNG > Reports > DNS Reply, I can see both my LAN and WLAN device IP addresses contacting different Domains. I'm also seeing a lot of 127.0.0.1 traffic from my router/pfSense host name to different Domains, for example:

In the pfBlockerNG > Reports > Unified, I can see blocked Destinations, for example:

My Roku is reaching out every minute, WOW! That's disturbing.

I ran an nslookup on one of the destinations listed in the Unified tab, see below:
:~$ nslookup e91869.dsca.akamaiedge.net
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.142
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.135
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.145
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.138
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.140
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.136
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.148
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.147
Name: e91869.dsca.akamaiedge.net
Address: 23.212.251.143
Name: e91869.dsca.akamaiedge.net
Address: 2600:1408:c400:11::17cd:6b45
Name: e91869.dsca.akamaiedge.net
Address: 2600:1408:c400:11::17cd:6b54

SteveITS

@newuser2pfsense re:Roku, some devices/appliances like that will retry automatically if they can’t connect.

Re:Akamai, that’s a content delivery network for major web sites. It has servers all over.

Gertjan

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

My Roku is reaching out every minute, WOW! That's disturbing.

Wait until you meet my "samsung' smart TV ......
Not disturbing.
It's "they" who want to know what "you" are doing with your device.
You had a discount (they made it cheaper) when you bought that device, and you give them now 'information" they can "use" (and believe me, they do).
And you know this is true, as you and I would do the same thing.
And when you and I wouldn't do this, then our share holders would convince use that it needs to be done (otherwise we wouldn't have share holder == no starting capital == no new gadgets (TV) etc etc).
Btw : not that I'm against all this. It's just so you should know what is really happening - and why.

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

I'm also seeing a lot of 127.0.0.1 traffic from my router/pfSense host name to different Domains

Could be part of the CNAME resolving.
Your 'PC' asks for facebook.com.
The resolver gets a lot of answers back, some or all are CNAME's.
The the resolver 'unwinds' these CNAME, to get finally a A (or AAAA) back. This process is used for CDN access == you wind up using the closest, or fastest facebook server.

Or you are using :

so ones a host name was looked up, unbound will keep this host info up to date in your local unbound cache. You see unbound asking to itself (== 127.0.0.1) : who is edgekey.net ?
Just to refresh the DNS info, as all DNS info has a time out == not good after xx minutes.

newUser2pfSense

@gertjan Here is my Services > DNS Resolver > General Settings:

Here is my Services > DNS Resolver > Advanced Settings:

Everything checked appropriately?

Gertjan

@newuser2pfsense

Looking fine.

Please, take one minute, read https://forum.netgate.com/topic/176060/dns-reslution-error-just-on-pfsense-box/3?_=1669305464894 and tell me why you think you need to forward ?

And I'll be silly : I'm using default parameters, and pfBlockerng-devel just blocks fine (for me) ^^

edit : and it was said many times by now : if you forward, disable DNSSEC (all DNSSEC related stuff) as only a resolver can do DNSSEC.

newUser2pfSense

@gertjan I read the post your provided. I am forwarding, at least the way I read the entry for the checkbox, "If this option is set, DNS queries will be forwarded to the upstream DNS servers defined under System > General Setup...", because I thought pfSense would use the DNS servers that I want it to use, not my ISP DNS servers, but the ones that I define only. I'm not a big proponent of using the Google's DNS servers or my ISP's DNS servers. I'm glad that pfSense gives me a choice. Anyway, maybe I have the incorrect understanding of the language for that checkbox. Here is my DNS Forwarder page. Now I'm a little confused. I don't have it selected so I'm not forwarding?
DNS Forwarder.png

Before I uncheck Enable DNSSEC Support, I just want to make sure I understand (remember, I'm no network guru) that the unbound DNS Resolver does DNSSEC already?

FrankM

@gertjan

And then they wonder why we try to block their snooping!

Gertjan

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

Here is my DNS Forwarder page. Now I'm a little confused. I don't have it selected so I'm not forwarding?

pfSense contains an forwarder, dnsmasq (the name of the process).
It still present and isn't activated by default. You don't need to use the forwarder (and if you do, disable the resolver/unbound first with the top most check box on it's settings page !). See it as as a extra possibility to do "DNS".

Unbound, the resolver can do both. So unbound can resolve, or forward.
The checkbox discussed above is the main switch between these two functionalities.
It can resolve, that's why pfSense included it several years ago, and it can do forwarding for those who like to do, have no choice, or whatever.

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

at least the way I read the entry for the checkbox, "If this option is set, DNS queries will be forwarded to the upstream DNS servers defined under System > General Setup...", because I thought pfSense would use the DNS servers that I want it to use, not my ISP DNS servers , but the ones that I define only.

And you are correct.

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

Before I uncheck Enable DNSSEC Support, I just want to make sure I understand (remember, I'm no network guru) that the unbound DNS Resolver does DNSSEC already?

See it like this :
If you want to use DNSSEC you need to use the unbound as a resolver, not a forwarder.
To answer the question : why is this so ? you need to understand what dnssec is, what it isn't.
Just keep in mind what's easy to remember : dnssec needs resolving, not forwarding.

newUser2pfSense

@gertjan Maybe I should have asked it like this. Seeing I have Cloudflare DNS servers entered in pfSense to use instead of any others, in Services > DNS Resolver > General Settings, if I uncheck DNS Query Forwarding - Enable Forwarding Mode, will pfSense continue to use the Cloudflare DNS servers I entered or different DNS servers?

As well, from the below screenshot, apparently if I uncheck Enable Forwarding Mode, the box right below, Use SSL/TLS for outgoing DNS Queries to Forwarding Servers, my DNS queries will no longer be encrypted? Do I have to uncheck that as well or if it remains checked, will my DNS queries still be encrypted?
DNS Query Forwarding.png

I did a test with DNS Leak Test dot com [https://www.dnsleaktest.com/]. I found that with the Enable Forwarding Mode checked, this is the result of the Extended Test:
DNS Leak Test.png

When I uncheck the Enable Forwarding Mode, the DNS Extended Leak Test shows:
DNS Leak Test 2.png

Gertjan

@newuser2pfsense
When you use "Cloudflare DNS servers", you are not resolving, but forwarding to an upstream DNS resolver.
Cloudflare DNS is a resolver.
Added to that, Cloudflare DNS servers supports DNS over TLS.

When unbound is in the default Resolving mode, TLS, port 853, is 't available, as as far as I know, root and tld servers, and most domain name servers, don't support this mode yet.
Root servers (13 of them, and all there CDN's over the world) typically only receive "where are/is the DNS = TLD that handles dot com" (if you were asking domain.com). Then a TLD server would handle "where is the domain name server of domain.com" - and finally a domain name server would handle your entire request.

While TLS isn't available when resolving, DNSSEC is, which mans that you can be sure of the received data, that it wasn't get spoofed. For those domains that support DNSSEC, that is.

Btw : supporting TLS while doing resolving means that every server in chain must support TLS. That will need a 100++ fold processing increase load on every server in the chain.

Cloudflare, Google DNS support TLS, as for them, the DNS service, while you are not paying, they make a revenue out of it, as your data is 'value' to them that can be sold.

newUser2pfSense

@gertjan Thanks for all of the explanations. It helps. So I've unchecked Enable Forwarding Mode and kept the other boxes checked such as Enable DNSSEC Support and Use SSL/TLS for outgoing DNS Queries to Forwarding Servers. Hopefully this is OK?

Interestingly though, I'm still getting a 127.0.0.53 using nslookup.
Using Firefox on my LAN, email malvertising images are still coming through. Maybe it's a Firefox and Gmail thing?

On my iPhone, I'm using Apple's native email app. Maybe this is why malvertising is blocked when displayed through this email app when checking my Gmail?

Gertjan

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

nd kept the other boxes checked such as Enable DNSSEC Support and Use SSL/TLS for outgoing DNS Queries to Forwarding Servers. Hopefully this is OK?

Unbound can't do DNSSEC, as DNSSEC needs resolving, not forwarding.

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

I'm still getting a 127.0.0.53 using nslookup

Running nslookup on which device ?

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

Using Firefox on my LAN, email malvertising images are still coming through. Maybe it's a Firefox and Gmail thing?

Well, Firefox can decide, according settings, to do it's own DNS, totally bypassing pfSense.
Check FF settings.

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

On my iPhone, I'm using Apple's native email app. Maybe this is why malvertising is blocked when displayed through this email app when checking my Gmail?

The iPhone email app, the iPhone uses probably the DNS it got from pfSense, which is unbound. As unbound uses pfBlockerNG as a filter, now it works.

newUser2pfSense

@Gertjan
When I run nslookup using a host on my LAN is where I get the 127.0.0.53 below:

nslookup google.com
Server: 127.0.0.53
Address: 127.0.0.53#53

When I go to pfSense > Diagnostics > Command Prompt and run nslookup, I get the following:

Shell Output - nslookup google.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Ive checked my Firefox settings and I believe it to be using the correct settings. Hmmm .

So this is where I'm still a bit confused... I left the box DNSSEC checked and I unchecked the box Enable Forwarding Mode.

DNS Query Forwarding.png

Unbound can't do DNSSEC, as DNSSEC needs resolving, not forwarding.

If I unchecked Enable Forwarding Mode, is it resolving? If it's not resolving, what do I need to configure and where? What boxes do I need to check? I seem to be missing something here.

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.