Serverbeveiliging en PHP-onderhoud: hoe ik amirs.life veiliger maak

Datum: 22 oktober 2026
Categorie: Serverbeheer, cybersecurity en infrastructuur
Leestijd: 5 minuten

Waarom ik mijn VPS tijdelijk heb stilgelegd

De beveiliging van een website begint niet alleen bij de applicatiecode. Ook het besturingssysteem, de PHP-runtime, de webserver en de beheeromgeving moeten up-to-date blijven.

Nadat ik een potentieel ernstig PHP-beveiligingsprobleem had geïdentificeerd, heb ik besloten mijn VPS tijdelijk stil te leggen. Daarmee wilde ik voorkomen dat ik de server onnodig bleef blootstellen terwijl ik onderzocht welke updates nodig waren.

Mijn VPS draait op Ubuntu 24.04 LTS met Plesk Obsidian. Op deze server wordt onder andere de infrastructuur voor amirs.life beheerd.

In deze blog beschrijf ik welke controles zijn uitgevoerd, welke problemen ik tegenkwam en welke stappen nodig zijn om de server verantwoord weer online te brengen.

1. De serveromgeving in kaart brengen

De eerste stap was het verzamelen van informatie over de bestaande configuratie.

De server bleek te draaien op:

Ubuntu 24.04.5 LTS
Plesk Obsidian 18.0.81.3
PHP 8.3 via de Ubuntu-pakketten
Plesk-managed PHP 8.3
Plesk-managed PHP 8.4

Hierbij kwam een belangrijk aandachtspunt naar voren: de server heeft meerdere PHP-installaties.

De PHP-versie die via de terminal wordt weergegeven, is niet noodzakelijk dezelfde versie die een website via PHP-FPM gebruikt. Daarom is ook de lijst met PHP-handlers van Plesk gecontroleerd.

Dit onderscheid is belangrijk bij beveiligingsupdates. Alleen de standaard PHP-installatie bijwerken is niet voldoende wanneer websites een afzonderlijke runtime gebruiken.

2. De pakketbronnen en systeemupdates controleren

Vervolgens heb ik de Ubuntu-pakketbronnen bijgewerkt en een simulatie van beschikbare upgrades uitgevoerd.

Daaruit bleek dat verschillende systeem- en beveiligingspakketten konden worden bijgewerkt. De simulatie liet onder andere updates zien voor AppArmor, Fail2ban en Plesk Watchdog.

Er waren ook acht pakketten waarvan de updates vanwege gefaseerde uitrol waren uitgesteld.

Tijdens deze controle kwamen twee aanvullende problemen naar voren.

Een afwijking in de systeemtijd

Ubuntu weigerde bepaalde pakketmetadata te accepteren omdat deze volgens de serverklok nog niet geldig waren.

Ik heb daarom de status van de tijdsynchronisatie gecontroleerd en de synchronisatieservice opnieuw gestart.

Daarna gaf APT geen fouten meer over repositorymetadata die in de toekomst gedateerd zou zijn.

Een correcte systeemtijd is essentieel voor betrouwbare pakketupdates, certificaatvalidatie en het analyseren van beveiligingslogs.

Een ontbrekende Plesk-ondertekeningssleutel

De PHP 8.3- en PHP 8.4-pakketbronnen van Plesk konden hun digitale handtekening niet laten verifiëren. APT meldde dat de publieke sleutel met ID 5B6AB2160B50DB96 ontbrak.

Ik heb de officiële Plesk-ondertekeningssleutel opgehaald en de volledige vingerafdruk gecontroleerd voordat ik deze aan de vertrouwde sleutelopslag toevoegde.

De vingerafdruk kwam overeen met de verwachte sleutel. Toch bleven de PHP-pakketbronnen daarna een verificatiefout geven.

Daarom is de oorzaak van het resterende probleem nog niet definitief vastgesteld. De repositoryconfiguratie moet verder worden onderzocht voordat PHP-updates veilig kunnen worden uitgevoerd.

3. Waarom digitale handtekeningen belangrijk zijn

Een pakketbeheerder zoals APT controleert de digitale handtekeningen van pakketbronnen om te voorkomen dat niet-geauthenticeerde software wordt geïnstalleerd.

Wanneer die controle mislukt, is het niet verstandig om de beveiligingscontrole uit te schakelen of pakketten van niet-geverifieerde bronnen te installeren.

De juiste aanpak is om te onderzoeken waarom de sleutel niet wordt herkend, bijvoorbeeld door de repositoryconfiguratie en eventuele Signed-By-instellingen te controleren.

Dit voorkomt dat een beveiligingsprobleem wordt vervangen door een nieuw risico in het updateproces.

4. Wat is er tot nu toe gedaan?

De volgende werkzaamheden zijn uitgevoerd:

De Ubuntu- en Plesk-versies vastgesteld.
De beschikbare PHP-handlers geïnventariseerd.
De Ubuntu-pakketbronnen bijgewerkt en de beschikbare upgrades gesimuleerd.
De tijdsynchronisatie gecontroleerd en opnieuw gestart.
De Plesk-ondertekeningssleutel gecontroleerd aan de hand van de volledige vingerafdruk.
De sleutel toegevoegd aan de vertrouwde sleutelopslag.
De pakketbronnen opnieuw gecontroleerd.

De resterende fout bij de Plesk PHP 8.3- en PHP 8.4-repositories betekent dat het patchproces nog niet als voltooid kan worden beschouwd.

5. Wat moet er nog gebeuren?

Voordat de server volledig operationeel wordt verklaard, moeten de volgende stappen worden afgerond:

De APT-repositoryconfiguratie onderzoeken en de handtekeningfout oplossen.
Beschikbare Ubuntu- en Plesk-updates veilig installeren.
Controleren of de gebruikte PHP-versies de vereiste beveiligingspatches bevatten.
Controleren of de PHP-FPM-services en webserver correct functioneren.
De Laravel-applicaties en de beheeromgeving van amirs.life testen.
Controleren op aanwijzingen van misbruik als er een concrete verdenking van een inbraak bestaat.
De openbare toegang pas herstellen wanneer de relevante controles succesvol zijn afgerond.

Conclusie

Dit incident onderstreept dat serverbeveiliging uit meerdere lagen bestaat. Een veilige server vereist niet alleen actuele software, maar ook betrouwbare pakketbronnen, correcte tijdsynchronisatie en controle over de runtimes die daadwerkelijk door websites worden gebruikt.

Ik heb de omgeving onderzocht, de tijdsynchronisatie hersteld en de Plesk-sleutel gecontroleerd. De resterende repositoryfout moet nog worden opgelost voordat ik kan bevestigen dat alle PHP-installaties gepatcht zijn.

Voor amirs.life blijft het uitgangspunt hetzelfde: eerst de beveiliging en integriteit van de infrastructuur controleren, daarna pas de publieke dienstverlening volledig herstellen.