Na kratko: Preden ogrožen strežnik postavite znova, zavarujte dokaze v vrstnem redu njihove hlapnosti: najprej procese, povezave in prijavljene uporabnike, nato dnevnike in konfiguracijo, nato popolno sliko sistema in podatke predhodnih storitev. Vsako zavarovano datoteko opremite s kontrolno vsoto in jo shranite zunaj strežnika. Strežnik pri tem odklopite z omrežja, vendar ga ne izklopite.
Refleks takojšnje ponovne postavitve
Kdor odkrije vdor, ga želi končati čim prej. Svež sistem, čisto nameščen, z novimi gesli: to daje občutek nadzora. Tehnično je ponovna postavitev pogosto tudi pravi korak, zlasti če je imel napadalec pravice root.
Težava je v trenutku. S starim sistemom izginejo vsi odgovori na vprašanja, ki pridejo v naslednjih dneh. Prek katere ranljivosti je napadalec prišel? Od kdaj je bil v sistemu? Ali je imel dostop do podatkov strank? Ali je prizadet tudi strežnik zbirke podatkov zraven? Brez sledi ostanejo samo domneve, te pa ne pomagajo ne pri varstvu podatkov ne pri zavarovalnici.
Po PHP2Shell se pojavi posebna točka: ni objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise). Ali in kako je bil strežnik prizadet, je mogoče razbrati samo iz obnašanja, torej iz prav tistih sledi, ki jih prenagljena ponovna postavitev izbriše. Strokovni tisk svetuje hranjenje dnevnikov strežnika od 20. 10. 2026 dalje.
Zavarovanje dokazov na strežniku: vrstni red je pomemben
Sledi so različno hlapne. Kar je v delovnem pomnilniku, izgine ob naslednjem ponovnem zagonu. Dnevniki preživijo dlje, vendar se rotirajo. Podatki na predhodnih storitvah izginejo po njihovih lastnih rokih. Iz tega izhaja vrstni red:
| Sled | Hlapnost | Kako zavarovati |
|---|---|---|
| Procesi, omrežne povezave, prijavljeni uporabniki | izgine ob ponovnem zagonu | izpise sistemskih ukazov zapišite v datoteke |
| Delovni pomnilnik | izgine ob ponovnem zagonu | samo s posebnim orodjem, naloga za forenzike |
Začasne datoteke v /tmp ali /dev/shm |
ob ponovnem zagonu pogosto izbrisane | skopirajte, ne da bi jih izvedli |
| Dnevniki spletnega strežnika, PHP, sistema | se rotirajo | skopirajte v celoti, ustavite rotacijo |
| Datotečni sistem in zbirka podatkov | stabilno do nove namestitve | posnetek stanja ali slika nosilca, izvoz zbirke podatkov |
| CDN, WAF, požarni zid, gostitelj | hramba po rokih ponudnika | zahtevajte izvoz, dajte si ga pisno potrditi |
Delovni pomnilnik zavarujete samo, če je pripravljen nekdo z ustreznim orodjem in izkušnjami. Pri sistemih z občutljivimi podatki ali predvidljivim pravnim sporom naj to prevzame IT forenzika.
Hlapne podatke zabeležite v nekaj minutah
Naslednji ukazi na sistemu ničesar ne spremenijo. Trenutno stanje zapišejo v datoteke, ki jih nato zavarujete zunaj strežnika. Ciljni imenik po možnosti ustvarite na priključenem, ločenem nosilcu podatkov:
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"
Kako nato dnevnike zavarujete v celoti in jih ovrednotite, opisuje vodnik Ovrednotenje dnevnikov spletnega strežnika po napadu. Pri virtualnih strežnikih je posnetek stanja prek upravljanja pri ponudniku najpreprostejša pot do popolne slike. Zajame sistem, ne da bi morali na ogroženem strežniku zaganjati dodatna orodja.
Da bo zavarovanje pozneje kaj vredno
Zavarovanje je samo toliko vredno kot njegov dokaz. Tri pravila ga naredijo verodostojnega:
- Kontrolne vsote: vsaka zavarovana datoteka dobi kontrolno vsoto SHA-256. S tem je pozneje mogoče pokazati, da je kopija nespremenjena.
- Zapisnik: kdo je kdaj kaj zavaroval, s katerim ukazom, kam? Vsaka predaja tretjim se zabeleži. Strokovnjaki temu pravijo dokazna veriga.
- Ločena hramba: kopije sodijo v sistem, do katerega napadalec ni imel dostopa, in se naprej uporabljajo samo bralno.
Nato delajte samo še s kopijami. Vsaka analiza na originalu spremeni časovne žige in lahko prepiše sledi. Sumljivih datotek nikoli ne izvajajte in jih ne odpirajte prek brskalnika.
Dnevnike CDN, WAF in gostitelja zahtevajte zgodaj. Ti podatki ležijo zunaj vašega strežnika in jih napadalec težko manipulira, vendar se pogosto hranijo samo kratek čas.
Kaj uniči dokazno stanje
Številne sledi ne izgubi napadalec, ampak dobronamerna prva pomoč. Ti koraki naj pred zavarovanjem izostanejo:
- Ponovni zagon ali izklop: procesi, povezave in delovni pomnilnik so nato izgubljeni.
- Protivirusni program z samodejnim brisanjem: datoteke odstrani, preden jih je kdo zavaroval, in spremeni časovne žige.
- Čiščenje dnevnikov ali začasnih map: tudi ko zmanjkuje prostora, najprej skopirajte, nato izbrišite.
- Nameščanje novih orodij z interneta na strežnik: vsaka namestitev piše v datotečni sistem in lahko prekrije sledi.
- Prijava s privilegiranimi poverilnicami brez nuje: če na strežniku še teče škodljiva koda, je mogoče prebrati vnesena gesla.
Zavarovalnice pozneje vprašajo, kaj je bilo kdaj zavarovano. Napotke o tipičnih obveznostih najdete pod Kibernetsko zavarovanje: kaj šteje v primeru škode.
Pretehtajte: koliko časa je na voljo za zavarovanje
Vsak incident ne dopušča dolgega zavarovanja. Če trenutno poteka uhajanje podatkov ali se napadajo obiskovalci, ima prednost zajezitev. Odklop z omrežja ob delujočem sistemu združuje oboje: napadalec izgubi dostop, sledi ostanejo ohranjene. Pri večini spletnih strežnikov zato zadošča pregleden čas za hlapne podatke in posnetek stanja.
Odločitev sprejmite zavestno in jo zabeležite: kdo je odločil, kdaj se postavi znova, in kaj je bilo pred tem zavarovano? Ta zapis je pozneje del časovnice incidenta. Ali je prava pot ponovna postavitev ali čiščenje, osvetljuje prispevek Strežnik postaviti znova ali počistiti?.
Kako PHP SOS pomaga konkretno?
- Hlapne podatke, dnevnike in sistemske slike zavarujemo v pravem vrstnem redu, s kontrolnimi vsotami in zapisnikom.
- Podatke predhodnih storitev zahtevamo, preden potečejo njihovi roki hrambe.
- Po potrebi s specializiranimi partnerji prevzamemo forenzično zavarovanje in ovrednotenje.
- Šele nato strežnik postavimo znova, zapremo vstopno točko in incident dokumentiramo, dokler ni zaključen.
Pogosta vprašanja
Zakaj naj pred ponovno postavitvijo zavarujem dokaze?
Ker samo sledi pokažejo, kako je napadalec prišel noter, kako dolgo je bil v sistemu in do katerih podatkov je lahko dostopal. Te odgovore potrebujete za varstvo podatkov, zavarovalnico in vprašanje, ali so prizadeti še drugi sistemi. Po ponovni postavitvi so izgubljeni.
Kaj je pri zavarovanju najnujnejše?
Hlapni podatki, kot so tekoči procesi, omrežne povezave in prijavljeni uporabniki, ob zaustavitvi izginejo. Zabeležite jih najprej. Sledijo dnevniki, posnetek sistema in podatki predhodnih storitev.
Ali kot zavarovanje dokazov zadošča navadna varnostna kopija?
Običajno ne. Številne varnostne kopije ne vsebujejo dnevnikov, sistemskih datotek in metapodatkov, kot so časovni žigi in lastniki. Za zavarovanje dokazov potrebujete popolno, nespremenjeno kopijo s kontrolno vsoto, idealno posnetek stanja (snapshot) ali sliko nosilca podatkov.
Ali smem strežnik pred zavarovanjem odklopiti z omrežja?
Da, če pri tem še naprej teče. Odklop z omrežja ustavi uhajanje podatkov in daljinsko upravljanje, ne da bi uničil hlapne sledi. Ponovni zagon ali izklop pa izbriše delovni pomnilnik in tekoče procese.