From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/5] ipblacklist: IP Address Blacklists
Date: Mon, 06 Jan 2020 11:21:19 +0000 [thread overview]
Message-ID: <D09011E8-45E0-443A-B4B1-95B475722753@ipfire.org> (raw)
In-Reply-To: <f4ef2b83-6b73-9f9b-f79c-87e113e6126c@tfitzgeorge.me.uk>
[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]
Hello Tim,
> On 28 Dec 2019, at 21:17, Tim FitzGeorge <ipfr(a)tfitzgeorge.me.uk> wrote:
>
> Hi,
>
> Having decided that we'll categorise the lists, the question is what
> categories to use. They need to be:
>
> - Short (to fit on the screen)
> - Easily translatable
> - and above all, useful.
>
> Looking at the lists the obvious categories are:
>
> - Invalid Address (on the public internet)
> BOGON, BOGON_FULL
>
> - Scanner (not by itself malicious)
> SHODAN
>
> - Application (potentially unwanted)
> TOR_ALL, TOR_EXIT
>
> - Malware C & C
> FEODO_RECOMMENDED, FEODO_IP, FEODO_AGGRESIVE
>
> - Composite
> EMERGING_FWRULE
I like all these a lot.
> Less obvious are:
>
> - Reputation
> ALIENVAULT, CIARMY, SPAMHAUS_DROP, SPAMHAUS_EDROP
>
> - Attacks
> BLOCKLIST_DE, DSHIELD, EMERGING_COMPROMISED
I even like those two, although I would potentially consider merging “Invalid Address” and Reputation. They are kind of the same to me. IP addresses I under no circumstances I want to talk to.
I also like the Attacks category, although the name is very generic. But I cannot come up with anything better. The only thing that might be worth considering is to merge it with Malware and just call it “Malicious”.
> I'm not sure that the distinction between these two is going to be
> helpful to most people (I'm not sure I understand it myself).
>
> We could use:
>
> - Top attackers
> DSHIELD, EMERGING_COMPROMISED, SPAMHAUS_DROP, SPAMHAUS_EDROP
>
> - Other attackers
> ALIENVAULT, BLOCKLIST_DE, CIARMY
>
> but that might be making a distinction that is better made by the user.
Agreed. It is not obvious why some are top attackers and others are not.
So I would 100% prefer the first option from above.
Best,
-Michael
>
> Any opinions?
>
> Tim
>
>
> On 18/12/2019 12:10, Michael Tremer wrote:
>> Hi,
>>
>>> On 16 Dec 2019, at 23:05, Tom Rymes <trymes(a)rymes.com> wrote:
>>>
>>> On 12/16/2019 5:20 PM, Michael Tremer wrote:> Hi,
>>>>
>>>>> On 16 Dec 2019, at 20:06, Tim FitzGeorge <lists(a)tfitzgeorge.me.uk> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I've attached the current GUI screenshot.
>>>>
>>>> Thanks for that.
>>>>
>>>> I have a couple of suggestions/concerns about it:
>>>
>>> [snip]
>>>
>>>> c) I would suggest to remove the “safe” column because that is a very hard summary of what the lists do. We should explain that on the wiki. I guess this is too complicated to explain to our users in one sentence and it needs at least a page of text. People who do not read that have you just lost out.
>>>
>>> [snip]
>>>
>>> May I opine that the "Safe" information would be helpful to me in the WUI. Perhaps we can be more explicit, or better explain, such as is often done with RBLs in mail server settings, where lists are sometimes described in terms of their likelihood to cause false-positives.
>>>
>>> It's all well and good in the documentation, but a quick "Safe|Moderate|Risky" listing in the WUI will prove handy, IMHO.
>>>
>>> Just my $0.02 as more of a user than a developer,
>>
>> I appreciate your input, but I still disagree with is that we take the decision if something is “risky” or not. There are too many things that need to be taken into account to make that decision and it probably varies for each user.
>>
>> What I take from your comment though is that we should categorise the lists, and that is something we can do.
>>
>> We can add a headline to the table and group the lists by “Blocking ambiguous packets”, “Blocking Malware”, etc.
>>
>> That makes it easier for the user to decide which lists are interesting or even necessary depending on what they want to achieve.
>>
>> How is that?
>>
>> -Michael
>>
>>>
>>> Tom
>>
>
next prev parent reply other threads:[~2020-01-06 11:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c0c3b48a-f773-8002-a004-82ff150ea1bb@tfitzgeorge.me.uk>
2019-12-16 22:20 ` Michael Tremer
2019-12-16 23:05 ` Tom Rymes
2019-12-18 12:10 ` Michael Tremer
2019-12-28 21:17 ` Tim FitzGeorge
2020-01-06 11:21 ` Michael Tremer [this message]
2020-01-22 20:35 ` Tim FitzGeorge
2020-01-23 10:53 ` Michael Tremer
[not found] <aeb93668-a4b6-5735-1f68-fd53cafa2210@tfitzgeorge.me.uk>
2020-01-06 11:27 ` Michael Tremer
2020-01-24 19:40 ` Tim FitzGeorge
2020-01-28 17:14 ` Michael Tremer
2020-01-29 20:40 ` Tim FitzGeorge
2020-01-30 12:54 ` Michael Tremer
2020-01-30 20:24 ` Tim FitzGeorge
2020-01-30 21:26 ` Michael Tremer
[not found] <6583305a-cd0d-94a5-aa8e-5456622de824@tfitzgeorge.me.uk>
2019-12-18 12:07 ` Michael Tremer
2019-12-21 18:34 ` Tim FitzGeorge
2019-12-24 10:29 ` Michael Tremer
2019-12-28 20:59 ` Tim FitzGeorge
2019-11-25 20:13 Tim FitzGeorge
2019-11-25 21:09 ` Peter Müller
2019-11-27 21:34 ` Tim FitzGeorge
2019-11-28 12:03 ` Michael Tremer
2019-11-28 21:39 ` Peter Müller
2019-11-29 23:25 ` Tim FitzGeorge
2019-12-02 11:17 ` Michael Tremer
2019-12-04 17:05 ` Peter Müller
2019-12-05 22:25 ` Michael Tremer
2019-12-08 20:50 ` Tim FitzGeorge
2019-12-13 23:11 ` Michael Tremer
2019-12-02 11:06 ` Michael Tremer
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=D09011E8-45E0-443A-B4B1-95B475722753@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