From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Brewer To: development@lists.ipfire.org Subject: Re: ipblacklist V2 Date: Thu, 10 Feb 2022 15:12:47 +0000 Message-ID: In-Reply-To: <1A1775FB-102E-4629-B7A8-3D2DFAAD4A06@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6809937313724821211==" List-Id: --===============6809937313724821211== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael On Thursday 10 February 2022 09:41 Michael Tremer wrote: > Hello Rob, >=20 >=20 > 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. >=20 >=20 > I assume you are talking about this here? >=20 > =20 https://git.ipfire.org/?p=3Dpeople/timf/ipfire-2.x.git;a=3Dshortlog;h=3Drefs/= heads/ipblacklist Yes Tim's link to his ipfire git pages which links your URL. >=20 > That would have been one of my first questions having looked at my emails > again: Get the code into some Git repository. >=20 > 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. >=20 I think the very large patch which gave you problems in May 2020 and linked=20 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=3Dpeople/timf/ipfire-2.x.git;a=3Dshortlog;h=3Drefs/= 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=20 required patch I am aware of would be to ipblacklists.dat to reflect the=20 changes in the latest version of IPFire. (There could be others as I only=20 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? >=20 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=20 disk is showing 95% full. Your offer of an account on IPFire might be a=20 sensible alternative.=20 > Do you have experience with Git? >=20 > We would need to rebase the branch onto next (which Adolf has already > pointed out), but I don=E2=80=99t think this would be a problem because we = are > mainly adding new code and don=E2=80=99t modify too much existing stuff her= e. >=20 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. >>=20 >> I also use fail2ban and Banish to manage iptables blocks on the firewall. >=20 > 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. >=20 I wasn't suggesting that we add this to the current ipblacklist version.=20 However it only requires 1 extra resource added to the sources file so the=20 modifications are minimal but would have limited user appeal and it does=20 require some local processing of server lo files. However for my botnet=20 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=E2=80=99t 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. >=20 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 >=20 > Thanks for finding this. Indeed the conversation just ended in nothingness > due to lack of time of everybody I would suspect. >=20 > 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. >=20 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=20 can be applied. Can the add-on be automatically removed on installaion and=20 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=20 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=20 you have any thoughts on this? > So, can we start with rebasing the Git branch, please? >=20 No problem. Rob --===============6809937313724821211==--