Как перенести сервис с подозрительного VPS на чистый сервер

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

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

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

Определите, каким источникам можно доверять

До создания нового сервера составьте таблицу:

Что нужно восстановить	Доверенный источник	Как проверить
Ubuntu и системные программы	новый образ хостера и подписанные репозитории	выпуск, обновления, список пакетов
исходный код	известный коммит Git до инцидента	remote, история, review и сборка
конфигурация	репозиторий конфигурации или документированная инструкция	ручное сравнение параметров
база и загрузки пользователей	копия до предполагаемого проникновения	дата, формат, выборочная проверка
пароли и токены	новые значения	старые значения отозваны

«Файл лежал на старом VPS» не является подтверждением. Если доверенного описания конфигурации нет, её восстанавливают вручную по известному назначению, а старый файл используют только как подсказку в изолированной среде.

Отдельно определите границы: какие домены, базы, очереди, хранилища и внешние API обслуживал старый сервер. Иначе новый VPS заработает, но забытый общий токен сохранит нарушителю доступ в соседнюю систему.

Выберите проверенный коммит приложения

На доверенном компьютере откройте локальный репозиторий и проверьте его источник и состояние:

git remote -v
git status --short
git log --oneline --decorate -n 10

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

Сам хеш коммита подтверждает содержимое внутри Git, но не личность автора. Если проект подписывает релизы или коммиты, проверьте подпись штатной командой процесса. Если подписей раньше не было, не объявляйте неподписанный коммит вредоносным; подтвердите его через review, историю CI и локальную сборку.

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

Создайте новый VPS отдельно от старого

Используйте поддерживаемый образ Ubuntu и новый набор SSH-ключей. Новый VPS не должен автоматически получать старый snapshot, общий authorized_keys или startup-script, происхождение которого не проверено.

После первого входа зафиксируйте базовое состояние:

lsb_release -ds
uname -r
sudo ss -lntup
systemctl --failed --no-pager

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

Затем последовательно выполните базовую настройку: отдельный администратор, проверенный SSH-ключ, UFW, автоматические исправления безопасности и точное время. После каждого изменения открывайте новую SSH-сессию, не закрывая предыдущую.

Не подключайте новый VPS к рабочему домену на этом этапе. Проверяйте сайт через локальную запись hosts, временное техническое имя или прямой адрес с корректным заголовком Host — в зависимости от приложения и TLS.

Установите программы из чистых источников

Системные пакеты устанавливайте из настроенных репозиториев нового выпуска. Контейнерные образы берите по проверенному тегу и digest из доверенного registry. Зависимости приложения собирайте из lock-файла выбранного коммита.

Не копируйте со старого узла:

• /usr/bin, /usr/lib и другие системные исполняемые файлы;
• весь каталог /etc;
• старые unit-файлы без сравнения с доверенным описанием;
• домашние каталоги администраторов целиком;
• виртуальное окружение, node_modules или слои контейнеров;
• cron-задачи и authorized_keys как готовый набор.

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

Воспроизведите конфигурацию, а не копируйте её вслепую

Создавайте Nginx, systemd, firewall и параметры приложения по документации проекта. Значения из старой конфигурации переносите только после ответа на вопросы:

• этот параметр ещё нужен;
• путь существует на новом сервере;
• значение не является старым секретом;
• правило не открывает лишний порт или право;
• изменение можно проверить и вернуть.

После каждого файла запускайте встроенную проверку программы, например nginx -t для Nginx или systemd-analyze verify для unit. Затем применяйте конфигурацию и выполняйте один связанный пользовательский тест. Так ошибка остаётся привязанной к последнему небольшому изменению.

Переносите данные через промежуточное место

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

Для обычного каталога начните с пробного списка rsync. Пути ниже являются примером и должны быть заменены точными каталогами данных:

rsync -a --dry-run --itemize-changes /staging/uploads/ /srv/app-data/uploads/

--dry-run ничего не копирует, а --itemize-changes показывает будущие действия. Проверьте, что источник заканчивается /, назначение не содержит системных каталогов и список включает только ожидаемые пользовательские файлы.

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

Базу восстанавливайте штатным инструментом самой СУБД из логической копии либо проверенного backup. Выполните восстановление сначала в изолированную базу, проверьте структуру, число ключевых записей и прикладные сценарии. Не запускайте хранимый код и миграции из неизвестного дампа без анализа.

Создайте новые секреты

Все ключи и токены, которые мог прочитать старый VPS, замените. В эту группу входят пароль базы, API-токены, deploy-ключ, cookie secret, SMTP и доступ к объектному хранилищу.

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

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

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

Пройдите пользовательские сценарии: открытие страниц, вход, чтение и запись данных, отправку писем или webhook — только те функции, которые действительно есть у проекта. Дополнительно проверьте:

• systemctl --failed не показывает необъяснимых служб;
• наружу открыты только ожидаемые порты;
• приложение запускается после перезагрузки;
• журнал не содержит повторяющихся ошибок;
• сертификат и его продление проверены;
• внешний мониторинг видит тестовый узел;
• создаётся новая ручная локальная резервная копия.

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

Переключите трафик с понятным возвратом

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

Измените один слой маршрутизации: запись DNS, адрес в балансировщике или origin CDN. С внешних сетей проверьте, что домен приходит на новый узел, HTTPS отдаёт ожидаемый сертификат, а пользовательские сценарии работают.

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

Оставьте старый сервер изолированным

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

Перед окончательным удалением подтвердите, что:

• новый сервер обслуживает весь трафик;
• на старый IP не приходят забытые интеграции;
• нужные данные проверены и перенесены;
• старые секреты отозваны;
• локальная копия нового состояния восстановима;
• материалы инцидента сохранены отдельно.

Доверенное состояние — это не ощущение, что «ничего подозрительного больше не видно». Это понятная цепочка происхождения системы, кода, конфигурации, данных и секретов, подтверждённая проверками на новом узле.

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

• NIST SP 800-61 Rev. 3: реагирование и восстановление
• CISA: Incident Response Playbook
• NCSC: восстановление и чистые резервные копии
• Ubuntu Server: базовые меры защиты