PfBlockerNG
-
Either create a new white list alias (ipv4/ipv6) with Permit_outbound. Permit rules are listed automatically above deny rules.
Permit_both only if you really need certain traffic to always pass without initially being originated from your LAN network. So, extremely rare in most cases. *Or, if you enabled suppression in General settings, just suppress the IP's in question if they are blocked. (In the alert tab* or manually add them to pfBlockerNGSuppress alias).
I use a whitelist alias, since I push my settings to over 40 boxes on occasion. Edit 1 list = 40 boxes having the same whitelist.
*edit *
more detail on permit_outbound vs permit_both at request. -
I'm using the Suppress List feature. However, it has an inconvenience: I wanted to "unlist" some allowed IPs, so I deleted them from the pfBlockerNGSuppress Alias, but the widget always reports them as suppressed :(
-
I'm using the Suppress List feature. However, it has an inconvenience: I wanted to "unlist" some allowed IPs, so I deleted them from the pfBlockerNGSuppress Alias, but the widget always reports them as suppressed :(
Run a "Force Update" and it will update the suppression count but the IPs you un-suppressed will not be restored until the next "Cron" event. You also have the choice of a "Force Reload" which will reload all previously downloaded lists to reflect the current settings.
-
Anyone know what's going on here? If I'm reading this correctly, the "Snaity Check" isn't correct. Is it? If not, what do I need to do to fix it?
#########################
Sanity Check (Not Including IPv6) ** These two Counts should Match! **
–----------
Masterfile Count [ 32614 ]
Deny folder Count [ 41350 ]Duplication Sanity Check (Pass=No IPs reported)
–----------------------
Masterfile/Deny Folder Uniq check
Deny Folder/Masterfile Uniq check
64.104.125.0/24 64.71.172.0/28 64.71.172.128/25 64.71.172.16/31 64.71.172.19/32 64.71.172.20/30 64.71.172.24/29 64.71.172.32/27 64.71.172.64/26 64.78.162.0/24 65.19.135.0/24 65.19.152.0/24 65.19.188.0/24 65.255.36.0/24 65.255.38.0/23 65.63.56.128/27 65.63.89.204/30 66.160.130.0/24 66.160.162.0/24 66.201.188.0/24 66.231.64.0/20 66.54.80.0/22 72.28.117.0/24 74.125.16.64/26 91.234.36.0/24 95.130.197.0/25 98.126.145.0/24 98.126.221.0/24 98.126.222.0/24 98.126.90.0/24Sync Check (Pass=No IPs reported)
-
Run a "Force Reload"…
-
Ha, ha, ha… if I've learned and remembered anything from this forum, it was to perform a "Force Reload"!
I did it again and the cron is ready to run in 8 minutes. We'll see what happens. and I'll let you know.
-
I have submitted Pull Request #820 to fix the following issues:
1. Issue for Nano and Ramdisk Installations -
The /var and /tmp folders get wiped on Reboot. This will delete the /var/db/aliastables folder which on Reboot causes a 60 second timeout per pfBNG Alias (Which for some can timeout for 20mins). The new functionality will now Archive the Aliastables on any Alias updates.
Using the **<earlyshellcmd></earlyshellcmd>**functionality, it will restore the archived Aliastables on reboot to prevent this issue.
However, all of the other /var/db/pfblockerng files are also deleted. To restore those files, a "Force Update" is required or ultimately will get restored by the next CRON run. This however, will not affect the reboot process.
If you manually patched the download_file() function from 60 secs to 5 secs. You can revert that change as its not required with these new changes.
2. Improved the Alerts Tab to handle a Large firewall log file (as 2.2 has functionality to increase the size of the log file). These changes should result in a 50-75% improvement in loading/CPU usage. The Javascript functions were also improved to avoid it being called when the "Auto Resolve" checkbox was not enabled. This was spinning up 2-3 additional php-fpm processes. A timeout was also added to reduce the hostname lookup to 30seconds. If you refresh the Alerts Page shortly after it loads, it can seem to take a little longer, but this is due to the hostname lookups that are still in progress.
3. Made additional improvements to the IPv6 Regex functionality.
4. This will bump the pfBNG version to 1.05.
The following Pull request #820 has been merged… pfBNG v1.05
Additional Fix's in this PR (Including all the above)
1. Aliastables Issue with Nano/Ramdisk Installs (See above)
2. Alerts Tab Improvements. I have also added a "Filter Regex" which will allow you to filter the Alerts better. Please use a "regex-style" search pattern.
3. "Keep Settings" is now a Default Setting. If you haven't already, please enable this checkbox!
4. Fix to the Cron Scheduler (mismatch between 0hr and 24hr) Thanks to Phil.Davis, for spotting it and for providing the patch! Much appreciated!
Please let me know if you have any issues… I hope you guys are happy with the Improvements!
Thanks!
-
Nope - same issue… :-(
-
I'm using the Suppress List feature. However, it has an inconvenience: I wanted to "unlist" some allowed IPs, so I deleted them from the pfBlockerNGSuppress Alias, but the widget always reports them as suppressed :(
Run a "Force Update" and it will update the suppression count but the IPs you un-suppressed will not be restored until the next "Cron" event. You also have the choice of a "Force Reload" which will reload all previously downloaded lists to reflect the current settings.
I did that, nothing happens. Even rebooted pfSense without result.
-
2. Alerts Tab Improvements. I have also added a "Filter Regex" which will allow you to filter the Alerts better. Please use a "regex-style" search pattern.
Thanks for that.
Alerts tab as a whole is noticeably faster on system with (and even without) larger then default 500k logs.Filter options is a welcomed addition.
-
I'm using the Suppress List feature. However, it has an inconvenience: I wanted to "unlist" some allowed IPs, so I deleted them from the pfBlockerNGSuppress Alias, but the widget always reports them as suppressed :(
Run a "Force Update" and it will update the suppression count but the IPs you un-suppressed will not be restored until the next "Cron" event. You also have the choice of a "Force Reload" which will reload all previously downloaded lists to reflect the current settings.
I did that, nothing happens. Even rebooted pfSense without result.
Can you be a little more specific? You had IPs in the pfBlockerNGSuppress alias.. You removed one or more IPs. Then what happened? or not happened?
When you say "the widget always shows them as suppressed", are you saying the the Supp: xx count doesn't match the number of IPs in the Suppress Alias?
What is the Supp Count, and how many IPs are in the alias? Also can you view the file
/var/db/pfblockerng/pfbsuppression.txt
and see how that compares to the IPs in the Alias?
From what I understand, you are referring to "Suppression" with the "+" icon, and not a WhiteList Alias as those are two different things.
-
BBcan177 - first I'd like to say a personal thank you for your efforts.
So far so good with the block lists but one thing that is perplexing me in the alert logs is a random alert that has been generated a few times over a 24 hour period. It's the only one detected outbound from my LAN interface. The rule being triggered links to a blacklist that I am using from infiltrated.net. In the list column it shows "No Match". Can you explain what this means?
-
BBcan177 - first I'd like to say a personal thank you for your efforts.
Thanks! Just don't smite me.. Someone out there already has it out for me! :D
So far so good with the block lists but one thing that is perplexing me in the alert logs is a random alert that has been generated a few times over a 24 hour period.
If you make rule changes, this can re-order the Rule Numbers, and the logs can become out of sync. Clear the Firewall log and it should be fine after that!
-
Yeah, I need to make things clearer. You know what they say, "A picture is worth a 1,000 words.". Well attached is a screen cap of what I have.
Hi Bummer,
I finally realized why your Whitelist was placed above the Blocked Rules in the firewall even without changing the Rules order. Typically When you have permit Rules, you would change the Rules Order in the "General Tab" to have the Permit rules above the Block rules… But after looking at this picture, I see that your first rule is a "Permit" rule, so that is why its being placed above the Blocked Rules... It was just odd when I saw that in that Teamviewer session today.
-
I'm using the Suppress List feature. However, it has an inconvenience: I wanted to "unlist" some allowed IPs, so I deleted them from the pfBlockerNGSuppress Alias, but the widget always reports them as suppressed :(
Run a "Force Update" and it will update the suppression count but the IPs you un-suppressed will not be restored until the next "Cron" event. You also have the choice of a "Force Reload" which will reload all previously downloaded lists to reflect the current settings.
I did that, nothing happens. Even rebooted pfSense without result.
Can you be a little more specific? You had IPs in the pfBlockerNGSuppress alias.. You removed one or more IPs. Then what happened? or not happened?
When you say "the widget always shows them as suppressed", are you saying the the Supp: xx count doesn't match the number of IPs in the Suppress Alias?
What is the Supp Count, and how many IPs are in the alias? Also can you view the file
/var/db/pfblockerng/pfbsuppression.txtand see how that compares to the IPs in the Alias?
From what I understand, you are referring to "Suppression" with the "+" icon, and not a WhiteList Alias as those are two different things.
I had 12 IPs in the pfBlockerNGSuppress alias; then, I removed 10 of them. Committing a Force & Cron Update didn't do anything, so I decided to un-flag the "use Suppression" in the settings, commit changes via force Cron, then I enabled use Suppression again.
This resulted in 2 IPs left (so, it's OK until this step).Then I wanted to delete this 2 (last) IPs. I used the same procedure as above, but «the Supp: xx count doesn't match the number of IPs in the Suppress Alias» as you correctly wrote.
Now I simply deleted the pfBlockerNGSuppress alias, committed Force & Cron, and finally the last 2 IPs went away :)
-
Panz, I followed through your posts and tried to duplicate what you described. I couldn't do it. Worked as expected, have you had any more problems with this?
-
I deleted them from the pfBlockerNGSuppress Alias, but the widget always reports them as suppressed
Panz, I followed through your posts and tried to duplicate what you described. I couldn't do it. Worked as expected, have you had any more problems with this?
I could not duplicate this issue in my testing. If I delete an IP is the pfBlockerNGSuppress Alias and run a "Force Update" the widget gets updated accordingly. If I add an IP and "Force Update", it also updates accordingly. However, if you clear all the IPs in the Suppress Alias, and "Force Update", it doesn't clear the Count in the widget. I have a fix, but will add this to the next version, as its more cosmetic and does not affect the "Suppression" function.
-
Yes, I can duplicate this issue. It goes away if I manually delete the Alias.
-
Even after clearing the firewall logs this alert gets generated at 5:10am every day generating from my physical host windows box. From the system logs the only thing that I see running at that ungodly hour is the adobe flash updater. In the firewall logs there are 9 outbound attempts with my WAN address listed as the destination. I am using the reputation feature of pfBlockerNG but still can't figure out why my LAN IP of 192.168.1.200 would get blocked.
So far so good with the block lists but one thing that is perplexing me in the alert logs is a random alert that has been generated a few times over a 24 hour period.
If you make rule changes, this can re-order the Rule Numbers, and the logs can become out of sync. Clear the Firewall log and it should be fine after that!
-
The rule being triggered links to a blacklist that I am using from infiltrated.net. In the list column it shows "No Match". Can you explain what this means?
Hi Heisenberg1977,
I can't see the Destination IP as you have obfuscated it.
Try to run the one of the following commands from the shell or from the GUI Diagnostics:Command :
[ Using [b]1.2.3.4 as an IP, change it to reflect the IP that is in question ]
grep "^1.2.3." /var/db/aliastables/pfB_Infiltratednet.txt
or
grep "^1.2." /var/db/aliastables/pfB_Infiltratednet.txt
or
grep "^1." /var/db/aliastables/pfB_Infiltratednet.txtI assume that the IP being blocked is in a large CIDR that the Alerts tab is not matching. You will have to sift tru the output and see if you can find a match.
Note - you can also try changing the path/folder to the following if you have multiple Lists inside an Alias, as the /var/db/aliastables folder is a compilation of all the lists in an alias.
/var/db/pfblockerng/deny/*
or You can view the Aliastable in the Log Browser, and scroll tru the list to see what IP CIDR is the cause of the Block.
