Kort sagt: Cybersikkerhed i mellemstore virksomheder strander ved PHP2Shell sjældent på patchningen, men på overblikket. Ved siden af websitet kører forhandlerportaler, konfiguratorer, karrieresider og interne wikier hos forskellige tjenesteudbydere. Først en fuldstændig liste gør risikoen håndterbar og dokumenterbar over for kunder og tilsyn.
Typiske PHP-systemer i mellemstore virksomheder
Over årene samler der sig i produktionsvirksomheder mange webbaserede applikationer: B2B-shops til reservedele, forhandler- og partnerportaler med prislister, produktkonfiguratorer, downloadområder til teknisk dokumentation og CAD-data, reklamations- og serviceportaler, karrieresider med ansøgerstyring. Internt kommer wikier som MediaWiki, ticket-værktøjer og webanalyse til.
En stor del af det kører på PHP. Systemerne blev ofte bestilt af fagafdelinger, bygget af bureauer og drives hos hostingudbydere, som den centrale it ikke kender. Netop dér ligger ved en sårbarhed som PHP2Shell det egentlige problem.
Hvilke data og forbindelser der kan være berørt
I portaler ligger kundevilkår, kontaktpersoner hos forhandlere, tilbuds- og ordredata samt tegninger, der er omfattet af fortrolighedsaftaler. Ansøgerportaler indeholder cv'er og betyg. For konkurrenter og afpressere er konstruktionsdata og prisstrukturer ofte mere værdifulde end personoplysninger.
Kritiske er forbindelserne: Mange portaler udveksler data med ERP, varedisposition eller PIM. Den, der udfører kode på sådan en webserver, finder dér adgangsdata til grænseflader, databaser eller VPN. En kompromitteret portal kan således blive indgangen til virksomhedens netværk.
Mellemstore virksomheder og cybersikkerhed: leverandørkæde og NIS2
Med NIS2 gælder der for mange virksomheder udvidede pligter til risikostyring og anmeldelse af væsentlige sikkerhedshændelser. Om jeres virksomhed er direkte berørt, afhænger af sektor og størrelse. Indirekte berørt er mange flere, fordi kunder videregiver sikkerhedskrav til deres leverandører via aftaler.
For ledelsen kommer spørgsmålet om eget ansvar til. Hvad der generelt gælder herom, forklarer siden om ledelsens ansvar. Vurderingen i det enkelte tilfælde hører til jeres juridiske rådgivning.
Palo Alto Networks (Unit 42) talte mere end 22,6 millioner eksponerede, potentielt sårbare instanser. Et glemt testsystem hos et bureau er lige så synligt for automatiserede scanninger som jeres hovedwebsite.
Det typiske ansvarshul i mellemstore virksomheder
| Område | Hvem der ofte beslutter | Hvad der mangler |
|---|---|---|
| Virksomhedens website | Marketing med bureau | Patchdokumentation for PHP |
| Forhandlerportal, B2B-shop | Salg med tjenesteudbyder | Indlemmelse i it-sikkerhedskonceptet |
| Karriereside | Personale med udbyder | Klarhed over hosting og data |
| Interne værktøjer | enkelte afdelinger | Fortegnelse og ansvarlige |
Den centrale it er ansvarlig for netværk, arbejdspladser og ERP, men har ofte ikke adgang til eksternt hostede systemer. Dette mønster bliver ved enhver kritisk sårbarhed til en flaskehals. Afhjælpning giver en enkel regel: Hver webapplikation, der behandler virksomhedens data, meldes til it med driftsansvarlig og kontaktperson, før den går online.
Adskil webserver og produktionsnetværk rent
I industrien kommer webapplikationer til, som taler med maskiner og anlæg: service- og fjernvedligeholdelsesportaler, dashboards med maskindata, portaler til kunder, der henter status på deres leverede anlæg. Nogle af dem er bygget på PHP og står i et netområde, der har flere forbindelser, end opgaven kræver.
En kompromitteret webserver må ikke være en løftestang ind i produktionen. Undersøg, hvilke forbindelser der findes fra webserverne netområder ind i kontor- og produktionsnetværk, og begræns dem til det nødvendige. Gemte adgangsdata på webservere bør kun have de rettigheder, som applikationen virkelig har brug for. Ved fjernvedligeholdelsesadgange gælder det især.
De første timer for it-ledelse og direktion
- Opret en fortegnelse over alle eksternt tilgængelige PHP-systemer: domæne, driftsansvarlig, PHP-version, driftsform, kontaktperson.
- Behandl systemer med mod_php og dem på PHP 8.1 eller ældre først. Ved mod_php vurderer PHP-teamet risikoen som højest.
- Lad for hvert system rettelse til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 hhv. backport og genstart bekræfte skriftligt. Det, der ikke kan bekræftes, tages midlertidigt af nettet.
- Sikr logs fra 20.10.2026, og kontrollér webservernes forbindelser ind i det interne netværk.
- Dokumentér status kortfattet, så I kan besvare kunder, forsikringsselskab og eventuelt myndigheder dokumenterbart.
Hvordan hjælper PHP SOS konkret?
- Vi opretter sammen med it og fagafdelinger fortegnelsen over PHP-systemerne og prioriterer efter risiko.
- Vi koordinerer rettelser og genstarter med bureauer og hostingudbydere og samler dokumentationen ét sted.
- Ved mistanke overtager vi den strukturerede incident response med sikring af spor og kontrol af forbindelserne ind i firmanetværket.
- Derefter tilbyder vi et sikkerhedsaudit eller en penetrationstest ved specialiserede partnere, hvis resultat I kan forelægge for kunder.
- På ønske overvåger vi systemerne løbende, så fortegnelsen forbliver aktuel.
Ofte stillede spørgsmål
Falder vores virksomhed ind under NIS2?
Det afhænger af sektor, virksomhedsstørrelse og omsætning og skal vurderes i det enkelte tilfælde. Også den, der ikke direkte falder ind under NIS2, mærker ofte kravene via kunder i leverandørkæden. Den bindende vurdering afklarer I med jeres juridiske rådgivning.
Kan en hacket webserver føre ind i firmanetværket?
Det er muligt, hvis webserveren har forbindelser ind i det interne netværk, f.eks. grænseflader til ERP, fælles adgangsdata eller en VPN-tunnel. Om det er tilfældet hos jer, viser en kontrol af netværksforbindelserne og de gemte adgangsdata.
Hvordan finder vi alle PHP-applikationer i virksomheden?
Udgangspunktet er DNS-poster, certifikater, hostingfakturaer og aftaler med bureauer. Som supplement hjælper interviews i marketing, salg, service og personale. Som regel dukker der dermed systemer op, som it-afdelingen slet ikke kendte.
Hvad forventer kunder af os som leverandør efter PHP2Shell?
Nogle kunder spørger aktivt, om deres leverandører var berørt, og hvordan de reagerede. Hjælpsom er en kortfattet, dokumenterbar fremstilling: hvilke systemer, hvilken patchstatus, hvornår genstartet, hvilke kontroller for kompromittering. At love mere, end der kan dokumenteres, skader.