PfBlocker
-
Can you explain how this works ? Are you talking about the general aliasses in pfsense? Or the list tab in pfblocker?
Is there some documentation available about this?
-
@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…. :)
Excuse my ignorance here, but could you be so kind to tell me exactly how you solved this? You mention an alias name in the comment field. I may be having the same or similar problem with pfblocker. Thanks for the tip on how to get the web configuator started from SSH to turn off pfblocker when the system hangs at boot.
-
Came across a new list of malware IPs
http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/download-ip-reputation-database/
Looks like either the gzip ver or the plain ver - of the Generic Format - would load fine in pfBlocker.
Haven't tried it yet - will give it a go tonight and post back how it loads.
-
Could you be so kind to tell me exactly how you solved this? You mention an alias name in the comment field. I may be having the same or similar problem with pfblocker.
take a look on list action description:
While creating rules with this list, keep aliasname in the beggining of rule description and do not end description with 'rule'.
custom rules with 'Aliasname something rule' description will be removed by package.pfblocker create aliases and rules on pfsense with your lists.
If you change action to alias only, pfblocker will create only the alias part, and no rules. This way, when you create your own rules, configure it`s description with 'aliasname custom1' for example to get widget working.att,
Marcello Coutinho -
Could you be so kind to tell me exactly how you solved this? You mention an alias name in the comment field. I may be having the same or similar problem with pfblocker.
take a look on list action description:
While creating rules with this list, keep aliasname in the beggining of rule description and do not end description with 'rule'.
custom rules with 'Aliasname something rule' description will be removed by package.pfblocker create aliases and rules on pfsense with your lists.
If you change action to alias only, pfblocker will create only the alias part, and no rules. This way, when you create your own rules, configure it`s description with 'aliasname custom1' for example to get widget working.att,
Marcello CoutinhoWell this is embarrassing. I am very new at this forum and I think I am quoting the wrong message. My problem is with the boot up after pfBlocker is installed on a nanobsd system. It takes a very long time or does not start at all. If I uncheck pfBlocker before re-booting then turn it on after things start up normally and it works fine. I get errors scrolling in the top right about lists are empty or something to that effect if I boot with pfBlocker enabled.
-
It would be nice if the "Enable pfBlocker" status would be preserved through reboots - it's kind of annoying having to re-enable it each time :/
-
I updated to pfBlocker to 1.0.2 this weekend, up from 1.0.1.
The dashboard widget was working properly before the package upgrade. Now the dashboard widget is empty - no table below the headers. So then I went to investigate the firewall rules and pfBlocker settings, and I discovered that the settings look exactly as I had them prior to the upgrade - however there are no longer any firewall rules for each of the settings within the package.
After uninstalling, rebooting and re-installing the package, the original package settings remain (all of the info within the tabs are completed) and there are still no rules, and no info in the widget. This of course leads me to believe that it's not blocking anything as there are no associated rules.
How do I fix this failed update and get pfBlocker working once again?
-
How do I fix this failed update and get pfBlocker working once again?
the uninstall/update process disables pfblocker on gui, did you re-enabled the service after it?
-
How do I fix this failed update and get pfBlocker working once again?
the uninstall/update process disables pfblocker on gui, did you re-enabled the service after it?
Doh! I looked and looked for why it wasn't happy, and I totally missed the check box to enable pfBlocker. Thank you for pointing that out.
-
Awesome package! Works perfectly so far.
Some feature requests, which I hope you can add to make it even better:
1) Traffic being blocked by pfblocker logged in a different tab (instead of the firewall log?) Easy to debug if something is being blocked by my own rules or the pfblocker app.
I do know that you can see that if something is blocked by pfblocker you can see that by looking at the details, but when you have allot of blocked records it's hard to filter2) Users are complaing specific sites are being blocked. Is there a whitelisting feature available to ignore certain websites? Or do I have to enter them in a alias in my firewall manualy?
3) I'm using squid (transparant) would it be possible to send some kind of message to the user that the site has been blocked? Now they get a connection error which makes the user think internet is not working (they call the helpdesk). Would love to send some kind of squid access denied error page or something like that.
4) I can set more interfaces on the outbound part, this allows me to block access to certain sites (outbound) in countries on my network. The problem is that I only want to block access to these users on my WIFI interface and not my LAN (which doesn't need that much security). Would it be possible to set the outbound interface on the country tabs instead of all outbound selections?
5) Ignore tab –> where I can enter my own ip for outbound and my servers for inbound? Just to make 100 % sure these do not get blocked?
I'd love to see these changes implemented as well. In addition, I have some rules that are being autocreated twice. Any timeline available?
-
Came across a new list of malware IPs
http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/download-ip-reputation-database/
Looks like either the gzip ver or the plain ver - of the Generic Format - would load fine in pfBlocker.
Haven't tried it yet - will give it a go tonight and post back how it loads.
Here's my report back on the AlienVault IP Reputation list.
I had it block matching http/https outbound - and block matching * inbound.The list is big, over 300k IPs.
The text version is 17MB and it added nearly a minute to my filter reload time (3Ghz PentiumD, 4GB).
I tried the gzip version and found it much smaller and faster. I had no noticeable difference in filter reload times.
After running the list for a most of a week, I had 2 false positives. That's not bad.
One was a big web host that AlienVault listed over a year ago (for serious malware distribution).
The IP was cleaned immediately so AlienVault must not delist IPs automatically.
The other false positive was a Tor directory server.Conclusion:
Given the big database (and no auto-delisting) I'd say AlienVault has a really low false positive rate.
My opinion is that it's worth trying - providing you log any hits on it. -
Some feature requests, which I hope you can add to make it even better:
1) Traffic being blocked by pfblocker logged in a different tab (instead of the firewall log?) Easy to debug if something is being blocked by my own rules or the pfblocker app.
I do know that you can see that if something is blocked by pfblocker you can see that by looking at the details, but when you have allot of blocked records it's hard to filter2) Users are complaining specific sites are being blocked. Is there a whitelisting feature available to ignore certain websites? Or do I have to enter them in a alias in my firewall manually?
5) Ignore tab –> where I can enter my own ip for outbound and my servers for inbound? Just to make 100 % sure these do not get blocked?
#1 - I'd sort of like that. Prob is I have 10+ block lists in addition to pfBlocker's country lists. I'd want them all logged individually and that doesn't seem practical.
Maybe a filtered syslog server could be a solution.For now, looking at ports/IPs in the firewall log can clue me in on what list is blocking.
If I suspect a site is blocked and I need to figure out which list is responsible; I'll run something like```
grep -r -o -Dskip 111.222.3.4 /#2 I have a Whitelist alias that I keep at the top of the rules list. I figure adding an IP to the alias is as simple as any option pfBlocker could provide. **Edit: You could also create a new Custom List in pfBlocker and set it to the top of your rules list.** #5 - See #2 (providing I understand correctly).
-
I have some rules that are being autocreated twice. Any timeline available?
I have that happen occasionally.
I'll delete the dupes and finish my usual setup and it doesn't bother me again after that.Just for the record, my usual setup:
-
Under Rules: Edit - I make sure the "Auto Rule" text is chopped off the end of the Description - of the rules I want to keep.
-
I delete the duplicate rules (and reorder the remaining ones if necessary). Apply rule changes.
-
Under pfBlocker -> Lists - I make sure Action is set to Alias_only for every list and repeat for Continent tabs.
Unless Action is set to Alias_only, pfBlocker will:
-
Create a new rule if the old one is modified
-
Restore the original order of it's rules
-
-
-
For anyone who's read the I-Blocklist doesn't protect Bittorrent users from being monitored article;
http://torrentfreak.com/anti-pirates-caught-spying-on-thousands-of-torrents-120829/
I put together a block list that comprises all 6 monitoring subnets, mentioned in the original study.http://dl.dropbox.com/u/71477228/P2PCIDRList.txt
Original P2P monitoring Study:
http://www.cs.bham.ac.uk/~tpc/Papers/P2PSecComm2012.pdf
If you P2P, I strongly recommend you read it.A more accurate summary of the study is that I-Blocklist missed about a third of the monitoring IPs and also had a lot of false positives.
They study authors mentioned 6 subnets that harbored P2P monitors and that's what's in this list.Disclaimer: My list is serious overkill. 99.9% of the IP addresses in it don't monitor anything.
The list is what it is because the study authors didn't mention specific IPs, just AS#'s (page #14).
So the list is all the IPs that fall under those AS#'s. -
I have some rules that are being autocreated twice. Any timeline available?
I have that happen occasionally.
I'll delete the dupes and finish my usual setup and it doesn't bother me again after that.On 2nd thought, maybe I shouldn't dismiss caustic386's point so quickly.
I added a list yesterday and had 5 duplicate rules (6 total) show up in WAN.
My theory is that it's tied to the length of time it takes my firewall rules to reload.
Could there be a loop that repeats until the firewall rules finish loading?(I have a lot of lists in my pfSense rig. I suspect if I add more lists, I'll have a greater # of dupes created.)
All my pfBlocker lists are configured as Alias - so not a big deal for me.
But this could be a real issue for someone who set their pfBlocker list config as Deny or Allow. Dupe rules could be created at every list reload. -
Here are Spamhaus criminal network block lists.
Drop: http://www.spamhaus.org/drop/drop.txt
EDrop: http://www.spamhaus.org/drop/edrop.txtDROP (Don't Route Or Peer) and EDROP are advisory "drop all traffic" lists, consisting of stolen 'hijacked' netblocks and netblocks controlled entirely by criminals and professional spammers.
The DROP list will not include any IP address space under the control of any legitimate network - even if being used by "the spammers from hell".
DROP will only include netblocks allocated directly by an established Regional Internet Registry (RIR) or National Internet Registry (NIR) such as ARIN, RIPE, AFRINIC, APNIC, LACNIC or KRNIC
or direct RIR allocations illicitly taken from the original allocatee, that is, the troubling run of "hijacked" IP address blocks that have been snatched away from their original owners (which in most cases are long dead corporations) and are now controlled by netblock thieves or sold to criminal spammers.EDROP is an extension of the DROP list that includes suballocated netblocks controlled by cyber criminals.
EDROP is meant to be used in addition to the direct allocations on the DROP list.From http://www.spamhaus.org/drop/
-
Here are Spamhaus criminal network block lists.
Thank's LinuxTracker. These lists are really usefull. :)
-
I have that happen occasionally.
Legend. Thank you. Fixed the dupe issue for me, and allowed a rule (that I'd setup to bypass the pfBlocker rule) to stay before the pfBlocker rule.
-
I made a list so I can block spam from Tor Exit nodes.
http://dl.dropbox.com/u/71477228/torexitnodes.txtIt pulls the IPs from here -> http://exitlist.torproject.org/ and updates every hour.
There are a lot of Tor Node lists, even a number of Tor Exit Node lists.
EmergingThreats, TorProject and dan.me.uk all maintain themFor whatever reason, I couldn't find a list of just Exit Nodes in the right format for pfBlocker.
I found about everything else though.As example, torexit.dan.me.uk is a DNSBL w/ a return value of 127.0.0.100
re: https://www.dan.me.uk/dnsblAnd this guy offers a Bash Script that will pull from dan.me.uk and upload right to IPTables.
https://github.com/jseidl/torblock/blob/master/torblock.shBut I couldn't find exactly what I wanted so I made it and there you are.
-
I have some rules that are being autocreated twice. Any timeline available?
I found out how to make this happen - On the GUI take a rule in the middle of your WAN rules, move it to the very end of the list. When you apply, the rule ends up by itself at the very end of the list of rules in the filter section of config.xml - there are WAN rules, then LAN rules then this 1 WAN rule. If you have lots of interfaces and move your rules order around from time to time, the rules for each interface end up in interspersed chunks in config.xml. Everything is fine for correct rule processing for pf, the rules for each interface are in the correct order in the filter section, it is just that rules for WAN, LAN, OPT1 OpenVPN etc get interspersed.
The pfBlocker code would apply pfBlocker rules every time it came to a "chunk" of rules for another interface. If there were 2 "chunks" of WAN rules in the filter section, then pfBlocker rules would be added before both "chunks".
I have fixed the logic so pfBlocker only adds the rules the very first time it comes across an interface.
@marcelloc - have a look at pull request https://github.com/bsdperimeter/pfsense-packages/pull/323 - it should fix this issue for good.