public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Rob Brewer <ipfire-devel@grantura.co.uk>
To: development@lists.ipfire.org
Subject: Re: ipblacklist V2
Date: Thu, 10 Feb 2022 15:12:47 +0000	[thread overview]
Message-ID: <su3a1g$7o2$1@tuscan3.grantura.co.uk> (raw)
In-Reply-To: <1A1775FB-102E-4629-B7A8-3D2DFAAD4A06@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 5603 bytes --]

Hi Michael

On Thursday 10 February 2022 09:41 Michael Tremer wrote:

> Hello Rob,
> 
> 
> Good to hear that you are in touch. I would like to invite Tim to join the
> conversation on here. I am sure he has a couple of thoughts to contribute
> and I hope he can find the time.
> 
> 
> I assume you are talking about this here?
> 
>   
https://git.ipfire.org/?p=people/timf/ipfire-2.x.git;a=shortlog;h=refs/heads/ipblacklist

Yes Tim's link to his ipfire git pages which links your URL.

> 
> That would have been one of my first questions having looked at my emails
> again: Get the code into some Git repository.
> 
> This is a large patchset and it is very difficult to scroll up and down to
> review it. Uploading it to a Git repository that is browsable in a web
> browser somewhere would be a lot better and we can put any patches on top
> of the branch, so that we only will have smaller changes to review and not
> a whole patchset again and again.
> 
I think the very large patch which gave you problems in May 2020 and linked 
to below and (PATCH v2 0/8 on Patchwork), patched the abandoned version 1 of 
ipblacklist to version 2. The resulting V2 patches:

ipblacklist: Build infrastructure
ipblacklist: Modifications to system
ipblacklist: Ancillary files
ipblacklist: WUI menus, language file etc
ipblacklist: WUI Log details page
ipblacklist: WUI Log page
ipblacklist: WUI Settings page
ipblacklist: Main script

are on:
https://git.ipfire.org/?p=people/timf/ipfire-2.x.git;a=shortlog;h=refs/heads/ipblacklist

I think these were (at May 2020) pretty much ready to go and would only need 
updating if the core files have changed in the meantime. To date the only 
required patch I am aware of would be to ipblacklists.dat to reflect the 
changes in the latest version of IPFire. (There could be others as I only 
patched  my system files rather than replaced them)


> Do you have a Git repository somewhere? Would you like me to set up your
> IPFire account so that you can use our servers?
> 

I have a Git Development Environment on this computer (Debian Sid 5.16.0-1-
amd64 16GB memory) currently at core163 but is a bit short of room as the 
disk is showing 95% full. Your offer of an account on IPFire might be a 
sensible alternative. 


> Do you have experience with Git?
> 
> We would need to rebase the branch onto next (which Adolf has already
> pointed out), but I don’t think this would be a problem because we are
> mainly adding new code and don’t modify too much existing stuff here.
> 
I don't think that would be a problem.

>> You may be interested in one of the modification I have made to
>> ipblacklist, is to add an additional local blacklist to the sources file
>> to get a
>> blocklist from a web server on my local network.  This is populated by a
>> script which greps the mail server logs for SMTP Auth attacks and has
>> been particularly useful in protecting the mail server from a recent
>> botnet attack where the offending ip addresses have been recycled every
>> one to three weeks. Currently the blocklist contains about 3000 ip
>> addresses and has blocked nearly 2000 smtp auth attempts so far to-day.
>> 
>> I also use fail2ban and Banish to manage iptables blocks on the firewall.
> 
> This is kind of a fail2ban but on the firewall. Since this patchset is
> already so large and there has been a custom blocklist existing before
> which got removed, I would push this project back a little bit until we
> have a base that we can add new features to.
> 
I wasn't suggesting that we add this to the current ipblacklist version. 
However it only requires 1 extra resource added to the sources file so the 
modifications are minimal but would have limited user appeal and it does 
require some local processing of server lo files. However for my botnet 
attack it is being very effective.

> I am not entirely convinced that this functionality scales well across all
> users. How would they move the logs to the firewall? We don’t have a
> simple API, but if we did, we would not have a system to authenticated
> other servers. This would be a project that I would find a little bit more
> complicated and we would need a couple more pieces in the puzzle before we
> are ready for it.
> 
I fully agree.

>> The last communication I could find between yourself and Tim was in May
>> 2020. https://lists.ipfire.org/pipermail/development/2020-May/007822.html
> 
> Thanks for finding this. Indeed the conversation just ended in nothingness
> due to lack of time of everybody I would suspect.
> 
> I could not find anything on the list that I would consider a blocker.
> There are however some smaller things like translations and probably there
> will be a couple of minor bugs and some improvements to the look and feel.
> 
There are a couple of points we need to consider:

1) IPBlacklist does not work very well if Tim's  ipfblocklist add-on is also 
installed. My view is that the add-on should be removed before IPBlacklist 
can be applied. Can the add-on be automatically removed on installaion and 
should we transfer the settings info from ipfbocklist to ipblacklist?

2) I added a init script to my firewall which doesn't seem to be present on 
Tim's patches. I'm not sure if this is needed as it will be started by fcron 
or changes made in the WUI but won't be instantly available on re-boot. Do 
you have any thoughts on this?


> So, can we start with rebasing the Git branch, please?
> 

No problem.

Rob


  reply	other threads:[~2022-02-10 15:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-04 18:17 Rob Brewer
2022-02-07 10:31 ` Michael Tremer
2022-02-07 12:58   ` Rob Brewer
2022-02-09 14:38     ` Adolf Belka
2022-02-09 21:43       ` Rob Brewer
2022-02-09 22:14         ` Adolf Belka
2022-02-10  9:45           ` Michael Tremer
2022-02-09 13:23   ` Rob Brewer
2022-02-09 14:29     ` Adolf Belka
2022-02-10  9:41     ` Michael Tremer
2022-02-10 15:12       ` Rob Brewer [this message]
2022-02-10 16:48         ` Michael Tremer
2022-02-12 21:29           ` Tim FitzGeorge
2022-02-13 12:44             ` Rob Brewer
2022-02-15 12:58               ` Michael Tremer
2022-02-15 12:54             ` Michael Tremer
     [not found] <ef8ac1dcde46b22207dde653d6717a95d2a737e7.camel@ipfire.org>
2022-03-01 13:13 ` Michael Tremer
2022-03-01 16:08 ` Rob Brewer
2022-03-05 18:52 ` Stefan Schantl
2022-03-05 21:46   ` Rob Brewer
2022-03-07 20:39     ` Michael Tremer
2022-03-07 22:54       ` Rob Brewer
2022-03-08 10:59         ` Rob Brewer
2022-03-08 15:45           ` Michael Tremer
2022-04-03  9:16           ` Stefan Schantl
2022-04-03 21:09             ` Rob Brewer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='su3a1g$7o2$1@tuscan3.grantura.co.uk' \
    --to=ipfire-devel@grantura.co.uk \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox