Bypassing DNSBL for specific IPs
-
I still wonder if I am chasing a ghost or something real... Here's an actual real life example:
My work laptop is connected to DMZ. Connection straight to the outside, no DNSBL running on DMZ, no pfblocker running on DMZ, no Snort, nothing. Straight out with the exception of a few FW rules blocking anything nasty (connecting to pfsense, communicating with other subnets, etc).
This laptop is totally dysfunctional. Intermittently, web pages dont load, stuff breaks and crashes, proxy app keeps re-creating new connections to its mother ship, etc. My employer's IT support are blaming my "home network". This laptop runs a proxy service that connects to "gateway.zscalertwo.com" on port 18000.
In pfsense's FW logs, I see hundreds and hundreds of entries showing blocked traffic on DMZ. All of these have "Default deny rule IPv4" as description. That doesnt say much....
Since the FW rules on DMZ are very basic and pretty much allow anything, I started searching for an explanation somewhere else... I found in pfBlockerNG > Reports > IP Block Stats:
Clicking on the filter icon:
So I'm going back to my original thought. To me pfblockerNG interferes with traffic on DMZ. How can I disable this without whitelisting stuff???
-
Nope, your not chasing ghosts, but if you were, you know who to call!
That looks like you have pfBlockerNG's IP block rules enabled on the DMZ outbound interface.The clue is the list name is "pfb_malicious_malware_v4"
You have a number of things you can do to either remove it completely, or fine tune it to remove this functionality on the DMZ interface only.
To prove it using the sledgehammer approach, disable pfBlockerNG in the Global Tab, this will turn of DNSBL and the IP Block functions on ALL interfaces. Your work laptop should then function normally.
To remove this from just the DMZ, first check on the Firewall > Rules > DMZ tab and you should see something like this: -
The name will be different, but it will have a "pfb" prefix and a "v4" suffix and the description will indicate it is an auto rule.
Assuming there is a rule on your DMZ, you can remove it using the Firewall > pfBlockerNG > IP page under "Outbound Firewall Rules. Deselect the DMZ. My guess is you have LAN and DMZ selected currently.If you want to keep the IP Blocks enabled in the DMZ to protect your other devices not using the zscaler service, which protects your work laptop from malicious web sites. You will need to figure out which list has the zscaler ip address tagged as a malicious malware site. That will be in the "Feeds" tab within pfBlockerNG's pages.
You can check that the 185.46.212.41 is in the pfb_malicious_malware_v4 list, by using the Diagnostic > Tables option and selecting the list name from the drop down and scrolling through the table.Some of the lists in the feeds are somewhat aggressive, like one I enabled stopped my son from doing his school work on google docs. He was quite happy about it, but I soon solved that problem and had to get back to his school work.
Hopefully this points you in the right direction. I work in the industry and everything works just fine, until you enable security, the more you enable, the more it becomes a house of cards. Its a balance between safety and security and it just not being useful anymore. Finding the balance is key. Everyone is different.
-
Hey @horse2370 , thanks for the reply!
Okay I took some more screenshots of my setup. As they say "The plot thickens".
Before all of that, I had taken the precaution to make sure pfblocker was disabled on DMZ, here's a screenshot of the IP configuration page. As you can see, pfblocker is selected only on LAN (my main home network). DMZ is not selected :
Also under Rules > DMZ I do not see any pfblocker rules (as expected!):
But still, this morning, the FW logs are filled with blocked connections on DMZ. Today, however, there's all kind of destination IP's in there (WAN, Amazon servers, Zscaler, etc...):
All (literally ALL) of these blocked connections have the following reason:
The rule that triggered this action is: @9(1000000103) block drop in log inet all label "Default deny rule IPv4"Until I sort this mess out, I will have to either commute to my office or physically bypass pfsense completely and connect the laptop directly to the cable modem.
Any idea of what's going on? I know these "TCP:RA" or "TCP:PA" could be asymetrical packets.... I am 99.9% sure I never had this before. Could my ISP be doing some sort of f*ckery with my connection?
-
@pftdm007 said in Bypassing DNSBL for specific IPs:
The rule that triggered this action is:
@9(1000000103) block drop in log inet all label "Default deny rule IPv4"Most easy solution : stop login the hits on the default block rules. (see Log > Settings )
Your 192.168.2.206 is a device that lives on DMZ, a VLAN.
Take it out of the VLAN to bypass "smart switch issues".
On the device, find why these "TCP:RA" or "TCP:PA" are send .... Is it a Wifi connected device ?Probably not a pfBlockerNG-devel issue. Disable pfBlockerNG-devel and these hits continue ?
-
@Gertjan said in Bypassing DNSBL for specific IPs:
Your 192.168.2.206 is a device that lives on DMZ, a VLAN.
Correct. So is my work cell phone. Same issue with my cell phone.
@Gertjan said in Bypassing DNSBL for specific IPs:
Take it out of the VLAN to bypass "smart switch issues".
OK will try to connect the laptop to a non-VLAN subnet, but in the meantime, all of my other computers/servers/networked printers, are all on LAN which is also a VLAN, and I have absolutely zero issues with any of them. Side note: everything is a lot more severe on LAN (more pfB/DNSBL lists, Snort, etc...)
@Gertjan said in Bypassing DNSBL for specific IPs:
On the device, find why these "TCP:RA" or "TCP:PA" are send .... Is it a Wifi connected device ?
My employer's IT are investigating on the device to see if everything is properly setup & running.... In the meantime, yes the laptop & cell are wifi connected to DMZ, but I already tried connecting the laptop via wired connection, same issues. That kinda eliminates possibilities of issues with my WIfi access point.
@Gertjan said in Bypassing DNSBL for specific IPs:
Disable pfBlockerNG-devel and these hits continue ?
When they release the laptop, I will reconnect to DMZ, and try. I am pretty sure I already tried, but I've done so many things in the last few days I am getting a bit confused so I will retry to make sure.
-
guys what is wrong in my custom config since all LAN subnet 192.168.1.0/24 is being filtered by DNSBL ? I want some computers (192.168.0.1 and 192.168.0.2) to be excluded from DNSBL filtering.
server:
access-control-view: 192.168.0.1/32 bypass
access-control-view: 192.168.0.2/32 bypass
access-control-view: 192.168.0.0/24 dnsbl
view:
name: "bypass"
view-first: yes
view:
name: "dnsbl"
view-first: yes
server: include: /var/unbound/pfb_dnsbl.*conf -
These are 'clauses' in the (unbound) config file :
server: .... view: ...They are recognised by the terminating ':'.
"view:" clause can exists multiple times.
"server:" clause can't (there is only one server)Or, you have two of them.
This one is thrown in by the pfBlockerNG-devel package :
server: include: /var/unbound/pfb_dnsbl.*confThat is, you edited it. pfBlockerNG-devel package added this :
# Unbound custom options server:include: /var/unbound/pfb_dnsbl.*confThis is the same thing :
# Unbound custom options server: include: /var/unbound/pfb_dnsbl.*confSo, I guess this would work for you :
server: include: /var/unbound/pfb_dnsbl.*conf access-control-view: 192.168.0.1/32 bypass access-control-view: 192.168.0.2/32 bypass access-control-view: 192.168.0.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yesBtw : Use this when you start to add unbound specific manual settings. It's part of the RTFM concept ;)
Be careful : if
server: include: /var/unbound/pfb_dnsbl.*confcan't be found by pfBlockerNG-devel when it start, it will automatically add such a clause again into the unbound config file.
Remember, pfBlockerNG-devel parses as a program, not as a human ^^
Adding a seconds "server:" clause probably breaks the unbound config .... -
@Gertjan thanks. removing server: clause solved problem. I hope pfBlockerNG-deve won't add it again
-
Hi, been reading through this post but confused. I want to allow my IP 192.168.1.16 to bypass the blocker, is this correct?
Go to Services/DNS resolver/General Settings then in Custom options write:
server:include: /var/unbound/pfb_dnsbl.*conf access-control-view: 192.168.1.16/24 bypass access-control-view: 192.168.1.16/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes -
server: access-control-view: 192.168.1.16/32 bypass access-control-view: 192.168.1.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes include: /var/unbound/pfb_dnsbl.*confThe changes are: -
access-control-view: 192.168.1.16/32 bypassMatches the host you want to bypass with a /32 to make it ONLY match the single address.
access-control-view: 192.168.1.0/24 dnsblMatches the rest of the subnet, assuming a 255.255.255.0 mask.
Moved the include: to the "dnsbl" view
-
Thanks very much! Is it possible to something more fine grained. Like allow 192.168.1.16 to www.blockedwebsite.com?
-
I have tried the following file and it appears to work, by adding a
local-dataentry in the view, and not allowing it to fall back to the globallocal-dataentries . It has the benefit of keeping the pfblockerng-generated entry# Allow these hosts to bypass pfblockerng server:access-control-view: 192.168.0.2/32 bypass view: name: bypass view-first: no local-data: "dummy.entry 60 IN A 10.10.10.1" server:include: /var/unbound/pfb_dnsbl.*conf -
Hi All,
I see this thread has been ongoing for a few years. How is that? Is there a systematic way to make suggestions so this gets added to pfBlockerNG-Devel? It seems like a reasonable request. If we can't get this added to the GUI is there something else the customer can do? i.e. whitelist the host for 15-60 minutes so they can get the info they need without getting blocked?
having end users manually point to a different DNS server just makes it a pain in the ass. Asking end users to run Opera in VPN mode is also extra steps and eventually I would want to block that as well except for a few users/ip addresses. Having a separate machine or VM on a different network is something our users would call us out on.
Do all the edits to these text files migrate during version upgrades or do we have to remember to re-do all the custom stuff we tinker with?
Thanks,
Joe -
@Gertjan I had this working 4 months back:
server: access-control-view: 192.168.0.20/32 bypass access-control-view: 192.168.0.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes include: /var/unbound/pfb_dnsbl.*confbut later HDD of my custom firewall crashed, and Covid-19 lockdown began.
Meanwhile, I took firewall home, replaced HDD, upgraded pfSense to 2.4.5, upgraded pfblockerng-devel to 2.2.5_33. Now my bypass doesnt work. Everytime Firewall restarts or Enable/Disable pfblockerng, it changes unbound custom option to:
server: access-control-view: 192.168.0.20/32 bypass access-control-view: 192.168.0.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes server:include: /var/unbound/pfb_dnsbl.*confi.e. it adds another server: clause in the last line. You mentioned that there can't be multiple server: clause.
bypass still doesnt work. Can you please help? -
Try this :
server: access-control-view: 192.168.0.20/32 bypass access-control-view: 192.168.0.0/24 dnsbl include: /var/unbound/pfb_dnsbl.*conf view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes -
Thanks @Gertjan for responding quickly.
I tried what you suggested, but bypass still not working.
Additionally, when i tried to enable/disable pfBlockerNG(with above custom option), it moved the include: to the last line, with additional server: clause.
server: access-control-view: 192.168.0.16/30 bypass access-control-view: 192.168.0.26/32 bypass access-control-view: 192.168.0.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes server:include: /var/unbound/pfb_dnsbl.*confAnymore ideas worth trying?
-
@Gertjan said in Bypassing DNSBL for specific IPs:
Most easy solution : stop login the hits on the default block rules. (see Log > Settings )
Sorry Gertjan, I am not following your suggestion here. Do you mean "the Settings tab under Status > System Logs"
-
@SmokinMoJoe said in Bypassing DNSBL for specific IPs:
Do you mean "the Settings tab under Status > System Logs"
Yep, this one:
@HiteshJain said in Bypassing DNSBL for specific IPs:
when i tried to enable/disable pfBlockerNG
pfBlockerNG is a program.
It's adds "server:include: /var/unbound/pfb_dnsbl.*conf" without taken in account if you have anything else already in there.
Normally, this isn't a big issue, because, normally, you do not need to enable and disable pfBlockerNG all the time.
And if you do, you have to visit the Resolver config page afterwards to "correct" the custom config options somewhat - if you have other, your own config settings entered.
The syntax has to be correct for unbound, who parses the config file.Btw : My proposition about how to format is : how I should do it.
There is another forum thread that details how to do so already, use that one to compare it with yours. -
@HiteshJain I have evolved the config I posted last month. It still allows pfblockerng to regenerate the configuration correctly, without corrupting it, and adds in a few addtional files which were needed.
# Allow these hosts to bypass pfblockerng server:access-control-view: 192.168.0.2/32 bypass # A view to bypass pfblockerng view: name: bypass view-first: no # This is needed to prevent falling back to the # global 'local-data' settings local-data: "dummy.entry 60 IN A 10.10.10.1" # Static host entries include: /var/unbound/host_entries.conf # dhcp lease entries include: /var/unbound/dhcpleases_entries.conf # Domain overrides include: /var/unbound/domainoverrides.conf server:include: /var/unbound/pfb_dnsbl.*conf -
