# Реагиране при инциденти (Incident Response) при атаки на сървъри

> Реагиране при инциденти (Incident Response) при атаки на сървъри: поемаме триажа, ограничаването, почистването и възстановяването с ясни роли и документиран ход.

Източник: https://phpsos.de/bg/leistungen/incident-response/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Когато една атака засяга повече от един уебсайт, Ви е нужен доставчик на услуги за Incident Response, който обработва инцидента структурирано. Ние поемаме картината на положението, ограничаването, почистването и сигурното възстановяване, с ясни роли и безпропускова документация. Вие запазвате решенията, ние осигуряваме техническата основа.

## Какво означава Incident Response при атаки на сървъри

Incident Response е подредената обработка на инцидент със сигурността. Вместо трескави единични действия работата следва твърди фази: разпознаване и класифициране, ограничаване, отстраняване, възстановяване, последваща работа. Всяка мярка се записва с момент и обосновка.

Особено при уеб сървърите това е важно. Сървър с PHP приложения често съдържа данни за достъп до бази данни, платежни доставчици, пощенски сървъри и интерфейси. Който е проникнал там, може да се придвижи нататък. Положението след PHP2Shell показва колко бързо може да възникне такава ситуация: изпълнение на код без удостоверяване, над 22,6 милиона изложени на риск инстанции според Unit 42 и никакви публикувани, потвърдени Indicators of Compromise.

## Кога Ви е нужен доставчик на услуги за Incident Response

- засегнати са или може да са засегнати няколко сървъра или приложения
- има съмнение, че са изтекли лични данни или платежни данни
- атакуващият може още да е активен, например чрез текущи връзки или нови акаунти
- има изнудване или публично обявяване на атаката
- застраховател, органи или бизнес партньори очакват документиран ход

При един-единствен заразен уебсайт често е достатъчна [спешната помощ при хакнат уебсайт](https://phpsos.de/bg/leistungen/website-gehackt-notfallhilfe/). Прехода към пълна обработка на инцидента обсъждаме с Вас, щом се очертае по-голям мащаб.

## Как помага PHP SOS конкретно?

1. **Триаж и картина на положението:** Изясняваме какво е наблюдавано, кои системи и данни може да са засегнати и кой вътрешно трябва да бъде включен. Резултатът е първа, писмена картина на положението с отворените въпроси.
2. **Запазване на следите и ограничаване:** Логовете, файловите системи и базите данни се архивират, преди да се намесим. След това изолираме засегнатите системи, блокираме компрометираните достъпи и прекъсваме разпознаваемите връзки на атакуващия.
3. **Отстраняване:** Затваряме входния път, например чрез пачване до поправените PHP версии и рестартиране на всички worker процеси, премахваме задните вратички и сменяме тайните. За детайлния анализ при нужда включваме специализирани партньори за [ИТ форензика](https://phpsos.de/bg/leistungen/it-forensik/).
4. **Възстановяване:** Системите се връщат в работа контролирано, по възможност от чисти източници или на наново настроени сървъри. След това ги наблюдаваме засилено за нови аномалии.
5. **Последваща работа:** Получавате заключителен доклад с времева линия, причини, мерки и препоръки. Заедно записваме какво трябва да върви по-бързо следващия път.

> **Действайте веднага:**
> Запазете сървърните логове и не променяйте системите, преди да е направен архив. При PHP2Shell BSI препоръчва уеб сървърите, които не могат да бъдат пачнати веднага, да се изключат временно от мрежата.

## Роли и комуникация по време на инцидента

Един инцидент се нуждае от ясни отговорности. Доказал се е малък кръг от лице с право да решава, технически човек за контакт от Ваша страна и ние като техническо ръководство. Оперативките се провеждат през определени интервали, резултатите се записват писмено.

Паралелно текат задачи, които не поемаме, но за които предоставяме факти: проверката на [задължение за уведомяване по ОРЗД в рамките на 72 часа](https://phpsos.de/bg/compliance/dsgvo-meldepflicht-72-stunden/), информирането на застрахователя, евентуален сигнал до органите и [кризисната комуникация](https://phpsos.de/bg/compliance/krisenkommunikation/) към клиенти и партньори.

## Какво ни е нужно от Вас и какво получавате

Нужни са ни административни достъпи до засегнатите системи, преглед на инфраструктурата и на доставчиците на услуги, лице с право да решава и готовност при нужда системите да се изключат временно. Полезни са налични планове за спешни случаи, мрежови скици и архиви с дата.

Получавате текущ протокол на инцидента, редовни картини на положението на разбираем език, заключителен доклад за управителите, длъжностното лице по защита на данните и застрахователя, както и приоритизиран списък с подобрения. Как да се подготвите по-добре за следващия инцидент, описва страницата [Изготвяне на ИТ план за спешни случаи за уеб сървъри](https://phpsos.de/bg/compliance/notfallplan-erstellen/).

## Типични грешки през първите часове

Много инциденти се влошават, защото в напрежението добронамерени стъпки се правят в грешен ред. Тези модели виждаме често:

- **Незабавно ново настройване:** Сървърът се изтрива и инсталира наново, преди да е направен архив. След това вече не може да се изясни дали са изтекли данни.
- **Смяна на пароли от заразената система:** Ако атакуващият още има достъп, той вижда и новите пароли.
- **Изтриване само на видимия файл:** Уеб шелът е изчезнал, но втората задна вратичка в cron задачата остава.
- **Пачване без рестартиране:** Новите PHP файлове лежат на диска, а старите worker процеси продължават да работят в паметта.
- **Никой не води протокол:** По-късно никой не знае кой кога какво е променил. Това затруднява разговорите със застраховател и органи.

Съгласуваният ход предотвратява тези грешки, без да забавя ограничаването.

## Какво не обещаваме

Не обещаваме, че всеки инцидент ще бъде изяснен изцяло; без следи остават въпроси и така го пишем в доклада. Не даваме правни консултации и изявления за отговорност или застрахователна защита. Целта ни е ясен край: работим по инцидента, докато той бъде приключен и документиран.


## Често задавани въпроси

**Каква е разликата между Incident Response и ИТ форензика?**  
Incident Response има за цел да ограничи инцидента и да възстанови работата по сигурен начин. ИТ форензиката изяснява детайлно и с доказателствена стойност какво се е случило. На практика двете се преплитат, а форензиката често запазва следите паралелно.

**Кога да привлека доставчик на услуги за Incident Response?**  
Веднага щом има съмнение, че атакуващ е имал достъп до системи и не можете да прецените сигурно мащаба. Колкото по-рано започне запазването на следите, толкова повече може да се докаже по-късно.

**Кой взема решенията по време на инцидента?**  
Решенията вземате Вие, например за изключвания, комуникация или уведомявания. Ние подготвяме техническите основи, показваме вариантите с последиците им и изпълняваме решенията.

**Трябва ли да уведомя полицията?**  
Подаването на сигнал в много случаи е разумно и за някои застрахователи е от значение. За това са компетентни Централните звена за контакт по киберпрестъпления (Zentrale Ansprechstellen Cybercrime) на германската полиция. Дали и кога да подадете сигнал, решавате заедно с Вашия адвокат.

## Източници

- [BSI: Федерална служба за информационна сигурност](https://www.bsi.bund.de/)
- [ОРЗД чл. 33: Уведомяване на надзорния орган](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Полиция: Централни звена за контакт по киберпрестъпления](https://www.polizei.de/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)