Kort sagt: Efter advarslen om PHP2Shell blev websites lukket ned i Tyskland, ifølge medier bl.a. webportalen for byen Mainz samt sider fra den hessiske delstatsregering og BKA (det tyske kriminalpoliti på forbundsplan). Der var tale om forsigtighed efter BSI's anbefaling, ikke om bekræftede angreb. Virksomheder kan lære heraf: En nedlukning er en legitim mulighed, hvis en patch ikke straks er mulig, og den lykkes bedst, når den er forberedt.
Websites lukket ned på grund af PHP: hvad skete den 21. oktober
Samme dag som PHP-sikkerhedsopdateringerne udkom, var talrige offentlige websites ikke tilgængelige i Tyskland. Ifølge mediedækning lukkede byen Mainz som forholdsregel sin centrale webportal ned. Forvaltningen forblev tilgængelig pr. telefon og e-mail.
I Hessen var ifølge hessenschau bl.a. sider fra delstatsregeringen, Bundeskriminalamt samt byerne Kassel og Wiesbaden midlertidigt offline. Staatskanzlei talte om tekniske tilpasninger og meldte intet angreb. Delstatssiderne var tilgængelige igen om aftenen. Yderligere kommuner, universiteter og klinikker tog ifølge rapporter ligeledes tilbud af nettet som forholdsregel.
Baggrunden er BSI's anbefaling om PHP2Shell: opdatér straks, og hvis det ikke straks er muligt, tag de berørte webservere midlertidigt af nettet. Hvad BSI nærmere anbefaler, opsummerer siden Hvad BSI anbefaler om PHP2Shell.
Nedlukket betyder ikke hacket
I kommentarer og på sociale netværk blev „offline“ hurtigt til „hacket“. Det er efter alt, hvad der vides, forkert. Nedlukningerne var en beskyttelsesforanstaltning i et øjeblik, hvor mange driftsansvarlige endnu ikke med sikkerhed kendte patchstatus på deres servere.
For virksomheder er dette skel vigtigt på to måder. For det første udadtil: Den, der selv lukker ned som forholdsregel, bør kalde det, hvad det er, og ikke tie. For det andet indadtil: En nedlukning besvarer ikke spørgsmålet, om serveren blev angrebet før. Den stopper blot yderligere forsøg. Undersøgelsen for spor er fortsat nødvendig.
Et tredje punkt overses ofte: En nedlukning må ikke ødelægge spor. Den, der geninstallerer serveren for at lukke ned eller sletter logs for at skaffe plads, fratager sig muligheden for senere at afklare, hvad der skete før nedlukningen. Bedre er det at omdirigere webserveren til en nødside eller spærre adgangen udefra og lade selve serveren med alle logs være uændret.
Hvorfor netop offentlige instanser reagerede sådan
Myndigheder driver ofte mange websites side om side: hovedportal, fagportaler, formulartjenester, sider for enkelte forvaltninger og institutioner. Ofte er flere serviceudbydere involveret. Den dag, advarslen kom, var det for mange forvaltninger simpelthen ikke muligt at få en dokumenteret patchstatus for hvert system inden for få timer. Nedlukningen som forholdsregel var i den situation den hurtigste måde at følge BSI's anbefaling på.
For virksomheder med et gradvist vokset it-landskab er situationen ofte lignende. Spørgsmålet „Er alt patchet?“ strander ikke på teknikken, men på manglende overblik.
Bemærkelsesværdigt er også, hvor hurtigt de hessiske delstatssider ifølge rapporter kom tilbage: allerede samme aften. Det viser, at en nedlukning som forholdsregel ikke behøver vare i dagevis. Den, der kender sine systemer og mestrer opdateringsvejen, kan patche, kontrollere og gå online igen i løbet af få timer. Nedlukningen dækker så blot tiden, indtil der er klarhed.
Hvornår en nedlukning som forholdsregel giver mening for virksomheder
Myndigheder har en særlig situation: mange websites, ofte forvaltet decentralt, og høj offentlig synlighed. Den afvejning, de stod i, er dog den samme som i enhver virksomhed. Følgende oversigt hjælper med beslutningen:
| Situation | Snarere lukke ned | Snarere lade være online |
|---|---|---|
| Patchstatus | uklar eller ikke bekræftet | rettet og dokumenteret, processer genstartet |
| PHP-version | 8.1 eller ældre uden bekræftet backport | understøttet gren på aktuel version |
| Driftsform | Apache med mod_php | patchet PHP-FPM med midlertidige foranstaltninger indstillet |
| Data på serveren | kundedata, logins, betalingsdata | rent statisk indhold |
| Serviceudbyderens tilgængelighed | patch først mulig om dage | patch planlagt inden længe |
Afvejningen mellem at patche, lukke ned og vente uddyber indlægget Patche, lukke ned eller vente?. Hvad der teknisk er muligt som overgang, hvis opdateringen endnu mangler, står under Akutte foranstaltninger uden patch.
At lukke en shop eller et kundeportal midlertidigt ned koster omsætning. En kompromitteret server med kundedata kan koste markant mere, helt op til anmeldelsespligter. Træf beslutningen bevidst, og fasthold den skriftligt.
Sådan forbereder I en nedlukning
Mainz viste, hvad det kommer an på: Forvaltningen forblev tilgængelig via andre kanaler. Det lykkes kun, hvis det er forberedt. Disse trin kan betale sig, før næste alvorlige situation indtræffer:
- Hav en nødside klar: en statisk HTML-side uden PHP med en kort forklaring, telefon- og e-mailkontakt og, om nødvendigt, oplysninger om igangværende bestillinger eller aftaler.
- Fastlæg omskiftningsvejen: Hvem kan omdirigere websitet til nødsiden, via webserver, DNS eller en foranstillet tjeneste? Hvor lang tid tager det?
- Afklar beslutningskompetencen: Hvem må beordre en nedlukning, også uden for arbejdstid?
- Kend afhængige tjenester: Hænger grænseflader, apps eller partnere på websitet? Hvem skal informeres på forhånd?
- Definér kriterier for genåbning: patch dokumenteret, genstart gennemført, første sporundersøgelse uden fund.
- Formulér budskabet på forhånd: to til tre sætninger til kunder, partnere og presse.
Hvordan I kommunikerer udadtil i en sådan situation, beskriver vejledningen om krisekommunikation.
Hvordan hjælper PHP SOS konkret?
- Beslutningsgrundlag: Vi fastslår patchstatus, driftsform og datasituation på jeres servere og giver jer en klar vurdering af, om en nedlukning er påkrævet.
- Ordnet nedlukning: Vi skifter over til en statisk nødside uden at miste logs eller spor.
- Patch og undersøgelse: Vi opdaterer PHP, genstarter alle processer og undersøger for påfaldende forhold.
- Kontrolleret genåbning: Vi tager websitet først online igen, når de aftalte kriterier er opfyldt og dokumenteret.
Forløbet beskrives under PHP2Shell-akuthjælp.
Konklusion
Myndighedernes nedlukninger var ikke tegn på tab af kontrol, men en bevidst forholdsregel. For virksomheder er det den egentlige lærdom: At gå offline er en legitim beslutning, når patchstatus er uklar. Den, der har forberedt nødside, ansvar og genåbningskriterier, træffer den på minutter i stedet for timer.
Ofte stillede spørgsmål
Hvorfor blev myndigheders websites lukket ned på grund af PHP?
BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler ved PHP2Shell en øjeblikkelig opdatering og, hvis den ikke straks er mulig, midlertidigt at tage webserverne af nettet. Flere myndigheder fulgte som forholdsregel denne anbefaling, indtil deres systemer var kontrolleret og opdateret.
Betyder en nedlukket website, at den er blevet hacket?
Nej. En nedlukning som forholdsregel er en beskyttelsesforanstaltning. Den hessiske Staatskanzlei meldte f.eks. ifølge hessenschau udtrykkeligt intet angreb. Om en server var berørt før nedlukningen, afklarer først en undersøgelse.
Hvor længe bør en website være offline?
Indtil PHP står på en rettet version, alle PHP-processer er genstartet, og en første undersøgelse for spor ikke har givet nogen påfaldende fund. Der findes ingen fast varighed; de hessiske delstatssider var ifølge rapporter tilgængelige igen samme aften.
Hvad viser jeg besøgende, mens websitet er offline?
Bedst en enkel, statisk nødside uden PHP med en kort forklaring og de kontaktveje, hvorigennem I fortsat kan træffes. Den bør være forberedt, før den bliver brug for.