PfBlocker
-
I can run this to see what happens getting the files:
$url_list1 = file("http://rules.emergingthreats.net/blockrules/rbn-ips.txt"); var_dump(count($url_list1)); $url_list2 = file("http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt"); var_dump(count($url_list2));
and I get:
int(9194) Warning: file(http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /usr/local/www/exec.php(246) : eval()'d code on line 7 int(1)
rbn-ips.txt is fetched OK by PHP into an array of 9194 entries.
RussianBusinessNetworkIPs.txt does not come, something blocking it from being read with PHP file()Additional info: If I change pfblocker.inc sync_package_pfblocker() to use the function download_file() from pfsense-utils.inc, downloading it first to a local file then letting the rest of the code parse a local copy, then it works. So the code in /etc/inc/pfsense-utils.inc:download_file() is able to download the list OK, getting 9251 entries.
Maybe pfblocker should use download_file() rather than PHP file()?
(That would need testing against a bunch of things people are using - some other list download might break???) -
Hi, got exactly the same problem, since a long ago, tried everything but this list http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt never loaded. This morning found this list http://rules.emergingthreats.net/blockrules/rbn-ips.txt that loads flawlessy. In my opinion it is quite the same listing. Try it.
Thanks! had no problem getting this one to load either. Looking at the site, at least this one seems more current as well. It's just a couple weeks old, not 2 years. I had brought the offend file local so I randomly picked about 30 addresses and they were in both so I'll hope the slightly lower line item count is because of newer data.
Rick
-
using pfblocker for the list management allows you to enter all the lists in a single alias. This is not possible for the regular aliases (url + url table). It's either many small lists, or one huge list, with those.
I'll start using http://rules.emergingthreats.net/blockrules/rbn-ips.txt since it causes fewer problems with people. Thanks for the info. Expect the update to come with the next blueprint update.
EDIT: Just checked and http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/emerging-rbn-malvertisers.txt should be http://rules.emergingthreats.net/blockrules/rbn-malvertisers-ips.txt, so it's 2 upcoming updates to the blueprint.
As far as I can remember those 2 were chosen because of lack of the rules.emergingthreats.net lists. -
@jflsakfja:
using pfblocker for the list management allows you to enter all the lists in a single alias. This is not possible for the regular aliases (url + url table). It's either many small lists, or one huge list, with those.
I'll start using http://rules.emergingthreats.net/blockrules/rbn-ips.txt since it causes fewer problems with people. Thanks for the info. Expect the update to come with the next blueprint update.
EDIT: Just checked and http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/emerging-rbn-malvertisers.txt should be http://rules.emergingthreats.net/blockrules/rbn-malvertisers-ips.txt, so it's 2 upcoming updates to the blueprint.
As far as I can remember those 2 were chosen because of lack of the rules.emergingthreats.net lists.Don't know your name so I'll just use the first two initials and say thanks JF!! (significant if you're a Phillip Dick fan… and how can you follow BOHP and not be a Dick fan)
One request; If possible and not too much hassle, could you somehow highlight the changes from your last blueprint?
I must say, since switching over to your method and using the rules to do pfblocker's work, even with more rules active under SNORT, system is much faster AND using much less memory. Which, made it possible to commit more memory to Squid which helps even more!
Thanks,
Rick -
I'm interested in the country-blocking abilities of pfBlocker.
I've got assets that are 99.99% of the time only accessed from within my country. So, I've added a rule with my country as the block list, then inverted the match so any traffic from OUTSIDE the country is dropped. Seems to work well enough, but can someone comment as to:
-
Where does pfBlocker gets its IPs from?
-
How often does pfBlocker update its IP list?
-
What is the likelihood that an IP range will be assigned to a country but won't be picked up by pfBlocker?
-
-
I'm interested in the country-blocking abilities of pfBlocker.
I've got assets that are 99.99% of the time only accessed from within my country. So, I've added a rule with my country as the block list, then inverted the match so any traffic from OUTSIDE the country is dropped. Seems to work well enough, but can someone comment as to:
-
Where does pfBlocker gets its IPs from?
-
How often does pfBlocker update its IP list?
-
What is the likelihood that an IP range will be assigned to a country but won't be picked up by pfBlocker?
1/ Here - The lists are 2 years old. ::)
2/ Never, the lists have gone commercial quite some time ago.
3/ Pretty high, given the above.All the country-based stuff should have been removed altogether from the package quite some time ago, useless.
-
-
I agree or the lists should be updated.
-
That is most unfortunate. I don't suppose anyone knows if an up-to-date country list is provided somewhere?
-
That is most unfortunate. I don't suppose anyone knows if an up-to-date country list is provided somewhere?
You can add the Country Block lists from IBlock Lists.
https://www.iblocklist.com/lists.php?category=country
I haven't tested it, but they are listed there.
-
Good afternoon,
Great thread so far, thanks for all your great detective work. :)
Im running pfs at a minimum with pfBlocker and system patches. I'm using nested alias lists: two url aliases, Evil_Lists_1 and 2, each containing 3-5 localhost list urls. All pfBlocker lists are set to "alias only" as I prefer to create my own rules (this also seems to be a better way according to others as well). I then created two WAN rules for each list, one to block inbound traffic and another to reject outbound traffic, and also two LAN rules for each interface rejecting outbound traffic for each list. They seem to be blocking properly as far as I can tell and the correct CIDR numbers are showing in the widget at all times but the lists are always shown as down in the widget. I have tried renaming my rule descriptions based on what Marcello and others have recommended in earlier posts ("lead with pfblocker* and dont end with rule") in varying ways but it still wont show as up in the widget.
Not a serious problem but I like the widget and I want it to work. Any suggestions?
Also, would I be better off having a rule for each original pfBlocker alias? I prefer steamlined rules and less of them, is there any benefit to individual rules other than the widget working?
Thanks again for an informative thread.
-
-
Not a serious problem but I like the widget and I want it to work. Any suggestions?
Try deleting the underscores from your alias descriptions, e.g., use 'pfBlockerEvilList' rather than 'pfBlockerEvil_List'. The widget doesn't seem to like spaces or special characters.
-
Semi-fix, I added the prefix "pfBlockerBadList1" and "pfBlockerBadList2" to the beginning of the respecive WAN rule for each and now both "pfBlockerBadList1" and "pfBlockerBadList2" show up in the widget and are recognized as being up; while this does not solve the original widget problem it does let me know at a glance that my lists are functioning; and as a nice additional benefit the packets that are blocked by the respective individual nested aliases within the two lists are still recorded correctly under the original widget list names. Sweet! :D
Here is a pictorial example of the lists:
(The blocked packets are not showing now beacause I restarted, but will show up under the individual list names, not BadList1/2, I like this.)
-
All issues we found has already been fixed.
The last thing to code is lists update frequency.
can you add the option to update weekly? it only allows up to daily right now ..which is awesome.. but sometimes iblocklist.com denies updating that frequently. at least it does on peerblock 1.2+ …
???
-
All issues we found has already been fixed.
The last thing to code is lists update frequency.
can you add the option to update weekly? it only allows up to daily right now ..which is awesome.. but sometimes iblocklist.com denies updating that frequently. at least it does on peerblock 1.2+ …
???
Isn't this done in a cron job? I think you can just set the cron job wday from a number 0-6 to set the day (somebody correct me if I am wrong).
-
Isn't this done in a cron job? I think you can just set the cron job wday from a number 0-6 to set the day (somebody correct me if I am wrong).
The pfBlocker frequency is set in the pfBlocker GUI per each individual Blocklist. (Never, 1hour, 4hour, or 24hours)
The Cron job that you see is to Update the URL tables which in most cases shouldn't be played with.
-
Is there a way that we can see what IP's are being currently blocked by PFblocker? The widget shows 85 blocked for a given list, I would like to know which one from that list are being blocked?
Thanks
-
To see what IP's were blocked by pfBlocker, you need to look at the Firewall log.
The widget only displays the total number of ips per blocklist.
-
I'm also having a problem "finding" the IP's that the widget is blocking. I go Status: System logs: Firewall but I see a bunch of traffic blocked. I added some allow rules in pfblocker and I see some IP's allowed but don't know what list they are from or any way to tell they are from pfblocker.
I grepped my syslogs and do not see anything except for stuff like this: /pkg_edit.php: [pfblocker] pfblocker_xmlrpc_sync.php is starting. I can see the see the pfblocker lists in the widget on the dashboard counting packets and I can see the IP lists in the Diagnostics: Tables so I know it's working, but I'm not sure where to be looking for detailed info such as logs that say pfblocker and then the list name and the IP's that were blocked. Any info will help
-
For the blocklists that you created in pfBlocker, did you use "aliases"? This is the preferred way to utilize pfBlocker.
Once the aliases are created by the pfBlocker program, you can add block or reject rules on each interface utilizing the defined aliases.