Накратко: Времевата линия на един ИТ инцидент подрежда хронологично всички наблюдения, решения и мерки в единна часова зона, в идеалния случай UTC. Всеки ред посочва източник, наблюдение, доказателство и оценка като доказано, вероятно или неизвестно. Така се получава проследима картина кога нападателят е бил в системата, какво е могъл да постигне и кога сте узнали за това.
Защо накрая всички питат кога
След инцидент въпросите идват от всички страни. Длъжностното лице по защита на данните иска да знае от кога лични данни са били достъпни. Застрахователят пита кога е открита и обявена щетата. Ръководството иска да знае дали уязвимостта е била отворена още преди последната актуализация. Всички тези въпроси имат нещо общо: въртят се около моменти във времето.
Без времева линия всеки отговаря на тези въпроси по памет и отговорите си противоречат. С добре водена времева линия има обща основа, на която се позовават всички участници. Тя е и скелетът на заключителния отчет.
При PHP2Shell времевата линия е особено показателна, защото публичните основни данни са добре документирани. Те могат да се поставят като опорни точки до собствените Ви наблюдения. Пълната последователност на публичните събития описва ръководството PHP2Shell: хронологията.
Структурата: какви колони са нужни на една времева линия
Достатъчна е една таблица, в електронна таблица или в споделен документ. Важни са фиксираните колони, които се попълват за всеки ред. Следният образец показва публичните основни данни за PHP2Shell като опорни точки, а под тях типични собствени записи във вид на заместители:
| Време (UTC) | Източник | Наблюдение | Доказателство | Оценка |
|---|---|---|---|---|
| 17.10.2026 | медийни съобщения | първи наблюдаван опит за атака чрез PHP2Shell | журналистическа публикация | доказано като медийно съобщение |
| 20.10.2026 | php.net | предварително съобщение за актуализациите за сигурност | съобщение на php.net | доказано |
| 21.10.2026, 14:00 | php.net | публикуване на 8.5.12, 8.4.27, 8.3.36, 8.2.35 | съобщение на php.net | доказано |
| собствено време | Access лог | струпване на грешки 500 при нормални страници | откъс от лог, номер на ред | вероятно релевантно |
| собствено време | файлова система | нов PHP файл в папката за качване | копие с контролна сума | доказано, моментът е несигурен |
| собствено време | вътрешно | инцидентът е забелязан, ръководството е информирано | имейл, бележка от разговор | доказано |
| собствено време | вътрешно | актуализацията е инсталирана, всички worker процеси са рестартирани | лог на пакетите, списък с процеси | доказано |
Колоната Оценка е най-важната част. Тя разделя какво е доказано, какво изглежда правдоподобно и какво остава открито. По-късните читатели веднага виждат къде времевата линия е стабилна и къде има празнини.
Времева линия на ИТ инцидент: обединяване на източниците
Записите идват от много източници, всеки със собствени формати и часови зони. Действайте в този ред:
- Определете часовата зона: водете всичко в UTC. Преминаването към зимно часово време на 25.10.2026 г. измества германското местно време с един час насред периода. Който смесва местни времена, измества събития незабелязано.
- Проверете часовниците: точен ли е бил часовникът на сървъра? Сравнение с известно събитие, например с Вашия собствен вход, показва отклонения.
- Външните източници първи: логовете на CDN, WAF, хостинг доставчика или защитната стена са извън сървъра и трудно се манипулират. Те образуват скелета.
- Допълнете със сървърните логове: уеб сървър, PHP-FPM, влизания, системен журнал. Методиката за това описва Анализ на логовете на уеб сървъра след атака.
- Подредете файловата система: добавете времевите печати на нови и променени файлове като насоки.
- Въведете вътрешните събития: кога е забелязано нещо, кой е информиран, кое решение кога е взето?
Какво издават времевите печати на файловете и какво не
Linux съхранява за всеки файл няколко момента, между другото последната промяна на съдържанието (mtime) и последната промяна на метаданните (ctime). И двата могат да се изведат само за четене, тук като списък на PHP файловете, променени след определена дата, сортиран по време в UTC:
# Промени на съдържанието от 17.10.2026, сортирани, в UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Всички времеви печати на един файл
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Работете при това само върху копие или запазен образ, както е описано в Запазете доказателствата, преди да преинсталирате. Имайте предвид две граници. Първо, нападателят може да върне датата на промяна на файл с прости средства; незабележима mtime не е оправдание. Второ, процесите на копиране и някои инструменти променят времевите печати. Затова важи: времената на файловете са насоки, записите в логове отвън са доказателства.
Запишете момента, в който Вашата фирма е узнала за възможно нарушение на сигурността на данните. Според чл. 33 от ОРЗД 72-часовият срок за уведомяване по принцип започва с узнаването. Оценката е работа на Вашето длъжностно лице по защита на данните или на адвокат.
Типични грешки и как да ги избегнете
Най-честите грешки не са впечатляващи. Времевата линия се възстановява от паметта едва накрая, вместо да се води текущо. Записите съдържат изводи вместо наблюдения, например „нападателят дойде през формуляра" вместо „POST заявка към формуляра, след това нов файл". А доказателствата липсват, защото никой не е отбелязал от кой лог файл и кой ред идва даден запис.
Затова определете човек, който води времевата линия, и въвеждайте събитията веднага щом възникнат. Изводите принадлежат в отделна колона или в отчета, не в наблюдението.
Освен това третирайте времевата линия като поверителен документ. Тя често съдържа IP адреси, потребителски имена и указания за слабости. Определете кой може да я чете и променя и пазете по-ранните версии. Когато една оценка се промени, например защото се появи нов откъс от лог, старият ред не се презаписва, а се допълва. Така остава проследимо какво е било известно в кой момент и на каква основа е взето решение.
Как помага PHP SOS конкретно?
- Водим времевата линия от първия контакт текущо и в UTC, с източник и доказателство за всеки запис.
- Анализираме заедно външните логове, сървърните логове и файловата система и отбелязваме всяко твърдение като доказано, вероятно или неизвестно.
- При нужда със специализирани партньори поемаме ИТ форензиката за анализ, годен пред съд.
- Предаваме времевата линия като част от отчет за ръководството, защитата на данните и застрахователя.
Често задавани въпроси
За какво ми е времева линия след инцидент със сигурността?
Тя подрежда всички наблюдения в последователност и показва кога нападателят е бил в системата, какво е могъл да постигне и кога сте разбрали за това. Тези данни са нужни на длъжностните лица по защита на данните, на застрахователите, на органите и на ръководството за техните решения.
В коя часова зона да водя времевата линия?
Еднообразно в UTC. Сървърите, услугите и съобщенията използват различни часови зони, а преминаването към зимно часово време в края на октомври допълнително измества местното време. Който преобразува всичко в UTC и добавя местното време само като допълнение, избягва грешки при сравняването.
Мога ли да се доверявам на времевите печати на файловете?
Само ограничено. Датата на промяна на един файл може да се фалшифицира с прости средства. По-надеждни са записите в логовете, особено в логове извън засегнатия сървър. Времевите печати на файловете са насоки, които трябва да се потвърдят от други източници.
Какво освен техническите събития влиза във времевата линия?
Също решения и комуникация: кога е забелязан инцидентът, кой е информиран, кога сървърът е изключен от мрежата, кога е поставен пач. Именно моментът на узнаването е важен за сроковете за уведомяване.