Kort sagt: Før I sætter en kompromitteret server op påny, sikrer I beviserne i rækkefølge efter, hvor flygtige de er: først processer, forbindelser og loggede ind brugere, derefter logs og konfiguration, så et fuldstændigt aftryk af systemet og data fra forudgående tjenester. Hver sikring får en kontrolsum og lægges uden for serveren. Serveren adskilles hertil fra nettet, men slukkes ikke.
Refleksen: at sætte op påny med det samme
Den, der opdager et indbrud, vil afslutte det så hurtigt som muligt. Et friskt system, rent installeret, med nye adgangskoder: Det føles som kontrol. Teknisk er en genopbygning også ofte den rigtige vej, især hvis en angriber havde root-rettigheder.
Problemet er tidspunktet. Med det gamle system forsvinder alle svar på de spørgsmål, der kommer i dagene efter. Gennem hvilken sårbarhed kom angriberen ind? Hvor længe havde han været i systemet? Havde han adgang til kundedata? Er databaseserveren ved siden af også berørt? Uden spor bliver der kun formodninger tilbage, og de hjælper hverken ved databeskyttelsen eller ved forsikringen.
Efter PHP2Shell kommer der et særligt punkt til: Der findes ingen offentliggjorte, bekræftede indicators of compromise. Om og hvordan en server var berørt, kan kun aflæses af adfærden, altså af netop de spor, som en forhastet genopbygning sletter. Fagpressen anbefaler at opbevare serverlogs fra og med 20.10.2026.
Bevissikring på serveren: Rækkefølgen tæller
Spor er forskelligt flygtige. Det, der står i arbejdshukommelsen, er væk ved næste genstart. Logs overlever længere, men roteres. Data hos forudgående tjenester forsvinder efter deres egne frister. Heraf følger rækkefølgen:
| Spor | Flygtighed | Sådan sikres det |
|---|---|---|
| Processer, netværksforbindelser, loggede ind brugere | forsvinder ved genstart | skriv systemkommandoernes output til filer |
| Arbejdshukommelse | forsvinder ved genstart | kun med specialværktøj, opgave for forensikere |
Midlertidige filer i /tmp eller /dev/shm |
ofte slettet ved genstart | kopiér uden at udføre |
| Logs fra webserver, PHP, system | roteres | kopiér fuldstændigt, stands rotationen |
| Filsystem og database | stabilt til nyinstallationen | snapshot eller aftryk af datamediet, databaseeksport |
| CDN, WAF, firewall, hostingudbyder | opbevaring efter udbyderens frister | anmod om eksport, få det bekræftet skriftligt |
Arbejdshukommelsen sikrer I kun, hvis nogen med passende værktøj og erfaring står klar. Ved systemer med følsomme data eller en forudsigelig retstvist bør en it-forensik tage sig af det.
Noter flygtige data på få minutter
De følgende kommandoer ændrer intet ved systemet. De skriver den aktuelle tilstand til filer, som derefter sikres uden for serveren. Opret helst målmappen på et tilsluttet, separat datamedie:
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
Hvordan I derefter sikrer og analyserer logs fuldstændigt, beskriver vejledningen Analysér webserverlogs efter et angreb. Ved virtuelle servere er et snapshot via udbyderens administration den enkleste vej til et fuldstændigt aftryk. Det fanger systemet, uden at I behøver at starte yderligere værktøjer på den kompromitterede server.
Så sikringen senere er noget værd
En sikring er kun så god som dens dokumentation. Tre regler gør den holdbar:
- Kontrolsummer: Hver sikret fil får en SHA-256-kontrolsum. Dermed kan det senere vises, at kopien er uændret.
- Protokol: Hvem har hvornår sikret hvad, med hvilken kommando, hvortil? Hver overdragelse til tredjepart noteres. Fagfolk kalder det bevismiddelkæden.
- Adskilt opbevaring: Kopier hører hjemme på et system, som angriberen ikke havde adgang til, og bruges derefter kun læsende.
Arbejd derefter kun med kopier. Hver analyse på originalen ændrer tidsstempler og kan overskrive spor. Udfør aldrig mistænkelige filer, og åbn dem ikke via browseren.
Anmod tidligt om logs fra CDN, WAF og hostingudbyder. Disse data ligger uden for jeres server og er svære for en angriber at manipulere, men opbevares ofte kun kort.
Det, der ødelægger bevisgrundlaget
Mange spor går ikke tabt på grund af angriberen, men på grund af velment førstehjælp. Disse skridt bør undlades før sikringen:
- Genstart eller slukning: Processer, forbindelser og arbejdshukommelse er derefter væk.
- Virusscanner med automatisk sletning: Den fjerner filer, før nogen har sikret dem, og ændrer tidsstempler.
- Oprydning af logs eller temp-mapper: Også når pladsen er knap, skal der først kopieres og derefter slettes.
- Installation af nye værktøjer fra internettet på serveren: Hver installation skriver til filsystemet og kan dække over spor.
- Login med privilegerede adgangsdata uden nød: Kører der stadig skadelig kode på serveren, kan indtastede adgangskoder blive læst med.
Netop forsikringsselskaber spørger senere, hvad der blev sikret hvornår. Henvisninger til typiske forpligtelser finder I under Cyberforsikring: Hvad der tæller i skadestilfælde.
Afvejning: Hvor meget tid er der til sikringen?
Ikke enhver hændelse tillader en lang sikring. Er der netop nu en dataudstrømning i gang, eller angribes besøgende, har inddæmningen forrang. Adskillelsen fra nettet ved kørende system forener begge dele: Angriberen mister adgangen, sporene bevares. For de fleste webservere rækker derefter et overskueligt tidsrum til de flygtige data og snapshottet.
Træf beslutningen bevidst, og notér den: Hvem har besluttet, hvornår der sættes op påny, og hvad blev sikret forinden? Denne note bliver senere en del af hændelsens tidslinje. Om genopbygning eller oprydning er den rigtige vej, belyser indlægget Sæt serveren op påny eller ryd op?.
Hvordan hjælper PHP SOS konkret?
- Vi sikrer flygtige data, logs og systemaftryk i den rigtige rækkefølge, med kontrolsummer og protokol.
- Vi anmoder om data fra forudgående tjenester, før deres opbevaringsfrister udløber.
- Efter behov overtager vi sammen med specialiserede partnere den forensiske sikring og analyse.
- Først derefter genopbygger vi serveren, lukker indgangen og dokumenterer hændelsen, til den er afsluttet.
Ofte stillede spørgsmål
Hvorfor skal jeg sikre beviser, før jeg sætter serveren op påny?
Fordi kun sporene viser, hvordan angriberen kom ind, hvor længe han var i systemet, og hvilke data han kunne nå. Disse svar har I brug for til databeskyttelse, forsikring og spørgsmålet om, hvorvidt andre systemer er berørt. Efter genopbygningen er de tabt.
Hvad er mest presserende ved sikringen?
Flygtige data som kørende processer, netværksforbindelser og loggede ind brugere forsvinder ved nedlukning. De noteres først. Derefter følger logs, et aftryk af systemet og data fra forudgående tjenester.
Er en almindelig backup nok som bevissikring?
Som regel ikke. Mange backups indeholder ingen logs, ingen systemfiler og ingen metadata som tidsstempler og ejere. Til bevissikring har I brug for en fuldstændig, uændret kopi med kontrolsum, ideelt et snapshot eller et aftryk af datamediet.
Må jeg tage serveren af nettet før sikringen?
Ja, hvis den fortsat kører. En adskillelse fra nettet standser dataudstrømning og fjernstyring uden at ødelægge flygtige spor. En genstart eller slukning sletter derimod arbejdshukommelsen og de kørende processer.