Kort sagt: White label-it-sikkerhed betyder for jeres bureau: I beholder kundeforholdet, vi udfører sikkerhedsarbejdet i baggrunden. Ved PHP2Shell betyder det en fortegnelse over alle kundesites, prioritering efter risiko, rettelse og genstart pr. server og en dokumentation pr. kunde, som I kan give videre.
Hvorfor bureauer er særligt pressede ved PHP2Shell
Et bureau med mange kunder passer sjældent et ensartet landskab. En del af siderne ligger på egne servere med Plesk, en del hos kundernes hostingudbydere, nogle gamle projekter på PHP-versioner, som for længst ikke får officielle opdateringer. Dertil kommer forskellige systemer: WordPress, TYPO3, Shopware, Craft CMS, egenudviklinger i Laravel.
Ved en sårbarhed i selve PHP rammer det alle projekter samtidig. Kunder forventer et svar på, om deres side er sikker, og projektteamet er fuldt optaget af løbende opgaver. Mange vedligeholdelsesaftaler regulerer CMS'et, men ikke serveren under det.
Dertil kommer systemer, som ikke længere dukker op i nogen projektliste: staging-miljøer på subdomæner, kampagnesider fra afsluttede projekter, testinstallationer fra udviklere på egne vServere. De kører ofte på ældre PHP-versioner, overvåges ikke og bærer alligevel navnet på jeres bureau eller jeres kunde. For automatiserede scanninger er de lige så synlige som hovedsiden.
Hvilke spørgsmål jeres kunder nu stiller
- Er mit website berørt, og er det i mellemtiden patchet?
- Blev der allerede indsmuglet noget før rettelsen?
- Gælder CMS-opdateringen som beskyttelse? Nej, en CMS-opdatering lukker ikke PHP-sårbarheden.
- Skal jeg tage mit website af nettet? BSI anbefaler det for servere, der ikke kan opdateres med det samme.
På hvert af disse spørgsmål har jeres bureau brug for et dokumenterbart svar pr. kunde, ikke en rundmail med generelle udsagn.
Sådan forløber white label-it-sikkerhed for bureauer
Vi arbejder som en del af jeres team, men uden egen kundekontakt. Opgavefordelingen er klar:
| Opgave | Jeres bureau | PHP SOS |
|---|---|---|
| Kundekommunikation og afregning | ja | nej |
| Fortegnelse over alle kundesites med PHP-status | leverer adgange | opretter og vedligeholder den |
| Rettelse, genstart, kontrol pr. server | frigiver vedligeholdelsesvindue | udfører eller koordinerer med hostingudbydere |
| Kontrol for kompromittering | modtager fundet | leder efter webshells og uregelmæssigheder |
| Dokumentation pr. kunde | giver videre | udarbejder neutralt eller i jeres format |
Ved sider hos fremmede hostingudbydere indhenter vi bekræftelsen af pakkestatus. Det viste versionsnummer alene er ikke nok, fordi backports kan lade det være uændret.
Prioritér først servere med Apache og mod_php, hvor PHP-teamet vurderer risikoen som højest, derefter shops og sider med logins, derefter projekter på PHP 8.1 og ældre. Statiske gamle projekter, som ingen længere har brug for, slukker I bedre, end I patcher dem.
Flere kundesites på én server: kontrollér isolationen
På bureauservere deler mange kundesites ofte én maskine. Kompromitteres en af dem, afgør adskillelsen, om angriberen også når de andre. Vigtige er egne systembrugere og PHP-FPM-pools pr. website, rene filrettigheder og grænser som open_basedir. På Plesk-servere kan disse indstillinger kontrolleres pr. abonnement.
Efter rettelsen gælder: Genstart alle pools og workers. Først da kører der ikke længere gamle PHP-processer i hukommelsen. Logs fra 20.10.2026 bør opbevares for hver kundeside.
Kundeinformation: hvad der er dokumenteret, og hvad der ikke er
Den største fristelse i denne situation er en beroligende fællesmail. Sikrere er et udsagn pr. kunde, som kun indeholder det, der er dokumenteret: hvilken server, hvilken PHP-pakkestatus, hvornår genstartet, om en kontrol for kompromittering har fundet sted, og med hvilket resultat. Hvad der endnu er åbent, står også deri.
Formuleringer som »Jeres side er sikker« undgår I bedre. En rettelse lukker sårbarheden, men beviser ikke, at der ikke skete noget før. Den, der adskiller det ærligt, står senere ikke i forklaringspligt, hvis der alligevel dukker et fund op.
Omformulér vedligeholdelsesaftaler efter PHP2Shell
Mange bureauaftaler regulerer opdateringer af CMS og udvidelser, men tier om serveren. Brug situationen til for hver kunde at fastholde, hvem der opdaterer PHP, hvem der er ansvarlig for genstarter, hvem der beslutter ved en hændelse, og hvilke ydelser der bestilles separat. Også en databehandleraftale med alle involverede tjenesteudbydere hører med. Den kontraktlige udformning afklarer I med jeres juridiske rådgivning.
Hvordan hjælper PHP SOS konkret?
- Vi overtager registreringen af alle kundesites med PHP-version, driftsform, hostingudbyder og ansvar.
- Via vores PHP-patch-service patcher vi jeres egne servere, genstarter alle workers og dokumenterer det pr. kunde.
- Vi kontrollerer prioriterede sider for kompromittering og renser ved fund, indtil hændelsen er afsluttet og dokumenteret.
- Vi leverer tekstbyggesten til jeres kundeinformation, som I tilpasser og selv sender af sted.
- Derefter overtager vi på ønske med en sikkerhedsvedligeholdelsesaftale den løbende sikkerhedsbetjening i baggrunden.
Ofte stillede spørgsmål
Optræder I over for vores kunder?
Kun hvis I ønsker det. I white label-modellen arbejder vi udelukkende i baggrunden, og al kommunikation løber via jeres bureau. Vores dokumentation leverer vi neutralt eller i jeres format.
Har vi brug for en databehandleraftale hertil?
Hvis vi tilgår systemer med personoplysninger fra jeres kunder, er der som regel brug for en databehandleraftale, ofte som underdatabehandling. Hvordan det passer ind i jeres eksisterende aftaler, afklarer I med jeres juridiske rådgivning. Vi stiller de nødvendige oplysninger om vores aktiviteter til rådighed.
Hvad med kundesites, hvis servere vi slet ikke administrerer?
Ligger kundesites hos fremmede hostingudbydere, indhenter vi i jeres navn eller med jeres skabeloner bekræftelser om patchstatus og genstart. Hvor der kun er FTP- eller CMS-adgang, undersøger vi, hvad der er muligt derfra, og markerer åbent, hvad kun hostingudbyderen kan dokumentere.
Kan vi også udlicitere det varigt efter PHP2Shell?
Ja. Mange opgaver gentager sig ved hver sårbarhed: vedligeholde fortegnelsen, indspille rettelser, dokumentere genstarter, melde uregelmæssigheder. Dette arbejde kan organiseres som løbende betjening i baggrunden.