IP Address Blacklists

Add-Ons
#1

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.

Screenshot_2020-01-22%20ipfire%20pookie%20home%20-%20IP%20Blocklists
Screenshot_2020-01-22%20ipfire%20pookie%20home%20-%20IP%20Blocklists1010×603 34.1 KB

Protect users who get spammy phishing links in emails
#2

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
#3

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:

#4

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

#5

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
#6

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
#7

Please do we will love this feature

1 Like
#8

This looks like it will be awesome.

#9

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

#10

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
#11

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
#12
#13

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:

imagen
imagen986×213 6.6 KB

The rules keep popping up.

imagen
imagen762×535 12.9 KB

How to fix it?

Regards.

#14

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
#15

Thanks Tim for this.

Is solved.

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

Thanks again.

Regards.

#16

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