PfBlockerNG
-
Yes, I'm a dummy. :-\
-
The Ips are to insure they are not blocked. These client are my bread and butter. One is from the UAE and the other is from IT.
-
I'll look in to the Alias. To me this seemed easier to manage.
-
Dumb question - where is the Spamhaus being denied access inbound? Via other lists? Sorry, I'm confused on this one. It shows it is blocking.
-
The ports I have opened are only the ones used. The last 2 are showing that they are blocking inbound.
-
As for the Continent tabs, it was set to block China. It was highlighted or whatever you want to call it. China is still showing up, but not as being blocked.
My concern it to protect the network by blocking all incoming traffic that could do harm.
-
-
No problem… Lets get it working for you...
-
Just be careful with a "Permit Inbound Rule". Make it very specific to a small IP range. You don't want to open up a large CIDR range if you don't need to... If the IPs are not in a Country that you are blocking, then a Country Block will not block it... Do you expect a list to Block any of those Whitelisted IPs... Its up to you. Just giving you information.
-
Spamhaus is "Deny Both" so if you do not have any Open ports, it could be "Deny Outbound".
-
Opened ports are opened if you created a NAT Rule or something similar.
Just remember that pfSense is a "Stateful Firewall" It blocks all Inbound by default. If a device on the Lan (Inside) wants to go out thru the Firewall, it will open an Outbound State which inturn allows that IP Inbound access. So generally, you can set these lists to "Deny Outbound"… Its only needed if you have defined open ports.
Read up on what a "Stateful Firewall means" ...
In the Asia Tab, Select "China", Set the "List Action" as "Deny Outbound" and Run a "Force Update"... If you defined any Open Ports, than use "Deny Both".
-
-
I really appreciate your help.
As for the inbound Ips, there is no range. They are 3 Ips and nothing else.
As for Spamhouse, e do have a mail server. My concern is more with spam coming in than leaving. Although, I don't want a hacked client spamming someone else.
Yes, the NAT rule only open the ports that we use. All other ports are closed.
Okay, I'm curious, for China why do I deny outbound? Isn't inbound that I should be concerned about?
Thanks!
-
I am using List Action: Deny Both. How can I use custom addresses to insert some whitelisted IPs ?
Giacomo
-
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?
