PfBlocker not blocking some porn sites



  • We're using a newly setup PFSense appliance to manage traffic for our guest network, and wish to block porn and some other content.

    We are using Squidguard and pfblocker. Squid guard is using Shallalist(sp?) and pfblocker the "porn"category at iBlocklist

    The problem - some sites, like Penthouse - seem to redirect to HTTPS - and the IP addresses (since pfblocker uses IP lists) apparently isn't in the porn category.

    I cannot find where to submit additions to the list.

    The source site for the category in iblocklist seems oriented towards squid/squidguard, as well as relying on email to contact them and no update form - and not much of a way to tell how the original lists get combined for iblocklist

    I could create a local IP list, but I really REALLY want to avoid trying to figure out all the IP's of the porn sites I might want to block in pfGuard that are already blocked in SquidGuard.

    I'd be happy with a way to enter site URL's into a list for pfBlocker.



  • You'll have to create a custom list in pfblocker with the IPs of Penthouse…but its a sad thing, they do write some good articles sometimes....

    Another option is to use OpenDNS Family Shield, they are pretty restrictive about this type of content and you can choose from 35 categories to block...

    Using both options is of course better.

    F.



  • If you aren't intercepting HTTPS then a family-friendly DNS like OpenDNS or Norton might be a better solution for you.



  • For the guest network, even at a school, I'm targeting more "good enough" (the savvy kids can set up VPNs or just use their cellular service).

    We used OpenDNS in the past - and canned the subscription. Not worth it for just the guest network. insufficiently granular for the main network. Staff kept giving away passwords to bypass blocks for stuff, by forgetting to obscure it when using it on projectors/etc. Ended with a Meraki box that I'm happy with, other than we've gained so many new devices we had to split out the guest network - thus the pfsense.

    I can generate IP lists if needed - even on more digging it seems no-one outside of iBlock generates prefab lists for porn, and figuring out how to suggest updates there - I've contacted both lock and the original source provider and gotten replies from neither.

    At this point, a tool that would lookup all the known IP's for a batch of URL's would make my life easier enough. Certainly easy enough to justify using more PFsense boxes where squid/etc. need to be setup easier in a de-facto appliance, we need more options than come available for filtering in a Mikrotik (love those boxes - the firewall, chain, and dynamic address rules on those are excellent), and cannot justify the licensing for a Meraki box (easy to arbitrarily manage the features presented being the strength there)

    Worst case - I'll roll my own. As long as I can generate a text list of IP's I'm set. I was just hoping for some alternate lists to download within pfGuard that I could point to, and maybe were easier to suggest updates for…



  • In the event I roll my own - it likely will be best to upload it as a dedicated file rather than use the "custom" box at the end of the config page for a rule.

    Any suggestions on best practices for a directory? Where I can find the list formatting rules other than 1 item per line, IP or CIDR?



  • @KOM:

    If you aren't intercepting HTTPS then a family-friendly DNS like OpenDNS or Norton might be a better solution for you.

    I have found that setting DNS servers to a service like this, and forcing users to use pfSense DNS Forwarder for their DNS (block DNS out from LAN/Guest to other external DNS) is effective for this sort of thing.
    DynDNS Internet Guide is another one of these services.



  • First - thank you everyone

    Just discovered DynDNS - it's not $1000/yr plus (more like 10 for a handful of statics, I only need 1)

    This will be a nice backup for the squid/squidguard/pfguard combo, AND I just got in touch with the guy who handles the IP blacklists for iblocklist.

    Good times.

    THAT said, I've updated the DHCP rules, and now need to figure out a firewall rule to block access to other DNS servers. Pretty trivial on my mikrotiks, but I'm still not entirely familiar with the pfsense box.


  • Moderator

    @dgarsys:

    First - thank you everyone

    Just discovered DynDNS - it's not $1000/yr plus (more like 10 for a handful of statics, I only need 1)

    This will be a nice backup for the squid/squidguard/pfguard combo, AND I just got in touch with the guy who handles the IP blacklists for iblocklist.

    Good times.

    THAT said, I've updated the DHCP rules, and now need to figure out a firewall rule to block access to other DNS servers. Pretty trivial on my mikrotiks, but I'm still not entirely familiar with the pfsense box.

    I think these services will offer some benefit, but they control what is in the lists, I would also expect them to be on the "Conservative" side to avoid Complaints from users.

    in pfBlockerNG, you can add Blocklists from IBlock and SquidGuard that will be the similar to what those Services offer. And most likely at a cheaper cost. Not to mention that its more configurable to do it in house.

    In pfBlockerNG v2.0, you will also be able to block by "Domain name" DNSBL….



  • @dgarsys:

    First - thank you everyone

    Just discovered DynDNS - it's not $1000/yr plus (more like 10 for a handful of statics, I only need 1)

    This will be a nice backup for the squid/squidguard/pfguard combo, AND I just got in touch with the guy who handles the IP blacklists for iblocklist.

    Good times.

    THAT said, I've updated the DHCP rules, and now need to figure out a firewall rule to block access to other DNS servers. Pretty trivial on my mikrotiks, but I'm still not entirely familiar with the pfsense box.

    I put this rule on LAN before any pass rule/s, it block any TCP/UDP to port 53 going anywhere except to LAN address (pfSense LAN IP where pfSense DNS is listening).



  • Moderator

    Blocking is two fold. Blocking via DNS (domain names) and by IP. It's easy for users to bypass this approach by going to the websites by IP.



  • @BBcan177:

    Blocking is two fold. Blocking via DNS (domain names) and by IP. It's easy for users to bypass this approach by going to the websites by IP.

    Yes, that is true. If the user has recorded the "naughty" web site IP addresses.

    Often these sort of web sites have content that is pulled in from all over the place and those link to ads, images… from other sites referenced by name and so they do not work. It is very difficult for the average user to get around that - so just DNS blocking is quite effective in an ordinary office environment. It stops "accidental" access of those sites.

    In a student college, for example, a lot more would be needed! Students would obtain a list of thousands of web site name-addresses and make their own local DNS on their laptop with thousands of "host overrides". That would fill in the "missing" name resolutions and allow them to navigate around all those sites by name without needing external name resolution.



  • I fully support using as many layers as possible as long as the CPU and RAM can keep up - which they can for right now with room to spare.

    OK - I can either PASS UDP/TCP traffic to the filtering DNS servers at DynDNS, and block all other DNS traffic, or set up DNS services and revise my DHCP rule before blocking all internally sourced DNS traffic.

    Any recommendations for that?

    I'll still be keeping PFGuard in place (NG actually - this box is NEW) as well as Squidguard.



  • I don't see any reason to have the clients going directly to DynDNS for their DNS.

    It seems easiest, and you get the benefit of having the local cache of already-resolved names, to have pfSense DNS point upstream to DynDNS. Then leave DHCP from pfSense at its default - the clients will be given pfSense LAN IP for their DNS server and gateway.
    Then you can block all DNS port 53 to anywhere other than pfSense LAN address.

    Thus you do not even need to mess with a special pass rule to let LAN clients through to DynDNS.



  • Figured as much. Thank you Phil.