Blog: PHP2Shell, serverbeveiliging en noodhulp
Duiding van de situatie, handleidingen voor beheerders en beslissingshulp voor de directie. Gesorteerd per thema, elk artikel met bronnen.
Situatie en duiding
17 artikelen
PHP2Shell: wat bewezen is en wat niet
Een factcheck over PHP2Shell: welke uitspraken uit primaire bronnen komen, welke uit mediaberichten en welke beweringen geen stand houden.
Lees verder →002Waarom het PHP-lek vóór de patch bekend werd
Volgens berichten werden details over PHP2Shell openbaar vóór het einde van het embargo. Wij leggen het verloop uit en wat dit betekent voor uw patchplanning.
Lees verder →003Overheden halen websites van het net: wat bedrijven ervan leren
Mainz, de deelstaatregering van Hessen en het BKA haalden websites preventief van het net. Wat bedrijven hieruit voor hun eigen beslissing kunnen leren.
Lees verder →004BSI-waarschuwingsniveau Oranje: wat de indeling betekent
Het BSI deelt PHP2Shell in op 3 / Oranje. Wat de schaal wel en niet zegt, en hoe bedrijven de indeling vertalen naar beslissingen.
Lees verder →005Wat CERT-EU en CERT-Bund over PHP2Shell adviseren
De officiële instanties zijn het eens: direct patchen, anders isoleren. Wij vergelijken de adviezen en laten zien hoe isoleren er in de praktijk uitziet.
Lees verder →006Cloudflare-beschermingsregels tegen PHP2Shell: wat ze doen en wat niet
Cloudflare heeft vroeg beschermingsregels tegen PHP2Shell uitgerold. Waarom dat helpt, waarom het de PHP-update toch niet vervangt en welke instellingen u moet controleren.
Lees verder →00722,6 miljoen blootgestelde instanties: cijfers juist inschatten
Unit 42, CybelAngel en anderen noemen zeer uiteenlopende cijfers over PHP2Shell. Wij leggen uit wat er is geteld en welk cijfer voor u echt telt.
Lees verder →008PHP2Shell in vijf minuten: briefing voor de directie
Het PHP-beveiligingslek PHP2Shell op één pagina voor besluitvormers: situatie, risico, vijf vragen aan de IT en de beslissingen voor vandaag.
Lees verder →009Het PHP-beveiligingslek eenvoudig uitgelegd
PHP2Shell voor niet-technici: met alledaagse beelden, een klein woordenlijstje en drie typische uitgangssituaties, wat u als website-beheerder moet doen.
Lees verder →010PHP2Shell: 15 vragen van hostingklanten
Staat uw website bij een hostingprovider en wilt u weten wat u bij PHP2Shell zelf moet doen? Hier de 15 meest gestelde vragen met korte antwoorden.
Lees verder →011Waarom een WordPress-update niet helpt tegen PHP2Shell
Veel beheerders hebben na de krantenkoppen WordPress bijgewerkt en voelen zich veilig. Waarom dat bij PHP2Shell niets uithaalt en wat er in plaats daarvan telt.
Lees verder →012PHP2Shell en Log4Shell: wat de lekken gemeen hebben
Velen vergelijken PHP2Shell met Log4Shell uit 2021. Wat de vergelijking waard is, waar ze mank gaat en welke lessen van toen vandaag helpen.
Lees verder →013Massascans naar ongepatcht PHP: zo verlopen geautomatiseerde aanvallen
Na PHP2Shell doorzoeken aanvallers het internet geautomatiseerd naar kwetsbare servers. Hoe dat verloopt, waarom omvang geen rol speelt en wat u beschermt.
Lees verder →014Het tijdvenster tussen patch en aanval
Bij PHP2Shell waren er aanvalspogingen al vóór de patch. Wij leggen de fasen van het tijdvenster uit, hoe u uw eigen venster meet en hoe u het verkort.
Lees verder →015Na PHP2Shell: waarom meer meldingen waarschijnlijk zijn
PHP2Shell is met de patch van 21 oktober niet afgesloten. Waarom vervolgmeldingen te verwachten zijn en hoe u uw team erop instelt.
Lees verder →016PHP2Shell: het situatiebeeld van de eerste week
Een week na de eerste waargenomen aanvalspoging: de stand van patches, overheidswaarschuwingen, aanvallen en uitschakelingen, netjes naar bronnen gescheiden.
Lees verder →017Gevaarlijke valse tips over PHP2Shell die nu rondgaan
Cookies blokkeren, foutmeldingen verbergen, alleen het CMS bijwerken: negen adviezen over PHP2Shell die schijnveiligheid geven, en wat echt telt.
Lees verder →Hosting en distributies
18 artikelen
PHP-versie wijzigen in het klantenmenu van de hosting
Hoe u in het klantenmenu van uw hostingprovider de PHP-versie omzet, welke versie u kiest en wat u vooraf en achteraf controleert.
Lees verder →019Debian en Ubuntu: is mijn PHP-pakket gepatcht?
Welke PHP-pakketten Debian en Ubuntu tegen PHP2Shell hebben gecorrigeerd, hoe u de geïnstalleerde stand exact vergelijkt en waaraan het bewijs strandt.
Lees verder →020RHEL, AlmaLinux en Rocky Linux: PHP-patch controleren
Wat Red Hat over PHP2Shell heeft gepubliceerd, hoe u op RHEL en de nabouwen de pakketstand aantoont en waarom een reload niet volstaat.
Lees verder →021De sury.org-repository: PHP-pakketten uit een externe bron
Veel Debian- en Ubuntu-servers betrekken PHP uit de sury-repository. Wat dat na PHP2Shell betekent voor updates, bewijs en oude PHP-versies.
Lees verder →022De Remi-repository: PHP op RHEL-systemen actueel houden
Remi levert actuele PHP-versies voor de RHEL-familie, als module of parallel te installeren. Zo controleert u de stand na PHP2Shell en voorkomt u vergeten takken.
Lees verder →023Waarom php -v na de update hetzelfde nummer toont
De update is gelopen, maar php -v meldt de oude versie. Meestal is dat een backport en geen fout. Zo onderscheidt u onschuldige van echte problemen.
Lees verder →024CVE-nummers aantonen in de pakket-changelog
Wie een PHP-patch moet aantonen aan directie, auditors of verzekeraars, heeft meer nodig dan een versienummer. Zo wordt de changelog-vermelding een bewijs.
Lees verder →025Hoster wisselen na een beveiligingsincident: waar op letten?
Na een incident is de wens naar een nieuwe hoster begrijpelijk. Opdat de aanvaller niet meeverhuist, komt het aan op volgorde en keuze.
Lees verder →026Meerdere PHP-versies op één server: patch elke versie afzonderlijk
Op veel servers draaien drie, vier of meer PHP-installaties naast elkaar. Na PHP2Shell moet elke installatie worden gevonden, bijgewerkt en herstart.
Lees verder →027Oude PHP-versies in het hostingpaneel uitschakelen
PHP2Shell is een goede aanleiding om oude PHP-versies kwijt te raken. Zo gaat u in drie fasen te werk, zodat geen website en geen cronjob ongemerkt uitvalt.
Lees verder →028Plesk: PHP-handlers begrijpen (FPM, FastCGI, Apache-module)
Welke PHP-handler Plesk voor een website gebruikt, bepaalt isolatie, configuratie en risico. Een vergelijking met het oog op PHP2Shell.
Lees verder →029CloudLinux en alt-php: wat hostingklanten moeten weten
Op CloudLinux-servers draaien websites vaak met eigen alt-php-pakketten. Elke versie heeft haar eigen patch nodig, en alleen de serverbeheerder kan die inspelen.
Lees verder →030PHP op NAS, firewalls en appliances: de vergeten systemen
Niet alleen webservers gebruiken PHP. Ook NAS-systemen, firewalls en vakapparatuur met een webinterface kunnen getroffen zijn. Patchen kan daar meestal alleen de fabrikant, de bereikbaarheid regelt u zelf.
Lees verder →031PHP bij cloud- en PaaS-aanbieders: wie patcht de runtime?
Op platformdiensten hangt de PHP-patch af van het bedrijfsmodel. Beslissend is de runtime die werkelijk levert, niet de lokale omgeving of de applicatiecode.
Lees verder →032Officiële PHP Docker-images: tags, digests en herbouw
Een tag van de officiële PHP-image is een verwijzing die na verloop van tijd naar nieuwe standen schuift. Wie weet wat tag, variant en digest betekenen, kiest de juiste image en kan de patchstand aantonen.
Lees verder →033CI/CD: PHP-images automatisch opnieuw bouwen
Een image veroudert ook zonder codewijziging. Met tijdgestuurde builds, een versiecontrole en uitrol via digest komen PHP-patches betrouwbaar in productie.
Lees verder →034Langetermijnondersteuning voor oude PHP-versies: opties en grenzen
Wie niet meteen kan overstappen van PHP 8.1 of ouder, vindt langetermijnondersteuning bij distributies, externe aanbieders en commerciële diensten. Wat die wegen bieden, wat u schriftelijk nodig hebt en waar de grenzen liggen.
Lees verder →035PHP onder Windows bijwerken
Onder Windows bestaat geen automatische PHP-update. Wie de juiste variant kiest, de download controleert en alle processen herstart, brengt de PHP2Shell-patch netjes op elke computer.
Lees verder →Detectie en forensisch onderzoek
18 artikelen
Waarschuwingssignaal: de webserver start een shell
Start een PHP-FPM- of webserverproces een shell, dan is dat een van de sterkste waarschuwingssignalen voor een inbraak. Zo controleert u de procesboom, plaatst u uitzonderingen en bewaakt u het patroon blijvend.
Lees verder →037Verdachte processen op Linux-servers vinden
Schadelijke processen vermommen zich met onschuldige namen, draaien vanuit tijdelijke mappen of vanuit verwijderde bestanden. Met enkele lezende opdrachten vindt u afwijkingen en plaatst u ze.
Lees verder →038Verborgen cronjobs als achterdeur herkennen
Aanvallers gebruiken geplande taken om na een opschoning terug te keren. Zo controleert u crontabs, cron-mappen, systemd-timers en at-opdrachten volledig en herkent u verdachte vermeldingen.
Lees verder →039Onlangs gewijzigde bestanden op de webserver vinden
Na een mogelijke inbraak telt wat er op de server is veranderd. Zo zoekt u op tijdvensters, gebruikt u mtime en ctime juist en vergelijkt u met pakketten, Git en back-ups.
Lees verder →040PHP-bestanden in de uploadmap: vindplaatsen juist duiden
Een PHP-bestand in de uploadmap is bijna altijd een alarmteken, maar niet elk is schadelijke code. Zo beoordeelt u de vondst zonder sporen te vernietigen en stelt u vast of iemand het heeft aangeroepen.
Lees verder →041Versluierde PHP-code herkennen
Onleesbare PHP-code met eval en base64_decode is een klassiek teken van ingebrachte schadelijke code. Welke patronen u zoekt, hoe u ze ongevaarlijk vindt en wanneer versluiering legitiem is.
Lees verder →042Uitgaande verbindingen van een server controleren
Een webserver antwoordt vooral op verzoeken. Bouwt hij zelf verbindingen naar onbekende doelen op, dan kan dat aansturing door aanvallers of gegevensuitstroom betekenen. Zo controleert en beperkt u uitgaand verkeer.
Lees verder →043Vreemde beheerdersaccounts in CMS en server vinden
Een onbekende beheerder is vaak de eenvoudigste achterdeur. Zo zoekt u laag voor laag naar vreemde accounts, ook naar accounts die de interface verbergt.
Lees verder →044Onbekende SSH-sleutels vinden en verwijderen
Een ingebrachte SSH-sleutel opent aanvallers de deur, ook als alle wachtwoorden zijn gewijzigd. Zo vindt u elk authorized_keys-bestand en controleert u elke vermelding.
Lees verder →045Cryptominer op de webserver: tekenen en aanpak
Permanent volle CPU zonder dat er meer bezoekers komen: dat kan een cryptominer zijn. Zo controleert u de belasting, vindt u het proces en zijn herstartmechanismen en gaat u ordelijk te werk.
Lees verder →046De server verstuurt spam: oorzaken vinden
Onbezorgbare mails, blokkadelijsten, klachten: als de eigen server spam verstuurt, zit er meestal een script of een gekaapt postvak achter. Zo vindt u de bron.
Lees verder →047SEO-spam en vreemde pagina's in de Google-index
Opeens ranken pagina's over medicijnen of merkproducten onder uw domein. Zo vindt u uit waar de SEO-spam vandaan komt en krijgt u hem weer uit de index.
Lees verder →048De website stuurt door naar vreemde sites
Bezoekers belanden op prijsvragen of dubieuze webwinkels, maar u ziet zelf niets? Zo vindt u de laag waarin de doorverwijzing zit en verhelpt u haar.
Lees verder →049Bewijs veiligstellen voordat u de server opnieuw opzet
Een herinstallatie verwijdert de aanvaller, maar ook alle sporen. Wie vooraf een uur in het veiligstellen van bewijs steekt, kan later zeggen wat er is gebeurd.
Lees verder →050De tijdlijn van een incident opstellen
Wanneer kwam de aanvaller, wat deed hij, wanneer werd het opgemerkt? Een zuivere tijdlijn beantwoordt die vragen en is de basis voor meldingen, verzekering en rapport.
Lees verder →051CMS-kernbestanden vergelijken met het origineel
De vergelijking met een schoon origineel toont elk gewijzigd bestand, ongeacht of een scanner het kent. Zo bouwt u de controle op voor WordPress, Composer-projecten en systeempakketten.
Lees verder →052De database controleren op ingebrachte code
Wie alleen bestanden controleert, mist de helft. Zo doorzoekt u inhoud, instellingen, triggers en accounts van de database op ingebrachte code, alleen-lezen en op een kopie.
Lees verder →053Malwarescanners voor websites: wat ze wel en niet vinden
De scanner meldt niets, dus alles goed? Niet per se. Welke soorten websitescanners er zijn, wat elke scanner ziet en wat ze principieel niet kan zien.
Lees verder →Hardening en configuratie
20 artikelen
PHP-FPM-pools per website isoleren
Een eigen pool per website is het begin, niet het einde. Zo controleert u bestaande pools en verhardt u sockets, extensies, statuspagina's, resources en logs.
Lees verder →055memory_limit juist instellen
memory_limit begrenst het geheugen per PHP-verzoek. Na PHP2Shell adviseert php.net tijdelijk het tegenovergestelde. Wat geldt in normaal bedrijf, in de overgang en na de update.
Lees verder →056post_max_size en upload_max_filesize zinvol beperken
Uploadgrenzen werken op drie plaatsen: in de webserver, in PHP en in de applicatie. Zo stelt u de waarden op elkaar af, ook met de overbruggingswaarden van php.net bij PHP2Shell.
Lees verder →057session.upload_progress uitschakelen: juist en blijvend
De remedie tegen CVE-2026-115560 en een van de PHP2Shell-overbruggingsmaatregelen is snel ingesteld. Om te blijven werken moet ze op de juiste plek staan, vergrendeld zijn en na elke update opnieuw worden gecontroleerd.
Lees verder →058expose_php en Server-header: versiegegevens verbergen
PHP, Nginx en Apache noemen standaard hun versienummer in elk antwoord. Dat beschermt niet tegen aanvallen, maar geeft scanners een handige lijst met doelwitten. Zo schakelt u het uit en houdt u toch het overzicht.
Lees verder →059display_errors off: foutuitvoer in productie uitschakelen
Zichtbare PHP-foutmeldingen verraden paden, databasenamen en versies. Zo schakelt u ze uit in PHP, in het framework en in de webserver, zonder de fouten uit het oog te verliezen.
Lees verder →060php_admin_value: instellingen tegen overschrijven vergrendelen
Een beveiligingsinstelling helpt weinig als de applicatie haar met één regel code weer wijzigt. Met php_admin_value en php_admin_flag legt u waarden voor PHP-FPM en Apache bindend vast.
Lees verder →061Geheugengrenzen instellen met systemd en cgroups
php.net adviseert als PHP2Shell-overbruggingsmaatregel memory_limit=-1 en een geheugengrens buiten PHP. Zo stelt u die grens in met systemd en cgroups, zonder dat één worker de hele service meesleept.
Lees verder →062Nginx veilig configureren voor PHP
De meeste zwakke plekken in Nginx-opstellingen voor PHP zitten niet in Nginx, maar in enkele regels van de PHP-location. Zo configureert u de overdracht aan PHP-FPM zodat alleen gewenste scripts worden uitgevoerd.
Lees verder →063Apache veilig configureren voor PHP
Apache is flexibel en precies dat maakt hem gevoelig voor verkeerde configuratie. Zo koppelt u PHP via PHP-FPM, sluit u .htaccess als achterdeur en stelt u de belangrijkste kernopties veilig in.
Lees verder →064PHP-uitvoering in uploadmappen verbieden
Een webshell heeft twee dingen nodig: een map waarin ze kan worden geschreven en een server die haar uitvoert. Zo ontneemt u haar het tweede, en wel in elke beschrijfbare map, niet alleen in uploads.
Lees verder →065Uploadverzoeken aan de rand filteren: kansen en risico's
Vakauteurs stellen voor uploadverzoeken buiten echte uploadpaden bij de proxy te blokkeren tot PHP is gepatcht. Dat kan helpen, maar ook formulieren en bestellingen lamleggen. Zo gaat u gecontroleerd te werk.
Lees verder →066ModSecurity en het OWASP Core Rule Set inzetten
Een eigen Web Application Firewall met ModSecurity en het OWASP Core Rule Set is gratis en krachtig, maar geen vanzelfsprekendheid. Zo kiest u de engine, start u zonder uitval en stemt u de regels af.
Lees verder →067Fail2ban voor webservers instellen
Fail2ban blokkeert adressen die in de logs herhaaldelijk opvallen. Voor webservers heeft het kant-en-klare filters en met enkele regels voegt u eigen toe. Zo stelt u het in zonder uzelf of uw klanten buiten te sluiten.
Lees verder →068Firewall voor webservers: alleen noodzakelijke poorten openen
Een webserver heeft naar buiten meestal maar twee poorten nodig. Toch luisteren op veel servers databases, PHP-FPM of beheeromgevingen op internet. Zo vindt u open diensten en sluit u wat niet nodig is.
Lees verder →069Automatische beveiligingsupdates op Linux-servers
Volgens berichten leverden distributies PHP-backports deels nog op 21 oktober 2026 uit, de dag van de patches. Wie automatische beveiligingsupdates gebruikte, had ze snel op de server. Om ook te werken zijn herstarts, externe bronnen en controle nodig.
Lees verder →070Least privilege: de rechten van de webservergebruiker
Binnengesmokkelde code draait met de rechten van de webservergebruiker. Wat dit account mag, bepaalt hoe ver een aanvaller komt. Zo beperkt u shell, sudo, cron, database en bestandssysteem tot het noodzakelijke.
Lees verder →071Beheeromgevingen afschermen met IP-whitelist, VPN of extra beveiliging
Waarom de backend van een website niet voor de hele wereld bereikbaar hoeft te zijn en hoe u hem afschermt met een IP-whitelist, VPN of voorgeschakelde aanmelding zonder uzelf buiten te sluiten.
Lees verder →072TLS en HTTPS correct configureren
Welke TLS-versies en cipher suites een webserver tegenwoordig hoort aan te bieden, waarop de aanbevelingen zijn gebaseerd en hoe u Nginx, Apache en uitgaande PHP-verbindingen controleert.
Lees verder →073CIS-benchmarks en BSI-bouwstenen voor webservers
Welke hardeningstandaarden er zijn voor Linux-webservers, hoe CIS-benchmarks en IT-Grundschutz-bouwstenen verschillen en hoe u daarvan een controleerbare richtlijn voor uw PHP-servers maakt.
Lees verder →Veilig ontwikkelen
16 artikelen
Wachtwoorden in PHP veilig opslaan: password_hash correct gebruiken
Hoe ontwikkelaars wachtwoorden in PHP opslaan met password_hash en password_verify, de passende methode kiezen en oude MD5- of SHA-1-hashes vervangen zonder wachtwoordreset voor alle gebruikers.
Lees verder →075CSRF-bescherming in PHP-applicaties
Hoe ontwikkelaars cross-site request forgery in PHP-applicaties voorkomen: tokens voor elk wijzigend verzoek, herkomstcontrole in de header en SameSite-cookies als extra laag.
Lees verder →076Invoer in PHP valideren en filteren met filter_var
Hoe ontwikkelaars invoer in PHP controleren met filter_var, filter_input_array en toegestane waardenlijsten, welke filters verouderd zijn en waarom validatie prepared statements en uitvoercodering niet vervangt.
Lees verder →077Command injection in PHP voorkomen
Hoe ontwikkelaars command injection in PHP vermijden: systeemopdrachten vervangen door PHP-functies, proc_open zonder shell gebruiken, argumenten controleren en gevaarlijke plekken in bestaande code vinden.
Lees verder →078Server-side request forgery (SSRF) in PHP voorkomen
Hoe ontwikkelaars voorkomen dat een PHP-applicatie in opdracht van vreemden interne systemen bevraagt: lijsten met toegestane doelen, protocolbeperking, controle van het omgezette adres en grenzen in het netwerk.
Lees verder →079XML external entities (XXE) in PHP voorkomen
Hoe ontwikkelaars XML in PHP veilig verwerken: standaardgedrag van libxml, riskante opties zoals LIBXML_NOENT, bescherming met entity-loader en LIBXML_NO_XXE en typische verborgen XML-invoerpunten.
Lees verder →080Type juggling in PHP: losse vergelijkingen als beveiligingsrisico
Waarom losse vergelijkingen met == in PHP tot beveiligingslekken kunnen leiden, wat er met PHP 8.0 is veranderd en hoe u vergelijkingen in logins, tokens en machtigingen robuust schrijft.
Lees verder →081Veilige willekeurige getallen en tokens in PHP met random_bytes
Hoe ontwikkelaars in PHP tokens voor wachtwoordlinks, API-sleutels en eenmalige codes genereren: cryptografisch veilige bronnen, voldoende lengte, opslag als hash en beperkte geldigheid.
Lees verder →082Toegangsgegevens en .env-bestanden correct beveiligen
Hoe u databasewachtwoorden, API-sleutels en andere geheimen in PHP-projecten beveiligt: .env-bestanden buiten de webroot, blokkades in de webserver, strikte rechten en ordelijke vervanging na een incident.
Lees verder →083Openbare .git-map: een onderschat datalek
Waarom een via Git uitgerolde webroot de volledige broncode inclusief geschiedenis kan prijsgeven, hoe u dat controleert, meteen blokkeert en de deployment blijvend zonder .git-map opbouwt.
Lees verder →084Back-upbestanden in de webroot: .zip, .sql en .bak
Waarom database-dumps, archieven en reservekopieën in de openbare map tot de meest voorkomende datalekken behoren, hoe u ze vindt, blokkeert en uitzoekt of ze zijn opgehaald.
Lees verder →085phpinfo()-bestanden: waarom ze moeten verdwijnen
Na PHP2Shell maken veel beheerders snel een info.php aan. Waarom zulke bestanden een datalek zijn, hoe u ze vindt en welke controlewegen beter zijn.
Lees verder →086Afhankelijkheden actueel houden: Composer, npm en plug-ins
Een project bestaat uit drie pakketwerelden: Composer, npm en CMS-plug-ins. Hoe u ze alle drie actueel houdt met een vast ritme, duidelijke verantwoordelijkheid en tests.
Lees verder →087Beveiligings-code-review voor PHP-projecten
Hoe teams de eigen PHP-code gericht doorlichten op beveiligingslekken: soorten reviews, kritieke functies, zinvolle hulpmiddelen en een checklist.
Lees verder →088Veilig loggen: fouten registreren zonder datalek
Logboeken helpen bij foutopsporing en forensisch onderzoek, maar worden snel zelf een datalek. Wat PHP-applicaties moeten loggen, wat nooit en hoe u logboeken beschermt.
Lees verder →089REST-API's in PHP beveiligen
Interfaces zijn vaak slechter beschermd dan de website ervoor. De belangrijkste regels voor REST-API's in PHP, van objectmachtiging tot snelheidsbeperking.
Lees verder →Management en recht
14 artikelen
Contracten met IT-dienstverleners: beveiligingsplichten helder regelen
PHP2Shell heeft laten zien hoe vaak onduidelijk is wie moet patchen. Welke beveiligingsplichten in contracten met bureau, hostingprovider en IT-dienstverlener horen.
Lees verder →091Verwerking in opdracht wanneer dienstverleners bij servers kunnen
Wie externen toegang geeft tot servers met klantgegevens, heeft meestal een verwerkersovereenkomst nodig. Wat art. 28 AVG eist en hoe u toegang in noodgevallen privacyconform organiseert.
Lees verder →092Kwetsbaarhedenbeheer voor het mkb
Geen enkel mkb-bedrijf kan elke melding meteen afhandelen. Een slank circuit van registreren, beoordelen, beslissen en aantonen zorgt dat het belangrijkste als eerste gebeurt.
Lees verder →093Weten wat er draait: inventaris van alle websites en servers
Bij PHP2Shell struikelden veel bedrijven niet over de patch, maar over de vraag waar PHP eigenlijk draait. Zo bouwt u een inventaris van alle websites en servers op.
Lees verder →094Patchbeheer als proces in plaats van brandweer
Wie alleen patcht als het brandt, verliest in een noodgeval tijd. Hoe een patchbeheerproces met vaste klassen, vensters en bewijsstukken routine en noodgeval verbindt.
Lees verder →095Noodcontacten: wie moet wanneer worden geïnformeerd?
In een noodgeval telt wie u bereikt en wanneer. Hoe u een lijst van IT-noodcontacten opbouwt, met aanleidingen, vervangers en de gegevens die elk telefoontje nodig heeft.
Lees verder →096Wat een gehackte server kost: de kostenposten
Een gehackte webserver veroorzaakt meer kosten dan alleen het herstel. Welke kostenposten er zijn en hoe u met eigen cijfers een budget voor preventie onderbouwt.
Lees verder →097Klanten informeren na een incident
Verplicht of vrijwillig: hoe u na een incident beslist wie u informeert, welke kanalen veilig zijn en hoe uw klantenservice is voorbereid.
Lees verder →098De toeleveringsketen op het web: bureau, hoster, plug-inaanbieder
PHP2Shell liet zien hoeveel schakels er tussen een patch en uw website liggen. Hoe u de keten van uw website kent, beveiligt en uitval van afzonderlijke schakels opvangt.
Lees verder →099Veiligheidsbewustzijn voor beheerders en redacteuren: security awareness in het webteam
Wie websites onderhoudt, beslist dagelijks over beveiliging, vaak zonder het te merken. Zo traint u beheerders en redacteuren op maat van hun rol en zonder sheetsslag.
Lees verder →100Noodoefening aan tafel: een webserverincident doorspelen
Een oefening aan tafel kost een middag en laat zien of uw noodplan standhoudt. Hier vindt u een kant-en-klaar draaiboek voor een incident op een PHP-webserver.
Lees verder →101ISO 27001 en TISAX: wat webservers raakt
Wie een ISMS volgens ISO 27001 beheert of een TISAX-label heeft, moet webservers meenemen. Hier staat welke eisen ze raken en welk bewijs na PHP2Shell telt.
Lees verder →102VdS 10000: informatiebeveiliging voor kleine en middelgrote bedrijven
De VdS 10000 is een slank kader voor informatiebeveiliging in het mkb. Wat ze vraagt, wat in 2025 nieuw kwam en wat dat voor websites en webservers betekent.
Lees verder →103Lessons learned: beter worden na het incident
Na het incident is voor het volgende. Een gestructureerde nabespreking zonder schuldvraag maakt van een slechte week meetbare vooruitgang.
Lees verder →Beslissingshulp
10 artikelen
Patchen, uitschakelen of afwachten? Een beslishulp bij het PHP-lek
Bij een kritiek PHP-lek moeten verantwoordelijken snel beslissen. Deze hulp ordent de drie opties, noemt criteria en laat zien wanneer afwachten verdedigbaar is.
Lees verder →105WAF of update: waarom u beide nodig hebt
Een Web Application Firewall kan aanvallen onderscheppen, maar dicht geen lek in de PHP-interpreter. Wanneer een WAF helpt, waar ze ophoudt en hoe u beide zinvol combineert.
Lees verder →106Server opnieuw opzetten of opschonen? De beslissing na een besmetting
Na een inbraak staan twee wegen open: de server opschonen of opnieuw opbouwen. Welke criteria beslissen, en waarom de volgorde belangrijker is dan de keuze.
Lees verder →107Zelf oplossen of een dienstverlener inschakelen? Een eerlijke afweging
Niet elke beveiligingssituatie vraagt externe hulp. Met deze criteria en een korte zelftest beslist u of uw team PHP2Shell alleen aankan of ondersteuning nodig heeft.
Lees verder →108Een IT-beveiligingsdienstverlener kiezen: 12 vragen vóór de opdracht
Onder tijdsdruk een goede beveiligingsdienstverlener vinden is lastig. Deze twaalf vragen helpen offertes zakelijk te vergelijken zonder in reclamebeloften te trappen.
Lees verder →109Managed hosting of eigen server? De beveiligingsvergelijking
PHP2Shell was een stresstest voor elk bedrijfsmodel. De vergelijking laat zien wanneer managed hosting veiliger is, wanneer de eigen server, en welke mengvormen zich bewijzen.
Lees verder →110PHP-upgrade of backport? De keuze voor oude systemen
Voor oude PHP-versies zijn er na PHP2Shell meerdere wegen: distributiebackport, externe bron, broncodepatch, langetermijnondersteuning of upgrade. Wat elke weg waard is en hoe lang hij draagt.
Lees verder →111Na de hack het CMS wisselen? Wanneer het helpt en wanneer niet
Na een inbraak is het vertrouwen in het CMS vaak weg. Toch lost een nieuw systeem zelden de eigenlijke oorzaak op. Wanneer de wissel zinvol is en hoe hij netjes lukt.
Lees verder →112Statische websites: minder PHP, minder aanvalsoppervlak
Een statische website levert kant-en-klare HTML-bestanden uit en heeft geen PHP op de server nodig. Dat verkleint het aanvalsoppervlak aanzienlijk, maar brengt eigen grenzen en plichten mee.
Lees verder →113Pentest, bug bounty of kwetsbaarhedenscan? De passende toetsmethode kiezen
Scan, penetratietest en bug bounty toetsen websites op totaal verschillende wijze. Wat elke methode levert, waar ze tekortschiet en welke volgorde bij uw bedrijf past.
Lees verder →Elk uur telt. Schrijf ons nu.
Beschrijf kort het systeem, de PHP-versie en wat u opmerkt. Wij nemen contact op, brengen de situatie in kaart en werken op afstand tot het incident is afgerond en gedocumenteerd.