From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Core Update 161 (testing) report Date: Tue, 02 Nov 2021 10:34:21 +0000 Message-ID: <25E7086E-51A6-4C73-96F2-5C6012348D28@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0056466574954619050==" List-Id: --===============0056466574954619050== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 2 Nov 2021, at 08:01, Peter M=C3=BCller wro= te: >=20 > Hello *, >=20 > Core Update 161 (testing; no release announcement or changelog has been pub= lished, yet) > is running here for about 12 hours by now without any major issues known so= far. Yay \o/ > During the upgrade, I noticed the Pakfire CGI still does not display log me= ssages as it > used to do, but at least there is now a spinning loading icon displaying th= e message that > an operation is currently in progress. From a UX perspective, this is okay = I guess. What is different about it? > The reconnection necessary for upgrading pppd went smooth, albeit Pakfire c= ould not download > add-on upgrades afterwards since the VPN did not came back in time, so I ha= d to do this > manually. Normally people don=E2=80=99t download packages over a VPN. So I can live wit= h this. > To my surprise, some IPsec N2N connections did not reconnect automatically,= even after > rebooting the testing machine. After manually clicking on one of the "resta= rt" buttons > on the IPsec CGI, they came back instantly, and have been stable ever since. Anything in the logs? It should come back automatically. > This affected N2N connections not being in the "on-demand" mode only. While= it is not > really a show-stopper if someone is sitting in front of his/her/its IPFire = machine, remote > upgrades might be tricky. Indeed. Could you please investigate further whether this is or is not a regr= ession introduced in this update? > Apart from that, this update looks quite good to me. The IPS changes are re= ally noticeable, > and bring a throughput I think I never experienced with IPFire and the IPS = turned on. :-) > This is certainly worth mentioning, as it finally makes the IPS suitable fo= r everyone, > hence massively increasing security without worrying too much of performanc= e impacts. >=20 > (For the sake of completeness: Unfortunately I did not yet have time do con= duct a penetration > test against this. Personally, I can imagine the IPS changes permitting som= e attacks > after Suricata decided it cannot analyse a connection further. Switching pr= otocols might > be an issue, starting with TLS, while using something completely different = afterwards. I expected you to bring this up a lot earlier and it is indeed a concern. Alt= hough I think it is a theoretical one: * You cannot really change back from a TLS connection on any application that= I am aware of * Suricata only does this if it is very very certain that the connection can = be bypassed and just hope the guys over there know what they are doing. > While I do not really consider this to be a critical attack surface, I want= ed to look deeper > into this as soon as I have some spare time to do so.) >=20 > Tested IPFire functionalities in detail: > - PPPoE dial-up via a DSL connection > - IPsec (N2N connections only) > - Squid (authentication enabled, using an upstream proxy) > - OpenVPN (RW connections only) > - IPS/Suricata (with Emerging Threats community ruleset enabled) > - Guardian > - Quality of Service > - DNS (using DNS over TLS and strict QNAME minimisation) > - Dynamic DNS > - Tor (relay mode) >=20 > I am looking forward to the release of Core Update 161. >=20 > Thanks, and best regards, > Peter M=C3=BCller -Michael --===============0056466574954619050==--