Накратко: Дали ще инсталирате сървъра наново след хак, или ще го почистите, зависи от това колко сигурно познавате обхвата на проникването. Ако нападателят евентуално е имал root права, моментът на проникването е неясен или липсват логове, новото изграждане от надеждни източници е по-сигурният избор. Почистване идва предвид само при тясно ограничено, добре доказано заразяване. И в двата случая важи: първо запазете доказателствата и затворете уязвимостта, чак тогава почиствайте.
Защо този въпрос след PHP2Shell се задава особено често
PHP2Shell според php.net позволява изпълнение на зловреден код отдалечено без вход. Който е стопанисвал непачнат сървър, затова трябва да се запита дали от 17.10.2026 г., първия според медийни съобщения наблюдаван опит за атака, нещо не се е случило. Пачът не отговаря на този въпрос и няма публикувани, потвърдени Indicators of Compromise.
Ако тогава се открие подозрителен файл, непознат процес или чужда cron задача, предстои решението. Импулсът често е да се изтрие бързо или веднага да се инсталира наново. И двете могат да са правилни, но не като първа стъпка.
Редът преди решението
Преди да изберете между почистване и нова инсталация, три неща трябва да са свършени. Те важат и за двата пътя.
- Ограничаване: Изключете сървъра от мрежата или ограничете достъпа до най-необходимото, без да го изключвате от захранването, ако още трябва да се запази оперативната памет.
- Запазване на доказателства: Запазете логове, файлове, база данни и по възможност образ на системата, с дата и контролна сума. Защо това е нужно преди всяка нова инсталация, обяснява Запазване на доказателства, преди да инсталирате наново.
- Включване на застрахователя и защитата на данните: Много киберполици очакват съществените стъпки да бъдат съгласувани. Насоки има в Киберзастраховка: какво има значение при щета. Дали съществува задължение за уведомяване по ОРЗД, оценяват длъжностното лице по защита на данните или адвокатът.
Едва след това си заслужава същинската преценка.
Нова инсталация на сървъра след хак или почистване: критериите
| Критерий | Почистване | Нова инсталация |
|---|---|---|
| Обхват на проникването | Тясно ограничен, доказан, например един файл в папката за качване без други следи | Неясен или с указания за достъп до системата |
| Възможни root права на нападателя | Изключени с добри доказателства | Не могат да се изключат |
| Наличност на логове | Пълни за съответния период | С пропуски, презаписани или подлежащи на манипулиране |
| Усилия | По-малки, когато находката е ясна | По-големи, но по-добре планируеми |
| Оставаща несигурност | По-висока, скритите задни врати трудно се изключват | По-ниска, ако е изградено чисто от надеждни източници |
| Време на прекъсване | Обикновено по-кратко | Обикновено по-дълго, с подготовка се управлява добре |
| Пригодност за стари системи | Проблематично, ако системата така или иначе е остаряла | Добра възможност да преминете към поддържана версия на PHP |
Като правило на палеца: колкото по-малко знаете, толкова повече говори за новото изграждане. При уязвимост в интерпретатора на PHP, която изпълнява код в контекста на потребителя на уеб сървъра, нападателят може да използва други слабости, за да получи повече права. Това трудно може да се изключи без задълбочено проучване.
И двата пътя на практика
Какво наистина означава „инсталиране наново“
Инсталиране наново не означава да копирате старото резервно копие на нов сървър. Новото изграждане започва с чиста операционна система от официален източник, актуални пакети и пачната версия на PHP. Приложението се инсталира от оригинала на производителя, добавките и темите също.
Едва тогава се добавят собствените съдържания, при това проверени. Качените файлове не бива да съдържат изпълними скриптове, базата данни може да съдържа внесено съдържание, например скрити администраторски акаунти или скриптове в публикации. Конфигурационните файлове се пишат наново, вместо да се копират. Всички данни за достъп се подновяват: база данни, CMS администратори, SSH ключове, API ключове, хостинг панел.
Резервните копия играят тук важна роля, но само ако състоянието им е преди проникването и самите те не са променяни. Няколко поколения на отделни места правят това проверимо; повече в Резервни копия по правилото 3-2-1.
Когато почистването е допустимо
Почистването може да има смисъл, ако заразяването е открито рано, налични са пълни логове и проучването не дава указание за други достъпи. Тогава намерените файлове се премахват след запазването, cron задачите, потребителските акаунти и SSH ключовете се проверяват, а основните файлове се сравняват с оригинала на производителя.
Важна е реалистичната оценка: webshell-овете често са незабележими и скрити на няколко места. Как се намират, описва Разпознаване и премахване на webshell-ове. След почистване сървърът трябва да се наблюдава внимателно, за да се забележи пропусната задна врата.
Не изтривайте нищо, преди логовете и файловете да са запазени, и затворете уязвимостта, преди сървърът да се върне в мрежата. Иначе губите следите и каните следващото проникване.
Кога не Ви трябва доставчик
При обикновен уебсайт на споделен хостинг, при който хостинг доставчикът управлява системата и потвърждава пача на PHP, решението често изобщо не е у Вас. Можете да инсталирате приложението наново от оригинала, да проверите съдържанията и да подновите данните за достъп, с подкрепата на хостинг доставчика. И опитен вътрешен екип може сам да се справи с ново изграждане, ако запазването на доказателства и документацията са наред.
Външна помощ си струва, когато root правата не могат да бъдат изключени, може да са засегнати лични данни, застраховката е ангажирана или няколко системи са свързани.
Как помага PHP SOS конкретно?
- Запазваме логове, файлове и база данни годно за доказване, преди нещо да бъде променено.
- Оценяваме обхвата на проникването и препоръчваме почистване или ново изграждане с обосновка, разделена на доказано, вероятно и неизвестно.
- При нужда изграждаме сървъра наново от надеждни източници, с пачната версия на PHP и подновени достъпи.
- Поемаме премахването на зловреден софтуер там, където почистването е допустимо, и документираме всяка стъпка.
Извод
На въпроса „нова инсталация или почистване?“ се отговаря чрез знанието за проникването. Който не познава обхвата сигурно, изгражда наново. Който може да го ограничи с добри доказателства, може да почисти. И в двата случая важи един и същ ред: ограничаване, запазване, затваряне на уязвимостта, чак тогава почистване.
Често задавани въпроси
Винаги ли е по-добре новата инсталация след хак?
Не винаги, но често. Ако е неясно докъде е стигнал нападателят, новото изграждане от надеждни източници обикновено е по-сигурният избор. При тясно ограничено, добре доказано заразяване може да стигне почистването.
Мога ли просто да върна старо резервно копие?
Само ако е сигурно, че копието е направено преди проникването и не съдържа задна врата. Освен това уязвимостта трябва да е затворена предварително, иначе сървърът веднага отново може да бъде атакуван. Данните от по-ново време трябва да се проверят отделно.
Какво трябва да запазя преди новата инсталация?
Логове, копие на файловете и на базата данни и, ако е възможно, образ на системата. Тези доказателства са Ви нужни за анализ на причините, за застраховката и за възможно уведомяване. След изтриването ги няма.
Достатъчно ли е да изтрия намерения webshell?
Рядко. Нападателите често създават няколко задни врати, например cron задачи, потребителски акаунти или SSH ключове. Който изтрие само видимия файл, оставя другите достъпи отворени.