From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: IP Address Blacklists
Date: Wed, 19 Feb 2020 18:13:38 +0100 [thread overview]
Message-ID: <ac03fd1868119c1210919781cbe364c32b28b364.camel@ipfire.org> (raw)
In-Reply-To: <E134F21C-69D1-4D63-BD5B-9921CEDFD219@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]
Hi Michael,
Am Mittwoch, den 19.02.2020, 11:52 +0000 schrieb Michael Tremer:
> Hi,
>
> > On 18 Feb 2020, at 16:49, ummeegge <ummeegge(a)ipfire.org> wrote:
> >
> > Hi all,
> >
> > Am Samstag, den 15.02.2020, 15:40 +0000 schrieb Tim FitzGeorge:
> > > Hi,
> > >
> > > I've pushed the my changes to implement IP Address Blacklists to
> > > the
> > > repository at git://git.ipfire.org/people/timf/ipfire-2.x.git on
> > > the
> > > ipblacklist branch.
> > >
> > > As a result of discussions with Michael, this has a number of
> > > changes
> > > from my first patch series:
> > >
> > > - Removed autoblacklist.
> > > - Added WUI log pages.
> > > - Removed status from settings WUI page.
> > > - Simplified download.
> > > - Modified sources file 'rate' to allow unit to be specified.
> > > - Updated sources file 'disable' to allow list to be specified.
> > > - Changed Dshield download URL to preferred address.
> > > - Removed Abuse.ch blacklist (discontinued).
> > > - Removed Talos Malicious blacklist (not appropriate).
> > > - Added Feodo recommended blacklist.
> > > - Added blocklist.de all blacklist.
> > > - Updated ignored messages in logwatch.
> > >
> > > There's also some additional code on the addresscheck branch
> > > which
> > > adds
> > > a WUI page that can check why a URL or address is being
> > > blocked. It's
> > > not production ready, but may possibly be useful in testing.
> > >
> > > Tim
> >
> > thanks for your hard work here which looks great.
> > As far as i can see, there are no possiblities to add own lists.
> > Might
> > it be an idea for such a possibility ? I use currently e.g. lists
> > from
> > firehol --> http://iplists.firehol.org/ via script and IPSet.
> > Am currently not sure how difficult it is to give the user there
> > some
> > individuality to choose it´s own list ?
>
> We currently do not allow this for the IPS either.
>
> And I am not really sure if we should. Why would we not add the lists
> for all users if we see any value in them.
>
> What reasons are there to allow users to do their own thing?
Use cases can be different e.g. i remeber a project in the old forum
which was about a company blocker (facebook, Windows, Apple) or in
general the whole telemetry stuff can also be unwanted and there are
some lists out there which can help to block also the "good" ones. If
there are own vast lists of unwanted IPs, IPSet which is working here,
is then the best way to do so, therefor my idea to bring in some
flexibility in this great project to prevent scripting around in
parallel for, let´s say, doing the same twice.
>
> >
> > Best,
> >
> > Erik
> >
>
>
next prev parent reply other threads:[~2020-02-19 17:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-15 15:40 Tim FitzGeorge
2020-02-18 14:58 ` Michael Tremer
2020-02-18 16:49 ` ummeegge
2020-02-19 11:52 ` Michael Tremer
2020-02-19 17:13 ` ummeegge [this message]
2020-02-19 17:21 ` Michael Tremer
2020-02-19 18:43 ` ummeegge
2020-02-19 19:48 ` Thoughts regarding IP-based ad blockers (was: Re: IP Address Blacklists) Peter Müller
2020-02-19 22:47 ` IP Address Blacklists Tim FitzGeorge
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=ac03fd1868119c1210919781cbe364c32b28b364.camel@ipfire.org \
--to=ummeegge@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