Lühidalt: IT-intsidendi ajajoon seab kõik tähelepanekud, otsused ja meetmed kronoloogilisse järjekorda ühtses ajavööndis, ideaalis UTC-s. Iga rida nimetab allika, tähelepaneku, tõendi ja hinnangu tõendatud, tõenäoline või teadmata. Nii tekib arusaadav pilt sellest, millal ründaja süsteemis oli, mida ta sai saavutada ja millal te sellest teada saite.
Miks lõpuks kõik küsivad, millal
Pärast intsidenti tulevad küsimused igast suunast. Andmekaitsespetsialist tahab teada, millest alates olid isikuandmed kättesaadavad. Kindlustaja küsib, millal kahju avastati ja teatati. Juhtkond soovib teada, kas auk oli avatud juba enne viimast uuendust. Kõigil neil küsimustel on midagi ühist: need keerlevad ajahetkede ümber.
Ajajoonetta vastab igaüks neile küsimustele mälu järgi ja vastused lähevad vastuollu. Korrektselt peetud ajajoonega on olemas ühine alus, millele kõik osalised toetuvad. See on samas ka lõpparuande karkass.
PHP2Shelli puhul on ajajoon eriti kõnekas, sest avalikud põhiandmed on hästi dokumenteeritud. Neid saab kinnituspunktidena enda tähelepanekute kõrvale panna. Avalike sündmuste täieliku jada kirjeldab juhend PHP2Shell: kronoloogia.
Ülesehitus: milliseid veerge ajajoon vajab
Piisab tabelist, olgu see tabelarvutuses või ühises dokumendis. Olulised on kindlad veerud, mis täidetakse iga rea jaoks. Järgnev näidis näitab PHP2Shelli avalikke põhiandmeid kinnituspunktidena ja all tüüpilisi enda kirjeid kohatäidetena:
| Aeg (UTC) | Allikas | Tähelepanek | Tõend | Hinnang |
|---|---|---|---|---|
| 17.10.2026 | meediaaruanded | esimene täheldatud rünnakukatse PHP2Shelli vastu | ajakirjandusaruanne | tõendatud meediaaruandena |
| 20.10.2026 | php.net | turvauuenduste eelteade | teade lehel php.net | tõendatud |
| 21.10.2026, 14:00 | php.net | versioonide 8.5.12, 8.4.27, 8.3.36, 8.2.35 avaldamine | teade lehel php.net | tõendatud |
| oma aeg | Access-Log | vigade 500 sagenemine tavalistel lehtedel | logilõik, reanumber | tõenäoliselt oluline |
| oma aeg | failisüsteem | uus PHP-fail üleslaadimiskaustas | koopia kontrollsummaga | tõendatud, ajahetk ebakindel |
| oma aeg | sisemine | intsident märgati, juhtkonda teavitati | e-kiri, vestluse märge | tõendatud |
| oma aeg | sisemine | uuendus paigaldati, kõik töölised taaskäivitati | paketilogi, protsesside loend | tõendatud |
Veerg Hinnang on kõige olulisem osa. See eristab, mis on tõendatud, mis näib usutav ja mis jääb lahtiseks. Hilisemad lugejad näevad nii kohe, kus ajajoon kannab ja kus on lüngad.
IT-intsidendi ajajoon: allikate ühendamine
Kirjed pärinevad paljudest allikatest, millest igaühel on oma vormingud ja ajavööndid. Toimige selles järjekorras:
- Määrake ajavöönd: pidage kõike UTC-s. Talveajale üleminek 25.10.2026 nihutab Saksamaa kohalikke aegu vaadeldaval ajavahemikul keset perioodi ühe tunni võrra. Kes kohalikke aegu segab, nihutab sündmusi märkamatult.
- Kontrollige kellasid: kas serveri kell käis õigesti? Võrdlus teadaoleva sündmusega, näiteks oma sisselogimisega, näitab kõrvalekaldeid.
- Välised allikad esimesena: CDN-i, WAF-i, majutaja või tulemüüri logid asuvad serverist väljaspool ja neid on raske manipuleerida. Need moodustavad karkassi.
- Täiendage serveri logidega: veebiserver, PHP-FPM, sisselogimised, süsteemipäevik. Metoodikat kirjeldab Veebiserveri logide analüüs pärast rünnakut.
- Paigutage failisüsteem: lisage uute ja muudetud failide ajatemplid vihjetena.
- Kandke sisse sisemised sündmused: millal midagi märgati, keda teavitati, milline otsus langetati millal?
Mida failide ajatemplid reedavad ja mida mitte
Linux salvestab iga faili kohta mitu ajahetke, muu hulgas sisu viimase muutmise (mtime) ja metaandmete viimase muutmise (ctime). Mõlemad saab lugevalt välja anda, siin kontrollpäevast alates muudetud PHP-failide loendina, sorteeritud aja järgi UTC-s:
# Sisumuudatused alates 17.10.2026, sorteeritud, UTC-s
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Ühe faili kõik ajatemplid
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Töötage seejuures ainult koopial või kindlustatud kujutisel, nagu on kirjeldatud artiklis Kindlustage tõendid enne serveri uuesti seadistamist. Arvestage kahe piiranguga. Esiteks võib ründaja faili muutmiskuupäeva lihtsate vahenditega tagasi seada; märkamatu mtime ei ole õigeksmõistmine. Teiseks muudavad kopeerimistoimingud ja mõned tööriistad ajatempleid. Seetõttu kehtib: failide ajad on vihjed, väljastpoolt pärit logikirjed on tõendid.
Kandke sisse ajahetk, mil teie ettevõte võimalikust andmerikkest teada sai. GDPR art. 33 järgi algab teavitamise 72-tunnine tähtaeg põhimõtteliselt teadasaamisest. Hinnang kuulub teie andmekaitsespetsialistile või juristile.
Tüüpilised vead ja kuidas neid vältida
Kõige sagedasemad vead on märkamatud. Ajajoon rekonstrueeritakse alles lõpus mälu järgi, selle asemel et seda jooksvalt pidada. Kirjed sisaldavad järeldusi tähelepanekute asemel, näiteks „ründaja tuli vormi kaudu“ asemel „POST-päring vormile, seejärel uus fail“. Ja tõendid puuduvad, sest keegi ei märkinud, millisest logifailist ja millisest reast kirje pärineb.
Määrake seetõttu üks isik, kes ajajoont peab, ning kandke sündmused sisse niipea, kui need toimuvad. Järeldused kuuluvad eraldi veergu või aruandesse, mitte tähelepanekusse.
Käsitlege ajajoont lisaks konfidentsiaalse dokumendina. See sisaldab sageli IP-aadresse, kasutajanimesid ja vihjeid nõrkustele. Määrake, kes tohib seda lugeda ja muuta, ning säilitage varasemad seisud. Kui hinnang muutub, näiteks uue logilõigu ilmumise tõttu, ei kirjutata vana rida üle, vaid seda täiendatakse. Nii jääb arusaadavaks, mis oli millal teada ja mille alusel otsustati.
Kuidas PHP SOS konkreetselt aitab?
- Peame ajajoont alates esimesest kontaktist jooksvalt ja UTC-s, iga kirje juures allika ja tõendiga.
- Analüüsime väliseid logisid, serverilogisid ja failisüsteemi koos ning märgime iga väite tõendatud, tõenäoline või teadmata.
- Vajaduse korral teeme koos spetsialiseerunud partneritega IT-kohtuekspertiisi kohtus kasutatava analüüsi jaoks.
- Anname ajajoone üle osana aruandest juhtkonnale, andmekaitsele ja kindlustusele.
Korduma kippuvad küsimused
Milleks on mul pärast turvaintsidenti ajajoont vaja?
See paneb kõik tähelepanekud järjekorda ja näitab, millal ründaja süsteemis oli, mida ta sai saavutada ja millal te sellest teada saite. Neid andmeid vajavad otsuste tegemiseks andmekaitsespetsialistid, kindlustajad, ametiasutused ja juhtkond.
Millises ajavööndis peaksin ajajoont pidama?
Ühtselt UTC-s. Serverid, teenused ja teated kasutavad erinevaid ajavööndeid ning oktoobri lõpus talveajale üleminek nihutab kohalikke aegu lisaks. Kes arvutab kõik UTC-sse ja lisab kohaliku aja vaid täiendusena, väldib võrdlemisel vigu.
Kas võin failide ajatemplitele loota?
Ainult piiratult. Faili muutmiskuupäeva saab lihtsate vahenditega võltsida. Usaldusväärsemad on logikirjed, eriti mõjutatud serverist väljaspool asuvad logid. Failide ajatemplid on vihjed, mida tuleks teiste allikatega kinnitada.
Mis kuulub peale tehniliste sündmuste ajajoonele?
Ka otsused ja suhtlus: millal intsident märgati, keda teavitati, millal server võrgust lahti ühendati, millal paigati. Just teadasaamise ajahetk on teavitustähtaegade jaoks oluline.