Kort sagt: En it-oversigt over webservere er en liste over alle websites, portaler, shops og servere med de oplysninger, man straks har brug for ved en sikkerhedsmelding: hvor det kører, med hvilken PHP-version og driftsform, hvilken applikation, hvem der er ansvarlig, og hvilke data der ville være berørt. Uden denne liste begynder enhver reaktion med at lede. Med den tager afstemningen ved en melding som PHP2Shell minutter i stedet for dage.
Det første spørgsmål var: Hvor kører der overhovedet PHP hos os?
Da PHP-projektet den 21.10.2026 offentliggjorde rettelserne, og BSI (det tyske forbundsagentur for informationssikkerhed) anbefalede at handle straks, var anvisningen entydig: opdatér PHP, genstart alle processer. For mange virksomheder var det første skridt alligevel ikke opdateringen, men en optælling. Hovedwebsitet var kendt. Men forhandlerportalen? Karrieresiden hos en anden udbyder? Landingpagen fra en kampagne for tre år siden? Den interne wiki?
Fagpressen og måletjenester har gjort problemets omfang synligt. Palo Alto Networks (Unit 42) talte mere end 22,6 millioner eksponerede, potentielt sårbare instanser. Blandt dem er der formentlig mange systemer, som deres driftsansvarlige simpelthen ikke tænker på længere.
Hvad der hører hjemme i en it-oversigt over webservere
En brugbar oversigt er en tabel med én række pr. website eller applikation. Disse kolonner har vist sig at fungere:
| Kolonne | Eksempel | Hvorfor |
|---|---|---|
| Adresse | shop.eksempel.dk | entydig tilknytning |
| Formål og betydning | onlineshop, omsætningskritisk | prioritering |
| Hostingudbyder eller placering | managed server hos udbyder X | hvem man ringer til |
| Server og styresystem | vServer, Debian | opdateringsvej, sikkerhedskilder |
| Webserver og PHP-driftsform | Nginx med PHP-FPM | risiko, f.eks. mod_php |
| PHP-version og pakkestatus | 8.3, pakke med dato | afstemning med meldinger |
| Applikation og version | Shopware, plugins | producentmeldinger |
| Ansvarlig intern / ekstern | it-chef / bureau Y | hvem handler |
| Behandlede data | kundekonti, ordrer | anmeldelsespligter, hastegrad |
| Backups | dagligt, eksternt, senest testet den … | genetablering |
| Seneste patch-dokumentation | dato og bilag | dokumentation over for tredjepart |
Driftsformen fortjener særlig opmærksomhed. Ved PHP2Shell vurderede PHP-teamet risikoen som højest ved Apache med mod_php. Den, der ved, hvilke systemer der drives sådan, kan tage dem først. Kolonnen om pakkestatus er vigtig, fordi det viste versionsnummer ofte forbliver det samme efter backports; henvisninger hertil findes under Kontrollér PHP-version og patchstatus korrekt.
Find glemte systemer: Sådan går I frem
De kendte systemer er hurtigt indtastet. Det egentlige arbejde er de ukendte. Disse kilder hjælper med at opspore dem:
- Domæner og DNS: Gennemgå alle virksomhedens domæner og deres subdomæner. Hver post, der peger på en webserver, er en kandidat.
- Fakturaer: Regnskabet kender enhver hostingudbyder, registrar og cloududbyder, der får penge. Det er ofte den mest fuldstændige liste.
- Bureauer og fagafdelinger: Marketing, salg og personaleafdeling bestiller gerne websites direkte. Spørg dem.
- Kendte servere: På hver server viser konfigurationen, hvilke websites den faktisk leverer.
- Enheder med webgrænseflade: NAS, routere og appliances har til dels deres eget PHP med, se PHP på NAS, routere og appliances.
Til trin 4 hjælper nogle læsende kommandoer på Linux-servere. De viser konfigurerede websites, PHP-tjenester og FPM-pools:
# Konfigurerede websites (Apache hhv. Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Kørende PHP-tjenester og -processer
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# FPM-pools under Debian og Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Kører der flere PHP-versioner side om side på en server, hører hver af dem med på listen. Hver skal opdateres og genstartes for sig.
Tag også systemer med, som egentlig skulle lukkes ned. Netop de kører ofte stadig, har ikke været opdateret i årevis og bliver glemt. Med en post "luk ned senest den …" forbliver opgaven synlig.
Hold oversigten opdateret
En oversigt er kun så god som sin seneste opdatering. Tre regler holder den i live. For det første: En person er ansvarlig og informeres ved hvert nyt website, hver flytning og hver nedlukning, også når et bureau udfører arbejdet. For det andet: Én gang i kvartalet afstemmes listen med DNS, fakturaer og serverkonfiguration. For det tredje: Oversigten er en del af nødplanen og foreligger også uden for egen it, f.eks. udskrevet.
For virksomheder med mange spredte systemer, f.eks. forhandlerportaler, konfiguratorer og leverandøradgange, beskriver It-sikkerhed for mellemstore virksomheder og industri typiske fundsteder. Hvordan oversigten indarbejdes i nødplanen, står under Udarbejd en it-nødplan for webservere.
Hyppige fejl i oversigten over webservere
Mange oversigter findes, men hjælper ikke i en nødsituation. Årsagerne ligner hinanden:
- Kun servere, ingen websites: Listen nævner maskiner, men ikke hvilke websites der kører på dem, og hvem der fagligt er ansvarlig. Ved en sårbarhed ved ingen så, hvilken afdeling der er berørt.
- Version i stedet for pakkestatus: "PHP 8.3" siger efter PHP2Shell ikke meget. Først pakkestatus og dato viser, om rettelsen er med.
- Eksterne systemer mangler: Det, der kører hos et bureau eller en platformtjeneste, udelades, fordi man angiveligt "ikke er ansvarlig dér". Ansvaret for dataene forbliver alligevel i huset.
- Ingen kontaktpersoner: En post uden navn og telefonnummer på den ansvarlige afdeling koster tid i en nødsituation.
- Engangsindsats: Oversigten oprettes i en krise-uge og åbnes derefter aldrig mere. Efter et år passer en god del ikke længere.
Den, der undgår disse fem punkter, har ved næste melding en liste, som man faktisk kan arbejde med.
Hvordan hjælper PHP SOS konkret?
- Vi registrerer sammen med jer alle websites og servere, også de glemte, via DNS, fakturaer, leverandører og serverkonfiguration.
- Vi fastslår for hvert system driftsform, PHP-version og den faktiske pakkestatus.
- Vi prioriterer systemerne efter tilgængelighed, data og driftsform og siger, hvor der skal handles først.
- Hvor PHP2Shell stadig er åben, lukker vi sårbarheden via PHP2Shell-akuthjælpen og fører dokumentationen ind i oversigten.
Konklusion: En oversigt er den mest uanselige og samtidig mest virkningsfulde sikkerhedsforanstaltning. Den, der ved, hvad der kører, kan handle straks ved næste melding i stedet for først at skulle lede.
Ofte stillede spørgsmål
Hvilke oplysninger skal en oversigt over webservere mindst indeholde?
Websitets adresse, server eller hostingudbyder, PHP's driftsform, PHP-version med pakkestatus, applikation med version, ansvarlig person internt og eksternt, typen af behandlede data og placeringen af backups. Med disse oplysninger kan enhver ny sikkerhedsmelding hurtigt afstemmes.
Hvordan finder jeg websites, som ingen længere kender til?
Ad flere veje på én gang: domæneadministration og DNS-zoner, fakturaer fra hostingudbydere og registrarer, spørgsmål til bureauer og fagafdelinger samt konfigurationen på de kendte servere. Gamle kampagnesider, testsystemer og subdomæner dukker som regel op på den måde.
Hvem bør vedligeholde oversigten?
En udpeget person, som regel i it-afdelingen eller hos it-chefen. Det vigtige er, at enhver ændring af websites og servere meldes dertil, også når en fagafdeling eller et bureau har foranlediget den.
Er en tabel nok, eller skal man bruge software?
For de fleste mellemstore virksomheder er en velvedligeholdt tabel nok. Software kan betale sig, hvis mange systemer skal registreres automatisk. Det afgørende er aktualiteten, ikke værktøjet.