Что делать при подозрении на взлом VPS

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

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

Если затронуты важные данные, несколько серверов или обязательства перед клиентами, привлеките специалиста по расследованию и ответственного за правовые вопросы. Эта инструкция объясняет безопасный базовый порядок для владельца одного VPS, но не заменяет профессиональную криминалистику.

Зафиксируйте, что именно вызвало подозрение

Откройте заметку на доверенном компьютере и запишите:

• точное время и часовой пояс;
• откуда пришёл сигнал: мониторинг, хостер, посетитель или журнал;
• дословный текст уведомления или наблюдаемый симптом;
• затронутый домен, VPS, пользователь и IP;
• какие действия уже успели выполнить;
• кто принимает дальнейшие решения.

Не заменяйте факты выводом «нас взломали». Формулировка «в 10:14 UTC мониторинг обнаружил исходящие соединения на неизвестный адрес» полезнее, потому что её можно проверить. Все последующие команды и изменения добавляйте в ту же временную линию.

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

Решите, нужно ли немедленно изолировать VPS

Срочное ограничение оправдано, если сервер сейчас рассылает вредоносный трафик, шифрует данные, меняет DNS, передаёт закрытые сведения или атакует другие системы. В такой ситуации приоритет — остановить ущерб.

По возможности используйте внешний firewall, отключение сетевого интерфейса или другую функцию панели хостера. Управление снаружи не зависит от программ на подозрительном VPS. Выберите минимальное ограничение, которое останавливает опасную активность:

1. Закрыть публичный порт конкретной службы.
2. Оставить административный доступ только с доверенного адреса.
3. Полностью отключить внешнюю сеть VPS.
4. Убрать узел из балансировщика или временно переключить DNS.

Не закрывайте единственную консоль, через которую собираетесь сохранить сведения. Если вы не уверены, как работает фильтр, сначала откройте консоль хостера.

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

Сохраните доступные сведения до активного исправления

Команды на подозрительной машине нельзя считать полностью достоверными, особенно при возможном доступе root. Тем не менее они помогают зафиксировать исходное состояние. Выполните небольшой набор чтения:

date --iso-8601=seconds
uptime
who
ps auxf
sudo ss -lntup
systemctl --failed --no-pager
sudo journalctl --since '2 hours ago' --output short-iso-precise --no-pager

date привязывает вывод ко времени, uptime показывает последнюю загрузку, who — активные сеансы, ps — дерево процессов, ss — слушающие порты и соединённые с ними процессы. Состояние systemd и journal дополняют картину ошибками служб и событиями выбранного периода.

Не устанавливайте новый диагностический пакет на исследуемый узел без необходимости: установка меняет файлы, процессы и журналы. Не завершайте подозрительный процесс до фиксации хотя бы его команды, владельца, PID, сетевых соединений и времени.

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

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

Отзовите доступ с другого доверенного устройства

Если злоумышленник мог читать память или файлы VPS, все доступные серверу секреты считаются потенциально раскрытыми. Менять их на том же узле опасно: неизвестный процесс может сразу перехватить новые значения.

С чистого компьютера начните с учётных записей верхнего уровня:

• основной почты владельца;
• панели хостера;
• регистратора домена и DNS;
• GitHub и системы публикации;
• менеджера секретов и резервного хранилища.

Проверьте активные сеансы, способы восстановления и многофакторную аутентификацию. Затем отзовите неизвестные и затронутые SSH-ключи, deploy-ключи, API-токены и пароли базы данных. Если одно значение использовалось в нескольких местах, проверяются все эти места.

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

Определите, насколько далеко мог распространиться доступ

Исходный симптом редко показывает полную область. Проверьте:

• успешные SSH-входы и события sudo;
• новых пользователей, группы и строки authorized_keys;
• systemd-службы и таймеры, cron и сценарии запуска;
• открытые порты и неожиданные исходящие соединения;
• код приложения, конфигурацию Nginx и последние релизы;
• CI, webhooks и ключи доступа к репозиторию;
• базу данных, объектное хранилище и резервные копии;
• соседние серверы и сервисы с общими секретами.

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

При возможном root-доступе нарушитель способен изменить локальные журналы, команды и библиотеки. Сравнивайте сведения с внешними источниками: историей Git, журналом хостера, DNS-провайдера, CI и мониторинга. Отсутствие локального следа в такой ситуации не доказывает отсутствие действия.

Выберите между исправлением и чистым восстановлением

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

Чистое восстановление выполняют последовательно:

1. Создают новый VPS из поддерживаемого образа хостера.
2. Устанавливают обновления и только необходимые пакеты.
3. Настраивают пользователей, SSH и firewall с новыми ключами.
4. Разворачивают код из проверенного коммита.
5. Восстанавливают проверенные данные из копии, созданной до инцидента.
6. Подключают новые секреты.
7. Проверяют службы, сайт, журналы и мониторинг.
8. Переключают трафик на новый сервер.
9. Оставляют старый узел изолированным на согласованный срок анализа.

Не переносите целиком /etc, домашние каталоги и исполняемые файлы со старого VPS. Вместе с полезной настройкой туда могут попасть новый ключ, unit или изменённая программа. Конфигурацию воспроизводят из доверенного описания, а данные переносят выборочно после проверки.

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

Проверьте новый сервер до переключения трафика

Наличие SSH и главной страницы недостаточно. До публикации проверьте:

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

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

Старый VPS не возвращают в сеть ради удобного копирования. Данные извлекают через контролируемый изолированный путь и проверяют перед размещением на новой системе.

Завершите инцидент разбором причины

Когда сервис снова работает, дополните временную линию и ответьте:

• как появился первоначальный доступ;
• почему событие не заметили раньше;
• какие права увеличили ущерб;
• какие сведения помогли, а каких не хватило;
• сколько заняло восстановление;
• какое конкретное изменение предотвратит повторение.

Каждое улучшение должно иметь проверяемый результат. Например, не «усилить SSH», а «удалить общий ключ, выдать отдельные ключи двум администраторам и подтвердить отказ старого отпечатка». Не удаляйте журналы и заметки сразу после восстановления: срок хранения выбирают с учётом возможного повторного анализа и требований, применимых к проекту.

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

Первоисточники

• NIST SP 800-61 Rev. 3: рекомендации по реагированию на инциденты
• CISA: Incident Response Playbook
• NCSC: технические возможности для реагирования и восстановления
• CISA: сохранение сведений и восстановление после ransomware