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 in ifconfig -a | grep 'inet '|sed -e's/^.*.inet //'| sed -e's/ .*//'|grep -v '127.0.0.1'|sort -u
do
for TABLE in pfctl -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
done
The 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).
