PFBlockerNG Python-Mode - Source-IP in Reports

mOrbo

Thanks for your help. If you need any logs/infos or tests from unbound or pfsense let me know :-)

andrebrait

@mOrbo the relevant lines from your dnsbl.log and dns_reply.log files would be helpful. Same for a screenshot of the Reports tab.

Both when in Unbound and Python modes.

Also, until that gets fixed, you can use a checkbox on the DNSBL page that disables logging from inside Python and uses the DNSBL webserver for that instead. It's normally used to allow for AD environments but it should work for your case.

mOrbo

@andrebrait I did some tests now.

First in python mode. The DNS Server IP is 10.11.1.15, the Client IP is 10.11.3.6.

As you can see, the report shows the IP of our internal DNS Server.

Same thing in the dnsbl.log:

DNSBL-python,Oct 12 08:41:33,youporn.com,10.11.1.15,Python,TLD_A,DNSBL_UT1,youporn.com,UT1_adult,+

The dns_reply.log does not show any entries regarding this blocked request:

DNS-reply,Oct 12 08:41:24,reply,PTR,PTR,15699,90.182.178.59.in-addr.arpa,10.11.1.15,triband-del-59.178.182.90.bol.net.in,unk
DNS-reply,Oct 12 08:41:24,reply,A,CNAME,20,binaries.templates.cdn.office.net,10.11.1.15,89.27.247.9,DE
DNS-reply,Oct 12 08:41:26,reply,A,CNAME,33,nexus.officeapps.live.com,10.11.1.15,52.111.236.26,IE
DNS-reply,Oct 12 08:41:29,reply,A,A,126,0.de.pool.ntp.org,10.11.1.15,194.25.134.196,DE
DNS-reply,Oct 12 08:41:30,reply,PTR,PTR,1149,111.30.235.114.in-addr.arpa,10.11.1.15,NXDOMAIN,unk
DNS-reply,Oct 12 08:41:30,reply,A,A,60,prod.nexusrules.live.com.akadns.net,10.11.1.15,52.111.236.23,IE
DNS-reply,Oct 12 08:41:33,reply,A,A,60,4.sophosxl.net,10.11.1.15,52.215.114.87,IE
DNS-reply,Oct 12 08:41:34,reply,A,CNAME,Unk,odc-commonafdrk-geo.onedrive.akadns.net,10.11.1.15,13.107.42.12,US
DNS-reply,Oct 12 08:41:37,reply,A,CNAME,2,umwatson.events.data.microsoft.com,10.11.1.15,20.189.173.21,US
DNS-reply,Oct 12 08:41:37,reply,A,CNAME,43,wu-bg-shim.trafficmanager.net,10.11.1.15,93.184.221.240,GB
DNS-reply,Oct 12 08:41:39,reply,PTR,PTR,1798,75.118.240.91.in-addr.arpa,10.11.1.15,NXDOMAIN,unk
DNS-reply,Oct 12 08:41:45,reply,PTR,PTR,247,102.134.237.37.in-addr.arpa,10.11.1.15,NXDOMAIN,unk

After that I switched to unbound mode. Here you can see the Client-IP as source:

Also in the dnsbl.log file:

DNSBL-Full,Oct 12 09:11:44,youporn.com,10.11.3.6,-|GET / HTTP/1.1|Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.60,DNSBL,DNSBL_UT1,youporn.com,UT1_adult,+
DNSBL-1x1,Oct 12 09:11:44,youporn.com,10.11.3.6,-|GET / HTTP/1.1|Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.60,DNSBL,DNSBL_UT1,youporn.com,UT1_adult,-

As in python mode, the dns_reply.log file is empty for this timestamp.

andrebrait

@mOrbo thanks for the logs.

I'll see if I can find out whether I can get that data and whatnot. I need to build a similar setup (it isn't hard, but I need to do it) and try to see the data that Unbound provides the Python code with to see if there's anything there that's perhaps not in their docs.

mOrbo

@andrebrait Thanks for your help!

Gertjan

@mOrbo said in PFBlockerNG Python-Mode - Source-IP in Reports:

Also in the dnsbl.log file:

DNSBL-Full,Oct 12 09:11:44,youporn.com,10.11.3.6,-|GET / HTTP/1.1|Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.60,DNSBL,DNSBL_UT1,youporn.com,UT1_adult,+
DNSBL-1x1,Oct 12 09:11:44,youporn.com,10.11.3.6,-|GET / HTTP/1.1|Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.60,DNSBL,DNSBL_UT1,youporn.com,UT1_adult,-

Question : what does this text "GET / HTTP/1.1|Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/117.0.0.0 Safari/537.36 " doing in a DNS request ?

Also : a DNS 'server' will not send upstream the original IP that initially for a DNS request.
Like unbound talking to "8.8.8.8" : "Hey, 192.168.10.45 wanted to know what the A record of "google.com" is".

Your ' internal DNS-Server' won't do neither. So, 'pfBlockerng' (unbound) DNS logs can't produce that info if the request came from an intermediate DNS server. It can only know about 'who', the IP the request came from, was asking not who was originally asking.

What probably happens is that DNSBL does its job, finds a DNSBL entry so it returns the pfBlockerng web server IP (the one that shows the "You are blocked " page).
Now, as the initial client was a web browser, it got redirected to this web server IP, this is the (default) 10.10.10.1
An that web server will 'see' the IP of the client.

Btw : the web page from this pfBlockerng web server will not show up on the client's device, as it can't show the page : no one can break https : meaning : if the browser wanted to visit https://whatever.tld and https://pfsense-pfblockerng-web-server/ was answering it will 'fail'
I do presume that no one use http anymore, as these sites simply do not exist anymore.

IMHO : the build in "pfBlockerng web server" is actually quiet useless.
But your question made me discover a reason to use it.

I switched to "Null block" a long time ago:

as my pfSense is the DNS of all my LAN's, I do see the originating (requester) IPs.

mOrbo

@Gertjan Probably your theory is right and the client IP comes from the pfblockerng webserver. So this IP could also be available in python mode.

What's not right is, that a https redirect will fail. It simply throws a certificate issue warning. So the client actually connects to the pfblockerng websever, but the browser displays a cert warning. Most users will close the site then, but if you ignore the warning you will see the block page.

So if the Client-IP comes from this webserver, it does not matter if its http or https.

Gertjan

@mOrbo said in PFBlockerNG Python-Mode - Source-IP in Reports:

you ignore the warning you will see the block page.

Very correct.
The thing is, you know that, and you probably know that black part of the URL is showing what is your pfSense device.
Like this URL :

The netgate.com part is in black. Because that the one that is important. That's the one matching the certificate from Netgate. So, ok, you know what you do. Internet isn't a dangerous place for you.

Now for the other 99,x % of us : if they all start to click through this "wrong cert" warning, pishing sites and other fake ones will have a bright future front of them.
So I tell them always : don't think - close it right away. Do not click any where.

IMHO : we as pfSense admins shouldn't contribute to the fact that our network users see this kind of info. It will introduce bad habits. And these 'stupid' users will pay the price later on.

Their IP will get logged of course, thus feeding the pfBlockerng stats.

seraph77

Hi,

I just ran into the exact same issue after switching to python mode. Since the update to 24.07.1 I have no more logs (unified /Alerts) when in Unbound mode. Before it worked like a charm. It still blocks but does not report. So I believe there's a bug somehow. When switching to Python mode, the logs are created again , but only showing the IP of the internal DNS, which is not that helpful for analysis. Is there a way to fix either of it (Python mode reporting source client ip or Unbound logging again as before)?

Gertjan

@seraph77

You don't see something like this :

?

@seraph77 said in PFBlockerNG Python-Mode - Source-IP in Reports:

but only showing the IP of the internal DNS

? Where ?