pfBlockerNG block local DNS lookup

revengineer

I woke up this morning with internet down. It turns out that it was just DNS lookups on my local firewall were blocked. The alert is shown below. Can someone tell me how to whitelist my local firewall at 192.168.1.1?

revengineer

additional info:

grep "192.168.1.1" /var/db/pfblockerng/dnsbl/*

yields

/var/db/pfblockerng/dnsbl/URLhaus.ip:192.168.1.1

URLhaus block list

https://urlhaus.abuse.ch/downloads/text

includes

http://192.168.1.1:8088/Mozi.m

johnpoz

The simple solution would be to make sure there is a rule at the top of your rule list that allows what you want to be sure is allowed. ie access to pfsense IPs for dns.

Whenever you use rules that destination is controlled by a list that is not maintained by you - it is always possible that stuff you don't want to block may get entered into that list.

Sim issue not that long ago where 8.8.8.8 was put into such a list, and was being blocked.

revengineer

Thank you @johnpoz. I actually have such rules, just the ordering is wrong because they are currently AFTER the pfb rules. So I can solve by reordering the rules.

The downside is that if I disable and reenable DNSBL in pfBlockerNG, these pfb rules will be on top again. I actually do this quite often because when I have trouble accessing a website, more often than not DNSBL is the culprit. Of course, this is my fault because my blocklists are somewhat extensive.

So, if there is a way to whitelist this within pfBlockerNG, I would prefer to go that route.

revengineer

So I have tried the custom list as described here

Problem is that when I pfBlockerNG -> Update -> Force update, the Permit Outbound rule is always placed at the end where it does me no good.

revengineer

I found the "Rule Order" feature, but none of the options work for me. In specific, I simply cannot allow pfBlockerNG to reorder ALL my rules including my non-pfBlockerNG pfsense rules. The missing option is

|pfB_Pass/Match|pfB_Block/Reject|All other Rules| (original format)

johnpoz

Wouldn't Shouldn't this work?

Or would that put any any above pfb block?

I am not a fan really of any sort of "auto" rules.. I just use pfblocker for alias managment.. And then manually use those aliases in rules I create..

You could put your allow to pfsense for dns rule in floating, while pfb rules on interface(s)

revengineer

The instructions read

Select the 'Order' of the Rules
Selecting 'original format', sets pfBlockerNG rules at the top of the Firewall TAB.
Selecting any other 'Order' will re-order all the rules to the format indicated!

I interpret that has reordering all my pfsense rules. I have my rules in the order they must be executed and putting all my pfsense pass rules before pfsense reject rules will not work.

It seems that the only way out is to disable/delete the faulty blacklist until this is fixed. There should be an easier way, mistakes can happen.

BBcan177

@revengineer

Click on the blue infoblock Icon for the "ACTION" setting.

You can use "ALIAS type" Action settings and manually create your own rules.

revengineer

@bbcan177 I may just be dense here but I do not see how this changes thing. To illustrate my problem, please see the following rules

pfB_DNSBLIP contains the 192.168.1.1 IP which I need to allow. I am allowing this in pfB_PermitOutbound, which is however executed after pfB_DNSBLIP. If I move pfB_PermitOutbound to the top, everything works fine, but the pfBlockerNG update process recreates the rules and original order, thus preventing 192.168.1.1 to pass. This problem seems to be the same whether I define 192.168.1.1 as an alias or put it in a custom list set to "Permit Outbound".

Am I thinking about this wrong?

revengineer

This thread seems to deal with the same issue but I am not sure I understand. The problem seems to be that all pfB deny rules are generated at the top of my rules table and I am do not know how to place a superseding permit rule at the top even if an alias is used.

BBcan177

@revengineer said in pfBlockerNG block local DNS lookup:

This thread seems to deal with the same issue but I am not sure I understand. The problem seems to be that all pfB deny rules are generated at the top of my rules table and I am do not know how to place a superseding permit rule at the top even if an alias is used.

Are you using pfBlockerNG-devel?

RFC 1918 addresses should have been filtered out automatically.

revengineer

@bbcan177 No I am using the non-devel version.

BBcan177

@revengineer said in pfBlockerNG block local DNS lookup:

@bbcan177 No I am using the non-devel version.

Upgrade to pfBlockerNG-devel, there are so many fixes around Rule ordering and sanitizing of IPs.

revengineer

@bbcan177 So you are saying this upgrading would fix this particular issue? (I have been hesitant because I am worried about things breaking.)

BBcan177

@revengineer said in pfBlockerNG block local DNS lookup:

@bbcan177 So you are saying this upgrading would fix this particular issue? (I have been hesitant because I am worried about things breaking.)

There is a monumental task to backtrack changes in pfBlockerNG-devel -> pfBlockerNG, its too much work and no time to do that on my own free time.

You have options:

Stay with pfBlockerNG:

Enable "Suppression" in the general tab, that should remove any RFC1918 addresses that it finds. I am not 100% sure if that covers DNSBL IP tho, would have to test it.
Use Alias Type Action settings if none of the pre-defined Auto-Rule ordering works for your needs.

Move to pfBlockerNG-devel:

Which is what I recommend
It is being actively supported and developed.
I try my best to address any issues as they are found.

revengineer

@bbcan177 Thank you, thank you, thank you!!! The "Suppression" option was disabled and enabling fixed the problem. The 192.168.1.1 IP is now begin removed from the URLhaus blacklist.

I think I also now understand the ALIAS solution. I would need to convert ALL pfB lists to aliases and completely forgo the auto rules. This seems to be good practice in general and I may consider this.

Finally, I do plan on updating to the devel version eventually, probably when I update to pfSense 2.5.0 in the future. This will take some time and I need to make sure I carve the time out from my schedule to address the issue. Right now, I am too busy at work and need the internet to just work for my video conferences.