pfBlockerNG-devel feedback
-
I installed pfBlockerNG-devel on a fresh 2.4.4 system.
For the Firewall 'Auto' Rule Order, how do I get the "Default Order"(original format) into the drop down selection list? I don't want to allow pfB_Pass/Match before all other rules - I just want pfB_Block/Reject same as pfBlocker 2.1.4
-
@Double-K
Those are the default settings now... If none of those Auto rule settings work for your needs, you can always use "Alias Type" Action settings and manually create the firewall rules to suit. Click on the blue infoblock icon for the Action setting for more details. -
@BBcan177 Thanks! Any plan to offer both options (the new default format & the old original format)?
-
@Double-K said in pfBlockerNG-devel feedback:
@BBcan177 Thanks! Any plan to offer both options (the new default format & the old original format)?
Not really... I never win with Auto Rules... This list would be 100000000000 different variations and no one will be happy with it.... So for now... I give up ;^)
-
@BBcan177 :-)
-
BBcan177, it's with great pleasure to report that I am extremely grateful and happy with pfBlockerNG-devl...never had an issue except the occasional feed load failure which usually recovered later that day or the next day...really appreciate you hard work, thank you.
-
I am so grateful for your work that I will be a patreon member very shortly.
Other than an occasional curl error and for some reason on routes I don't show anything on the vip address but I do on the host address and have stats.
I am investigating that today. -
PfBlockerNG has been working well. I only wish it could do wildcards and/or regex in DNSBL like pihole can do (different DNS server, I know). Also, when I block a domain in Opendns it blocks subdomains too. PfBlockerNG does not. That is all I really want to do.
EDITED: I do now realize that I can enable the TLD feature and it will block subdomains. It was just not where I was expecting to find that.
-
Ran into an interesting issue where a DHCP interface ended up changing IPs and the new IP Address was on a list. While the IP Address being on a list is an issue, it broke other services as the feed stopped traffic (unrelated to the list) that shouldn't have been interrupted.
It would be greatly appreciated if there was a means to categorically exclude each interface - possibly as a choice of: None, IP Address or Network. Something that reveals that an interface IP Address/Network matched in a list and a means to locate the specific list(s) (or pf table) where the IP Address "matched" would be helpful.
FYI - may have missed it, but didn't locate anything that inferred a means to "exclude" an interface's IP Address (or network) - without specifying the IP/Network. This would be critical for interfaces that are DHCP driven. The exclusion of the firewall itself (IP/Network) from any feed would ensure that pfB can remain "first check" ("Default format") before services, without it potentially taking down services. This avoids potentially "unsavory" sources from being able to reach any service(s) in the first place.
Hadn't seen this issue previously, so was caught 'off guard' by the fact that this happened and took a little to determine the source of connections being rejected.
Thanks!
-
@justme2 said in pfBlockerNG-devel feedback:
where a DHCP interface ended up changing IPs and the new IP Address was on a list.
Woow. Impressive.
What IP range ? Where ? What entity hands out thee kind of IP's ? And, most important, what list ? -
What's important is the effect of the block list causing the firewall to block "itself" inadvertently (ie: inbound/outbound connections on a port for a required service, such as remote administrative access being blocked at the branch site, by "itself"), while trying to maximize efficiency - shunning undesirable traffic, first. Yes, one might argue to place the administrative service -prior- to the block lists, but why expose any service to sources that are considered "bad" for one reason or another? Would think that most folks would like the advantage of knowing that blocked addresses are simply rejected in total to reduce superfluous traffic. However that obviously backfires if an address ends up on a list. If pfBlocker logically allows the firewall to "block itself", the protection becomes equal to the risk of not blocking those addresses. External interface with logical rule ordering:
- Block RFC-1918
- Block Bogon
- Block from <lists>
- Block to <lists>
- All other rules
As a temporary 'hack' added the following shell script to remove anything that matches for the specific IP Address, but does little if for some reason the network were to end up in a list. This was added to the cron jobs by tacking on " && /bin/sh <script-name>" so that at conclusion of each update, any interface IP addresses would be removed. Not the "best" solution, but a "gross" temporary means. It still unfortunately means that until the processing by pfBlocker is completed - some services could be interrupted (vs performing exclusion prior to pushing the new table data in which would protect legitimate connections). With pfBlocker set to a cron interval of 1 hour - this means that any connection exceeding 1 hour would be 'clipped'. Script:
#!/bin/sh
export SCRIPTNAME="
echo $0|sed -e's/^.*.\///'"
for IP inifconfig -a | grep 'inet '|sed -e's/^.*.inet //'| sed -e's/ .*//'|grep -v '127.0.0.1'|sort -u
do
for TABLE inpfctl -s Tables | grep '^pfB'|sort -u
do
export CHECK="pfctl -t ${TABLE} -T show | grep ${IP}"
if [ "x${CHECK}" != "x" ]; then
pfctl -t ${TABLE} -T delete ${IP} >/dev/null 2>&1 3>&1
logger -t ${SCRIPTNAME} " : ${TABLE} : ${IP}"
fi
done
doneThe point still remains that if by way of DHCP IP address changes or unexpected entry to a list - production services could be blocked inadvertently. The complexity (programmatically) could be a bit daunting based on what's available for efficient and fast processing of v4 and v6 addressing. Using something in 10.0.0.0/8 as crude example:
Interface IP Address: 10.57.93.84
Network in block list: 10.56.0.0/15
Would need to translate to: 10.56.0.0/16,10.57.0.0/18, 10.57.64.0/20,... 10.57.93.0, ... 10.57.93.83, 10.57.93.85, ... 10.57.93.255, 10.57.94.0/23, 10.57.96.0/22, ...Noting that 10.57.93.84 being removed from list as it occurs on an interface. This would increase table sizes where its network centric. It also adds overhead to the process as each leading octet would need to be vetted (ability to ignore processing where lead octet doesn't match any of the leading octets for interfaces present).
Notionally, maintaining all of the other "blocks" while excluding (at a minimum) interface address and potentially interface network(s). Otherwise, you'd end up either losing a significant protection or having to use overrides that nullify the advantages.
Assertion being that if an IP Address ends up in a list - you don't want communication with that IP Address. Unfortunately, when the IP address on one of the firewall's interfaces ends up in a list.... After realizing what happens, it becomes a palm-to-forehead moment that could result in a less than enjoyable discussion.
Granted, one might hope to think that any given address static or dynamic that they use wouldn't end up on a list, but its possible. Interestingly enough, the dynamic IP Address was evidently already on a list for a type of service that is specifically denied outbound in the firewall (making it all the more agitating).
