# Egy incidens idővonalának elkészítése

> IT-incidens idővonalának elkészítése: források és időzónák helyes használata, az állítások minősítése igazoltnak, valószínűnek vagy ismeretlennek.

Forrás: https://phpsos.de/hu/blog/zeitleiste-eines-vorfalls/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/ratgeber/php2shell-chronologie/) ú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:

1. **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.
2. **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.
3. **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.
4. **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](https://phpsos.de/hu/ratgeber/logfiles-auswerten/) írja le.
5. **A fájlrendszer besorolása:** Az új és módosított fájlok időbélyegeit támpontként egészítse ki.
6. **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:

```bash
# 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](https://phpsos.de/hu/blog/beweise-sichern-vor-neuinstallation/) 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.

> **Fontos:**
> 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](https://phpsos.de/hu/leistungen/it-forensik/) 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.

## Források

- [php.net: PHP2Shell biztonsági közlemények](https://www.php.net/)
- [GDPR 33. cikk: bejelentés a felügyeleti hatóságnak](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI (a német Szövetségi Információbiztonsági Hivatal): tudnivalók IT-biztonsági incidensekhez](https://www.bsi.bund.de/)