Re: Core Update 161 (testing) report

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]

Hello,

> On 2 Nov 2021, at 08:01, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> Core Update 161 (testing; no release announcement or changelog has been published, 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 messages as it
> used to do, but at least there is now a spinning loading icon displaying the 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 could not download
> add-on upgrades afterwards since the VPN did not came back in time, so I had to do this
> manually.

Normally people don’t download packages over a VPN. So I can live with 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 "restart" 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 regression introduced in this update?

> Apart from that, this update looks quite good to me. The IPS changes are really 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 for everyone,
> hence massively increasing security without worrying too much of performance impacts.
> 
> (For the sake of completeness: Unfortunately I did not yet have time do conduct a penetration
> test against this. Personally, I can imagine the IPS changes permitting some attacks
> after Suricata decided it cannot analyse a connection further. Switching protocols 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. Although 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 wanted to look deeper
> into this as soon as I have some spare time to do so.)
> 
> 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)
> 
> I am looking forward to the release of Core Update 161.
> 
> Thanks, and best regards,
> Peter Müller

-Michael