Накратко: ИТ форензиката на сървър отговаря на въпроса какво действително се е случило при една атака: кога, как и с какви последици. Заедно със специализирани партньори по форензика запазваме следите с доказателствена стойност, анализираме логове, файлови системи и бази данни и предоставяме проследим доклад. Той служи като основа за уведомявания, застраховка и при нужда наказателно преследване.
Кога Ви е нужна ИТ форензика за сървъра
Не всеки инцидент се нуждае от форензично разследване. Тя е разумна най-вече когато може да са засегнати лични данни, платежни данни или търговски тайни, когато се очертава сигнал до органите или правен спор или когато застрахователят очаква надеждно доказателство. И при въпроса дали е нужно уведомяване на надзорния орган доказаните факти помагат повече от предположенията.
След PHP2Shell се добавя една особеност. Уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват изпълнение на код без удостоверяване и няма публикувани, потвърдени Indicators of Compromise. Затова дали един сървър е бил засегнат, не може да се отметне с контролен списък, а само чрез анализ на поведението: кои процеси са работили, какви файлове са възникнали, какви връзки са излизали навън? Първи опорни точки дава страницата Вече компрометиран ли съм?.
С какво форензиката се различава от бързото почистване
Почистването иска да направи сървъра отново чист. Форензиката иска да разбере и да докаже. Единият въпрос е „Сигурен ли е сървърът отново?“, другият е „Какво точно се е случило и кои данни са били достижими?“. За уведомяванията, застраховката и информирането на клиентите обикновено решаващ е вторият въпрос. Двете се съвместяват, когато редът е правилен: първо се архивира, после се променя. Който първо изтрие, пачне или рестартира, губи преходни следи и по-късно често не може да покаже какво е видял атакуващият.
Съхранявайте всички сървърни логове от 20.10.2026 г. нататък и помолете хостинг доставчика да не ротира и да не изтрива протоколите. Липсващите логове са най-честата причина за отворени въпроси в доклада.
Кои следи на един PHP уеб сървър имат значение
На един типичен уеб сървър има повече следи, отколкото много оператори предполагат. Дали те са използваеми, зависи от това колко дълго се съхраняват и дали са били архивирани преди намесата.
- Протоколи за достъп и грешки на уеб сървъра и на PHP-FPM, включително сринали се worker процеси
- Файлова система: нови или променени файлове, техните времеви печати и собственици, изпълним код в папките за качвания
- База данни: нови потребителски акаунти, променени настройки, внедрено съдържание
- Система: cron задачи, потребители, SSH ключове, протоколи за влизане, работещи процеси и мрежови връзки
- Предходни системи: протоколи на CDN, WAF, защитна стена, балансьор на натоварването и пощенски сървър
Именно предходните системи често се забравят. Те лежат извън уеб сървъра и затова за атакуващия са по-трудни за манипулиране. При някои доставчици те се пазят само за кратко, затова трябва да ги експортирате рано.
Как помага PHP SOS конкретно?
- Изясняване на поръчката: С Вас определяме на кои въпроси трябва да се отговори, например входен път, период, засегнати данни или придвижване в мрежата. От това става ясно кои системи ще се разследват.
- Запазване с доказателствена стойност: Ние и нашите специализирани партньори създаваме копия на носители, логове, бази данни и, където е възможно, на оперативната памет. Всеки архив получава контролна сума, всяко предаване се документира.
- Анализ: Анализираме протоколите за достъп и грешки, промените във файловете, потребителските акаунти, cron задачите, процесите и изходящите връзки. Методиката за логове описва страницата Анализ на логовете на уеб сървъра след атака.
- Изготвяне на времева линия: От находките възниква времева линия на инцидента, в която всяко твърдение сочи конкретно доказателство.
- Предаване на доклада: Получавате технически доклад и разбираемо резюме за управителите.
Какво получавате и какво ни е нужно
Докладът съдържа запазените доказателства с контролни суми, документацията на веригата на предаване, времевата линия, установения или вероятния входен път, засегнатите системи и видове данни, както и препоръки. Всяко твърдение е отбелязано като доказано, вероятно или неизвестно.
От Вас ни е нужно:
- достъп до засегнатите системи или съгласие Вашият хостинг доставчик да ни предостави копия
- лице с право да решава, което определя обхвата и приоритетите
- информация за системния пейзаж, доставчиците на услуги и известните промени от последните седмици
- налични протоколи, също от защитни стени, CDN, WAF или пощенски сървъри
- уточнение дали застраховател, полиция или адвокат вече са включени
Ако искате да подадете сигнал, ще намерите бележки на страницата Подаване на сигнал: Централни звена за контакт по киберпрестъпления. Какво застрахователите обикновено очакват при щета, обяснява страницата Киберзастраховка: какво има значение при щета.
Какво не обещаваме
Форензиката може да анализира само това, което има като следи. Ако логовете липсват, са презаписани или са манипулирани от атакуващия, остават пропуски и ние ги назоваваме. Не обещаваме, че един съд ще оцени нашите резултати по определен начин, и не даваме правна оценка. Не назоваваме извършители, а описваме какво показват следите. И твърдения като „със сигурност не са изтекли данни“ правим само когато доказателствата ги подкрепят.
Ако атаката още продължава, ограничаването има приоритет. Тогава започваме с Incident Response и паралелно запазваме колкото се може повече следи.
Често задавани въпроси
Какво означава запазване на доказателства, годно пред съд?
Следите се запазват така, че по-късно да може да се докаже, че са непроменени. Към това спадат контролни суми, документирана верига на предаване и работа с копия вместо с оригинала. Дали един съд ще използва дадено доказателство, обаче решава самият съд.
Може ли ИТ форензиката да изясни дали са изтекли клиентски данни?
Често може да се стесни до кои данни атакуващият е имал достъп и дали има признаци за изтичане. Сигурно изключване не винаги е възможно, особено когато липсват логове. Затова резултатът се разграничава на доказано, вероятно и неизвестно.
Колко дълго трябва да се съхраняват логовете?
За изясняването колкото е възможно по-дълго, най-малко докато разследването приключи. При PHP2Shell специализираната преса съветва да се съхраняват сървърните логове от 20.10.2026 г. нататък. Правните задължения за съхранение и изтриване изяснете с Вашето длъжностно лице по защита на данните.
Мога ли да рестартирам или да пачна сървъра преди форензиката?
Рестартирането заличава преходните следи в оперативната памет, а пачът променя файлове. Ако можете, първо направете архив или говорете накратко с нас. Ако опасността е остра, ограничаването има приоритет и това се документира.