PfBlocker

OldGrayandCranky

I believe that a bug exists in pfBlocker 1.0.2 or maybe it is by design but I can't see why it would be.

In a fresh install of pfSense 2.01, after completing the setup wizard and installing the pfBlocker package, WAN rules are not created automatically by pfBlocker unless a manually added rule already exists in the WAN rules. The Action selected was "Deny Both".

The LAN rules are created without any problem. I did a complete fresh install again to verify this. Can someone confirm if this is a bug?

A workaround is to manually create a rule in the WAN rules and then configure pfBlocker. Everything works fine then.

Thanks for your help. :)

phil.davis

Each interface has an implicit "block all" rule on the end (not listed on the GUI). So if there are no WAN rules, or just other blocking rules (like Block bogon networks), then all connection attempts from WAN are being blocked already. So there is nothing to be gained by adding a pfBlocker rule (I guess it would just add extra processing for nothing). The behaviour is by design, not a bug.
Once you open up something on WAN, then you need to go to pfBlocker and "Save" again. It will reprocess everything, find stuff opened up on WAN and add its blocking rules.
Note: if I then delete the rules that opened things up on WAN, go to pfBlocker and "Save", then pfBlocker does not remove its rules from WAN. So you can end up with an unusual-looking state (but no security issue). If you disable pfBlocker and save, then enable and save, it cleans up any rules then puts back the essential rules, restoring the state of things to "normal".

marcelloc

phil.davis,

100% correct :)

Explaining the code:

While applying pfblocker rules, if it does not find wan rules array, it will not create one(as default action is block). That's why you need a rule on wan before pfblocker can apply rules to it.

att,
Marcello Coutinho

OldGrayandCranky

Thanks Phil and Marcelloc, The explanation was informative and I do agree with the logic of the design. I appreciate the time spent on the project. It fills a very important need. Thanks!

On useability, I can't help thinking that allowing the "Deny Both" option to be successfully executed lures the user into a false sense of security when in fact, they need to reapply the rules to be protected.

Since the package already tests to see if there are rules on the WAN, is it possible to use that logic to fail the execution if no rules exist and force the user to select an option that would meet all of the requirements? If so, the error message could instruct them to add rules to the WAN or choose another option.

That extra step would improve the package and provide an extra measure of protection by default.

S_D

Ok, I have this working and it's a great package. Thanks for your hard work on it.

I have a feature suggestion though

I'm moving from Peerblock on my data server to pfblocker. Both using the level 1 block list. My data server behaves exactly as expected. However, with pfblocker I and the level 1 list with 'deny both' (inbound and outbound) I note that pfblocker blocks traffic talking to the lan interface of my pfsense box (192.168.101.1). Replicating that setup with Peerblock does not deny this traffic.

I'm wondering if this is what you said about it handling large networks?

How about a box where I could enter a test IP and see if pfblocker would block it? Unfortunately I can't view the resulting level1 table in diagnostics–>tables as it is too large and I just get a white page...

Unless there's another reason why this IP may be blocked?

Thanks,

Simo

marcelloc

@S_D:

Unfortunately I can't view the resulting level1 table in diagnostics–>tables as it is too large and I just get a white page...

try this on console/ssh

/sbin/pfctl -t pfblocker_alias_name -T show | grep ip_you_want_to_check

S_D

Thanks. Running that doesn't show the IP as being blocked (in fact opening the file manully in wordpad doesn't list it either - hardly surprising as it's an RFC1918 address).

however, adding another 'allow' custom list containing the address before this allows the traffic again.

Running your command on this list shows the ip

I think what we're seeing though is a raw search of the downloaded file, rather than a search of the compiled tables.

Which leaves 2 questions.

Why is the level1 list block 192.168 addresses (I've tried changing to 192.168.1.1 to test further and it's still blocking it)
and
Is it possibly to search or query the compiled list?

Thanks,

Simon

S_D

Just built a VM replica enviroment to test this again and have confirmed it there to, so it's not corruption on that system i don't think.

I can see the blocks in the firewall logs.

S_D

A final bit of diagnosis.

I've changed the LAN network to be 10.1.1.0/24 (firewall on .1), and pfBlocker is not blocking traffic. That leads me to believe it is something to do with the way it is summarising it's 192.x network somewhere, but as I say I don't know how to properly query the compiled list. :)

S_D

@marcelloc:

P2p lists are converted to cidr format after download. If p2p range generates a network mask bigger then /16, pfBlocker will TRF to find a network cidr for this, What could result on a /12 or /8 network. In this situation, you may have some non blacklisted ips blocked.

Cidr is the recommended format for lists.

Sorry to spam this thread, this is the last question I promise.

Above you mention CIDR as the recommended format.

I've been downloading in P2P format (http://list.iblocklist.com/?list=bt_level1&fileformat=p2p&archiveformat=gz)

When I tell pfBlocker do download the same list in CIDR format instead, the traffic now flows! So I assume the pfBlocker conversion of P2P to CIDR is what was causing the issue. I also now only get around half the number of CIDRs showing in the widget now (approx 252000). Is that right?

Thanks!

marcelloc

@S_D:

Sorry to spam this thread, this is the last question I promise.

No problem. Today the forum helps you, tomorrow you help the forum ;)

@S_D:

I also now only get around half the number of CIDRs showing in the widget now (approx 252000). Is that right?

Probably yes.

jp141

Thanks guys this is amazing, a vast improvement over the older packages :D

The only 2 requests I have are:

1.) Have its own log tab so you can quickly and easily see what has been blocked

2.) On the dashboard widget breakdown the blocked stats to incoming/outgoing

Would they be possible?

Thanks again

marcelloc

@jp141:

1.) Have its own log tab so you can quickly and easily see what has been blocked

pfblocker just create firewall rules with log options selected, so there is no way to distinct from other firewall log rules

@S_D:

2.) On the dashboard widget breakdown the blocked stats to incoming/outgoing

No plans for that yet.

jp141

Ok thanks for the update.

Keep up the great work ;D

jp141

@marcelloc:

Pfsense is trying to update urltables applied by pfblocker during boot.

I'll try to find a way to prevent this if there is no link/ip/webserver up.

Hi marcelloc,

I am also getting this issue, it is preventing pfsense fully booting, if I go in via SSH and force the web configurator to start then disable pfblocker the system continues to boot fine.

I have multi wan, not sure if that is the issue?

I just get this for each list in the startup log:

php: : The command '/usr/bin/fetch -T 5 -q -o '/var/db/aliastables/pfBlockerDshield.txt.tmp' 'https://127.0.0.1:443/pfblocker.php?pfb=pfBlockerDshield'' returned exit code '1', the output was 'fetch: transfer timed out'

Once the system has booted I can start pfblocker with no issues.

Edit: this is on nanobsd if it matters and the latest pfblocker (only installed today)
I can also see "No pfBlocker action during boot process." in the logs a couple of times so it is obviously trying to delay but going wrong somewhere.

S_D

One little bug, Marcelloc.

When i use a list with deny inbound (for example), the widget 'packets' (blocked) counter counts up. However, if I just alias a list, and reference that in a firewall wall (even if that rule is logged) then the packet counter doesn't work at all (the field remains blank).

Is this by design or a bug?

If so, I guess I could work around it by using deny inbound, and then modifying the resulting rule in the rulebase to point to the one LAN host that I want. However, will this modification be remembered, or will it revert to it's default 'all/all/all' settings??

S_D

I think I've answered my own question just now. If the comment field for the rule you create contains the Alias name then the widget counter goes up correctly…. :)

marcelloc

@S_D:

I think I've answered my own question just now. If the comment field for the rule you create contains the Alias name then the widget counter goes up correctly…. :)

That's it, You need to follow alias name pattern to get a working widget. :)

eri--

@marcelloc:

@jp141:

1.) Have its own log tab so you can quickly and easily see what has been blocked

pfblocker just create firewall rules with log options selected, so there is no way to distinct from other firewall log rules

You could create the rules with 'label pfBlocker' and get stats based on that.
pf(4) allows that and this will give you stats.

marcelloc

@ermal:

You could create the rules with 'label pfBlocker' and get stats based on that.
pf(4) allows that and this will give you stats.

Is it possible to include label on firewall rules gui?