Re: Core Update 161 (testing) report

[Bernhard Bitsch <bbitsch@ipfire.org>]

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

Hello,

Am 02.11.2021 um 11:34 schrieb Michael Tremer:
> 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?

I've implemented the changes also ( took them from the patches ).
I found this difference, too. The 'old' state is, that the messages of 
the last pakfire call are displayed. The patch tries to show the actual 
update progress. But nothing of it is displayed.

> 
>> 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
> 

- Bernhard