Na kratko: Časovnica IT incidenta kronološko uredi vsa opažanja, odločitve in ukrepe v enotnem časovnem pasu, idealno UTC. Vsaka vrstica navaja vir, opažanje, dokaz in oceno kot dokazano, verjetno ali neznano. Tako nastane sledljiva slika o tem, kdaj je bil napadalec v sistemu, kaj je lahko dosegel in kdaj ste za to vedeli.
Zakaj na koncu vsi vprašajo po času
Po incidentu pridejo vprašanja z vseh strani. Pooblaščenec za varstvo podatkov želi vedeti, od kdaj so bili osebni podatki dosegljivi. Zavarovalnica vpraša, kdaj je bila škoda odkrita in prijavljena. Vodstvo želi vedeti, ali je bila ranljivost odprta že pred zadnjo posodobitvijo. Vsa ta vprašanja imajo nekaj skupnega: vrtijo se okoli časovnih točk.
Brez časovnice vsak na ta vprašanja odgovarja po spominu, odgovori pa si nasprotujejo. Z urejeno vodeno časovnico obstaja skupna podlaga, na katero se sklicujejo vsi udeleženci. Hkrati je ogrodje za zaključno poročilo.
Pri PHP2Shell je časovnica še posebej zgovorna, ker so javni ključni podatki dobro dokumentirani. Lahko jih postavite kot sidrne točke ob lastna opažanja. Celotno zaporedje javnih dogodkov opisuje vodnik PHP2Shell: kronologija.
Zgradba: katere stolpce časovnica potrebuje
Zadošča tabela, bodisi v preglednici bodisi v skupnem dokumentu. Pomembni so stalni stolpci, ki se izpolnijo za vsako vrstico. Naslednji vzorec prikazuje javne ključne podatke o PHP2Shell kot sidra in pod njimi tipične lastne vnose v obliki ograd:
| Čas (UTC) | Vir | Opažanje | Dokaz | Ocena |
|---|---|---|---|---|
| 17. 10. 2026 | poročila medijev | prvi opaženi poskus napada na PHP2Shell | poročilo v tisku | dokazano kot poročilo medijev |
| 20. 10. 2026 | php.net | predhodna napoved varnostnih posodobitev | obvestilo na php.net | dokazano |
| 21. 10. 2026, 14:00 | php.net | objava 8.5.12, 8.4.27, 8.3.36, 8.2.35 | obvestilo na php.net | dokazano |
| lastni čas | dnevnik dostopov | kopičenje napak 500 na običajnih straneh | izsek dnevnika, številka vrstice | verjetno pomembno |
| lastni čas | datotečni sistem | nova datoteka PHP v mapi za nalaganje | kopija s kontrolno vsoto | dokazano, čas negotov |
| lastni čas | interno | incident opažen, vodstvo obveščeno | e-pošta, zapis pogovora | dokazano |
| lastni čas | interno | posodobitev nameščena, vsi delavci znova zagnani | dnevnik paketov, seznam procesov | dokazano |
Stolpec Ocena je najpomembnejši del. Loči, kaj je dokazano, kaj se zdi verjetno in kaj ostaja odprto. Poznejši bralci tako takoj vidijo, kje časovnica drži in kje so vrzeli.
Časovnica IT incidenta: združevanje virov
Vnosi izvirajo iz številnih virov, ki imajo vsak svoje oblike in časovne pasove. Postopajte v tem vrstnem redu:
- Določite časovni pas: vse vodite v UTC. Prehod na zimski čas 25. 10. 2026 nemške lokalne čase sredi obdobja premakne za eno uro. Kdor meša lokalne čase, neopazno premakne dogodke.
- Preverite ure: ali je ura strežnika šla pravilno? Primerjava z znanim dogodkom, na primer z lastno prijavo, pokaže odstopanja.
- Najprej zunanji viri: dnevniki CDN, WAF, gostitelja ali požarnega zidu ležijo zunaj strežnika in jih je težko manipulirati. Tvorijo ogrodje.
- Dopolnite z dnevniki strežnika: spletni strežnik, PHP-FPM, prijave, sistemski dnevnik. Metodologijo za to opisuje Ovrednotenje dnevnikov spletnega strežnika po napadu.
- Umestite datotečni sistem: časovne žige novih in spremenjenih datotek dodajte kot namige.
- Vnesite interne dogodke: kdaj je bilo kaj opaženo, kdo je bil obveščen, katera odločitev je padla kdaj?
Kaj razkrijejo časovni žigi datotek in česa ne
Linux za vsako datoteko hrani več časovnih točk, med drugim zadnjo spremembo vsebine (mtime) in zadnjo spremembo metapodatkov (ctime). Oba je mogoče izpisati bralno, tu kot seznam datotek PHP, spremenjenih od določenega datuma, razvrščen po času v UTC:
# Spremembe vsebine od 17. 10. 2026, razvrščeno, v UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Vsi časovni žigi ene datoteke
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Pri tem delajte samo na kopiji ali zavarovani sliki, kot je opisano v Zavarujte dokaze, preden strežnik postavite znova. Upoštevajte dve omejitvi. Prvič, napadalec lahko datum spremembe datoteke s preprostimi sredstvi ponastavi; neopazen mtime ni oprostitev. Drugič, postopki kopiranja in nekatera orodja časovne žige spremenijo. Zato velja: časi datotek so namigi, vnosi v dnevnikih od zunaj so dokazi.
Vnesite trenutek, ko je vaše podjetje izvedelo za morebitno kršitev varstva podatkov. Po členu 33 GDPR se 72-urni rok za prijavo praviloma začne z vedenjem. Presoja sodi k vašemu pooblaščencu za varstvo podatkov ali odvetniku.
Tipične napake in kako se jim izognete
Najpogostejše napake niso spektakularne. Časovnica se na koncu rekonstruira po spominu, namesto da bi se vodila sproti. Vnosi vsebujejo sklepe namesto opažanj, na primer „napadalec je prišel prek obrazca“ namesto „zahteva POST na obrazec, nato nova datoteka“. In dokazi manjkajo, ker nihče ni zapisal, iz katere datoteke dnevnika in katere vrstice vnos izvira.
Zato določite osebo, ki časovnico vodi, in dogodke vnašajte, takoj ko nastopijo. Sklepi sodijo v svoj stolpec ali v poročilo, ne v opažanje.
Časovnico obravnavajte tudi kot zaupen dokument. Pogosto vsebuje naslove IP, uporabniška imena in namige na šibke točke. Določite, kdo jo sme brati in spreminjati, in hranite prejšnja stanja. Če se ocena spremeni, na primer zaradi novega izseka dnevnika, se stara vrstica ne prepiše, ampak dopolni. Tako ostane sledljivo, kaj je bilo v katerem trenutku znano in na kakšni podlagi je bilo odločeno.
Kako PHP SOS pomaga konkretno?
- Časovnico vodimo od prvega stika sproti in v UTC, z virom in dokazom pri vsakem vnosu.
- Zunanje dnevnike, dnevnike strežnika in datotečni sistem ovrednotimo skupaj ter vsako trditev označimo kot dokazano, verjetno ali neznano.
- Po potrebi s specializiranimi partnerji prevzamemo IT forenziko za ovrednotenje, uporabno pred sodiščem.
- Časovnico predamo kot del poročila za vodstvo, varstvo podatkov in zavarovalnico.
Pogosta vprašanja
Čemu potrebujem časovnico po varnostnem incidentu?
Vsa opažanja uredi v zaporedje in pokaže, kdaj je bil napadalec v sistemu, kaj je lahko dosegel in kdaj ste to izvedeli. Te podatke za svoje odločitve potrebujejo pooblaščenci za varstvo podatkov, zavarovalnice, organi in vodstvo.
V katerem časovnem pasu naj vodim časovnico?
Enotno v UTC. Strežniki, storitve in obvestila uporabljajo različne časovne pasove, prehod na zimski čas konec oktobra pa lokalne čase dodatno premakne. Kdor vse preračuna v UTC in lokalni čas samo doda, se izogne napakam pri primerjavi.
Ali se lahko zanesem na časovne žige datotek?
Samo omejeno. Datum spremembe datoteke je mogoče s preprostimi sredstvi ponarediti. Zanesljivejši so vnosi v dnevnikih, zlasti v dnevnikih zunaj prizadetega strežnika. Časovni žigi datotek so namigi, ki jih je treba potrditi z drugimi viri.
Kaj sodi v časovnico poleg tehničnih dogodkov?
Tudi odločitve in komunikacija: kdaj je bil incident opažen, kdo je bil obveščen, kdaj je strežnik šel z omrežja, kdaj je bil nameščen popravek. Prav trenutek, ko ste izvedeli, je pomemben za roke obveščanja.