Что делать, если ваш сервер взломали: план действий

Пока ничего не стирайте. После обнаружения взломанного сервера возникает порыв удалить всё и начать заново в течение часа, и это единственный ход, который гарантирует, что вас взломают второй раз тем же способом. Работает такой порядок: изолировать машину, чтобы она перестала вредить, сохранить достаточно улик, чтобы позже ответить на вопросы, сменить все учётные данные, которые она когда-либо хранила, пересобрать, а не чистить, восстановить данные из копии до вторжения и только потом снова открыться. Выяснить, как именно проникли, - не первый шаг, но пропустить его совсем - как раз то, из-за чего людям приходится проходить это дважды.

Два допущения делают остальные решения простыми. Первое: считайте, что у атакующего было всё, что было у сервера, - каждый пароль в конфигурационном файле, каждый API-токен, каждый ключ SSH, каждая строка базы данных. Второе: считайте, что ничему на этой машине нельзя доверять в вопросе правды, включая вывод её собственных команд. Отталкиваясь от этих двух, вы не убедите себя в необходимости срезать угол.

Статья написана под тот масштаб, на котором большинство людей находится: один игровой сервер, один сайт, один небольшой VDS, никакой команды безопасности. Это не руководство по криминалистике. Там, где честный ответ - «нужен специалист», так и сказано.

Как вы узнаёте об этом и какие признаки настоящие#

Большинство людей узнаёт не из оповещения мониторинга. Они узнают, потому что что-то ведёт себя странно, или потому что им сообщает кто-то другой. Вот сообщения, которые обычно оказываются настоящими:

• Сообщение от вашего хостера или его вышестоящего провайдера. Жалобы на злоупотребление отправляют потому, что трафик измерили, а не угадали. Считайте такое сообщение подтверждённым, пока не доказано обратное.
• CPU прижат к 100% процессом, который вы не устанавливали. Криптомайнеры - самая частая нагрузка на небольших серверах, потому что на них проще всего заработать. Они часто маскируются под правдоподобное имя вроде kworkerd или [kswapd0].
• Исходящие соединения на адреса и порты, которые вы не можете объяснить, особенно на машине, которая должна только принимать соединения.
• Файлы, изменённые в то время, когда никто не работал. Изменённый index.php, новый .htaccess с редиректом, PHP-файл в каталоге загрузок.
• Появившиеся учётные записи и ключи. Новая строка в /etc/passwd, новый ключ в authorized_keys, новый администратор в вашей CMS, новый субпользователь в аккаунте панели.
• Ваш сайт показывает поисковым системам что-то другое. Спам-ссылки, видимые краулеру и невидимые вам, - классика, и первым признаком обычно бывает падение позиций или предупреждение браузера.
• В игре: в консоли появляются команды, которые вы не запускали, неизвестным игрокам выданы права администратора, предметы или валюта, которых нельзя объяснить, мир, отредактированный в четыре утра.

Признаки, которые обычно не значат взлома: всплеск неудачных входов по SSH (это фоновый шум интернета, и он постоянен), самостоятельный перезапуск сервера (сначала проверьте память - контейнер, упёршийся в лимит, останавливается и запускается начисто, что выглядит драматично, а на деле нет) и одна странная строка в журнале без других свидетельств вокруг.

Первые десять минут: изолировать, ничего не разрушая#

Цель - не дать машине атаковать других, тратить ваши деньги или продолжать утечку данных, оставив при этом как можно больше нетронутым.

1. Остановите службу или отключите её от сети. На панельном хостинге нажмите Stop. Контейнер остановится, а его файлы останутся ровно такими, как были, - это лучшее из двух миров. На VDS остановите затронутую службу или уберите сетевой маршрут, оставив машину работать.
2. Не выключайте машину, если вы собираетесь как следует разбираться. Выключение уничтожает всё, что в памяти, а именно там живут работающий майнер, его конфигурация и нередко адрес его управляющего сервера. Для большинства небольших инцидентов никто не будет заниматься криминалистикой памяти, так что правило мягкое, - но выключение к тому же нельзя отменить.
3. Ничего не удаляйте. Ни странный файл, ни подозрительную задачу cron, ни незнакомого пользователя. Они вам ещё понадобятся, а удаление одной из этих вещей, пока у атакующего остаётся путь внутрь, скажет ему, что вы заметили.
4. Работайте с машины, которой доверяете, и не вставляйте учётные данные в скомпрометированную. Если атакующий проник через ваш собственный ноутбук, а это бывает чаще, чем думают, именно этот шаг не даст вам отдать ему и новые учётные данные.
5. Запишите время. Каждый журнал, который вы будете читать потом, - это хронология, и первая запись в ней: «замечено в 14:20 UTC». Везде используйте UTC; смесь часовых поясов губит больше расследований, чем нехватка журналов.
6. Откройте тикет у хостера. Он видит сетевые потоки, события на уровне узла и жалобы на злоупотребления, которых не видите вы. Расскажите, что вы заметили, и спросите, нужно ли им что-то сохранить, прежде чем вы будете пересобирать.

Сохраните то, что понадобится потом#

Десять минут копирования сейчас спасают всё расследование. Вы собираете три вещи: копию скомпрометированного состояния, журналы и список того, что изменилось и когда.

• Снимите резервную копию сервера как есть и заблокируйте её, чтобы ротация не смогла её удалить. В RE:NODE слот резервной копии можно заблокировать от ротации именно для этого. Подпишите её понятно. Это единственная копия места преступления, которая у вас когда-либо будет, и её нельзя случайно восстановить на боевой сервер.
• Скачайте журналы, пока они не ротировались. В Linux: /var/log/auth.log или /var/log/secure, журналы доступа и ошибок веб-сервера, журнал приложения и вывод journalctl. На игровом сервере или сервере приложений: журнал консоли и любой журнал активности панели.
• Составьте список недавно изменённых файлов и сохраните вывод:

$ find /var/www -type f -newermt "2026-09-01" -printf "%T+ %p\n" | sort | tail -50$ ls -la /tmp /dev/shm /var/tmp$ crontab -l; crontab -l -u www-data; ls -la /var/spool/cron/crontabs$ last -a | head -30$ ss -tunap$ ps auxf --sort=-%cpu | head -20

/tmp, /dev/shm и /var/tmp стоит осмотреть отдельно: они доступны на запись всем, и именно туда обычно попадает сброшенная вредоносная нагрузка.

Одна важная оговорка: на скомпрометированной машине её собственные инструменты могут лгать. Руткит подменяет ps, ls и netstat так, чтобы его собственные процессы и файлы в них не появлялись. Если цифры не сходятся - CPU на 100%, а в ps пусто, диск полон, а больших файлов нет, - перестаньте перечислять что-либо изнутри. Снимите копию на уровне файлов, пересоберите и считайте, что расследование - это то, что делается на копии, вне сети.

Смените каждый секрет, к которому сервер прикасался#

Этот шаг делают вполсилы, и по этой причине люди получают удар дважды за две недели. Всё, что читалось на этой машине, теперь публично. Меняйте в таком порядке, потому что первое защищает остальное:

1. Аккаунт у хостера и в панели. Смените пароль с чистой машины, включите двухфакторную аутентификацию, если она ещё не включена, завершите все остальные сессии и удалите любой API-ключ, который вы не узнаёте или который не нужен. В RE:NODE на странице аккаунта есть список активных сессий с кнопкой выхода, API-ключи можно ограничить конкретными адресами, а коды TOTP берутся из любого приложения-аутентификатора, и за ними стоят одноразовые коды восстановления. Настройка, включая то, что делать, если потеряны оба, описана в статье двухфакторная аутентификация в аккаунте панели.
2. Ключи SSH. Сгенерируйте новые, установите их, а затем очистите authorized_keys от всего старого. Как сделать это, не заперев себя снаружи, читайте в статье ключи SSH и укрепление доступа.
3. Пользователи и пароли баз данных. Каждый пользователь каждой базы, до которой сервер мог дотянуться, а не только тот, что стоял в используемом им конфигурационном файле. Что этим пользователям стоит разрешать после этого, разобрано в чек-листе безопасности баз данных.
4. Секреты приложений. Ключи подписи сессий, ключи шифрования, соль для сброса пароля, секреты подписи вебхуков. Смена ключа сессий разлогинивает всех, в этом и смысл: это разлогинивает и атакующего.
5. Токены сторонних сервисов. Токены ботов Discord и URL вебхуков, токены игровых серверов Steam, ключ Cfx.re, ключи платёжного API, ключи отправки почты, deploy-ключи и персональные токены доступа на вашем git-хостинге. По возможности отзывайте, а не заменяйте, чтобы старое значение перестало работать немедленно.
6. Пароли RCON и администратора, а также любой список администраторов в игре. Почему порт RCON со слабым паролем на практике - удалённая оболочка, объясняет статья безопасная работа с RCON.
7. Всё, что использовалось где-то ещё. Если пароль с этого сервера совпадает с паролем от вашей почты, это теперь самый срочный пункт в списке, и делать его надо было первым.

Пока вы там, прочитайте журнал активности аккаунта и список субпользователей, команд и выданных прав. Атакующий с доступом к панели добавляет тихий второй аккаунт гораздо чаще, чем делает что-нибудь драматичное. Как должны выглядеть эти права, показано в статье субпользователи и минимальные привилегии.

Пересобирайте, а не чистите#

Чистить скомпрометированную систему - значит доказывать отрицание: что нигде на диске нет ничего, что снова запустится по воле атакующего. На машине с менеджером пакетов, корнем веб-сервера, системой cron, несколькими служебными аккаунтами и парой тысяч файлов, которые вы не писали, такого доказательства у вас нет. Закрепление дёшево и банально - запись cron, unit systemd, строка в .bashrc, ключ SSH, изменённый плагин, запись LD_PRELOAD, запланированная задача в вашей CMS, - а вам достаточно пропустить одно.

Поэтому переустанавливайте. Правило о том, что можно вернуть со старого сервера, простое. Данные вернуть можно. Код и бинарные файлы - нельзя.

• Возвращается: дампы баз данных (после проверки), сохранения миров, загруженные картинки и документы, конфигурация, которую вы можете прочитать построчно.
• Не возвращается: само приложение, плагины, моды, темы, всё исполняемое, всё, что вы не можете объяснить. Устанавливайте их заново из первоисточника в актуальной версии.

На панельном хостинге это проще, чем кажется, потому что контейнер уже изолированная одноразовая сущность. Переустановка сервера даёт чистый образ, а один контейнер на сервер означает, что компрометация внутри него не превратилась в root на машине. На VDS вы переустанавливаете операционную систему, и поэтому чек-лист первый час на новом VDS стоит записать до того, как он понадобится в спешке.

Проверяйте всё, что переносите. В базе данных, кроме данных, может быть внедрённое содержимое: строки со спамным HTML в таблице записей, скрытый администратор, сохранённый тег script в поле профиля. В каталогах загрузок могут лежать PHP-файлы, замаскированные под картинки. Просмотрите дамп через grep до загрузки и настройте новый сервер так, чтобы ничто в каталоге загрузок никогда не могло исполняться.

Восстановление данных без восстановления проблемы#

Теперь вопрос о копиях, и он не в том, «какая самая новая».

1. Установите, когда всё началось. По сохранённому списку изменённых файлов и журналам найдите самое раннее свидетельство. Обычно оно раньше, чем вы думаете: между взломом и полезной нагрузкой нормально проходят недели.
2. Выберите копию, сделанную до этого момента. Более новые копии могут содержать чёрный ход, и так люди восстанавливаются, через день заражаются снова и делают вывод, что атакующий «всё ещё в сети».
3. Вот почему нужно хранить больше одного поколения. Единственная ночная копия, которая перезаписывает себя, даёт ровно один выбор, и он, скорее всего, заражён. Подробнее об этом - в статье резервные копии, которые действительно восстанавливаются.
4. Сначала восстановите в изолированное место и посмотрите, прежде чем это начнёт кого-либо обслуживать.
5. Смиритесь с потерей данных между чистой копией и сегодняшним днём или сливайте выборочно вручную. Слияние медленное и оправданное для магазина или долго живущего мира, и делать его нужно как данные, а не копированием файлов целиком.

Если все ваши копии новее взлома, вы выбираете между потерей всего и восстановлением того, чему нельзя полностью доверять. Пересоберите начисто, восстановите только те данные, которые можете проверить, и потом снова смените все секреты.

Поиск двери#

Теперь полезный вопрос. На практике это почти всегда что-то из перечисленного, примерно в порядке частоты:

Последнее заслуживает подчёркивания. Вредоносная программа-инфостилер на ноутбуке забирает сессии браузера, сохранённые пароли и ключи SSH за один заход, и каждый последующий вход действительно ваш. Если вы меняете всё с той же заражённой машины, вы отдаёте и новые секреты. Если ничто на сервере не объясняет вторжение, проверьте машины, с которых он администрируется, прежде чем решить, что это было волшебство.

Для игровых серверов в частности стандартный путь - неофициальная сборка плагина, и обычная примета - плагин, скачанный из сообщения на форуме или с сайта повторной публикации, а не у автора. Как искать и проверять источники, разобрано в статье как держать модифицированный сервер чистым.

Возвращение в сеть и что наблюдать#

Возвращайтесь осознанно:

• Сначала обновите. Актуальные пакеты операционной системы, актуальные CMS и плагины, актуальная сборка игры. Эксплойт, который сработал однажды, автоматические сканеры попробуют снова в течение нескольких дней.
• Закройте всё, что не должно быть открыто. У каждого слушающего порта должна быть причина. Краткая версия - в статье правила файрвола, которые важны: по умолчанию запрет, затем разрешение названных вещей.
• Включите двухфакторную аутентификацию везде, где она предлагается, и используйте для SSH ключи, а не пароли.
• Включите то логирование, которого вам не хватало. Соединения, аутентификация, административные действия, изменения файлов в корне сайта. Что хранить и как долго, разобрано в статье журналы, которые стоит хранить.
• Добавьте [fail2ban](/blog/fail2ban-guide) на VDS, чтобы повторные неудачи чего-то стоили атакующему.
• Наблюдайте две недели. Сначала ежедневно проверяйте журнал аутентификации, список процессов и исходящие соединения. Повторное заражение, если происходит, обычно происходит быстро.

Скажите правду тем, кто на неё вправе рассчитывать. Если на этом сервере были данные игроков или клиентов, скажите об этом прямо и расскажите, что вы изменили; если затронуты платёжные или персональные данные, в вашей юрисдикции может быть обязанность уведомить, и это стоит десяти минут настоящей консультации, а не догадки. Короткое фактическое уведомление обойдётся вам гораздо дешевле, чем вариант, когда люди узнают позже.

FAQ#

Может, просто удалить сервер и начать заново?

В конце концов да, и это правильный инстинкт. Сначала сделайте две вещи: снимите и заблокируйте копию скомпрометированного состояния и скопируйте журналы. Это занимает минуты, и это единственный способ потом ответить на вопрос «как это случилось». Затем пересобирайте, а не чистите.

Можно ли удалить вредоносную программу и работать дальше?

Удалить можно ту часть, которую вы нашли. Доказать, что нашли всё, нельзя, потому что закрепление - это одна строка в одном файле среди тысяч. Если машина делала что-то важное для вас, переустановите её. Единственный случай для чистки на месте - один, хорошо понятный, изолированный объект, например один внедрённый файл на статическом сайте без серверного кода.

Как они попали внутрь, если пароль был надёжным?

Надёжность останавливает подбор и больше ничего. Повторное использование, старая утечка, вредоносная программа на вашем компьютере, устаревший плагин или секрет, попавший в репозиторий, - всё это пути, которые вообще не затрагивают энтропию вашего пароля. Таблица выше - список, по которому нужно пройтись.

Отвечает ли за это мой хостер?

Он отвечает за платформу: оборудование, сеть, изоляцию между клиентами и безопасность самой панели. Вы отвечаете за то, что работает внутри вашего сервера, версии программ, моды и учётные данные. Взлом вашего приложения или утёкший пароль лежат на вашей стороне этой границы, но всё равно сообщите ему: он видит трафик, которого не видите вы, и скажет, затронуты ли другие.

Исправит ли всё восстановление из копии?

Только если копия сделана до взлома и вы при этом сменили учётные данные. Восстановление заражённой копии заново устанавливает чёрный ход, а восстановление чистой, пока у атакующего остаётся действующий ключ или пароль, просто даёт ему свежий сервер. Сделайте и то и другое, именно в таком порядке.

Как долго атакующие обычно сидят внутри, прежде чем что-то сделать?

Часто неделями. Автоматические взломы нередко сначала ставят лишь тихую точку опоры и возвращаются позже, и поэтому дата самого раннего свидетельства важнее даты, когда вы заметили, и поэтому одного поколения копий недостаточно.