# Контролен списък след хакване: 20 точки за последващите действия

> Контролен списък при хакнат уебсайт: 20 точки от ограничаване и запазване на доказателства през почистване и нови достъпи до задължения за уведомяване.

Източник: https://phpsos.de/bg/ratgeber/checkliste-nach-dem-hack/  
Актуалност: 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

**Накратко:** Ако уебсайтът Ви е хакнат, този контролен списък помага да не забравите нищо: първо ограничаване и запазване на доказателства, после намиране на причината и почистване, след това подновяване на всички достъпи, проверка на задълженията и документирано приключване на инцидента. Редът е важен, защото който първо изтрива, губи следи, а който само почиства, без да затвори уязвимостта, бива атакуван отново.

## За какво важи този контролен списък, когато уебсайтът е хакнат

Контролният списък е насочен към ръководството, собствениците и ИТ отговорниците след потвърдена или вероятна атака срещу уебсайт, магазин или PHP уеб сървър. Подходящ е и след PHP2Shell, когато сървър е бил достъпен преди актуализацията и има указания за компрометиране.

Не всяка точка пасва на всяка среда. Все пак преминете през списъка изцяло и отбележете при всяка точка дали е изпълнена, неприложима или открита. Този протокол по-късно е ценен за застраховката, защитата на данните и вътрешния разбор.

Записвайте за всяка стъпка дата, час, отговорно лице и резултат. Ако участват няколко лица, определете едно лице, което води списъка и фиксира решенията.

## Фаза 1: Незабавно ограничаване и запазване

1. **Ограничете щетите:** Преминете уебсайта в режим на поддръжка или го изключете от мрежата, ако посетителите са застрашени или могат да изтичат данни. BSI (Федералната служба за информационна сигурност на Германия) препоръчва при PHP2Shell непачнатите уеб сървъри да се изключват временно от мрежата, ако актуализацията не е възможна веднага.
2. **Не изтривайте нищо:** Не премахвайте файлове, не инсталирайте сървъра наново и не изчиствайте логове, преди следите да са запазени.
3. **Запазете логовете:** Копирайте access, error, PHP-FPM и системните логове на друга система и запазете контролните суми. За PHP2Shell специализираната преса съветва логовете да се пазят от 20.10.2026.
4. **Запазете образ:** Създайте копие на файловете и на базата данни, а при виртуални сървъри snapshot, като доказателствено състояние и не го променяйте.
5. **Информирайте отговорните лица:** Включете рано ръководството, длъжностното лице по защита на данните, хостинг доставчика и, ако има такава, киберзастраховката. Много застраховки имат задължения за уведомяване.

## Фаза 2: Намиране на причината и почистване

6. **Установете входната врата:** Анализирайте логове, промени във файлове и версии. Проверете самия PHP, CMS, теми, разширения, данни за достъп и услуги на сървъра. Без позната причина рискът от нова атака остава.
7. **Затворете уязвимостта:** Приведете PHP до поправена версия (8.5.12, 8.4.27, 8.3.36 или 8.2.35, респективно потвърден backport от доставчика), актуализирайте CMS и разширения, рестартирайте всички PHP worker процеси.
8. **Ограничете периода:** Определете най-ранния момент на подозрителна активност. Той решава кои резервни копия могат да са чисти и кои данни може да са засегнати.
9. **Премахнете задните вратички:** Проверете и премахнете уеб шелове, чужди PHP файлове в директориите за качвания и кеш, променени основни файлове, cron задачи, SSH ключове и системни услуги. Заменете основните файлове от чист източник.
10. **Почистете базата данни:** Премахнете непознати администраторски акаунти, внедрени скриптове в съдържанието и настройките, както и спам съдържание.
11. **Обмислете ново изграждане:** При дълбоко компрометиране на сървъра ново изграждане върху свежа, пачната система с проверени данни често е по-надеждният път от почистване в работещата система.

## Фаза 3: Подновяване на достъпите и заздравяване

12. **Сменете паролите:** За CMS, хостинг акаунт, панел, база данни, FTP, SFTP, SSH и имейл, и то от чисто устройство.
13. **Заменете ключовете и токените:** Генерирайте наново API ключове, интерфейси към услуги за плащане и доставка, ключове на приложението на CMS, SSH ключове и сертификати, които са били на сървъра.
14. **Прекратете сесиите:** Отпишете всички активни влизания в CMS и в услугите и проверете регистрираните устройства за двуфакторно удостоверяване.
15. **Активирайте двуфакторно удостоверяване:** За всички администраторски достъпи, включително хостинг, домейн и DNS.
16. **Заздравете сървъра:** Проверете и документирайте настройките на PHP, правата за файлове, забраните за изпълнение в директориите за качвания, firewall-а и хедърите за сигурност.

## Фаза 4: Задължения, комуникация и приключване

17. **Проверете задълженията за уведомяване:** Ако може да са засегнати лични данни, може да е необходимо [уведомяване по чл. 33 ОРЗД в рамките на 72 часа](https://phpsos.de/bg/compliance/dsgvo-meldepflicht-72-stunden/). Оценката е работа на длъжностното лице по защита на данните или на адвокат. Задълженията по бранш, например по NIS2, проверете отделно.
18. **Обмислете подаване на сигнал:** [Централните контактни пунктове за киберпрестъпност (Zentrale Ansprechstellen Cybercrime, ZAC)](https://phpsos.de/bg/compliance/anzeige-polizei-zac/) на германската полиция приемат сигнали от фирми. Запазените логове са важна основа за това.
19. **Информирайте клиентите и Google:** Информирайте засегнатите обективно и съгласувано. Ако Google показва предупреждение, поискайте повторна проверка след почистването, както е описано в [Премахване на предупреждението на Google](https://phpsos.de/bg/ratgeber/google-warnung-entfernen/).
20. **Документирайте приключването и наблюдавайте:** Запишете причината, периода, мерките и откритите точки в доклад, изведете поуки за плана за аварийни ситуации и наблюдавайте засилено системите през следващите седмици.

## Чести грешки при последващите действия

Много инциденти се проточват, защото в първата тревога се спестява на грешното място или се действа прекалено бързо. Тези грешки трябва да избягвате:

- **Премахване само на видимото:** Изтрита спам страница или премахнато пренасочване не е доказателство за чист уебсайт. Задните вратички често остават незабелязани.
- **Смяна на паролите от засегнатата система:** Ако на компютъра или сървъра още работи зловреден софтуер, новите данни за достъп могат веднага да изтекат отново.
- **Сляпо възстановяване на резервно копие:** Без затворена уязвимост и без проверка на резервното копие атакуващият бързо отново е на вратата.
- **Възприемане на пача като отбой:** Актуализация до поправена версия на PHP не доказва, че преди това нищо не се е случило, и не премахва внедрен зловреден софтуер.
- **Късна проверка на задълженията:** Сроковете започват с узнаването на инцидента, не с края на почистването.
- **Липса на документация:** Без протокол въпросите на застраховка, органи или клиенти по-късно трудно могат да се отговорят.

> **Важно:**
> Този контролен списък не заменя правна консултация. При въпроси за задължения за уведомяване, отговорност или застраховка се обърнете към Вашето длъжностно лице по защита на данните, адвокат или застраховател.

## Как конкретно помага PHP SOS?

- Поемаме структурираното [реагиране при инциденти](https://phpsos.de/bg/leistungen/incident-response/) и водим контролния списък заедно с Вас, точка по точка с протокол.
- Запазваме логовете и състоянията на системата така, че да останат използваеми за застраховка, органи и евентуална [ИТ криминалистика](https://phpsos.de/bg/leistungen/it-forensik/).
- Затваряме уязвимостта, почистваме или изграждаме наново и подновяваме достъпите в правилния ред.
- Предоставяме заключителен доклад с причина, мерки и препоръки и при желание наблюдаваме системите и след това.


## Често задавани въпроси

**Кое е първото, което трябва да направя, ако уебсайтът ми е хакнат?**  
Запазете спокойствие, не изтривайте нищо и ограничете щетите. При нужда изключете уебсайта от мрежата или го преминете в режим на поддръжка и запазете логовете и файловете, преди да почиствате. След това следват търсенето на причината и почистването.

**Достатъчно ли е да възстановя уебсайта от резервно копие?**  
Обикновено не. Резервното копие може вече да съдържа злонамерен код, а уязвимостта, през която е влязъл атакуващият, след възстановяването е още отворена. Първо затворете причината, после внесете проверено, чисто състояние върху актуализирана система.

**Трябва ли да съобщя за хакване на органа по защита на данните?**  
Ако може да са засегнати лични данни, чл. 33 ОРЗД по принцип предвижда уведомяване в рамките на 72 часа след узнаването, освен ако рискът за засегнатите е малко вероятен. Оценката е работа на длъжностното лице по защита на данните или на адвокат.

**Кога един инцидент е наистина приключен?**  
Когато причината е затворена, всички известни задни вратички са премахнати, достъпите са подновени, задълженията са изпълнени и мерките са документирани. Към това спада и период на засилено наблюдение след това, за да се разпознаят пропуснати следи.

## Източници

- [ОРЗД, чл. 33: Уведомяване на надзорния орган](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Полиция: Централни контактни пунктове за киберпрестъпност](https://www.polizei.de/)
- [BSI: Указания за инциденти със сигурността на ИТ](https://www.bsi.bund.de/)
- [php.net: Съобщения за сигурност относно PHP2Shell](https://www.php.net/)
