IP Address Blacklists

[cbrown (Charles Brown)]

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.

[timf (Tim FitzGeorge)]

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.

[cbrown (Charles Brown)]

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

[cbrown (Charles Brown)]

Haven’t heard any news of this feature for a while. Has it been abandoned?

[ms (Michael Tremer)]

I think it looks like it.

Tim, who developed this, has not been responding to any emails recently. Nobody of the other developers was involved in this to carry this forward.

It would have been a great feature.

[timf (Tim FitzGeorge)]

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.

[jesreal]

Please do we will love this feature

[trish]

This looks like it will be awesome.

[pmueller (Peter Müller)]

Hi Tim,

@timf

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.

Suspicious network resurrections

Thanks, and best regards,
Peter Müller

[timf (Tim FitzGeorge)]

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.

[pmueller (Peter Müller)]

Hi,

@timf

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.

great to hear that. Could you drop me/us a line in case you have done so?

@timf

However if the code makes it in, I would intend to make sure it’s properly maintained.

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.

Thanks, and best regards,
Peter Müller

[markusm (DJ-Melo)]

@timf

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.

• 1 Hopefully it finds its way into ipfire by default as long as again here the installation works without problems https://github.com/timfprogs/ipfblocklist also with Core 153 testing.

[roberto (Roberto Peña)]

Hi.

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.

Even if I disable the module:

The rules keep popping up.

How to fix it?

Regards.

[timf (Tim FitzGeorge)]

The BOGON lists will cause problems if your red interface has a private IP address (usually 192.168.x.x).

To try to fix the problem log into the command line and try the following:

1. Is ipblocklist running? (pgrep ipblocklist).
   If it is, kill it.

2. Look at the settings file /var/ipfire/ipblocklist/settings.
   Is BOGON_FULL set to ‘on’ or ‘off’ (should be ‘off’).
   If it’s set to off:

   1. Have a look in /var/log/httpd/error_log
      Are there any error messages in there that look relevant?
   2. Using a text editor change the setting to ‘off’.

3. Run ipblocklist.pl.
   Are there any error messages?

4. As a last resort enter the following commands:

   iptables -D INPUT -i red0 -j BOGON_FULL
   iptables -D FORWARD -i red0 -j BOGON_FULL
   iptables -F BOGON_FULL
   iptables -F BOGON_FULL_BLOCK
   iptables -X BOGON_FULL
   iptables -X BOGON_FULL_BLOCK
   ipset flush BOGON_FULL
   ipset destroy BOGON_FULL

   It’s important to get the order right.

   There will also be a file in /etc/ipset/blocklist that you can delete.

[roberto (Roberto Peña)]

Thanks Tim for this.

Is solved.

But it would be great if the uninstaller removed all the entries from iptables.

Thanks again.

Regards.

[timf (Tim FitzGeorge)]

I’ve now pushed the updated code to my repository; it’s been running for a few days on one of my systems without problems.

The only changes from the patches I submitted earlier this year are in src/initscripts/system/firewall and make.sh.

Tim

[peppetech]

Hello Tim,

Great work on this Add-on

is this Add-On and you repository for public use or is it for private use only?

[bonnietwin (Adolf Belka)]

Hi @peppetech

This addon is not yet part of IPFire.

[bonnietwin (Adolf Belka)]

Hi @timf

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.

[peppetech]

Thank you for letting me know @bonniewin