From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH 0/5] ipblacklist: IP Address Blacklists Date: Wed, 04 Dec 2019 17:05:00 +0000 Message-ID: <1f1767fc-b90e-f19a-8b4a-8e90ad970aa3@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0264119474039271060==" List-Id: --===============0264119474039271060== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Tim, hello Michael, please see my responses inline... >>> >>> 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. >>> >>> @All: Thoughts on this? >> >> I think there are a number of points here. >> >> 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 the= se servers sooner or later, so we do not disclose additional data if the blackli= sts were fetched from these. Needless to say, Tor (hidden services) would be better, but that is a differe= nt story indeed. :-) >=20 > The point is rather that a forget list can be sent instead of the =E2=80=9C= real=E2=80=9D one. I did not get this. Forget? Forged?? ??? >=20 >> 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 not document a recommended update interval anywhere, so we can only guess. Personally, more static lists seem to be preferable for packet filtering. Hig= hly dynamic ones such as CIArmy should be done via DNSBL queries or something sim= ilar - do we really want to have that list here? >=20 > How did you come up with the hour? Will it be retried more often if the dow= nload was not successful? One hour is the most common interval indeed, but adding some random time might be useful in order to reduce load on the servers providing a blacklist. >=20 >> 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 traffic to them. Of course, that depends on the update interval again. >> >>> >>> 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. >>> >> 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). >> >> 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 >> >> 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 are= just giving them something so that they do not have to put the thought and r= esearch into things themselves and make their jobs easier. Agreed. >=20 > I think performance matters. And if the IPS comes first, the most likely ca= se would be that we are seeing a SYN packet that is being scanned and after t= hat being dropped by the blacklist. It was pointless to even scan the empty p= acket (TCP fast open aside). This is only different for other packets with pa= yloads. >=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 direct= ion. Me too. >=20 > What IPFire is lacking is a statistical analysis for those logs. Collecting= 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 ma= kes sense to spend too much work on this. Based on my personal experience, firewall hits observed on a single machine e= xposed to the internet are interesting, but the overall situation across multiple ma= chines is even more interesting. Very quickly, you'll end on something like a centra= lised logging server and custom statistical analysis here... >=20 >>> >>> Personally, I consider Spamhaus DROP/EDROP can be safely enabled by defau= lt. >>> I would love to see the bogon ruleset here, too (think about 8chan succes= sor >>> hosted at unallocated RIPE space in Saint Petersburg), but that will like= ly cause >>> interference if RED does not have a public IP address assigned. >> >> 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 add= resses of all IPFire systems in the world with Spamhaus and who is hosting th= eir 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 which = version the patchset will be to) after we agreed on something. If we do, I will have a look at the licensing stuff (DShield and Spamhaus do = not seem to be problematic, as they are hosted on 3rd party servers, too). Thanks, and best regards, Peter M=C3=BCller --===============0264119474039271060==--