Cloudflare en PHP-veiligheid: kijk ook achter de proxy

Teken eerst de route van een bezoeker

Begin met een eenvoudige schets. Welke naam typt de bezoeker in? Waar komt het webverzoek binnen? Welke dienst levert de pagina? Waar worden formulieren, logins en andere dynamische functies afgehandeld?

Bij een geproxiede DNS-configuratie zit Cloudflare tussen bezoeker en server. Bij een DNS-only-record wordt het HTTP- of HTTPS-verkeer niet langs die proxy geleid. Dat zijn verschillende situaties, ook wanneer beide domeinnamen in hetzelfde Cloudflare-account staan. Cloudflare-documentatie over proxystatus.

Voor een eerste gesprek kun je drie vakken tekenen: bezoeker, Cloudflare en oorsprongserver. Die laatste wordt vaak de origin genoemd. Voeg daarna pas de echte uitzonderingen toe. Een ingewikkeld schema helpt weinig als niemand weet welke lijn het offerteformulier gebruikt.

De naam van de leverancier zegt niet genoeg

Een bedrijf kan Cloudflare gebruiken voor DNS, bescherming, caching, applicatiehosting of meerdere van die onderdelen. ‘We gebruiken Cloudflare’ beschrijft dus geen volledige technische inrichting.

Vraag liever: welke onderdelen van onze website worden waar uitgevoerd? Een statische pagina en een apart PHP-beheersysteem kunnen bijvoorbeeld een andere route volgen. Een veilige conclusie over de ene omgeving geldt niet automatisch voor de andere.

Dit is ook waarom je niet op basis van een logo of een responseheader moet concluderen dat een website geen PHP gebruikt. Vraag de beheerder om de applicatieomgeving te bevestigen. Als die informatie ontbreekt, noteer je de runtime als onbekend en maak je daar een concrete vervolgactie van.

Bescherming vóór de server is iets anders dan onderhoud erop

Wij behandelen beveiliging hier als een taakverdeling. De buitenste laag beoordeelt verkeer dat haar passeert. De applicatie verwerkt toegestane verzoeken. De host onderhoudt de relevante serveromgeving. De eigenaar bepaalt welke functies nodig zijn en welke tijdelijke beperkingen acceptabel zijn.

Een maatregel in de eerste laag neemt niet vanzelf het werk in een andere laag over. Als een PHP-update nodig is, blijft er een uitvoeringsvraag voor de host of beheerder. Cloudflare kan onderdeel zijn van een tijdelijke of blijvende bescherming, maar is niet hetzelfde als het installeren van die update.

Maak dit onderscheid zichtbaar in het werkoverzicht. Gebruik afzonderlijke regels voor bescherming gecontroleerd, runtime gecontroleerd en applicatiefuncties getest. Eén algemene status ‘veilig’ verbergt juist de verschillen die je nodig hebt om verstandig te beslissen.

Vermijd de verkeerde geruststelling

Een fictieve webwinkel ontvangt een beveiligingsmelding en krijgt als antwoord dat er veel verdachte verzoeken worden geblokkeerd. Dat kan waar zijn. Toch weet de eigenaar daarmee nog niet welke PHP-versie actief is, of alle relevante routes langs de beschermlaag lopen en of de update is uitgevoerd.

De juiste vervolgvraag is niet of het blokkeercijfer hoog genoeg is. De vraag is welk deel van het risico ermee wordt afgedekt en welk deel nog actie vraagt. Zo voorkom je dat een positief dashboard een open onderhoudstaak onzichtbaar maakt.

Wat een WAF wel helpt beoordelen

Een web application firewall, meestal WAF genoemd, is een van de mogelijke beschermlagen. Cloudflare levert beheerde regels voor het herkennen en afhandelen van bepaalde aanvalspatronen. De beschikbare regelsets hangen af van het abonnement, en instellingen of uitzonderingen beïnvloeden wat er gebeurt. Cloudflare Managed Rules.

Voor een beheerder betekent dit dat ‘WAF aanwezig’ een beginpunt is, geen afgeronde controle. Je wilt weten welke regels actief zijn op de bedoelde website en of uitzonderingen een relevante route uitsluiten. Je hoeft dat niet als ondernemer allemaal zelf te configureren, maar je kunt wel om een begrensde bevestiging vragen.

Wij zouden de beheerder laten antwoorden in gewone taal: welke route valt binnen de controle, welke relevante instelling is vastgesteld, welke beperking blijft bestaan en welk vervolg staat gepland? Dat maakt een technisch product begrijpelijk zonder een onhoudbare beschermingstoezegging te doen.

Geen brede uitzondering om één formulier te redden

Soms wordt een legitieme handeling tegengehouden. Bijvoorbeeld een medewerker die een lang tekstveld opslaat of een toegestane upload doet. De verleiding is dan groot om de beveiliging voor een hele omgeving uit te zetten.

Onze praktische voorkeur is eerst het probleem klein maken. Noteer de route, het tijdstip, de handeling en de relevante melding. Laat de beheerder onderzoeken welke specifieke regel betrokken is. Beoordeel daarna de smalste aanpassing die de echte functie herstelt.

Iedere uitzondering krijgt een reden en een eigenaar. Tijdelijke uitzonderingen krijgen ook een herbeoordelingsmoment. Zo blijft zichtbaar waarom iets is toegestaan en voorkom je dat een eenmalige oplossing stilzwijgend permanent beleid wordt.

De origin verdient een eigen toegangsplan

De oorsprongserver is de plek waar de achterliggende applicatie draait. Bescherming van die server vraagt meer dan vaststellen dat de normale domeinnaam via een proxy loopt. Laat de verantwoordelijke beheerder bevestigen welke toegangswegen bedoeld zijn en hoe ongewenste rechtstreekse toegang wordt beperkt.

Cloudflare beschrijft daarvoor verschillende maatregelen, waaronder netwerkbeperking en authenticatie richting de origin. De juiste combinatie hangt af van de hostingarchitectuur en mogelijkheden van de provider. Cloudflare-handleiding voor originbescherming.

Dit is geen oproep om zonder toestemming allerlei adressen of poorten te scannen. Het begint bij documentatie, configuratie en antwoorden van de eigenaar van de infrastructuur. Een gerichte controle hoort pas daarna, met duidelijke grenzen en toestemming van de verantwoordelijke partij.

Vraag wat werkelijk wordt afgedwongen

Er is verschil tussen een gewenste route en een afgedwongen route. Een tekening kan zeggen dat verkeer via Cloudflare loopt. Je wilt daarnaast weten welke configuratie dat ondersteunt en welk bewijs de beheerder daarvoor heeft.

Een bruikbare terugkoppeling noemt de relevante hostnamen, de maatregel en de controledatum. Zij zegt ook wat niet is bekeken. Bijvoorbeeld: de publieke website is beoordeeld, maar een oude testomgeving valt buiten de opdracht. Dat is veel eerlijker dan een conclusie over het volledige domein op basis van één pagina.

Geef zo'n open punt meteen een eigenaar. Oude testomgevingen zijn vaak niet meer belangrijk voor de verkoop, maar kunnen nog wel software en gegevens bevatten. Het ontbreken van bezoekers is geen bewijs dat beheer niet nodig is.

Authenticatie naar de origin is geen enkel vinkje

Authenticated Origin Pulls gebruikt clientcertificaten voor de verbinding van Cloudflare naar de origin. Belangrijk detail: het algemene, door Cloudflare geleverde certificaat identificeert niet uitsluitend jouw account. Cloudflare beschrijft eigen certificaten op zone- of hostnameniveau als mogelijkheid voor strengere afbakening. Uitleg over Authenticated Origin Pulls.

Daarom vermijden we de uitspraak dat het inschakelen van één optie automatisch bewijst dat alleen jouw website de server kan bereiken. Je moet weten welke variant is ingericht, wat de server controleert en hoe dat past bij de rest van de omgeving.

De praktische vraag aan je host is: ‘Welke identiteit wordt hier geaccepteerd en hoe is die beperkt tot onze bedoelde route?’ Laat het antwoord door de beheerder toetsen aan de echte configuratie. Kopieer geen certificaten of privésleutels naar een gedeeld rapport om dat gesprek te voeren.

Een tunnel is een andere inrichting

Cloudflare Tunnel kan via een verbinding die vanuit de eigen omgeving wordt opgezet verkeer naar een applicatie brengen, zonder daarvoor een publiek routeerbaar originadres te vereisen. Dat is een andere architectuur dan een traditionele publiek bereikbare webserver achter een proxy. Cloudflare Tunnel-documentatie.

Een tunnel is niet automatisch de juiste keuze voor iedere website. Beoordeel beheerbaarheid, ondersteuning door de host en de gevolgen als de verbinding wegvalt. Maak er ook geen impulsieve wijziging van midden in een urgente patchronde als de bestaande route goed beheerst kan worden.

Wij zouden eerst de onderhoudstaak afmaken en een grotere netwerkverandering apart ontwerpen, tenzij de verantwoordelijke beheerder vaststelt dat onmiddellijke afscherming noodzakelijk is. Zo blijven aanleiding, wijziging en testresultaat begrijpelijk.

Maak een inventaris van hostnamen en functies

Een domein kan meer omvatten dan de website die klanten dagelijks zien. Denk aan een beheerpaneel, een oude campagnepagina, een API, een testomgeving of een apart klantportaal. Maak daarvan een overzicht met alleen de informatie die voor het beheer nodig is.

Gebruik per onderdeel vijf velden: naam, functie, beheerder, uitvoeromgeving en beoogde toegang. Voeg de datum van bevestiging toe. Niet iedereen hoeft alle technische gegevens te kunnen zien; een samenvatting kan verwijzen naar een beveiligd beheerdocument.

Neem mail en andere diensten niet klakkeloos mee in webinstellingen. Cloudflare onderscheidt expliciet diensten die niet via de gewone HTTP-proxy horen te lopen. Een algemene instructie ‘zet alles op proxied’ is daarom geen zorgvuldig beheeradvies. Wanneer DNS-only nodig is.

Maak onderscheid tussen onbekend en overbodig

Een vergeten subdomein kan nog nodig zijn voor een koppeling. Een onbekend record verwijderen omdat het oud lijkt, kan dus een echte functie onderbreken. Zoek eerst de eigenaar en de reden van bestaan.

Als een onderdeel niet meer nodig blijkt, plan je een gecontroleerde beëindiging. Leg vast wat verdwijnt, welke gegevens moeten worden bewaard en hoe je controleert dat er geen actieve route meer van afhankelijk is. Opruimen is een wijziging met gevolgen, niet alleen administratie.

Deze inventaris helpt ook bij overdracht. Een nieuwe beheerder hoeft dan niet te raden welke naam bij welke leverancier hoort. Dat verkleint de kans op brede aanpassingen die een onzichtbare afhankelijkheid raken.

Een gecachte pagina bewijst geen gezonde applicatie

Bij een controle willen we de route testen die een gebruiker werkelijk nodig heeft. Een mooie voorpagina is nuttig, maar geen bewijs dat de achterliggende aanvraag of login goed wordt verwerkt. Daarom koppelen we technische observaties altijd aan functionele controles.

Vraag de beheerder te verklaren welke delen uit cache kunnen komen en welke handelingen de applicatie gebruiken. Je hoeft niet willekeurig caches te legen of alle optimalisaties uit te schakelen. Je wilt alleen voorkomen dat je een andere laag beoordeelt dan je denkt.

Een fictief adviesbureau ziet de homepage normaal laden, maar nieuwe afspraakaanvragen mislukken. De eerste controle meldt ‘website bereikbaar’. De betere controle meldt ‘publieke pagina bereikbaar, afspraakroute faalt bij verzenden’. Dat verschil bepaalt wie het probleem kan oplossen.

Test met herkenbare, onschuldige handelingen

Gebruik een afgesproken testaccount of testinvoer waar dat beschikbaar is. Leg vast welke route je doorloopt en waar het resultaat zichtbaar hoort te worden. Stuur geen echte betaling of klantbericht alleen om te kijken wat er gebeurt.

Wanneer een beveiligingsregel een test tegenhoudt, noteer je het tijdstip en de route voor de beheerder. Voeg geen volledige formulierinhoud of persoonsgegevens toe als dat niet nodig is. Een technische onderzoeksvraag kan meestal met veel minder informatie worden beantwoord.

Behandel een geslaagde test als bewijs voor precies die handeling, op die omgeving en op dat moment. Het is geen algeheel veiligheidscertificaat. Die beperkte formulering maakt je verslag betrouwbaarder, niet minder nuttig.

Patchen blijft een afzonderlijk werkpakket

Een actieve beschermlaag is geen reden om het daadwerkelijke PHP-onderhoud uit het overzicht te halen. Laat de host of verantwoordelijke beheerder bevestigen wat er draait, welke wijziging nodig is en hoe die is uitgevoerd.

Wij scheiden daarvoor drie taken. Eerst vaststellen welke omgeving geraakt wordt. Daarna de passende wijziging voorbereiden en uitvoeren. Tot slot de belangrijke applicatieroutes controleren. De netwerklaag kan bij ieder onderdeel relevant zijn, maar vervangt geen van die taken.

Voor het volledige uitvoeringsproces verwijzen we naar PHP updaten zonder uitval. Daar staat ook waarom terugschakelen naar een kwetsbare publiek bereikbare runtime geen vanzelfsprekende veilige rollback is.

Leg tijdelijke bescherming vast als tijdelijk

Als een beheerder tijdens onderzoek een extra beperking instelt, noteer dan het doel en de voorwaarden voor herbeoordeling. Zonder die context kan iemand de beperking later verwijderen omdat een legitieme functie niet meer werkt, terwijl de onderliggende update nog openstaat.

Omgekeerd kan een tijdelijke maatregel onnodig lang bezoekers hinderen als niemand haar opnieuw bekijkt. Koppel daarom een eigenaar en een controlepunt aan de maatregel. De eigenaar beslist op basis van bewijs, niet alleen omdat er een aantal dagen zijn verstreken.

Het eindverslag onderscheidt dan: tijdelijke bescherming actief, structurele wijziging uitgevoerd, functionele tests afgerond en tijdelijke uitzondering herbeoordeeld. Daarmee is voor iedereen zichtbaar waar het werk werkelijk staat.

Gebruik logging voor een vraag, niet voor een verzameldrang

Bij onderzoek heb je voldoende informatie nodig om gebeurtenissen te koppelen. Maar meer opgeslagen inhoud betekent niet automatisch meer inzicht. Begin met de onderzoeksvraag: welke route gaf een fout, welke regel greep in en welk tijdstip hoort erbij?

Onze praktische voorkeur is werken met beperkte technische kenmerken en verwijzingen naar afgeschermde logs. Vermijd het kopiëren van volledige aanvragen, sessiegegevens of klantinhoud naar een rapport. Geef alleen mensen toegang die de informatie voor de taak nodig hebben.

Bepaal ook hoe lang de onderzoeksinformatie bewaard moet blijven. Een tijdelijke foutanalyse is geen automatische reden voor onbeperkte opslag. Als extra gegevens nodig zijn, maak dan eerst duidelijk waarom en wie verantwoordelijk is voor die verwerking.

Een telling zonder context kan misleiden

Een groot aantal geblokkeerde verzoeken klinkt indrukwekkend, maar vertelt weinig over de werking van jouw belangrijke routes. Hetzelfde geldt voor een rustige grafiek: weinig meldingen bewijzen niet dat iedere relevante omgeving is bekeken.

Vraag daarom om een combinatie van configuratiebewijs en gerichte functionele controles. Welke maatregelen zijn vastgesteld? Welke routes zijn getest? Welke onderdelen blijven onbekend? Dat antwoord helpt bij prioriteiten en voorkomt dat beveiliging vooral een presentatie van dashboardcijfers wordt.

Een fictieve beheercontrole van begin tot einde

Stel dat een trainingsbureau een publieke WordPress-site, een apart inschrijfformulier en een oude testomgeving heeft. Het hoofddomein staat bij Cloudflare. De eigenaar denkt daarom dat alle onderdelen onder dezelfde bescherming vallen. Dit is een verzonnen voorbeeld om het proces zichtbaar te maken.

De beheerder begint niet met nieuwe regels. Eerst brengt hij de drie onderdelen in kaart en laat hij de hostingpartij hun runtime bevestigen. Daarbij blijkt dat de testomgeving een andere inrichting heeft en niet meer gebruikt wordt voor actuele ontwikkeling.

Vervolgens wordt per actieve route vastgesteld welke beschermlaag geldt en wie PHP beheert. De formulierroute krijgt een eigen functionele test. De oude testomgeving wordt niet impulsief verwijderd, maar krijgt een beëindigingsvoorstel met controle op resterende afhankelijkheden.

Na de benodigde update worden de publieke pagina, de inschrijving en de ontvangst van de testaanvraag gecontroleerd. Het verslag bevat geen algemene claim ‘alles onhackbaar’. Het noemt de onderzochte onderdelen, de uitgevoerde wijziging en het nog open besluit over de oude omgeving.

Dat is een bruikbaar resultaat: de eigenaar kan zien wat afgerond is en wat nog een beslissing vraagt. De volgende beheerder kan dezelfde kaart gebruiken zonder opnieuw de hele omgeving te moeten reconstrueren.

Checklist voor je gesprek met host en beheerder

Gebruik deze vragen om het gesprek concreet te houden:

• Welke publieke en interne onderdelen horen bij onze website?
• Welke routes lopen aantoonbaar via de bedoelde beschermlaag?
• Wie bevestigt waar PHP wordt uitgevoerd en onderhouden?
• Welke originmaatregelen zijn vastgesteld en wanneer gecontroleerd?
• Welke beveiligingsuitzonderingen bestaan en waarom?
• Welke belangrijke klantacties zijn na de wijziging getest?
• Welke tijdelijke maatregelen vragen nog herbeoordeling?
• Welke onbekende onderdelen hebben een eigenaar en een volgende stap?

Je hoeft niet ieder antwoord technisch te kunnen beoordelen. Je wilt vooral dat de antwoorden specifiek zijn en onderling aansluiten. Vraag een beheerder om onduidelijke verschillen uit te leggen in termen van bereikbaarheid, risico en bedrijfsfunctie.

Controleer opnieuw na overdracht of verhuizing

Een eerdere beoordeling blijft nuttige geschiedenis, maar beschrijft niet automatisch de inrichting na een verhuizing. Als hosting, domeinbeheer of de websitebouwer verandert, moet iemand controleren of de bedoelde routes nog overeenkomen met de nieuwe situatie.

Maak die controle onderdeel van de overdracht. Vraag de vertrekkende partij welke onderdelen zij beheerde en laat de nieuwe beheerder bevestigen welke taken zijn overgenomen. Vermeld ook tijdelijke adressen en testomgevingen die tijdens de verhuizing zijn gebruikt. Anders kan een goed bedoelde tussenoplossing buiten beeld blijven nadat de nieuwe website al werkt.

Een praktisch overdrachtsdocument bevat geen verzameling geheime instellingen. Het noemt de onderdelen, de verantwoordelijke rollen, de locatie van beveiligde configuratie en het resultaat van de afgesproken controles. Ontbrekende informatie krijgt een herkenbaar open punt. Zo kan de eigenaar zien of de overdracht werkelijk afgerond is of alleen de zichtbare homepage is verhuisd.

Herhaal vervolgens de kleine set functionele tests die bij de onderneming past. Dat is ook zinvol wanneer het ontwerp helemaal niet veranderde. De bezoeker ziet misschien dezelfde knop, terwijl de aanvraag achter die knop een andere route volgt. Juist dat verschil wil je controleren voordat een medewerker ontdekt dat aanvragen ontbreken.

Veelgestelde vragen

Maak bescherming en onderhoud samen zichtbaar

Cloudflare kan een waardevol onderdeel van je inrichting zijn. Het wordt vooral nuttig wanneer duidelijk is welke rol het vervult en waar de verantwoordelijkheid van de host en applicatiebeheerder begint. Zo krijgt een beveiligingsmelding een eigenaar en een toetsbare afhandeling.

Wil je samen bekijken welke lagen jouw website werkelijk heeft en welke beheervraag nog onbeantwoord is? Plan een gesprek. We beginnen met de bestaande inrichting, niet met de aanname dat je meteen alles moet vervangen.