PfBlockerNg, What's the real need? Think you'll be surprised
-
I betcha significant number of pfSense users run pfBlockerNg in their home environment without realizing whether they really need it or not. Most might just run it because they might not realize the cost-benefit (cost in terms of memory usage & overhead of running the pfBlockerNg package and benefit in terms of blocking traffic that is already blocked by the pfSense itself) aspect of running pfBlockerNg.
Why is pfBlockerNg really needed (at least for most of the residential use case)? That is the question of the moment for me. As is (aka out-of-the-box), the pfSense auto blocks any inbound traffic on the WAN side. So then what's really the use case for most of the homebound end-users? Maybe, for some reason, they want to selectively restrict inbound connections or may be they want to restrict/limit outbound connections from within their network from hosts that might have been comprised (ie: worms/trojans that initiate outbound connection which bypasses the inbound WAN originated connections).
So, I ask you folks to chime in and share your thoughts..
-
I run mail, web and file servers and it's a domestic environment
Obviously I have ports that are open and I use it purely for Geo block purposes. I do not use the DNSBL features - I did for a short while but SWMBO complained about it being too effective. :)
-
Same here basically. I host a small private discussion forum and use it for the Geo blocking to keep spammers out. I recently enabled the DNSBL feature to block unwanted ads and I'm quite pleased with it.
-
I recently removed pfBlockerNg from my system. For me it wasn't causing any performance-related issues to start. However, I started thinking about why I had it running and the original intent was to geo-block certain countries. Once I started thinking about it, I figured that most actors who would be able to penetrate my next layer of security would also have the means to attack from anywhere in the world, so my conclusion is that geo-blocking is probably not all that effective since it can easily be bypassed.
-
pfBlockerNG is much more than simple geo-blocking. I use it with many blacklists that stop bad IP's, ranges and domains. In the upcoming version it will be easy to block specific services. See here https://www.patreon.com/pfBlockerNG
-
The new version looks very useful and looks like it will be a replacement for SquidGuard (or work with it). When will it be available on pfSense 2.4.2?
-
Ask @bbcan177 :) he's the developer. I'm hoping soon, once the bugs are ironed out.
-
The OP seems to be conflating the fact that they weren’t using pfBlockerNG appropriately with the value of the pfBlockerNG package itself…
Yes, geo-blocking on a SoHo network where you aren’t running servers is of limited value because everything should hit a dead-end. pfBlocker also does IP and DNS blackholing and that is very valuable in that environment.
I can recall a specific incident with a friend of mine, they would be a client but they’re too far away. A customer of theirs picked up something nasty, which emailed itself to my friends’ business, the AV at their provider missed it, a colleague opens it (because they’re expecting a document) and it was game over. They nearly lost the business and their home as a result (no backups of certain key data.)
Whilst by no means the only mitigation, but a firewall is one component of “defence in depth”. pfBlockerNG could have stopped issues by blocking outbound access to the C&C and payload servers through blackhole lists. It’s not just about what comes in unsolicited - sometimes nasty things get pulled in by client devices. We had a long chat and they now have much better IT suppliers now btw.
I also use mine at home to block ads and tracking servers, but the prime use case for pfBlockerNG in a SoHo environment is the same principle. The firewall covers Outbound as well as inbound traffic.
-
Whether home or business, if I could only choose one package to install it would be pfBlockerNG. First, DNSBL is fantastic (think built-in Pi-hole). Yes, the default WAN rules will already block everything if you don't have any forwards. But as motific and others have alluded to, even then, if you deny both directions (LAN and WAN) via the IP component your internal clients will get blocked when trying to communicate with known bad addresses. The alerts/reports will show this activity as well. This is a pic of the alerts on the new version, but the older version had similar functionality. On this particular firewall, if the LAN interface shows up in the list of "denies" I need to investigate the cause of the alert.
