From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: ipblacklist V2
Date: Tue, 15 Feb 2022 12:58:49 +0000 [thread overview]
Message-ID: <EDFBE258-1162-4F94-9953-9B92280137AF@ipfire.org> (raw)
In-Reply-To: <suaufa$3da$1@tuscan3.grantura.co.uk>
[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]
Hello,
> On 13 Feb 2022, at 12:44, Rob Brewer <ipfire-devel(a)grantura.co.uk> wrote:
>
> Hi Tim, Good to see your posing here.
>
> On Saturday 12 February 2022 21:29 Tim FitzGeorge wrote:
>
>> 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 the address to an ipset if the number of dropped packets exceeded a
> threshold. This runs completely within iptables/ipset.
>>
>> 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 $autoblacklist -j SET --add-set $autoblacklist src" );
>>
>
> 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 extra rule does not change behaviour of the firewall and I wasn’t sure if it would add some false sense of extra security.
Since the firewall has no idea who is hammering some web application trying out 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, but I don’t believe that this is the right place.
>
>
>>>>>
>>>> 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?
>>>
>>> Yes, in theory we could remove any old files in the updater and install our own ones.
>>>
>
> There are a couple of errors on your uninstall-blocklist.sh script which leaves
> 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’t need this script 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
>>>> 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?
>>>
>>
>> I don't think this is needed - the change to the firewall init script should call the ipblacklist script at the correct time.
>
> I hadn't noticed the last few lines in your firewall init script which my init
> script duplicates. So I agree my addition isn't needed.
>
> I have started producing the v3 patches requested by the devs, but apart from the couple
> of changes needed to ipblacklists.dat I think they will be almost identical to your
> v2 patches.
It isn’t bad when things are identical. Good code is good code and doesn’t 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
next prev parent reply other threads:[~2022-02-15 12:58 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
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 [this message]
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=EDFBE258-1162-4F94-9953-9B92280137AF@ipfire.org \
--to=michael.tremer@ipfire.org \
--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