From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: ipblacklist V2 Date: Tue, 15 Feb 2022 12:58:49 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0546733466841064745==" List-Id: --===============0546733466841064745== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 13 Feb 2022, at 12:44, Rob Brewer wrote: >=20 > Hi Tim, Good to see your posing here. >=20 > On Saturday 12 February 2022 21:29 Tim FitzGeorge wrote: >=20 >> This sounds as if it does the same sort of thing as something I had in my = first patchset. I added an extra rule to the input policy chain that added t= he address to an ipset if the number of dropped packets exceeded a=20 > threshold. This runs completely within iptables/ipset. >>=20 >> iptables( "-I ${autoblacklist}_BLOCK -m set --match-set $autoblacklist src= -j SET --add-set $autoblacklist src --exist" ); >> iptables( "-I ${autoblacklist}_BLOCK -m set --match-set $autoblacklist dst= -j SET --add-set $autoblacklist dst --exist" ); >> iptables( "-I POLICYIN 1 -i $red_iface -m hashlimit --hashlimit-mode srcip= --hashlimit-above $settings{BLOCK_THRESHOLD}/hour --hashlimit-name $autoblac= klist -j SET --add-set $autoblacklist src" ); >>=20 >=20 > Aotoblacklist looks like a useful addition. Why did you drop t? I asked for that. I believed that it would causing more trouble than it helps. The default policy of the firewall is dropping traffic anyways. Adding an ext= ra rule does not change behaviour of the firewall and I wasn=E2=80=99t sure i= f it would add some false sense of extra security. Since the firewall has no idea who is hammering some web application trying o= ut passwords I did not see the value if that makes sense. It would be great to have some more insight into who the big offenders are, b= ut I don=E2=80=99t believe that this is the right place. >=20 >=20 >>>>>=20 >>>> There are a couple of points we need to consider: >>>>=20 >>>> 1) IPBlacklist does not work very well if Tim's ipfblocklist add-on is = also=20 >>>> installed. My view is that the add-on should be removed before IPBlackli= st=20 >>>> can be applied. Can the add-on be automatically removed on installaion a= nd=20 >>>> should we transfer the settings info from ipfbocklist to ipblacklist? >>>=20 >>> Yes, in theory we could remove any old files in the updater and install o= ur own ones. >>>=20 >=20 > There are a couple of errors on your uninstall-blocklist.sh script which le= aves > some files behind when it is run. I can send you a patch for this if it is = of help. Since this is going into the main distribution we won=E2=80=99t need this scr= ipt any more, but you can make it work for testing if you like. >>>> 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 f= cron=20 >>>> or changes made in the WUI but won't be instantly available on re-boot. = Do=20 >>>> you have any thoughts on this? >>>=20 >>=20 >> I don't think this is needed - the change to the firewall init script shou= ld call the ipblacklist script at the correct time. >=20 > I hadn't noticed the last few lines in your firewall init script which my i= nit > script duplicates. So I agree my addition isn't needed. >=20 > I have started producing the v3 patches requested by the devs, but apart fr= om the couple=20 > of changes needed to ipblacklists.dat I think they will be almost identica= l to your > v2 patches. It isn=E2=80=99t bad when things are identical. Good code is good code and do= esn=E2=80=99t need to be changed just for the sake of it. Your Git repository is still empty, do you know how to push anything into it?= I am mostly curious if I set it up okay that it will work :) -Michael > Rob=20 --===============0546733466841064745==--