PFSense 23.05.1 and pfBlocker

Netgate 2100 running PFsense 23.05.1, and trying to get pfBlockerNG 3.2.0._5

What ever I do I can not get pfBlocker to work, only one lan connection.

Followed this old steps - PfSense Web Filter With pfBlockerNG - Filter Ads and Malicious Websites | Open School Solutions

Can someone point me in any direction to get it to work.

I have a video here on that topic

Hey Tom,

With this stuff I’m mostly concerned about out bound filtering and am wondering if this is worth much? My WAN side is pretty much locked down already, but bad stuff happening on my LAN reaching out to a bad server is where the real action is (AFAIK). If I add this stuff to my LAN rules I can log/block known bad stuff, but that still leaves a lot of exposure for the unknown stuff. The trade-off you mention in your video about false positives becomes a crucial point of determining effectiveness.

And at this point I step back and ask myself what am I protecting? My LAN or my potentially infected PC? The PC is a whole other conversation. For my LAN, I feel like I can rely on my inter-LAN FW rules to mitigate horizontal movement (bummer for those on the subnet). Locking down inbound-LAN stuff is straight forward, and internal services can be further protected by isolating them. After that if the bad guys use me for my bandwidth I should see that in traffic spikes. So I get some indication of something bad happening on my LAN in that regard. For anything else I have to use the various tools for PC protection to solve that other problem.

Does all that spaghetti logic make sense to you? Am I thinking about this stuff correctly?

You can set the rules on pfblockerng for inbound and outbound on the on malicious IP addresses from the priority feeds. Unless I am misunderstanding what you are after.

The lists used by pfblocker are not for unknown bad sites, they made from knowns bad sites. There is always a chance something can get through and the best mitigation for that is to have a plan.

The heart of this question may be, is it a chance or a relative certainty that something gets out (or is not caught)? The ephemeral nature of IPs among other things makes me think these block lists (and the admin selecting these lists) needs to error on the side of caution. Which makes me think this isn’t terribly effective. Tom, feel free to correct me if I’m wrong. But I bet 95% of this battle is fought on the PC side. Edge “content” filtering just isn’t that useful.

I like to block hard no’s on my gateway only, those being tor and public DNS IPs only. The public DNS are for bad actors inside my network using public DOH servers, which bypass my DNS filtering. For others using normal DNS there is a simple redirect rule for them. For those smarter than that I don’t have a good way to filter this on the gateway.

DNS filtering is better than nothing but things still get through.

What do you think about this idea?

For those cases where some bad actor/script is not using one of those IP lists and not using public DOH or regular DNS, we need a way to identify them. They are the last group of bad guys I can’t account for at my gateway (AFAIK). I have thought about writing a script that would scan my DNS & outbound WAN logs to create two tables of internal IP addresses. If an internal IP address hasn’t communicated with my DNS server in say 5 minutes but has been active on my WAN list then that internal IP is added to a log/block list. The theory being this is likely VPN traffic or something using a private DOH server. I think 5 minutes would be enough to remove most false positives but that could be changed.

I’ve had this idea for a while but just never have time to act on it.

What do you think?

Network traffic analysis is and will always be a cat and mouse game. It all depends on how much time you want to sink in it. Me personally, I setup all the feeds in pfblockerng that make sense in my home/home lab for DNS/IP. I don’t mess around with IPS/IDS and setup certificates or setup a proxy, but that would be the way to go to inspect your traffic for threats inbound and outbound and block them.

I don’t like IDS either. DNS filtering is the best bang for the buck with content filtering that I can see.

My only goal with this idea is to force my LAN users to use my DNS. In both of our setups we have a pretty big hole in that regard. If we could completely lock down traffic not using our DNS I think we could close the door on a lot of traffic we both currently miss. Of course, there will always be the brand new stuff that our DNS filter doesn’t see, but that is the never ending cat & mouse game we all play (unless you run a DNS “access list”, which I have done in the past).

Pfblockerng has a DOH list you can block. Also you can setup a firewall rule to only allow dns queries to your DNS server. Something like this.

Deny—source(LAN NET)—source port(*)—destination(!LAN Address)—destination port(53)

What this rule is saying is deny all DNS traffic that is NOT the lan address.

Yep, that is all well and good, but I am talking about the “other” traffic. That closes one door but leaves two or three doors wide open.

Note: I suggest redirecting udp traffic instead of blocking it. I don’t like the tech help calls.