IP Address Blacklists

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.

1 Like

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 :cowboy_hat_face:

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

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.

1 Like

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.

8 Likes

Please do we will love this feature

1 Like

This looks like it will be awesome.

Hi Tim,

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. :slight_smile:

Thanks, and best regards,
Peter Müller

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.

2 Likes

Hi,

great to hear that. :slight_smile: 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.

Thanks, and best regards,
Peter Müller

1 Like
1 Like

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.

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.

1 Like

Thanks Tim for this.

Is solved.

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

Thanks again.

Regards.

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

2 Likes

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?

Hi @peppetech

This addon is not yet part of IPFire.

2 Likes

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.

Thank you for letting me know @bonniewin