Vraag over veiligheidsrisico's PHP
De security support van PHP 7 loopt af.
En de main respository voorziet niet in een update naar PHP 8.
https://wiki.debian.org/PHP#How_PHP_is_packaged_in_Debian
https://www.php.net/supported-versions.php
Wat is de beste oplossing voor dit probleem?
Ik heb gehoord van deb.sury.org , maar gezien dat hier slechts 1 persoon achter zit, brengt dit een onverantwoord beveiligingsrisico met zich mee.
Eerst zelf compileren op een ander systeem lijkt me veel gedoe met overzetten, ik ken niet alle afhankelijkheden en moet garanties hebben dat dan alles wel goed werkt, en dat binnen 2 weken omdat daarna PHP 7 niet meer ondersteund wordt.
Het kritieke productiesysteem afsluiten brengt de bedrijfscontinuïteit in gevaar.
We lijken hier vast te lopen met Debian. Als ik naar andere Linux-distributies kijk, zoals CentOS, komt ook hier weer een third party packager aan te pas.
Is dit het einde van PHP voor onze productie-omgeving?
Of moeten we verplicht overgaan op een commerciële aanbieder van Long Term Support zoals Freexian?
Wat zou jij doen ?
Edit:
Topictitel is gewijzigd van 'Beetje domme vraag' naar 'Vraag over veiligheidsrisico's PHP'
Gewijzigd op 14/11/2022 12:53:57 door - Ariën -
Je PHP blijft gewoon werken, alleen volgen er geen beveiligingsupdates meer. Het is niet zo dat ineens niks meer werkt. Aangezien dat men niet zomaar ineens je server kan binnendringen, heb je wel iets langer de tijd dan die 2 weken.
Ik zou naast de huidige server een nieuwe (test)server opzetten met een frisse installatie en daar alles naar overzetten, terwijl je de huidige server laat draaien. Op de nieuwe server ga je dan testen of alles naar behoren werkt en zo niet aanpassingen doorvoeren. Als alles werkt kun je de switch maken naar de nieuwe server en de actuele databasegegevens (indien van toepassing) overzetten.
Welke software zou je op de testserver zetten, en waar haal je die vandaan?
Ad Fundum op 14/11/2022 11:35:12:
Klinkt goed.
Welke software zou je op de testserver zetten, en waar haal je die vandaan?
Welke software zou je op de testserver zetten, en waar haal je die vandaan?
https://www.php.net/downloads.php
Toevoeging op 14/11/2022 12:49:30:
Ik ken trouwens nog genoeg omgevingen die nog steeds op PHP 5.x draaien.
1 daarvan is dit jaar naar 7.0 bijgewerkt...
Maar net zoals je nog steeds je pc met windows 7 of 8 kunt opstarten, werkt PHP 7.4 voor volgende maand nog gewoon hoor.
Gewijzigd op 14/11/2022 12:51:29 door - Ariën -
Ivo P op 14/11/2022 12:47:39:
https://www.php.net/downloads.php
Ad Fundum op 14/11/2022 11:35:12:
Klinkt goed.
Welke software zou je op de testserver zetten, en waar haal je die vandaan?
Welke software zou je op de testserver zetten, en waar haal je die vandaan?
https://www.php.net/downloads.php
Oké, maar als ik vanaf https://www.php.net/downloads.php PHP download, krijg ik geen voorgecompileerde code. Dus dan moet ik na het compileren PHP van de testserver overzetten naar de productieserver, want op de productieserver is geen build systeem aanwezig (met reden). Als ik naar https://www.php.net/manual/en/install.unix.php kom ik niet te weten hoe je de gecompileerde PHP verder kan distribueren naar andere servers. Als daar een document van zou zijn dan zou deze optie wel een mogelijkheid zijn.
Toevoeging op 14/11/2022 15:28:28:
Ivo P op 14/11/2022 12:47:39:
Toevoeging op 14/11/2022 12:49:30:
Ik ken trouwens nog genoeg omgevingen die nog steeds op PHP 5.x draaien.
1 daarvan is dit jaar naar 7.0 bijgewerkt...
Maar net zoals je nog steeds je pc met windows 7 of 8 kunt opstarten, werkt PHP 7.4 voor volgende maand nog gewoon hoor.
Ik ken trouwens nog genoeg omgevingen die nog steeds op PHP 5.x draaien.
1 daarvan is dit jaar naar 7.0 bijgewerkt...
Maar net zoals je nog steeds je pc met windows 7 of 8 kunt opstarten, werkt PHP 7.4 voor volgende maand nog gewoon hoor.
Toch kan ik met dit verhaal niet onderbouwen waarom het veilig is om Windows 7 of 8 als "server" aan het internet te hangen, helaas.
Toevoeging op 14/11/2022 15:34:11:
- Ariën - op 14/11/2022 12:49:58:
Als de main respository niet voorziet in een update naar PHP 8, dan kan je toch een aparte fork aanmaken om dit te fixxen? Of ligt de software niet in jullie beheer?
De software die we gebruiken moet aangepast om op PHP 8 te draaien, maar waar het hier om gaat is dat de main repository van Debian niet voorziet in PHP 8.
Ik heb nog op internet nagezocht wie er achter deb.sury.org zit. Deze Tsjech heeft een betrouwbare reputatie, maar opereert helemaal in zijn eentje. Hij kan dus in zijn eentje de updates bepalen van PHP 8, er is verder geen procesmatige garantie met iets als een twee-ogen-principe over wat hij op onze productieserver kan. Alleen al om die reden kan ik dat bijvoorbeeld vanuit de AVG-wetgeving niet verantwoorden naar de Autoriteit Persoonsgegevens.
Dat is heel jammer, omdat de oplossing die hij aanbiedt technisch veruit het gemakkelijkste werkt.
https://computingforgeeks.com/how-to-install-php-on-debian-linux-2/
"How To Install PHP 8.1 on Debian 11/10/9"
Ivo P op 14/11/2022 17:30:22:
Als je het via een package wilt doen:
https://computingforgeeks.com/how-to-install-php-on-debian-linux-2/
"How To Install PHP 8.1 on Debian 11/10/9"
https://computingforgeeks.com/how-to-install-php-on-debian-linux-2/
"How To Install PHP 8.1 on Debian 11/10/9"
Het probleem dat ik heb zit hem in Step 2: Add Sury APT repository to Debian. Die repository wordt beheerd door 1 enkele Tsjech, en dat is een risico. In theorie kan zo iemand op elk gewenste moment een update uitbrengen met kwaadwillende code. Het zou mooier zijn als er verschillende mensen bij betrokken zouden zijn, met een proces van testen en goedkeuren.
Vergelijk het met het doen van financiële transacties namens een organisatie, dat is ook in meerdere stappen (opdracht plaatsen, goedkeuren en uitvoeren) en door verschillende mensen.
Als er nu iets mis gaat met die repository, en je moet een datalek uitleggen aan het AP, dan heb je geen goed verhaal als je moet zeggen: "ik heb een mede Europeaan op z'n blauwe ogen geloofd, en nu ligt de data van al m'n klanten op straat"
Zelf download ik altijd de source om die vervolgens te compilen. Kost je wel eerst een middag om uit te zoeken welke onderdelen (mysql, xml, zip etc) je in je php nodig hebt, maar daarna kun je scripts-gewijs je php updaten (de minor versions bedoel ik dan: dus van 8.1.10 naar 8.1.11 of naar 8.1.14 etc)
Ik heb nooit helemaal begrepen waarom je php middels
apt-install php8 zou moeten installeren als dat betekent dat je soms maanden moet wachten voor zo iets in de distro van je Linux-versie beschikbaar is...
Nu mis ik alleen nog informatie die nodig is voor de laatste stap.
Hoe kan ik PHP van het ene systeem overzet naar het andere, zonder opnieuw te compileren?
@Ozzie, nog bedankt voor de tip! Ik kan alleen niet even de productieserver verwisselen, dat zorgt voor veel downtime.
Dus alle options in het configure commando maak je kloppend.
Tijdens het compilen wordt deze lijst opgeslagen onder de naam config.nice.
Die gebruik ik keer op keer bij mijn update-script.
Voor het upgraden roep ik aan : sh upgradephp.sh 8.1.99
Dat script luidt:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
[***@***~]$ cat upgradephp.sh
#!/bin/bash
VERSION=$1
echo $VERSION
CURRENTVERSION=$(php -r 'echo phpversion();')
echo $CURRENTVERSION
if [ $VERSION > $CURRENTVERSION ] ;
then
rm "php-$VERSION.tar.gz"
rm -rf "php-$VERSION"
/usr/bin/wget "https://www.php.net/distributions/php-$VERSION.tar.gz" &&
tar xvfz "php-$VERSION.tar.gz" &&
cd "php-$VERSION"
if [ -f "../php-$CURRENTVERSION/config.nice" ] ;
then
sh "../php-$CURRENTVERSION/config.nice"
else
sh "../php-8.1.1/config.nice"
fi
make && sudo make install && sudo service httpd restart
else
echo "already on version $VERSION"
fi
#!/bin/bash
VERSION=$1
echo $VERSION
CURRENTVERSION=$(php -r 'echo phpversion();')
echo $CURRENTVERSION
if [ $VERSION > $CURRENTVERSION ] ;
then
rm "php-$VERSION.tar.gz"
rm -rf "php-$VERSION"
/usr/bin/wget "https://www.php.net/distributions/php-$VERSION.tar.gz" &&
tar xvfz "php-$VERSION.tar.gz" &&
cd "php-$VERSION"
if [ -f "../php-$CURRENTVERSION/config.nice" ] ;
then
sh "../php-$CURRENTVERSION/config.nice"
else
sh "../php-8.1.1/config.nice"
fi
make && sudo make install && sudo service httpd restart
else
echo "already on version $VERSION"
fi
en voor referentie de inhoud van de config.nice (op _mijn_ server):
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#! /bin/sh
#
# Created by configure
'./configure' \
'--program-prefix=' \
'--datadir=/usr/share' \
'--includedir=/usr/include' \
'--with-config-file-path=/etc/php81/' \
'--with-curl' \
'--enable-gd' \
'--with-libdir=lib64' \
'--enable-exif' \
'--with-openssl' \
'--with-zlib' \
'--with-bz2' \
'--enable-soap' \
'--enable-ftp' \
'--cache-file=../config.cache' \
'--without-pear' \
'--with-apxs2=/usr/bin/apxs' \
'--enable-cli' \
'--with-kerberos' \
'--with-imap-ssl' \
'--with-zlib-dir=/usr/lib' \
'--disable-cgi' \
'--with-mysqli' \
'--with-pdo-mysql' \
"$@"
#
# Created by configure
'./configure' \
'--program-prefix=' \
'--datadir=/usr/share' \
'--includedir=/usr/include' \
'--with-config-file-path=/etc/php81/' \
'--with-curl' \
'--enable-gd' \
'--with-libdir=lib64' \
'--enable-exif' \
'--with-openssl' \
'--with-zlib' \
'--with-bz2' \
'--enable-soap' \
'--enable-ftp' \
'--cache-file=../config.cache' \
'--without-pear' \
'--with-apxs2=/usr/bin/apxs' \
'--enable-cli' \
'--with-kerberos' \
'--with-imap-ssl' \
'--with-zlib-dir=/usr/lib' \
'--disable-cgi' \
'--with-mysqli' \
'--with-pdo-mysql' \
"$@"
Dit script loopt een aantal minuten. Vooral het stuk "make" duurt lang.
NB: dit script restart ook apache.
Dit gebruik ik op een dev-omgeving. Waarschijnlijk wil je dat in productie-omgeving handmatig doen
In mijn geval heb ik naast het upgraden naar PHP 8.0 ook nog het probleem dat mijn applicatie naar PHP 8.0 moet. En dat gaat me niet lukken binnen de tijd. Ik bedacht me later pas dat zelfs al had ik aan unit tests gedaan, dan nog is het lastig vanwege de aanpassingen in booleanse logica in PHP 8.
Dus gaat de klant nu versneld over op een andere gecompileerde applicatie, en wordt PHP 7.4 direct uitgefaseerd.