Kort gezegd: Wie zijn server voor PHP wil hardenen, zorgt ervoor dat één enkel lek niet de hele server openzet. Wij scheiden websites van elkaar, stellen PHP en webserver veilig in, beperken rechten en toegangen en documenteren elke wijziging. Zo blijft de schade kleiner als er toch iets gebeurt.
Waarom hardening sinds PHP2Shell belangrijker is geworden
PHP2Shell heeft laten zien hoe snel een lek in PHP zelf een probleem wordt voor alle websites op een server. Met CVE-2026-109618 en CVE-2026-109619 kunnen aanvallers zonder inloggen code uitvoeren. De patch sluit die deur. Hardening beantwoordt een andere vraag: wat kan iemand doen die er toch in slaagt binnen te komen, via dit of het volgende lek?
Op een niet-gehardende server draaien vaak alle websites onder dezelfde gebruiker, mag PHP systeemopdrachten uitvoeren en liggen toegangsgegevens leesbaar voor alle processen. Een inbraak op een kleine nevensite reikt dan tot aan de webshop. Een goede hardening scheidt die gebieden. Ze is geen eenmalige actie, maar een basistoestand die bij elke nieuwe website en elke versiewissel behouden moet blijven.
Server hardenen voor PHP: wat wij concreet aanpassen
Isolatie per website
Elke website krijgt een eigen systeemgebruiker en een eigen PHP-FPM-pool. Met open_basedir en passende bestandsrechten ziet een toepassing alleen haar eigen map. Meer daarover onder open_basedir en isolatie per website.
Veilige PHP-configuratie
Wij stellen de php.ini en de poolconfiguratie zo in dat toepassingen beveiligingsrelevante waarden niet zelf kunnen overschrijven. Een fragment, zoals het in een FPM-pool eruit kan zien:
; Waarden vast voorschrijven in de FPM-pool, niet wijzigbaar via ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Welke functies u aanvullend kunt blokkeren, hangt af van de toepassing. Aanwijzingen daarover staan onder php.ini veilig configureren en disable_functions juist inzetten.
Bestandsrechten en schrijftoegang
De webserver mag alleen schrijven waar dat nodig is, bijvoorbeeld in de uploadmap. In uploadmappen wordt het uitvoeren van PHP verhinderd. Programmacode is eigendom van een andere gebruiker dan die waaronder PHP draait. De uitgangspunten legt Bestandsrechten op de webserver uit.
Toegangen, diensten en logs
SSH alleen met sleutel, beheerinterfaces met tweefactorauthenticatie, niet-benodigde diensten en poorten gesloten. Logs worden zo bewaard en beveiligd dat ze na een incident nog beschikbaar zijn. Back-ups controleren wij op herstelbaarheid.
Webserver en beveiligingsheaders
Ook de webserver zelf hoort bij de hardening: versie-informatie verbergen, mapoverzichten uitschakelen, toegang tot configuratie-, back-up- en versiebeheerbestanden blokkeren en beheergedeelten extra beveiligen, bijvoorbeeld met een IP-vrijgave. Beveiligingsheaders zoals Content-Security-Policy of HSTS beschermen de bezoekers van uw website in de browser.
Wat we bij de inventarisatie vaak aantreffen
Veel zwakke plekken herhalen zich van server tot server. Typisch zijn meerdere websites onder een gemeenschappelijke gebruiker, openbaar bereikbare database-interfaces, oude testinstallaties in submappen, vergeten PHP-versies naast de actuele en back-ups die in de webmap staan en te downloaden zijn. Vaak ontbreekt bovendien elke registratie van aanmeldingen, of worden logs na enkele dagen gewist.
Geen van deze punten is op zich spectaculair. Samen bepalen ze echter of een inbraak beperkt blijft tot één website of de hele server treft.
Hoe helpt PHP SOS concreet?
- Inventarisatie: wij leggen besturingssysteem, webserver, PHP-versies, websites, gebruikers, open diensten en bestaande back-ups vast.
- Maatregelenplan: u ontvangt een geprioriteerde lijst met inspanning en mogelijke gevolgen per punt. U beslist wat wordt uitgevoerd.
- Uitvoering in stappen: wij wijzigen configuraties in overleg, testen de websites na elke stap en leggen vast hoe elke wijziging kan worden teruggedraaid.
- Controle: na de uitvoering controleren we het effect, bijvoorbeeld of een website werkelijk geen vreemde mappen meer kan lezen.
- Overdracht: u ontvangt een documentatie van de nieuwe stand, die ook uw hoster of bureau kan volgen.
Wat u krijgt en wat wij nodig hebben
U krijgt een hardeningrapport met uitgangssituatie, uitgevoerde maatregelen, bewust opengelaten punten inclusief motivering en een aanbeveling voor de regelmatige controle. Wijzigingen in configuratiebestanden zijn navolgbaar gedocumenteerd.
Van u hebben wij nodig:
- root- of beheerderstoegang tot de server, bij panelen aanvullend de paneeltoegang
- een lijst van de toepassingen en hun bijzonderheden, bijvoorbeeld uploads, koppelingen, cronjobs
- een technisch aanspreekpunt dat functies na wijzigingen kan bevestigen
- onderhoudsvensters voor herstarts
- een actuele back-up of de opdracht er vooraf een te maken
Wat we niet beloven
Hardening maakt een server niet onaantastbaar. Ze verkleint het aanvalsoppervlak en beperkt schade, maar vervangt noch updates noch bewaking. Een niet-gepatchte PHP-versie blijft kwetsbaar, hoe goed de rest ook is ingesteld. Daarom combineren we de hardening met de PHP-patchservice en adviseren we daarna doorlopende begeleiding via een beveiligingsonderhoudscontract.
Bij shared hosting is veel niet instelbaar, omdat de hoster de configuratie voorschrijft. Dan laten we zien wat binnen uw pakket mogelijk is en waar een overstap naar een eigen of beheerde server zinvol zou zijn.
Veelgestelde vragen
Wat betekent het om een server te hardenen?
Hardenen betekent alles uitschakelen of beperken wat voor de bedrijfsvoering niet nodig is. Daartoe horen overbodige diensten, te ruime rechten, open poorten en onveilige standaardinstellingen. Het doel is dat één enkele fout niet meteen de hele server openzet.
Had hardening PHP2Shell kunnen voorkomen?
Nee, tegen een lek in PHP zelf helpt alleen de patch. Hardening beperkt wel wat een aanvaller na een geslaagde inbraak kan bereiken, bijvoorbeeld of hij bij andere websites of toegangsgegevens kan komen.
Gaat mijn website kapot door de hardening?
Dat risico bestaat als instellingen zonder test worden gewijzigd. Wij voeren wijzigingen stapsgewijs door, controleren na elke stap de functies en leggen vast hoe elke wijziging kan worden teruggedraaid.
Hoe vaak moet de hardening worden gecontroleerd?
Uiterlijk na grotere updates, een wissel van PHP-versie of nieuwe toepassingen op de server. Zinvol is een regelmatige controle in het kader van het lopende onderhoud.