PfBlocker
-
How/where could I apply a pfBlocker list to filter inbound traffic on a NAT-PMP port created by miniupnpd?
-
How/where could I apply a pfBlocker list to filter inbound traffic on a NAT-PMP port created by miniupnpd?
Try first on floating rules and go testing access with tcpdump on console.
-
Found a few good pfBlocker compatible blocklists:
I am specifically worried about Malware.
formats: txt
Known AD server IPs:
http://pgl.yoyo.org/adservers/iplist.php?ipformat=peerblock&showintro=0&mimetype=plaintext
Main page: http://pgl.yoyo.org/adservers/Malcode (anti-malware):
http://malc0de.com/bl/IP_Blacklist.txtAMaDa C&C IP Blocklist:
http://amada.abuse.ch/blocklist.php?download=ipblocklistabuse.ch ZeuS IP blocklist:
http://www.abuse.ch/zeustracker/blocklist.php?download=ipblocklistSucuri Security Malware Scanning IPs:
http://tools.sucuri.net/blacklist/MS-iplist.txt
CI Army Malicious IP List:
http://www.ciarmy.com/list/ci-badguys.txtRussian Business Network:
http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt -
Thanks for your contribution.
Do you know how often its Updated?
-
I don't know how often the advertising blacklist is updated, it doesn't seem to be very effective. I'm the "cup half full" type of person so I block those IP's anyways.
As to the known malware IP's, I believe from looking at the commented-out time stamp within the files they look to be updated daily.
-
Can somebody please tell me why PFblocker widget isn't showing all my block lists as being blocked?
Specifically the Russian Business Network Malverisers IP list is working however their CI Army list is not…. but the IP lists are of the same structure.
Working: http://rules.emergingthreats.net/blockrules/rbn-malvertisers-ips.txt
Not working or showing on Pfblocker widget: http://www.ciarmy.com/list/ci-badguys.txt
Please help!
-
Check first in diagnostics tables if this list was filled up.
Then check rule description for this alias rule.
-
Check first in diagnostics tables if this list was filled up.
Then check rule description for this alias rule.
Can you please explain this in further detail? I don't see alias rules for these lists, shouldn't they have been automatically made?
-
The pfBlocker is great! It's easy to use and very effective! Thank you!
I have 2 dumb questions.
- I have Russia blocked but need to allow for the access to my network from the IP 213.238.8.10. I looked up the CiDR for it. How do I enter the IP to allow it past the Russia block list?
CIDR results for 213.238.8.10
213.238.8.10/32 = 213.238.8.10 through 213.238.8.10 [1 IP - Single IP]
213.238.8.10/31 = 213.238.8.10 through 213.238.8.11 [2 IPs]
213.238.8.8/30 = 213.238.8.8 through 213.238.8.11 [4 IPs]
213.238.8.8/29 = 213.238.8.8 through 213.238.8.15 [8 IPs]
213.238.8.0/28 = 213.238.8.0 through 213.238.8.15 [16 IPs]
213.238.8.0/27 = 213.238.8.0 through 213.238.8.31 [32 IPs]
213.238.8.0/26 = 213.238.8.0 through 213.238.8.63 [64 IPs]
213.238.8.0/25 = 213.238.8.0 through 213.238.8.127 [128 IPs]
213.238.8.0/24 = 213.238.8.0 through 213.238.8.255 [256 IPs - Class C]
213.238.8.0/23 = 213.238.8.0 through 213.238.9.255 [512 IPs]
213.238.8.0/22 = 213.238.8.0 through 213.238.11.255 [1024 IPs]
213.238.8.0/21 = 213.238.8.0 through 213.238.15.255 [2048 IPs]
213.238.0.0/20 = 213.238.0.0 through 213.238.15.255 [4096 IPs]
213.238.0.0/19 = 213.238.0.0 through 213.238.31.255 [8192 IPs]
213.238.0.0/18 = 213.238.0.0 through 213.238.63.255 [16384 IPs]
213.238.0.0/17 = 213.238.0.0 through 213.238.127.255 [32768 IPs]
213.238.0.0/16 = 213.238.0.0 through 213.238.255.255 [65536 IPs - Class B]
213.238.0.0/15 = 213.238.0.0 through 213.239.255.255 [131072 IPs]
213.236.0.0/14 = 213.236.0.0 through 213.239.255.255 [262144 IPs]
213.232.0.0/13 = 213.232.0.0 through 213.239.255.255 [524288 IPs]
213.224.0.0/12 = 213.224.0.0 through 213.239.255.255 [1048576 IPs]
213.224.0.0/11 = 213.224.0.0 through 213.255.255.255 [2097152 IPs]
213.192.0.0/10 = 213.192.0.0 through 213.255.255.255 [4194304 IPs]
213.128.0.0/9 = 213.128.0.0 through 213.255.255.255 [8388608 IPs]
213.0.0.0/8 = 213.0.0.0 through 213.255.255.255 [16777216 IPs - Class A]
212.0.0.0/7 = 212.0.0.0 through 213.255.255.255 [33554432 IPs]
212.0.0.0/6 = 212.0.0.0 through 215.255.255.255 [67108864 IPs]
208.0.0.0/5 = 208.0.0.0 through 215.255.255.255 [134217728 IPs]
208.0.0.0/4 = 208.0.0.0 through 223.255.255.255 [268435456 IPs]
192.0.0.0/3 = 192.0.0.0 through 223.255.255.255 [536870912 IPs]
192.0.0.0/2 = 192.0.0.0 through 255.255.255.255 [1073741824 IPs]
128.0.0.0/1 = 128.0.0.0 through 255.255.255.255 [2147483648 IPs]- I would like to go view the stats of what is blocked by pfBlocker. I saw your screen capture at the beginning of the pfBlocker forum. Where or how do I access this?
Again, great work!
-
I am getting this in the System Log. Any ideas?
php: : The command '/usr/local/pkg/pf/IP-Blocklist.sh start' returned exit code '2', the output was 'not running root: IP-Blocklist was found not running 0 table deleted. 0 table deleted. rm: /tmp/rules.debug.tmp: No such file or directory /usr/local/pkg/pf/IP-Blocklist.sh: cannot create /usr/local/www/packages/ipblocklist /errorOUT.txt: No such file or directory rm: /tmp/rules.debug.tmp: No such file or directory 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 cat: /usr/local/www/packages/ipblocklist/interfaces.txt: No such file or directory 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 rm: /usr/local/www/pacI might make the suggestion that pfblocker uninstall runs a script to clean it out of the packages directory (and any directories it leaves behind there). While one could go to do this manually (especially if you had country block before), it makes more sense to remove the scripts and files it creates there so a reinstall will keep this type of thing from happening.
If not a BIG FAT STICKY that tells people what they need to do would probably keep these types of messages from having to be posted.
Essentially, manually remove:
/usr/local/www/packages/pfblock* and the other two related directories, especially the one with the startup script. It doesn't unintall cleanly or reinstall cleanly.
-
Grazman,
It's related to ip-blocklist package.
If you had removed it, maybe you need to delete this remaining script.'/usr/local/pkg/pf/IP-Blocklist.sh'
Also look for ipblocklist scripts in /usr/local/etc/rc.d
-
The pfBlocker is great! It's easy to use and very effective! Thank you!
I have 2 dumb questions.
- I have Russia blocked but need to allow for the access to my network from the IP 213.238.8.10. I looked up the CiDR for it. How do I enter the IP to allow it past the Russia block list?
Create a new list, choose action allow inbound and paste your networks in custom list.
-
So you're saying my new list will over ride the other lists by default?
Also, what format to I put the IPs in? Is it listed as below?
213.238.8.10/32
Sorry to be so stupid on this.
Thanks!
-
whitelist(allow) rules are applied before blacklists(deny).
the custom list is in CIDR format, so if its only one ip address 213.238.8.10/32 is fine.
-
Thank you!
-
FYI http://www.countryipblocks.net/information/country-ip-blocks-endorses-pfsense/
-
FYI http://www.countryipblocks.net/information/country-ip-blocks-endorses-pfsense/
Awesome. Thank you.
-
I'd like to begin by saying thank you for pfblocker and what all of you do to make this project a success. The post I'm about to write is intended for communicating how pfblocker could be improved, but if not read in the proper mindset may come off as me being critical of pfblocker so I want to make my intentions clear up front.
I am not currently using pfblocker for a couple of reasons, the primary reason is it seems to make establishing new connections incredibly slow. This is most easily noticed when browsing from one domain to another, in my configuration anyway it causes an immense connection time but once the connection is established it seems to do ok-ish.
This may not necessarily be the fault of pfblocker as it does take system resources to run such a package gracefully, so I believe perhaps a chart or even a dynamically calculated value on the pfblocker page would help tremendously. For example, I'm not sure if pfblocker is processor hungry or memory hungry, but it could compare for instance available ram with amount of rule entries and give the user an idea of the performance they should be getting with their rules. If they have gone over the limit for their system, the user then can either deal with it, remove some rules, or remove other system resource intensive package or setting. This would make diagnosing these types issues much easier.
Another suggestion I have for pfblocker would be to have the option to dynamically increase the number of firewall entries to the amount of rules for the lists the user has selected + however many for their personal needs. For example, a checkbox "Automatically Increase Firewall Maximum Table Entries", then a box to enter how many above the amount of rules for personal firewall rules, possibly with a default of 10000 which should be sufficient for most everyone.
That's all for now… hope these recommendations are fresh and I'm not just "yet another griper" lol. I didn't see anyone suggesting this but there are many places to look.
-
In reply to Kamel,
pfblocker performance is going to depend on your hardware. Keep in mind that pfblocker is neutral to how your system will perform. Your system performance with pfblocker will be affected by how large your lists are. If you're using a very small list the you won't even notice pfblocker. The larger the lists then the more memory is required.
Creating a chart for usage is moot. Everything depends on your hardware and your lists. For example, a list with 5000 IPs runs like nothing on my firewall but a list of 5000 may cause problems on an embedded system. So if your experiencing problems then you need to upgrade your hardware or reduce your pfblocker usage.
Firewall entries should be left to the user. Most users will never have to increase system resources to use pfblocker. If we dynamically change system variables on the fly this could cause issues with the system or other packages. Basically, it's an unnecessary risk to change a variable that a user can do at their own risk. A compromise to this could be to have the user enable this feature at their own risk.
My pfense is running on hardware that is way overkill for pfsense, however running addons like pfblocker does take a lot of system resources. With that being said, I am running pfblocker with over two billion IP's. It's takes a lot of RAM but I don't experience and slow downs or any latency because my hardware is built for it.
-
I'm not sure I effectively communicated what I was trying to say… I realize that list sizes are going to impact performance. Maybe even just a "rule of thumb" chart would be helpful, like "for systems with 256mb of ram use no more than X entries, systems with 512mb of ram no more than X entries, systems 1gb-4gb use no more than X entries" or something to that effect would still be helpful.
If there is risk to dynamically changing the number of rules, a compromise might be to add a check when applying the settings then... if total list rules combined are greater than the maximum available rules in your firewall settings, produce an error and don't let the user submit their settings. This would make the error obvious, so that they don't get weird errors in their logs and wonder why pfblocker isn't working right.
