Röviden: Egy IT-incidens idővonala időrendben, egységes időzónában, ideális esetben UTC-ben rendezi az összes megfigyelést, döntést és intézkedést. Minden sor megnevezi a forrást, a megfigyelést, a bizonyítékot és egy értékelést: igazolt, valószínű vagy ismeretlen. Így követhető kép keletkezik arról, mikor volt a támadó a rendszerben, mit érhetett el, és mikor szerzett Ön tudomást róla.
Miért kérdezi végül mindenki, hogy mikor
Egy incidens után minden irányból érkeznek a kérdések. Az adatvédelmi felelős tudni akarja, mióta voltak elérhetők személyes adatok. A biztosító azt kérdezi, mikor fedezték fel és jelentették a kárt. A vezetés azt szeretné tudni, hogy a rés már az utolsó frissítés előtt is nyitva volt-e. Mindezekben a kérdésekben van egy közös vonás: időpontok körül forognak.
Idővonal nélkül mindenki emlékezetből válaszol, és a válaszok ellentmondanak egymásnak. Egy rendesen vezetett idővonallal van egy közös alap, amelyre minden érintett hivatkozhat. Egyúttal a záró jelentés vázát is adja.
A PHP2Shell esetében az idővonal különösen sokatmondó, mert a nyilvános főbb adatok jól dokumentáltak. Ezek a saját megfigyelések mellé horgonypontként elhelyezhetők. A nyilvános események teljes sorrendjét a PHP2Shell: az időrend útmutató írja le.
A felépítés: milyen oszlopokra van szükség egy idővonalban
Egy táblázat elég, akár táblázatkezelőben, akár közös dokumentumban. Fontosak a rögzített oszlopok, amelyeket minden sorban ki kell tölteni. A következő minta a nyilvános PHP2Shell-főadatokat mutatja horgonyként, alattuk tipikus saját bejegyzések helyőrző formában:
| Idő (UTC) | Forrás | Megfigyelés | Bizonyíték | Értékelés |
|---|---|---|---|---|
| 2026. 10. 17. | Médiabeszámolók | a PHP2Shell elleni első megfigyelt támadási kísérlet | sajtóbeszámoló | igazolt médiabeszámolóként |
| 2026. 10. 20. | php.net | a biztonsági frissítések előzetes bejelentése | közlemény a php.net-en | igazolt |
| 2026. 10. 21., 14:00 | php.net | a 8.5.12, 8.4.27, 8.3.36, 8.2.35 kiadása | közlemény a php.net-en | igazolt |
| saját idő | Access-log | 500-as hibák felhalmozódása normál oldalakon | naplókivonat, sorszám | valószínűleg releváns |
| saját idő | Fájlrendszer | új PHP-fájl a feltöltési mappában | másolat ellenőrző összeggel | igazolt, az időpont bizonytalan |
| saját idő | belső | az incidenst észrevették, a vezetést tájékoztatták | e-mail, beszélgetési jegyzet | igazolt |
| saját idő | belső | a frissítést telepítették, az összes workert újraindították | csomagnapló, folyamatlista | igazolt |
Az Értékelés oszlop a legfontosabb rész. Elválasztja azt, ami bizonyított, attól, ami hihetőnek tűnik, és attól, ami nyitva marad. A későbbi olvasók így azonnal látják, hol bírja az idővonal a terhet, és hol vannak hézagok.
Egy IT-incidens idővonala: a források egyesítése
A bejegyzések sok forrásból származnak, amelyek mindegyikének saját formátuma és időzónája van. Ebben a sorrendben haladjon:
- Az időzóna rögzítése: Mindent UTC-ben vezessen. A 2026. 10. 25-i téli időszámításra való átállás a német helyi időket az időszak közepén egy órával eltolja. Aki helyi időket kever, észrevétlenül eltolja az eseményeket.
- Az órák ellenőrzése: Jól járt a szerver órája? Egy ismert eseménnyel, például a saját bejelentkezéssel való összevetés megmutatja az eltéréseket.
- Először a külső források: A CDN, a WAF, a tárhelyszolgáltató vagy a tűzfal naplói a szerveren kívül vannak, és nehezen manipulálhatók. Ezek adják a vázat.
- A szervernaplók kiegészítése: Webszerver, PHP-FPM, bejelentkezések, rendszernapló. A módszertant a Webszerver-naplók kiértékelése támadás után írja le.
- A fájlrendszer besorolása: Az új és módosított fájlok időbélyegeit támpontként egészítse ki.
- Belső események rögzítése: Mikor vettek észre valamit, kit tájékoztattak, melyik döntés mikor született?
Mit árulnak el a fájlok időbélyegei, és mit nem
A Linux minden fájlhoz több időpontot tárol, többek között a tartalom utolsó módosítását (mtime) és a metaadatok utolsó módosítását (ctime). Mindkettő kiírható olvasással, itt egy adott időpont óta módosított PHP-fájlok listájaként, UTC szerinti idő szerint rendezve:
# Tartalmi módosítások 2026. 10. 17. óta, rendezve, UTC-ben
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Egyetlen fájl összes időbélyege
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Eközben csak egy másolaton vagy mentett lemezképen dolgozzon, ahogyan a Bizonyítékok mentése a szerver újratelepítése előtt cikk leírja. Vegyen figyelembe két korlátot. Először: a támadó egyszerű eszközökkel visszaállíthatja egy fájl módosítási dátumát; egy feltűnésmentes mtime nem felmentés. Másodszor: a másolási műveletek és egyes eszközök módosítják az időbélyegeket. Ezért érvényes: a fájlidők támpontok, a kívülről származó naplóbejegyzések bizonyítékok.
Jegyezze fel azt az időpontot, amikor a vállalkozása tudomást szerzett egy lehetséges adatvédelmi incidensről. A GDPR 33. cikke szerint a bejelentésre vonatkozó 72 órás határidő alapvetően a tudomásszerzéssel kezdődik. Az értékelés az adatvédelmi felelős vagy egy ügyvéd feladata.
Tipikus hibák és hogyan kerülheti el őket
A leggyakoribb hibák nem látványosak. Az idővonalat csak a végén rekonstruálják emlékezetből, ahelyett hogy folyamatosan vezetnék. A bejegyzések következtetéseket tartalmaznak megfigyelések helyett, például „a támadó az űrlapon keresztül jött” ahelyett, hogy „POST-kérés az űrlapra, utána új fájl”. És hiányoznak a bizonyítékok, mert senki sem jegyezte fel, melyik naplófájlból és melyik sorból származik egy bejegyzés.
Ezért jelöljön ki egy személyt, aki az idővonalat vezeti, és az eseményeket akkor jegyezze fel, amikor bekövetkeznek. A következtetések saját oszlopba vagy a jelentésbe valók, nem a megfigyelésbe.
Kezelje az idővonalat bizalmas dokumentumként is. Gyakran tartalmaz IP-címeket, felhasználóneveket és gyenge pontokra utaló jeleket. Határozza meg, ki olvashatja és módosíthatja, és őrizze meg a korábbi állapotokat. Ha egy megítélés megváltozik, például mert felbukkan egy új naplókivonat, a régi sort nem írják felül, hanem kiegészítik. Így követhető marad, hogy mi volt ismert mely időpontban, és milyen alapon döntöttek.
Hogyan segít konkrétan a PHP SOS?
- Az idővonalat az első kapcsolatfelvételtől folyamatosan és UTC-ben vezetjük, minden bejegyzéshez forrással és bizonyítékkal.
- A külső naplókat, a szervernaplókat és a fájlrendszert együtt értékeljük ki, és minden állítást igazoltnak, valószínűnek vagy ismeretlennek jelölünk.
- Szükség esetén specializált partnerekkel átvesszük az IT-forenzikát a bíróságon is felhasználható kiértékeléshez.
- Az idővonalat a vezetésnek, az adatvédelemnek és a biztosításnak szóló jelentés részeként adjuk át.
Gyakori kérdések
Mire kell az idővonal egy biztonsági incidens után?
Sorrendbe rendezi az összes megfigyelést, és megmutatja, mikor volt a támadó a rendszerben, mit érhetett el, és mikor szerzett Ön tudomást róla. Ezekre az adatokra az adatvédelmi felelősöknek, a biztosítóknak, a hatóságoknak és a vezetésnek szüksége van a döntéseikhez.
Melyik időzónában vezessem az idővonalat?
Egységesen UTC-ben. A szerverek, a szolgáltatások és a jelentések különböző időzónákat használnak, az október végi téli időszámításra való átállás pedig a helyi időket még tovább tolja. Aki mindent UTC-re számít át, és a helyi időt csak kiegészítésként adja meg, elkerüli az egyeztetési hibákat.
Megbízhatok a fájlok időbélyegeiben?
Csak korlátozottan. Egy fájl módosítási dátuma egyszerű eszközökkel hamisítható. Megbízhatóbbak a naplóbejegyzések, különösen az érintett szerveren kívüli naplók. A fájlok időbélyegei olyan támpontok, amelyeket más forrásoknak kell megerősíteniük.
Mi tartozik az idővonalba a technikai események mellett?
A döntések és a kommunikáció is: mikor vették észre az incidenst, kit tájékoztattak, mikor vették le a szervert a hálózatról, mikor javítottak. Éppen a tudomásszerzés időpontja fontos a bejelentési határidők szempontjából.