Re: Core Update 161 (testing) report

[Bernhard Bitsch <bbitsch@ipfire.org>]

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

Hi,

Am 14.11.2021 um 11:52 schrieb Bernhard Bitsch:
> Am 12.11.2021 um 23:33 schrieb Bernhard Bitsch:
>> Hi,
>>
>> as far as I saw in the code, the new CGI tries the refreshing of the 
>> tail -f also. But it is never displayed.
>> I tried to search by test prints, but had no success, yet.
> 
> Reinstalled my test prints.
> The processing I saw till now:
> - update is called
>    waiting for lock ( 7 x sleep(1) )
> - no output( lockfile does not exist )
> Each - block describes a call of the .cgi
> 

I think, there's a problem with the refreshing of the page.
I'm no HTML guru, but I suppose the refreshing  only works on open 
pages. If do not exit the cgi script, but just go to the display of the 
logs, I managed to get a second box with the log snippet.
Could somebody with more experience in web design look at this?

> Next I'll add some timing information.
> 
> Update: time between calls ~35-40s
> 

- Bernhard

>> Because I didn't test the real CU 161, I'm not sure I've implemented 
>> all changes ( especially these new systemxxx functions). So I decided 
>> to stop this research.
>> I'll give a new try next days.
>>
>> Regards,
>> Bernhard
>>
>> Am 12.11.2021 um 19:54 schrieb Kienker, Fred:
>>> Peter - the behavior you describe also happens on all our testing 
>>> systems. It took us several tries to realize the systems hand not just
>>> locked up.
>>>
>>> Michael - this is a regression from previous behavior.
>>>
>>> There is never any indication to the user the update processing has been
>>> completed. The tailf of the update log provided an indication of when
>>> the processing is completed.
>>>
>>> Best regards,
>>> Fred
>>>
>>> Please note: Although we may sometimes respond to email, text and phone
>>> calls instantly at all hours of the day and night, our regular business
>>> hours are 9:00 AM - 6:00 PM ET, Monday thru Friday.
>>>
>>> -----Original Message-----
>>> From: Peter Müller <peter.mueller(a)ipfire.org>
>>> Sent: Friday, November 12, 2021 12:32 PM
>>> To: Michael Tremer <michael.tremer(a)ipfire.org>
>>> Cc: IPFire: Development <development(a)lists.ipfire.org>
>>> Subject: Re: Core Update 161 (testing) report
>>>
>>> Hello Michael,
>>>
>>> thanks for your mail. Please excuse my tardy reply - I currently have a
>>> lot of other things on my plate, and 24 hours per day are not sufficient
>>> to get them done.
>>>
>>> [Insert personal load average graph here]
>>>
>>>> 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 older CGI used to print a "tail -f"-like output of Pakfire's log,
>>> reloading the page every few seconds so the user could see the actual
>>> process of the ongoing operation.
>>>
>>> Nowadays, it only gives a spinning GIF image and a text note - better
>>> than nothing, but the user has no idea what is going on behind the
>>> scenes and how long it will take to be completed.
>>>
>>>>
>>>>> 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 dont 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.
>>> Unfortunately, I did not yet have time to look at this.
>>>
>>>>
>>>>> 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?
>>>
>>> Will do.
>>>
>>>>
>>>>> 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.
>>> Yes. Again, things are quite packet on my end - sorry.
>>>
>>> Indeed, it is a rather theoretical setup: If an attacker already got a
>>> TLS connection established so far that Suricata cannot look into it
>>> anymore, why not use that connection to conduct the malicious
>>> activities? There is no need to do protocol obfuscation anymore.
>>>
>>> Thanks, and best regards,
>>> Peter Müller
>>>
>>>>
>>>>> 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
>>>>
>>>
>>>