Kort sagt: Om I efter et hack opsætter en server på ny eller rydder den op, afhænger af, hvor sikkert I kender indbruddets omfang. Havde angriberen muligvis root-rettigheder, er indbrudstidspunktet uklart, eller mangler der logs, er en genopbygning fra troværdige kilder det mere pålidelige valg. En oprydning kommer kun i betragtning ved et snævert afgrænset, godt dokumenteret angreb. I begge tilfælde gælder: først sikre beviser og lukke sårbarheden, så rydde op.
Hvorfor dette spørgsmål stilles særligt ofte efter PHP2Shell
PHP2Shell tillader ifølge php.net udførelse af skadelig kode på afstand uden login. Den, der har drevet en upatchet server, må derfor spørge sig selv, om der er sket noget i tiden siden 17.10.2026, det ifølge medierapporter første observerede angrebsforsøg. Patchen besvarer ikke dette spørgsmål, og der findes ingen offentliggjorte, bekræftede Indicators of Compromise.
Findes der så en mistænkelig fil, en ukendt proces eller et fremmed cronjob, står beslutningen for døren. Impulsen er ofte at slette hurtigt eller geninstallere straks. Begge dele kan være rigtige, men ikke som første skridt.
Rækkefølgen før beslutningen
Før I vælger mellem at rydde op og at opsætte på ny, skal tre ting være gjort. De gælder for begge veje.
- Inddæmme: Tage serveren af nettet eller begrænse adgangen til det nødvendigste, uden at slukke den, hvis arbejdshukommelsen endnu skal sikres.
- Sikre beviser: Sikre logs, filer, database og helst et aftryk af systemet, med dato og kontrolsum. Hvorfor det er nødvendigt før enhver nyinstallation, forklarer Sikr beviser, før I opsætter på ny.
- Inddrage forsikringsselskab og databeskyttelse: Mange cyberpolicer forventer, at væsentlige skridt afstemmes. Henvisninger står under Cyberforsikring: Hvad der tæller i skadestilfælde. Om der består en anmeldelsespligt efter GDPR, vurderer databeskyttelsesrådgiver eller advokat.
Først derefter kan selve afvejningen betale sig.
Opsætte serveren på ny efter hack eller rydde op: kriterierne
| Kriterium | Rydde op | Opsætte på ny |
|---|---|---|
| Indbruddets omfang | Snævert afgrænset, dokumenteret, f.eks. én fil i upload-mappen uden yderligere spor | Uklart eller med tegn på systemadgang |
| Angriberens mulige root-rettigheder | Udelukket med gode beviser | Kan ikke udelukkes |
| Tilgængelighed af logs | Fuldstændige for den relevante periode | Mangelfulde, overskrevne eller kan være manipuleret |
| Indsats | Mindre, hvis fundet er klart | Større, men bedre at planlægge |
| Tilbageværende usikkerhed | Højere, skjulte bagdøre er svære at udelukke | Lavere, hvis opbygget rent fra troværdige kilder |
| Nedetid | Som regel kortere | Som regel længere, med forberedelse godt at styre |
| Egnethed til ældre systemer | Problematisk, hvis systemet alligevel er forældet | God lejlighed til at skifte til en understøttet PHP-version |
Som tommelfingerregel gælder: Jo mindre I ved, desto mere taler for genopbygningen. Ved en sårbarhed i PHP-fortolkeren, der udfører kode i webserverbrugerens kontekst, kan en angriber udnytte yderligere sårbarheder for at opnå flere rettigheder. Det kan næppe udelukkes uden en grundig undersøgelse.
Begge veje i praksis
Hvad "opsætte på ny" egentlig betyder
At opsætte på ny betyder ikke at kopiere den gamle backup over på en frisk server. En genopbygning begynder med et rent styresystem fra officiel kilde, aktuelle pakker og en patchet PHP-version. Applikationen installeres fra producentens original, plugins og themes ligeså.
Først derefter kommer det eget indhold til, og det kontrolleret. Uploadede filer må ikke indeholde eksekverbare scripts, databasen kan indeholde indsmuglet indhold, f.eks. skjulte admin-konti eller scripts i indlæg. Konfigurationsfiler skrives på ny i stedet for at blive kopieret. Alle adgangsoplysninger fornyes: database, CMS-administratorer, SSH-nøgler, API-nøgler, hostingpanel.
Backups spiller her en vigtig rolle, men kun hvis deres status ligger før indbruddet, og de selv ikke er blevet ændret. Flere generationer på adskilte steder gør det kontrollerbart; mere herom under Backups efter 3-2-1-reglen.
Når en oprydning er forsvarlig
En oprydning kan være fornuftig, hvis angrebet blev opdaget tidligt, fuldstændige logs foreligger, og undersøgelsen ikke giver tegn på yderligere adgange. Så fjernes de fundne filer efter sikringen, cronjobs, brugerkonti og SSH-nøgler kontrolleres, og kernefiler sammenlignes med producentens original.
En realistisk vurdering er vigtig: Webshells er ofte uanselige og skjult flere steder. Hvordan man finder dem, beskriver Genkend og fjern webshells. Efter en oprydning bør serveren overvåges nøje, så en overset bagdør opdages.
Slet intet, før logs og filer er sikret, og luk sårbarheden, før serveren kommer på nettet igen. Ellers mister I sporene og inviterer det næste indbrud.
Hvornår I ikke har brug for en leverandør
Ved et enkelt website på shared hosting, hvor hostingudbyderen administrerer systemet og bekræfter PHP-patchen, ligger beslutningen ofte slet ikke hos jer. I kan geninstallere applikationen fra originalen, kontrollere indhold og fornye adgangsoplysninger, støttet af hostingudbyderen. Også et erfarent internt team kan klare en genopbygning selv, hvis bevissikring og dokumentation sidder.
Ekstern hjælp kan betale sig, hvis root-rettigheder ikke kan udelukkes, personoplysninger kan være berørt, forsikringsselskabet er involveret, eller flere systemer hænger sammen.
Hvordan hjælper PHP SOS konkret?
- Vi sikrer logs, filer og database bevisegnet, før noget ændres.
- Vi vurderer indbruddets omfang og anbefaler oprydning eller genopbygning med begrundelse, adskilt efter dokumenteret, sandsynligt og ukendt.
- Vi bygger om nødvendigt serveren op på ny fra troværdige kilder, med patchet PHP-version og fornyede adgange.
- Vi overtager fjernelse af malware dér, hvor en oprydning er forsvarlig, og dokumenterer hvert skridt.
Konklusion
Spørgsmålet "opsætte på ny eller rydde op?" besvares gennem viden om indbruddet. Den, der ikke kender omfanget sikkert, bygger på ny. Den, der kan afgrænse det godt dokumenteret, må rydde op. I begge tilfælde gælder den samme rækkefølge: inddæmme, sikre, lukke sårbarheden, så rydde op.
Ofte stillede spørgsmål
Er en ny opsætning altid bedre efter et hack?
Ikke altid, men ofte. Hvis det er uklart, hvor langt angriberen nåede, er en genopbygning fra troværdige kilder som regel det mere pålidelige valg. Ved et snævert afgrænset, godt dokumenteret angreb kan en oprydning være nok.
Kan jeg bare indspille en gammel backup?
Kun hvis det er sikkert, at backuppen blev lavet før indbruddet og ikke indeholder en bagdør. Desuden skal sårbarheden være lukket på forhånd, ellers kan serveren straks angribes igen. Nyere data skal kontrolleres separat.
Hvad skal jeg sikre, før jeg opsætter på ny?
Logs, en kopi af filerne og databasen samt, hvis muligt, et aftryk af systemet. Disse beviser har I brug for til årsagsanalyse, forsikring og en mulig anmeldelse. Efter sletningen er de væk.
Er det nok at slette den fundne webshell?
Sjældent. Angribere lægger ofte flere bagdøre, f.eks. cronjobs, brugerkonti eller SSH-nøgler. Den, der kun sletter den synlige fil, lader de andre adgange stå åbne.