I’ve been using the legacy timfprogs/ipfblocklist plugin feature for some time now. I’m happy to see that this will be incorporated into the IPFire product.
I have noticed one wart and I’m curious if it will still exist in the new version.
The wart:
After rolling up nicely for several days, the pkts and bytes counts for some lists (in this example: “The CINS Army List” and “Emerging Threats Blocklist”) go blank. The lists are still used – per the blocked entries in the firewall logs – so things are still working fine. It’s just a little confusing when you see the pkts and bytes counts go blank – I would assume after rolling over some threshold.
It seems to be parsing the iptables output incorrectly. If you want to fix it, you could try changing the line
my ($pkts, $bytes, $chain) = $line =~ m/^\s+(\d+\w?)\s+(\d+\w?)\s+(\w+)_BLOCK/;
to
my ($pkts, $bytes, $chain) = $line =~ m/^\s*(\d+\w?)\s*(\d+\w?)\s+(\w+)_BLOCK/;
It’s at about line 111 in blocklist.cgi. Alternatively, the information is available on the Firewall > iptables page in the WUI. Just select the name of the blacklist in the top pull down and update.
The code that’s being integrated has changed significantly from the code on github. It now blocks packets output to the red interface as well as inputs, should take significantly less CPU time and is better integrated into the system. This does, unfortunately, mean that it’s not compatible with the github code, which will have to be uninstalled before IPFire is updated (currently expected in core update 143). It’s also changed the way that the statistics are displayed, so that they’re now displayed similarly to the other firewall logs. You can find some screenshots attached to this post on the development list: https://lists.ipfire.org/pipermail/development/2020-January/006822.html - go right to the bottom.
Excellent, that line of code in blocklist.cgi did indeed correct the output on the WUI.
Thanks for all your good work @timf, I look forward to core update 143 – and uninstalling the timfprogs/ipfblocklist version
Hi,
I’m still about (although I have been busy with COVID-19 related stuff). I don’t recall having received any emails about this recently, but I’m happy to do the work to get it into IPFire.
no rush intended, but are you working on this or happen to have an ETA? With regards to events such as this one, the IP address blacklist feature would be very nice to have in IPFire, but we need a maintainer for it.
The code I submitted in may (I think) is complete. It needs a slight modification for the latest version of IPFire, because the IPTables in the main chains have changed recently. I’m going to try to push the code changes to my repository in the next couple of weeks. Obviously, since the code is not in IPFire, it’s not at the top of my list of priorities, given all the extra work that COVID-19 seems to be putting in my direction. However if the code makes it in, I would intend to make sure it’s properly maintained.
great to hear that. Could you drop me/us a line in case you have done so?
I believe this is the message we have been waiting for. If there is some spare time left on tonight’s telephone conference, I will bring that up once more, and hope to finally make this land in IPFire.
I have encountered a problem with this addon. If I check the group BOGON_FULL, for example, it blocks my communications from Green to Red because it denies me two-way communications. If I uncheck the BOGON_FULL group in the IP Blocklist module, this filtering does not disappear.
With the changes in IPFire since May 2020 and the newer fixes you have made, I think it would be good if you could submit a new version of your patches. Core Update 154 is in testing now so Core Update 155 has just started being merged so it would be a good point in time to get involved again.
