From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer 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: In-Reply-To: <1f1767fc-b90e-f19a-8b4a-8e90ad970aa3@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3266711590814404302==" List-Id: --===============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 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==--