PfBlockerNG v2.0 w/DNSBL
-
I manually set ad domains to 127.0.0.1, which results in a "Non-existent domain" response from Unbound. No waiting for timeouts. A website or app that breaks if ads can't be reached is a site or app I don't care about. Others may not be able to say that.
Every website that has annoying ads, I've been blackholing DNS for over a year without issues. Results may vary.
Truth be told, I suspect blackholing undesirable traffic along those lines should work for most things. I haven't tried it myself to see what could go wrong. But, that kind of blackholing would kill the logging system pfBlockerNG uses for the Alerts page. For non-HTTPS traffic, pfBlockerNG logs blocked traffic when an endpoint pulls down the php page that its redirected to. This logging method has the advantage of logging blocked traffic even when DNS entries are cached by an endpoint, and also captures other useful diagnostic information, such as the referrer URL, which tells you what page you were looking at that had the blocked traffic.
Redirection doesn't work for HTTPS traffic, as the browser won't complete a TLS handshake with the DNSBL webserver due to the certificate issue. So, BBcan177 came up with a workaround that basically logs the failed HTTPS connection. But, while alerts are still logged, this method doesn't provide the same amount of information.
Getting the Alerts working reliably is very important. The common DNS blocklists include things that definitely will break stuff. Many include various AWS domains, which breaks all kinds of things. Separate from that, I found that the Amazon and HBO Go apps did not work properly until I unblocked a few domains. I'm sure those aren't the only examples.
My guess is my limited list doesn't cause issues, but when you feed a list of 1k+ records, one of those may break a page. In general, web pages should function on their own, except when referencing CDN resources.
The only time I care about logging is when debugging an issue. Being a home user, I have the convenience of debugging after the fact instead of digging through logs for a one-off that needs to be solved.
What I really don't want is yet another service listening to a port on my firewall. But if there is a high enough risk of breaking popular sites, then I guess I'd rather not blackhole. I'd be interested to know what that risk is. How many of the top 1000 sites completely break when blackholing DNS instead of redirecting?
There is also the issue that Chrome and others are looking at making self-signed certs virtually useless in the near future. I'd rather not have to install a self-signed CA to every device on my network, especially when visitors come over.
"Hey bro, I have this ad block on my network, you'll need to add my self-signed root-CA to your computer, otherwise your browser is going to throw a tantrum on every site you visit"
Just saying.
-
"Hey bro, I have this ad block on my network, you'll need to add my self-signed root-CA to your computer, otherwise your browser is going to throw a tantrum on every site you visit"
Hi Harvey, there is nothing in the Instructions to require adding any self-signed CAs to any browser? As reggie14 has stated, adding a Self-Signed CA to a browser will not achieve anything either.
There is a self-signed CA for DNSBL but that is only there so that the Browser will terminate the connection when it sees that it is not a valid cert for HTTPs. Without a DNSBL Cert, the Browser will take more time to terminate the session. DNSBL then uses the Lighttpd error.conditional log to find the Domains that failed and log those requests to the Alerts Tab.
I think its best not to base everything on a few exceptions that break browsing, or cause some nuisance alerts. Most of those seem to be on Safari anyways. Suppressing those domains is also easy to accomplish.
And if you have a Guest network, and you wanted to bypass DNSBL, then you would just assign a different DNS server (ISP or Google) for that LAN segment via DHCP and the issue is moot.
-
Getting back to the main issue, I'd be curious to see some examples of websites that generate a HTTPS/TLS warning/error message. I haven't had any recently, except for when I click on a link that redirects me through tracking domains (SlickDeals.net are a good example of this). I haven't gotten any error messages when there's simply an ad on a page that gets blocked.
-
Hi, I'm a bit confused as how to configure pfBlockerNG.
I run a server, just a Mumble and a game server. I only wish them to be port-forwarded for IPs of my country (Sweden).
For instance, Mumble runs on the default 64738. I have it port-forwarded in firewall NAT. With pfBlockerNG running, I select 'Sweden' under Countries->Europe. Under 'List Action' I select 'Permit Both'. I Force Update.
Rule order is default pfB_Pass/Match | pfB_Block/Reject | pfSense Pass/Match.
My UK-based friend has no issues connecting, which is not my intention. How exactly would I go about to configure this?
Thanks a bunch in advance.
-
Select all countries except Sweden. Set action to deny inbound.
-
@Gé:
Select all countries except Sweden. Set action to deny both.
Nooooooooooooooooooooooooooooo!!! Here we go again.
Look. This is absolutely absurd. Use the Sweden as alias for the traffic source on the port-forwarding rule, instead of blocking the entire world. WTF.
-
Again?
Geez :o -
@Gé:
Select all countries except Sweden. Set action to deny both.
Nooooooooooooooooooooooooooooo!!! Here we go again.
Look. This is absolutely absurd. Use the Sweden as alias for the traffic source on the port-forwarding rule, instead of blocking the entire world. WTF.
This much I've realized. It's just that exactly how I would go about doing what you just described? Does it mean 'List Action' be 'Alias'? Do these aliases have anything to do with the aliases in Advanced Inbound Firewall Rule Settings? I apologize for my ignorance, it's just that the one sentence "Use the Sweden as alias for the traffic source on the port-forwarding rule" doesn't explain it enough for me, unforuntately.
-
Much as I hate to dip into this, it should be pointed out that high level statements like this should be viewed as guidelines rather than absolute rules. The reason for this guideline is to help keep the number of rules under control. Depending upon the reputation lists you have and your de-dup settings, you may end up with about the name number of rules either way. If you care about efficiency, the appropriate thing to do is to compare the number of resulting rules and choose your approach based on the actual numbers.
Nooooooooooooooooooooooooooooo!!! Here we go again.
Look. This is absolutely absurd. Use the Sweden as alias for the traffic source on the port-forwarding rule, instead of blocking the entire world. WTF.
-
I run a server, just a Mumble and a game server. I only wish them to be port-forwarded for IPs of my country (Sweden).
See the following:
https://forum.pfsense.org/index.php?topic=99987.msg572399#msg572399 -
If you care about efficiency, the appropriate thing to do is to compare the number of resulting rules and choose your approach based on the actual numbers.
Sigh… If you care about efficiency, you do NOT ever create a rule containing tens of thousands of huge CIDRs for absolutely no reason, when the same job can be done by a whitelist rule with many many many orders of magnitude lower overhead, not wasting your RAM and CPU for nothing. Only pass/forward traffic that you want, instead of blocking everything else. The rest will be taken care of by the implicit default deny rule. Really take a while and think about what you are doing before creating absurd setups.
-
My point exactly.
Really take a while and think about what you are doing before creating absurd setups.
-
Hi,
I got the second crash report today since upgraded to V2, the first one was at: https://forum.pfsense.org/index.php?topic=102470.msg575377#msg575377
PHP Errors:
PHP Fatal error: Maximum execution time of 900 seconds exceeded in /usr/local/pkg/pfblockerng/pfblockerng.inc on line 1663 -
I got the second crash report today since upgraded to V2, the first one was at: https://forum.pfsense.org/index.php?topic=102470.msg575377#msg575377
I had one other complain about this, but couldn't track down the issue. Send me an email and I will get some more details from you. Maybe its doing that during a Cron event and timing out on a download as the 900 seconds is the php cURL timeout limit.
-
I got the second crash report today since upgraded to V2, the first one was at: https://forum.pfsense.org/index.php?topic=102470.msg575377#msg575377
I had one other complain about this, but couldn't track down the issue. Send me an email and I will get some more details from you. Maybe its doing that during a Cron event and timing out on a download as the 900 seconds is the php cURL timeout limit.
Dont know what exactly was happening when the crash occurred. I login to the pfSense web GUI, Status: Dashboard, and saw there was a prompt on the top of the page saying there was a crash report and then I just submitted the report….
-
Hi
I have an issue trying to get Squid to play nice with pfB DNSBL. My DNSBL is configured to use ports 8081 and 8441. And this is also properly reflected under the "NAT: Port Forward" where port 80 is forwarded to 8081 and port 443 to 8441 (for LAN interface).
However, Squid just won't seem to respect the Port Forward, hence, when the Resolver returns the IP 10.10.10.1 for an ad domain, Squid still insists to go out to 10.10.10.1:80 instead of 10.10.10.1:8081. The same applies to SSL connections i.e. it will use 443 instead of 8441.
I'm already using ports 80 and 443 (pfSense GUI, etc) for other usages. So I rather
thannot use these ports for DNSBL.Do you have any ideas how I can get around this problem?
-
I have an issue trying to get Squid to play nice with pfB DNSBL. My DNSBL is configured to use ports 8081 and 8441. And this is also properly reflected under the "NAT: Port Forward" where port 80 is forwarded to 8081 and port 443 to 8441 (for LAN interface).
However, Squid just won't seem to respect the Port Forward, hence, when the Resolver returns the IP 10.10.10.1 for an ad domain, Squid still insists to go out to 10.10.10.1:80 instead of 10.10.10.1:8081. The same applies to SSL connections i.e. it will use 443 instead of 8441.
"For LAN interface" is useless when the traffic is from localhost. Perhaps tick and select LAN and loopback under DNSBL - DNS Block List Configuration - DNSBL Firewall Rule.
-
I noticed that when a download fail, the list is removed.
[ PRI3_DangerRulez ] Downloading update . cURL Error: 28 Resolving timed out after 15567 milliseconds Retry in 5 seconds... . cURL Error: 28 Resolving timed out after 15544 milliseconds Retry in 5 seconds... . cURL Error: 28 Resolving timed out after 15580 milliseconds Retry in 5 seconds... .. unknown http status code [ pfB_PRI3 - PRI3_DangerRulez ] Download FAIL [ 12/02/15 19:29:38 ] Firewall and/or IDS are not blocking download. The Following list has been REMOVED [ PRI3_DangerRulez ]If the list existed before the update, it could be useful to have an option to keep and use the previous file until the next update succeed?
-
If the list existed before the update, it could be useful to have an option to keep and use the previous file until the next update succeed?
Check the General Tab for that exact option :) It should default to enable… Will have to check that...
-
It is enabled ;)
However it is not there at the end of the update.
I did a reload at the end and it uploaded the list fine.
[UpdateLog 20151202.txt](/public/imported_attachments/1/UpdateLog 20151202.txt)
