public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Tim FitzGeorge <ipfr@tfitzgeorge.me.uk>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/5] ipblacklist: IP Address Blacklists
Date: Wed, 22 Jan 2020 20:35:11 +0000	[thread overview]
Message-ID: <b8b2d7ad-a8d9-22cc-0eaf-eee92c6cce9b@tfitzgeorge.me.uk> (raw)
In-Reply-To: <D09011E8-45E0-443A-B4B1-95B475722753@ipfire.org>

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

Hello Michael,

On 06/01/2020 11:21, Michael Tremer wrote:
> 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 think I'd rather keep them separate, since conceptually they're rather
different.  Also, if your red interface has a private address, you
definitely wouldn't want to enable these lists.

>
> 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 suspect that anything more specific that Attacks is going to only
describe a single list.  It's (unfortunately) a catch-all category for
anything that doesn't fit better somewhere else.

I'd rather not merge it with Malware C&C since the behaviour of the two
is rather different - under most circumstances lists in this category
shouldn't block any packets, whereas the Attacks category is expected to
block a lot of inbound traffic.

>
>> 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
>

Tim

>>
>> 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
>>>
>>
>


  reply	other threads:[~2020-01-22 20:35 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
2020-01-22 20:35           ` Tim FitzGeorge [this message]
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=b8b2d7ad-a8d9-22cc-0eaf-eee92c6cce9b@tfitzgeorge.me.uk \
    --to=ipfr@tfitzgeorge.me.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