PfBlockerNG v2.0 w/DNSBL

doktornotor

@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.

Gerard64

Again?
Geez :o

superapan

@doktornotor:

@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.

dennypage

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.

@doktornotor:

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.

BBcan177

@superapan:

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

doktornotor

@dennypage:

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.

dennypage

My point exactly.

@doktornotor:

Really take a while and think about what you are doing before creating absurd setups.

pfcode

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

BBcan177

@pfcode:

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.

pfcode

@BBcan177:

@pfcode:

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….

torsurfer

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 ~~than~~ not use these ports for DNSBL.

Do you have any ideas how I can get around this problem?

doktornotor

@torsurfer:

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.

RonpfS

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?

BBcan177

@RonpfS:

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...

RonpfS

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)

BBcan177

@RonpfS:

It is enabled ;)

I think the DangerRulz "State" needs to be set to "Flex"… If it was never downloaded in the first place, then there is nothing to restore... Some others seem to be failing also. Try those URLs in a browser tab and see if it works from there... If those DNSBL feeds still fail, send me the URLs, as the parser might have to be updated if those lists are formatted differently.

nb- please edit your post and put the log into a code format... There is a "#" icon in the Message editor... It makes reading posts a lot cleaner...

RonpfS

I did but I probably copied over the [ /code] end, or 3000 lines was too much :o
I edited and put a attachment file instead

DangerRulz was downloaded many times before.

torsurfer

@doktornotor:

"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 do have the LAN and loopback selected under the DNSBL Firewall Rule. This only ensures that the firewall doesn't prevent LAN and loopback from accessing the DNSBL VIP. It won't, however, 'make' Squid go to port 8081 for a blacklisted domain.

I think a solution to this problem might be the use of a reverse proxy, which I'd have to look into to see if it's possible. But thanks Doc for your comment.

doktornotor

@torsurfer:

I think a solution to this problem might be the use of a reverse proxy, which I'd have to look into to see if it's possible. But thanks Doc for your comment.

I think that will produce one giant kaboom, but whatever… You should rather look into NAT firewall rules with "This firewall" as source.

torsurfer

@doktornotor:

@torsurfer:

I think a solution to this problem might be the use of a reverse proxy, which I'd have to look into to see if it's possible. But thanks Doc for your comment.

I think that will produce one giant kaboom, but whatever… You should rather look into NAT firewall rules with "This firewall" as source.

Yeah, it involves some manual settings in lighttpd conf files to enable reverse proxy for 80 -> 8081 and 443 -> 8441. The settings will survive reboots, but won't survive any 'Save' done via the GUI. Still, it hasn't quite kaboom on me. ;D But definitely not preferable.

Re: NAT firewall rules. Unless there's something there at the NAT rules where it allows me to choose Localhost as the Interface, nothing that I've tinkered with so far has any effect on Squid. But thanks for the idea, Doc.

Edit: I've said too soon, the manual settings in lighttpd conf files get 'refreshed' after reboot. So now I have to look for a different solution. :(