From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/5] ipblacklist: IP Address Blacklists
Date: Thu, 05 Dec 2019 22:25:50 +0000
Message-ID: <F668BB11-A30E-4141-8AFC-6054E9354A75@ipfire.org>
In-Reply-To: <1f1767fc-b90e-f19a-8b4a-8e90ad970aa3@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3266711590814404302=="
List-Id: <development.lists.ipfire.org>

--===============3266711590814404302==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

> On 4 Dec 2019, at 17:05, Peter M=C3=BCller <peter.mueller(a)ipfire.org> wro=
te:
>=20
> Hello Tim, hello Michael,
>=20
> please see my responses inline...
>>>>=20
>>>> We could periodically update the blacklists on our main mirror (and
>>>> wait for the network to sync it), make sure it is signed and write
>>>> a small downloader that fetches, validates and installs them.
>>>>=20
>>>> @All: Thoughts on this?
>>>=20
>>> I think there are a number of points here.
>>>=20
>>> Firstly, from the point of a third party using IPFire, is this really
>>> solving the privacy disclosure problem?  There's no way round disclosing
>>> your public IP address to someone you're downloading from; all this does
>>> is change who that information is being disclosed to.  For the  user
>>> there's no way of knowing whether the source is more or less protective
>>> of the user's privacy than the blacklist provider.  Indeed it won't be
>>> possible to know who the lists are being downloaded from until the
>>> download starts.
>>=20
>> There is a way: Tor. But that is a totally different story.
> Well, I see a third option on this: Use the mirror infrastructure we already
> have. Every IPFire installation discloses its public IP address to one of t=
hese
> servers sooner or later, so we do not disclose additional data if the black=
lists
> were fetched from these.
>=20
> Needless to say, Tor (hidden services) would be better, but that is a diffe=
rent
> story indeed. :-)
>>=20
>> The point is rather that a forget list can be sent instead of the =E2=80=
=9Creal=E2=80=9D one.
> I did not get this. Forget? Forged?? ???

Yes, I meant to write forged, but auto-correct didn=E2=80=99t let me.

>>> Secondly, latency; some of the lists are updated every 5 minutes.  While
>>> I've limited the maximum check rate to hourly, will the updates
>>> propagate quickly enough.  For reference on my main system the 24
>>> updates on the CIARMY list made 143 498 changes (additions or
>>> deletions).  I've seem it do over 200 000.
> Yes, I observe that behaviour for CINS/CIArmy too. Unfortunately, they do n=
ot
> document a recommended update interval anywhere, so we can only guess.
>=20
> Personally, more static lists seem to be preferable for packet filtering. H=
ighly
> dynamic ones such as CIArmy should be done via DNSBL queries or something s=
imilar
> - do we really want to have that list here?

It is not really an option to implement a DNSBL into a packet filter, but I g=
et your point.

>> How did you come up with the hour? Will it be retried more often if the do=
wnload was not successful?
> One hour is the most common interval indeed, but adding some random time mi=
ght
> be useful in order to reduce load on the servers providing a blacklist.

Yes, definitely. Otherwise we will shoot down our mirrors.

>>> Third, bandwidth; while the downloads are fairly small (ALIENVAULT is
>>> the largest at a few MB), there are going to be a lot of them.  How will
>>> this affect the willingness of people to mirror IPFire?
> I do not consider this being a problem as we do not generate that much traf=
fic
> to them. Of course, that depends on the update interval again.

That depends on your point of view.

I do not have a problem with this at all in my data center, but there are ple=
nty of people with a volume-based LTE plan or simply a 128 kBit/s connection.=
 It will take a longer time to download the lists for them. We need to mind t=
hat.

>>>=20
>>>>=20
>>>> Talking about the preference of packet filter and IPS, I prefer to
>>>> use the latter as well as it gains more insight in what kind of malicious
>>>> traffic tried to pass a firewall machine. On systems with low resources,
>>>> this might be problematic and removing load from the IPS can be preferred
>>>> (make this configurable?!), on others, people might want to have both
>>>> results.
>>>>=20
>>> You're only going to get one result for a packet whichever way round the
>>> IP blacklist and IPS are since whichever comes first will drop the
>>> packet before it reaches the second (well it would be possible to put
>>> the IP blacklist first and get it to log and mark packets which are then
>>> dropped after the IPS, but I think that's getting a little complicated.
>>> In addition I've seen the messages about the trouble marking was
>>> causing in the QoS).
>>>=20
>>> I think it's a 50/50 choice as to which is more valuable first; it's
>>> probably going to differ from packet to packet.  For me the possibility
>>> of reducing the IPS load means I prefer putting the IP blacklist first
>>>=20
>>> It should be fairly easy to add the choice of where to put the IP
>>> blacklist.  I think it'll have to be in the main firewall script, so
>>> it'll require a firewall restart, but it's not something that'll be
>>> changed often.
>>=20
>> I do not think that the user should choose this. If we cannot easily make =
a decision, how can our users do this? Not saying they are stupid here, we ar=
e just giving them something so that they do not have to put the thought and =
research into things themselves and make their jobs easier.
> Agreed.
>=20
>>=20
>> I think performance matters. And if the IPS comes first, the most likely c=
ase would be that we are seeing a SYN packet that is being scanned and after =
that being dropped by the blacklist. It was pointless to even scan the empty =
packet (TCP fast open aside). This is only different for other packets with p=
ayloads.
>>=20
>> We would protect the IPS from a SYN flooding attack here at least and from=
 scanning more packets unnecessarily.
> So dropping packets from blacklisted IP addresses/networks before IPS is it=
, then.
>>=20
>> I do not even think it makes sense to swap the order in the outgoing direc=
tion.
> Me too.
>=20
>>=20
>> What IPFire is lacking is a statistical analysis for those logs. Collectin=
g more and more data isn=E2=80=99t helpful from my point of view. Only if you=
 are looking at a very specific thing.This is true, but I am not sure if it m=
akes sense to spend too much work on this.
> Based on my personal experience, firewall hits observed on a single machine=
 exposed
> to the internet are interesting, but the overall situation across multiple =
machines
> is even more interesting. Very quickly, you'll end on something like a cent=
ralised
> logging server and custom statistical analysis here...

Probably a project for IPFire 4.0 :)

>>=20
>>>>=20
>>>> Personally, I consider Spamhaus DROP/EDROP can be safely enabled by defa=
ult.
>>>> I would love to see the bogon ruleset here, too (think about 8chan succe=
ssor
>>>> hosted at unallocated RIPE space in Saint Petersburg), but that will lik=
ely cause
>>>> interference if RED does not have a public IP address assigned.
>>>=20
>>> I can add a field to the options file that controls whether a list is
>>> enabled by default.
> Thank you. :-)
>>=20
>> To stress the point from above again: We would then share all public IP ad=
dresses of all IPFire systems in the world with Spamhaus and who is hosting t=
heir infrastructure. That can be considered a threat.
> This is my only objection against this patchset. Now, what can we do about =
it?
> One possibility is to apply the patchset now and implement a custom download
> source thing later on, or do that before releasing Core Update 139 (or whic=
h version
> the patchset will be to) after we agreed on something.

I do not see this being merged for 139. But that is not important. We need to=
 get it right first and then release it.

As far as I know, nobody has tested this, yet.

I have huge concerns about the automatic blacklist. @Peter: What is your opin=
ion on this?

> If we do, I will have a look at the licensing stuff (DShield and Spamhaus d=
o not
> seem to be problematic, as they are hosted on 3rd party servers, too).

One of them will be, sooner or later. And one is enough I suppose.

I do not really want to overthink this - we didn=E2=80=99t do this with clama=
v for example either. But it probably is a decision to be made by the user wh=
at they want to enable and we should not enable anything by default. So no da=
ta will be leaked as long as the user does not consent.

-Michael

>=20
> Thanks, and best regards,
> Peter M=C3=BCller


--===============3266711590814404302==--