PfBlocker

LinuxTracker

Apply pfBlocker conf with action I want on rules.

Change alias description on created firewall rules and then customize it's order.

Back on pfBlocker and change action to alias only.

I did #1 and #2 and had just started on #3.
The moment I set the first country-group to alias (S.America) it tosses that country group off the list.
The remaining rules - order and customizations - were all reset.

As near as I can tell, any change at all in pfBlocker now mandates that I rewrite my rules from scratch.

It may be that every list update does the same.
I offer that because the rules table completely reset about 11:30pm today - I have to rewrite them again.

marcelloc

Linuxtracker,

How are you renaming rule description before changing action to alias only?
I did a clean install and then:

Installed pfblocker
denied inbound access to argentina and some countries on Oceania
Renamed the rule description from South America to block Argentina
saved firewall rules and applied changes
back to pfblocker, set action to alias only on South America tab
saved config

After this, both rules(South america and Oceania) are still there.

I'll do some tests with lists applied too.

LinuxTracker

@marcelloc:

Linuxtracker,

How are you renaming rule description before changing action to alias only?

I don't change the rule descriptions that are generated by pfBlocker.
I figured they were necessary for the widget to work.

When I write the rules from scratch, the descriptions are identical to the pfBlocker generated ones.
ie:```
pfBlockerSouthAmerica auto rule


Thanks

LinuxTracker

@marcelloc:

I did a clean install and then:

Installed pfblocker

denied inbound access to Argentina and some countries on Oceania

Renamed the rule description from South America to block Argentina

saved firewall rules and applied changes

back to pfblocker, set action to alias only on South America tab

saved config

After this, both rules(South America and Oceania) are still there.

I'll do some tests with lists applied too.

I need to clarify something.

Renamed the rule description from South America to block Argentina

You mean you changed the rule description from "South America", so that it read "block Argentina" - correct?

The last time I changed my rule descriptions, my pfBlocker widget quit working.
So, I've kept my rules descriptions identical to whatever pfBlocker created.

But:
It seems we can rename the pfBlocker-generated alias name
as long as the new alias name is at the beginning of the rules description.

That won't break the widget. Do I understand correctly?

marcelloc

Linuxtracker,

I've changed rule description to "pfBlockerSouthAmerica deny inbound" to do not break widget and also included a list with every hour update and rules are still there.

LinuxTracker

@marcelloc:

Linuxtracker,

I've changed rule description to "pfBlockerSouthAmerica deny inbound" to do not break widget and also included a list with every hour update and rules are still there.

OK Thanks for your time on this.

I'll uninstall the package tonight and see what a fresh start yields.

Question: How do I force a manual list update?

marcelloc

@LinuxTracker:

Question: How do I force a manual list update?

As I forgot to include this option, you can change update frequency to every hour and then run

/usr/local/bin/php -q /usr/local/www/pfblocker.php cron

on console.

LinuxTracker

@marcelloc:

Linuxtracker,

I've changed rule description to "pfBlockerSouthAmerica deny inbound" to do not break widget and also included a list with every hour update and rules are still there.

My custom lists weren't pulling new updates. I don't think the countries were updating either.

So I uninstalled the package and deleted the pgblocker*.xml files in /usr/local/pkg.
After reinstalling pfBlocker, both lists and countries updated correctly.

After that, I followed your guide as before.
Once my rules were setup, I went back into pfBlocker and changed Oceana from Deny All to Alias
and all my rule changes and ordering were thrown out.

That made me sad.

Update:
So with a heavy heart I set out to rewrite my rules from scratch.
I set the rest of the pfBlocker options to Alias and applied the settings.

I next went to rules - and discovered that my rule settings and ordering - were restored back to where I wanted them.

I am no longer sad. Now I am confused.

marcelloc

@LinuxTracker:

My custom lists weren't pulling new updates. I don't think the countries were updating either.

Did you tried to run it on console the way I described to you?

@LinuxTracker:

I don't think the countries were updating either.

Country lists are updated on pfblocker releases, not via cron job.

@LinuxTracker:

So I uninstalled the package and deleted the pgblocker*.xml files in /usr/local/pkg.
After reinstalling pfBlocker, both lists and countries updated correctly.

After that, I followed your guide as before.
Once my rules were setup, I went back into pfBlocker and changed Oceana from Deny All to Alias
and all my rule changes and ordering were thrown out.

That made me sad.

Update:
So with a heavy heart I set out to rewrite my rules from scratch.
I set the rest of the pfBlocker options to Alias and applied the settings.

I next went to rules - and discovered that my rule settings and ordering - were restored back to where I wanted them.

I am no longer sad. Now I am confused.

I'll keep trying to simulate this issue.
All tests I did, preserving the aliasname on firewall rule description were fine.

LinuxTracker

@marcelloc:

Did you tried to run it on console the way I described to you?

Yes. That did work and helped me to find a misspelled list name.

It'll also come in handy in the future.

@LinuxTracker:

Country lists are updated on pfblocker releases, not via cron job.

After I uninstalled the package -> deleted the pfblocker*.xml files -> reinstalled it - the country lists updated normally.

I think the package handler was wonky and didn't update pfblocker properly the last time.

@LinuxTracker:

I'll keep trying to simulate this issue.
All tests I did, preserving the aliasname on firewall rule description were fine.

That my rules would suddenly show correctly - after they were reset - seems really strange.

I have other pfSense boxes out there. I'll update one or two of them and see if any issues pop up.

I certainly appreciate your efforts.
For now I'll keep looking into things on my end.

archy

My exp for using pfBlocker ,
if I set max table size = 100000 ,
there still have error logged ,

php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:23: cannot define table pfBlockerNorthAmerica: Cannot allocate memory pfctl: Syntax error in config file: pf rules not loaded The line in question reads [23]: table <pfblockernorthamerica>persist file "/var/db/aliastables/pfBlockerNorthAmerica.txt"

if I set max table size = 1000000

problem solve , just like to share .</pfblockernorthamerica>

dhatz

I wonder if the pfBlocker developers have considered using pf anchors ( http://openbsd.org/faq/pf/anchors.html ) ?

IMHO it'd be a nice design practice for pfsense packages to use anchors.

Check article http://forum.pfsense.org/index.php/topic,45277.0.html which among others notes the recent pf extensions by Apple to make sure Mac OS X applications that interact with the packet filter configuration do not clobber each others' rules.

marcelloc

dhatz,

Pfblocker use pfsense firewall rules and url table.

No pf rule is created by this package, only xml info to pfsense alias and rules.

anyway, thanks for this suggestion :)

stilez

I managed to get Pfblocker to work here (2.0.1 i386 full), and have a few suggestions for improvement. No obvious tracker so posting them here!

If php memory still needs editing, can there be an option "increase/override PHP memory" (hacking code is ugly compared to interface or config options). If not possible and yet needed should a feature be requested for system tunables -> PHP memory?
Can "reload lists" and "clear tables" buttons be added? The first because if it fails (and perhaps isn't aware it failed) it can wait a long time to try again, the second because if used on hardware that can't increase PHP allocation to display the tables and their "delete all" option, the user doesn't have any easy way to delete the tables.
Can we have "allow on all interfaces" to match "block on all interfaces"? There are allow/exclusion lists in use too.
Last request is a bit more involved. Can there be an option that if set, pfblock produces a merged allow/block lists (by removing allow IPs from the block ranges) or can automatically set the tag rules below, so that manual aliases + tagging aren't needed when using an allow/exclusion list.

As well as blocklists, I-BL publish known exceptions (the "exclusions" list), and these can need sneaky config. I'm new-ish to this but AFAIK this works, if so then can someone add it to the Pfblock FAQ/wiki/howto?

Example:

Imagine Spamhaus "evil-spam" list contains 44.0.0.0/12, I-Blocklist exclusion list contains a number of important exclusions including one for 44.0.8.0/24 (nice company/genuine news site), and I currently have the firewall set to deny by default all unsolicited incoming traffic other than on specific open ports: 192.168.1.15:[3000-3001] and 192.168.1.22:[20000-20001]. Nothing unusual - we want to block evil ranges, not autoblock known exclusions, and have a few tightly controlled open ports. There are just 4 rules plus "default deny": (A) block Spamhaus "evil spam" list, (B) Allow I-Blocklist "exclusions" list, (C) Open port for any traffic with destination 192.168.1.15:[3000-3001], (D) Open port for any traffic with destination 192.168.1.22:[20000-20001].

Normal filters won't work. If the rules are ordered B->A->C->D then traffic from 44.0.8.0/24 or any other "exclusion list" site for other servers or ports will "pass" under rule B before they can be rejected by rule C/D. If ordered C->D->B->A then traffic from "evil spam" list sites won't be blocked from the open ports. The problem is that downloadable exclusions/allow lists aren't an absolute allow, they only mean the downloadable block lists shouldn't be applied to those ranges. Also these are regularly updated lists so ditching them or manually editing are both unlikely to be optimal. What's really needed is a way to say "don't block via rule: <blocklist alias="">if the packet matches rule:<allowlist alias="">".

I use tagging (AKA packet marking, policy filters):
1. Test packet against block rule -> tag as "BLOCKLIST" if a match (see "advanced" options at the end of the rule definition form)
2. Test packet against allow rule -> delete the tag if a match (set to "")
3. Test if packet tag == "BLOCKLIST" -> block it.
4. Continue with other rules
Result - packets matching the allow list aren't blocked, but nor are they immediately passed. They get tested against the rest of the rules. I'm not sure if 2+3 can be combined to make 2 rules: (Test packet against allow list INVERTED and tag if matched with "NOTEXCLUDED") -> (Test packet against double condition: matches blocklist AND tag = "NOTEXCLUDED", block if a match).

Haven't seen a reference to this here so hopefully it will help someone!</allowlist></blocklist>

marcelloc

Hi stilez,

Thanks for your feedback.

The pfBlocker wiki is:
http://doc.pfsense.org/index.php/Pfblocker

@stilez:

If php memory still needs editing, can there be an option "increase/override PHP memory" (hacking code is ugly compared to interface or config options). If not possible and yet needed should a feature be requested for system tunables -> PHP memory?

I'll try to push an update to pfsense system advanced features to enable this but I have first to ask core team if It's a feature they want on pfsense.

@stilez:

Can "reload lists" and "clear tables" buttons be added? The first because if it fails (and perhaps isn't aware it failed) it can wait a long time to try again, the second because if used on hardware that can't increase PHP allocation to display the tables and their "delete all" option, the user doesn't have any easy way to delete the tables.

The update now/reload list is a feature I forgot to include, but it is on my todo list. :)

To remove a table, just delete the list that generated it and the table will be flushed.

@stilez:

Can we have "allow on all interfaces" to match "block on all interfaces"? There are allow/exclusion lists in use too.

If you select all interfaces on Inbound and create a list/country list with allow inbound isn't it a way to get it working?

@stilez:

Last request is a bit more involved. Can there be an option that if set, pfblock produces a merged allow/block lists (by removing allow IPs from the block ranges) or can automatically set the tag rules below, so that manual aliases + tagging aren't needed when using an allow/exclusion list.

As well as blocklists, I-BL publish known exceptions (the "exclusions" list), and these can need sneaky config. I'm new-ish to this but AFAIK this works, if so then can someone add it to the Pfblock FAQ/wiki/howto?

allow action works as a whitelist and is applied before deny rules.
If you block 44.0.0.0/12 on a list and allow 44.0.8.0/24 on other list, it will work

@stilez:

Example:

Imagine Spamhaus "evil-spam" list contains 44.0.0.0/12, I-Blocklist exclusion list contains a number of important exclusions including one for 44.0.8.0/24 (nice company/genuine news site), and I currently have the firewall set to deny by default all unsolicited incoming traffic other than on specific open ports: 192.168.1.15:[3000-3001] and 192.168.1.22:[20000-20001]. Nothing unusual - we want to block evil ranges, not autoblock known exclusions, and have a few tightly controlled open ports. There are just 4 rules plus "default deny": (A) block Spamhaus "evil spam" list, (B) Allow I-Blocklist "exclusions" list, (C) Open port for any traffic with destination 192.168.1.15:[3000-3001], (D) Open port for any traffic with destination 192.168.1.22:[20000-20001].

Using action as alias only, you can create rules the way you want on firewall -> rules

stilez

@marcelloc:

@stilez:

Can we have "allow on all interfaces" to match "block on all interfaces"? There are allow/exclusion lists in use too.

If you select all interfaces on Inbound and create a list/country list with allow inbound isn't it a way to get it working?

Not really.

Well, technically yes but at the cost that it's a global setting for all PFblock rules, meaning every other list would also get applied to all interfaces. You might not want that. (If it was that easy then logically nobody would need "Deny Both" as an option, they'd just use "Deny Inbound" and trap all interfaces instead! If "Deny Both" isn't redundant then logically "Allow Both" probably isn't either.) Simple option worth adding, for completeness if nothing else :)

@marcelloc:

@stilez:

Last request is a bit more involved. Can there be an option that if set, pfblock produces a merged allow/block lists (by removing allow IPs from the block ranges) or can automatically set the tag rules below, so that manual aliases + tagging aren't needed when using an allow/exclusion list.

As well as blocklists, I-BL publish known exceptions (the "exclusions" list), and these can need sneaky config. I'm new-ish to this but AFAIK this works, if so then can someone add it to the Pfblock FAQ/wiki/howto?

allow action works as a whitelist and is applied before deny rules.
If you block 44.0.0.0/12 on a list and allow 44.0.8.0/24 on other list, it will work

@stilez:

Example:

Imagine Spamhaus "evil-spam" list contains 44.0.0.0/12, I-Blocklist exclusion list contains a number of important exclusions including one for 44.0.8.0/24 (nice company/genuine news site), and I currently have the firewall set to deny by default all unsolicited incoming traffic other than on specific open ports: 192.168.1.15:[3000-3001] and 192.168.1.22:[20000-20001]. Nothing unusual - we want to block evil ranges, not autoblock known exclusions, and have a few tightly controlled open ports. There are just 4 rules plus "default deny": (A) block Spamhaus "evil spam" list, (B) Allow I-Blocklist "exclusions" list, (C) Open port for any traffic with destination 192.168.1.15:[3000-3001], (D) Open port for any traffic with destination 192.168.1.22:[20000-20001].

Using action as alias only, you can create rules the way you want on firewall -> rules

No, I wonder if it's well explained. In fact you can do it with aliases (that's how I'm doing it) but not because it acts as a whitelist and not in an easy obvious way. The problem is that normally the flow of rules is like this:

rule 1 -> if matched then pass/block/refuse/route otherwise continue with rule 2
rule 2 -> if matched then pass/block/refuse/route otherwise continue with rule 3
rule 3 -> if matched then pass/block/refuse/route otherwise continue with rule 4
etc (eventually some rule matches or the default rule applies)

But with block and allow lists the flow is like this:

rule 1 -> if matched then pass/block/refuse/route otherwise continue with rule 2
rule 2 -> if matched then pass/block/refuse/route otherwise continue with rule 3
rule 3 (ALLOW LIST) if matched then IGNORE/SKIP rule 4 and continue with rule 5 otherwise continue with rule 4
rule 4 (BLOCK LIST) if matched then block/refuse otherwise continue with rule 5
rule 5 -> if matched then pass/block/refuse/route otherwise continue with rule 6
etc

An allow list doesn't cause a pass or block event, it causes a skip event - the block list won't be tested. Unfortunately usual pfsense rules don't include a "skip" option, you can't add (without advanced options) a rule that says "if matched, ignore some other rules and continue with checking the rules after them". You also can't avoid this structure if an allow list is used, unless your other rules are really simple, but we can say that people choosing pfsense usually won't have such very simple rules. Logically it can't be turned into a list that avoids skip-on-match. You can do it only 2 ways, by adding tag conditions to the existing automatic rules or by pre-merging the lists to create an "effective" block list (without allow list), either works. Logically, allow lists really set an automatic extra tag condition on the pfblock automatic rules which may be needed whenever an allow list is used, but I think it's not obvious.

marcelloc

I understand your point but it will not be easy to exclude a cidr inside another cidr.

The skip rule option is native on ipfw, and as well as I know about pfsense, floating rules use ipfw but it think there is no skip option on gui to apply it.

The idea of selecting interfaces for each tab is not bad, but I think most users prefer a simple way to apply conf. Every advanced rule apply can be done using alias just like you do.

stilez

@marcelloc:

I understand your point but it will not be easy to exclude a cidr inside another cidr.

The skip rule option is native on ipfw, and as well as I know about pfsense, floating rules use ipfw but it think there is no skip option on gui to apply it.

Yeah, that's what I found. But man pf suggests a way to get round it perhaps so simple that pfblock's rules could be tweaked to do it automatically.

Suppose we have 2 lists, normally Pfblock creates automated aliases, for example "PFBLOCK_BLOCKS" and "PFBLOCK_ALLOWS". It uses these to create automated rules:

[some rules…]
If (MATCHES: PFBLOCK_ALLOWS) then (pass)
If (MATCHES: PFBLOCK_BLOCKS) then (block/reject)
[other rules…]

Pfblock has to do that because that's pretty much all that it can do with usual rule conditions.
But suppose when an allow list is in use, the automatic rules had these different conditions:

[some rules…]
If (MATCHES: PFBLOCK_BLOCKS) then (ADVANCED: TAG WITH: "PFBLOCK_BLOCK")
If (! MATCHES: PFBLOCK_ALLOWS) AND (ADVANCED: IS_TAGGED WITH: "PFBLOCK_BLOCK") then (block/reject)
[other rules…]

This uses ordinary Pfsense rules to do exactly what's desired, exclude a CIDR within a CIDR.
It's not just good for simple pfblock lists, but also multiple block/allow lists and any mix of reject/block, exactly correctly:

[some rules…]
If (MATCHES: PFBLOCK_REJECTLIST_1) then (ADVANCED: TAG WITH: "PFBLOCK_REJECT")
If (MATCHES: PFBLOCK_REJECTLIST_2) then (ADVANCED: TAG WITH: "PFBLOCK_REJECT")
If (MATCHES: PFBLOCK_BLOCKLIST_1) then (ADVANCED: TAG WITH: "PFBLOCK_BLOCK")
If (MATCHES: PFBLOCK_BLOCKLIST_2) then (ADVANCED: TAG WITH: "PFBLOCK_BLOCK")
If (MATCHES: PFBLOCK_ALLOWS_1) then (ADVANCED: TAG WITH: <null string="">or "PFBLOCK_ALLOW")
If (MATCHES: PFBLOCK_ALLOWS_2) then (ADVANCED: TAG WITH: <null string="">or "PFBLOCK_ALLOW")
IF (ADVANCED: IS_TAGGED WITH: "PFBLOCK_BLOCK") then (block)
IF (ADVANCED: IS_TAGGED WITH: "PFBLOCK_REJECT") then (reject)
[other rules…]

This sequence of testing and use of advanced -> tag conditions (built into pfsense rules) correctly handles any combination of block, reject or allow lists on any interface, that it's possible to configure within pfblock. It prioritises block over reject if the IP is on both kinds of list. It's also simple, efficient and easy to understand. If pfblock created these automatic rules rather than its existing ones it would then correctly handle any lists the user can enter.</null></null>

marcelloc

That's a good suggestion, include a checkbox with tag rules for example.

I'm quite busy on work + sarg package + mailscanner quarantine tab but it's on my todo list now.

stilez

@marcelloc:

I'm quite busy on work + sarg package + mailscanner quarantine tab but it's on my todo list now.

Sounds good. I'm trying to figure how to use syslog-ng, logzilla/octopussy or some other advanced syslog web viewer working with pfsense so the logs can be kept on the router and analysed/viewed in full via the web. Don't suppose you know whether there's a simple how-to pfsense this that I missed anywhere? :)