Что делать, если взломали VPS

Не пытайтесь очистить взломанный VPS

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

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

Это основной аргумент. Вот механизм, стоящий за ним. Злоумышленник, получивший права root, может заменить ps так, что определенный ID процесса никогда не появится в выводе. Одна строка в /etc/ld.so.preload загружает код атакующего в каждую динамически скомпонованную программу на сервере, поэтому ls, ss и find будут предоставлять одинаково ложные данные. Загружаемый модуль ядра может скрывать файлы на уровне системных вызовов, поэтому даже свежескачанный бинарный файл будет видеть «чистый» диск. Вы удаляете майнер, график нагрузки CPU падает, и сервер затихает. Но тишина — это именно то, как выглядит работающий бэкдор.

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

Подтверждение факта взлома

Многие серверы, которые считаются взломанными, на самом деле таковыми не являются. Тысячи неудачных попыток входа по SSH в день — это фоновый шум интернета, так как каждый публичный IPv4-адрес сканируется непрерывно. Вывод lastb, полный попыток root и admin, означает лишь то, что сканеры обнаружили ваш порт. Это не значит, что кто-то получил доступ.

На взлом указывают следующие признаки:

• Успешный вход в систему, который вы не совершали, например, Accepted password for root from 203.0.113.7.
• Ключ в authorized_keys, который вы не добавляли.
• Уведомление о злоупотреблении (abuse) от хостинг-провайдера по поводу исходящего трафика с вашего сервера.
• Процесс, потребляющий 100% CPU и имеющий имя, скопированное у потока ядра. Майнеры, установленные через открытые сокеты Redis и Docker, часто отображаются под именами вроде kdevtmpfsi и kinsing.
• Исходящие соединения с адресами, которые не использует ни один из ваших сервисов.

Маскировку под поток ядра можно быстро проверить. Настоящие потоки ядра отображаются в квадратных скобках и не имеют исполняемого файла, поэтому команда sudo ls -l /proc/<pid>/exe для них завершается с ошибкой No such file or directory. Если процесс, отображаемый как [kworker/0:2], имеет ссылку exe, указывающую на файл в /tmp, то это обычная пользовательская программа, использующая имя ядра.

Выполняйте эти проверки, учитывая, что система может предоставлять ложные данные. Их достаточно, чтобы понять, что что-то не так. Но их недостаточно, чтобы гарантировать отсутствие проблем.

Отключайте сеть на уровне провайдера, а не внутри сервера

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

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

Есть две причины не делать этого изнутри сервера. Межсетевой экран, настроенный внутри скомпрометированного ядра, управляется этим же ядром, и пользователь root может сбросить правила nftables так же легко, как вы их создали. Кроме того, sudo ip link set enp1s0 down через SSH первым делом прервет вашу собственную сессию, что заблокирует вам доступ к машине в процессе её исследования.

Блокируйте как исходящий, так и входящий трафик. Обратная оболочка (reverse shell) устанавливает соединение с сервером атакующего изнутри, поэтому блокировка только входящих соединений оставит уже установленное соединение полностью рабочим. Если ваш провайдер предлагает только правила для входящего трафика, остаются варианты отключения сетевого интерфейса или выключения инстанса.

Не перезагружайтесь сразу. Сначала проверьте наличие /var/log/journal. Если этот каталог отсутствует, journald записывает данные в /run/log/journal, который находится в оперативной памяти, поэтому перезагрузка удалит все записи о вторжении. Запущенные процессы также исчезают при перезагрузке, а их командные строки часто являются самым наглядным доказательством, которое вы можете получить.

Создайте снапшот диска перед внесением любых изменений

Снапшот и резервная копия выполняют разные задачи. Снапшот, который вы делаете сейчас, — это копия скомпрометированного диска: это ваше доказательство и единственный способ вернуться к исходному состоянию, если вы случайно что-то перезапишете. Ваши старые резервные копии — это путь к восстановлению. Если в панели управления вашего провайдера эти понятия используются нестрого, сначала прочитайте чем снапшоты VPS отличаются от полноценных резервных копий, так как правила хранения и процесс восстановления у них различаются.

Создайте снапшот через панель управления провайдера до того, как снова войдете в систему. «Живой» снапшот является crash-consistent: он фиксирует состояние диска в конкретный момент времени, аналогично внезапному отключению питания. Для целей сбора доказательств этого достаточно. Назовите его так, чтобы никто не восстановил его по ошибке. Название вроде COMPROMISED-do-not-restore-2026-08-12 — это именно тот уровень ясности, который нужен. Храните его до завершения расследования и закрытия всех тикетов о нарушении (abuse) у вашего хостинг-провайдера.

Как получить доступ, если SSH недоступен

Существует два способа, оба доступны через панель управления провайдера. Веб-консоль (VNC или последовательный порт) подключается к машине так, будто вы физически подключили клавиатуру. Она работает, когда sshd не запущен, когда настройки firewall неверны или когда злоумышленник изменил порт SSH. Аутентификация происходит по локальному паролю, поэтому для сервера, настроенного только на вход по ключам, может потребоваться сброс пароля root, прежде чем консоль станет полезна.

Rescue mode — более предпочтительный вариант. Он загружает небольшую live-систему, при этом ваш диск подключается, но не запускается. Это гарантирует надежность ваших команд: скомпрометированное ядро и скомпрометированные бинарные файлы не выполняются. Монтируйте диск в режиме только для чтения.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Если lsblk показывает тома LVM (logical volume manager) вместо обычного раздела, сначала активируйте их с помощью sudo vgchange -ay, а затем смонтируйте устройство, которое появится в /dev/mapper/.

Не используйте chroot для входа в смонтированный диск с целью осмотра. Команда chroot выполняет бинарные файлы злоумышленника с вашими правами доступа, что полностью нивелирует смысл загрузки в rescue mode.

Сбор достоверных доказательств

Запустите эти команды из режима восстановления (rescue mode), примонтировав диск в режиме только для чтения в /mnt/victim. Начните с журналов входа в систему: они позволяют определить время взлома, а наличие временного интервала упрощает дальнейший анализ.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

Отсутствие /var/log/auth.log само по себе не является подозрительным. Некоторые современные образы Ubuntu поставляются без rsyslog, поэтому sshd записывает логи только в journal, что и считывает команда journalctl -D. Стоит обратить внимание на разрывы в непрерывных логах или на файлы журналов, усеченные до нулевого размера. Очистка логов — распространенное и обычно грубое действие.

Далее проверьте учетные записи и ключи.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

Команда awk выводит все учетные записи с идентификатором пользователя 0. Любое значение, отличное от root в этом выводе, указывает на наличие второй учетной записи root. Шаблон find намеренно включает authorized_keys2, так как OpenSSH по умолчанию считывает оба файла, и второй легко пропустить. Если lsattr выводит i в списке атрибутов, файл является неизменяемым (immutable): злоумышленник устанавливает этот флаг, чтобы ваша попытка удалить его ключ завершилась ошибкой Operation not permitted, а уставший администратор решил, что редактирование прошло успешно.

Механизмы закрепления (persistence) скрываются в небольшом количестве мест, поэтому проверьте их все.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

Файл /etc/ld.so.preload не существует в стандартной системе Ubuntu или Debian, поэтому No such file or directory — это нормальный результат, а любое содержимое заслуживает вашего внимания. Файл входа, который передает вывод base64 -d в оболочку (shell) — это аналогичный случай: легитимной конфигурации не нужно скрывать свой текст.

Стройте хронологию событий по времени изменения метаданных (ctime), а не по времени модификации содержимого (mtime).

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

Команда touch позволяет установить время модификации на любое значение, которое выберет злоумышленник, поэтому mtime легко подделать. Время изменения метаданных (ctime) обновляется при любом изменении inode, и touch не может сдвинуть его назад, поэтому -newerct дает более честный список того, что было записано недавно. Это все еще не является абсолютным доказательством, так как root может изменить системные часы или записать данные непосредственно на блочное устройство.

Целостность пакетов проверяется одной командой с одной оговоркой. В работающей системе sudo dpkg --verify выводит строку для каждого упакованного файла, контрольная сумма которого не совпадает, с пометкой 5 в столбце контрольных сумм, а sudo debsums -ac выполняет ту же задачу, включая файлы конфигурации, если установлен пакет debsums. Интерпретируйте результат только в одну сторону. Измененный /usr/sbin/sshd — это реальное доказательство. Чистый отчет ничего не доказывает, так как та же учетная запись root, которая заменила бинарный файл, может перезаписать списки контрольных сумм в /var/lib/dpkg/info/. Сканеры руткитов, такие как rkhunter и chkrootkit, следуют тому же правилу: обнаружение угрозы — это информация, а отсутствие обнаружений — не гарантия безопасности.

Скопируйте собранные данные с машины, прежде чем предпринимать какие-либо деструктивные действия.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Запишите этот хеш где-нибудь вне сервера. Если дело дойдет до страхового случая или полицейского отчета, возможность доказать, что архив не менялся с момента сбора, станет решающим фактором между доказательствами и просто папкой с файлами. Случайное удаление данных во время расследования — обычное дело, и наличие снимка системы вместе с этим архивом поможет пережить такую ситуацию. Отмена последствий неудачной команды rm гораздо сложнее, чем принято считать, как объясняется в восстановление файлов, удаленных с помощью rm -rf.

Найдите точку входа

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

Парольная аутентификация SSH. Строка Accepted password for root с неизвестного вам адреса — это уже готовый ответ. Проверьте PasswordAuthentication в /etc/ssh/sshd_config и в каждом файле в каталоге /etc/ssh/sshd_config.d/. sshd использует первое найденное значение для параметра, а строка Include в Ubuntu находится в самом верху основного файла. Таким образом, добавленный файл конфигурации незаметно переопределяет настройки, которые вы изменили ниже по тексту.

Сервис, опубликованный без аутентификации. Redis на порту 6379, Docker API на 2375, база данных, привязанная к 0.0.0.0 вместо 127.0.0.1. Docker — частый источник сюрпризов. Публикация порта контейнера добавляет правила DNAT (destination network address translation), которые обрабатываются раньше цепочек ufw. Поэтому ufw status может сообщать, что порт закрыт, в то время как контейнер за ним отвечает всему Интернету. Разберитесь с этим до пересборки: почему опубликованные порты Docker обходят ufw — здесь описан порядок правил и способы исправления.

Необновленное веб-приложение. Изучите access log веб-сервера в районе самой ранней подозрительной временной метки на предмет POST-запросов к путям загрузки или административным разделам. Затем поищите файлы в корневом каталоге веб-сервера, время изменения которых совпадает с инцидентом. Лишний PHP-файл в директории загрузок — классический результат.

Утечка учетных данных. Ключ, закоммиченный в репозиторий, токен, отправленный в чат, или файл .env, который отдается как статический контент из-за неверной настройки веб-сервера. Автоматизация упрощает совершение таких ошибок, что является аргументом в пользу хранения секретов вне AI-агентов и их конфигурационных файлов.

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

Смените все учетные данные, к которым мог получить доступ сервер

Выполняйте смену только после отключения сети, но не раньше. Смена ключей при активном соединении злоумышленника просто передаст ему новые секреты.

• Все закрытые SSH-ключи, хранящиеся на сервере, а также все учетные записи, которые доверяли соответствующим открытым ключам.
• Любые ключи, переданные на сервер с помощью ssh -A. Пересылка агента оставляет сокет в /tmp, и пользователь root на этой машине может использовать его для аутентификации от вашего имени везде, где принят ваш ключ, пока ваша сессия остается открытой.
• API-токены в файлах .env, в строках Environment= systemd, в конфигурациях CI и учетных данных провайдеров.
• Пароли от баз данных и учетные записи приложений, которые их используют.
• Закрытые ключи TLS (transport layer security), которые хранились на сервере. Перевыпустите сертификат и отзовите старый.
• Пароль от вашей учетной записи хостинг-провайдера с включенной двухфакторной аутентификацией. Эта панель позволяет пересоздавать, делать снимки и подключаться к консоли любого вашего сервера, поэтому она является реальным периметром безопасности.
• Любой пароль, введенный в сессии оболочки на этом хосте во время компрометации, так как пользователь root может записывать терминальную сессию в реальном времени.

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

Контрольный список для пересборки сервера

1. Создайте новый сервер из чистого образа дистрибутива. Не используйте снимок скомпрометированной системы или полное восстановление файловой системы root.
2. Устанавливайте пакеты только из репозиториев дистрибутива. Никогда не копируйте бинарные файлы со старого диска.
3. Восстанавливайте только данные из резервной копии, созданной до появления первых признаков взлома в вашей хронологии. Это дампы баз данных, загруженные файлы и состояние приложений. Оставьте /etc, /usr и старые файлы юнитов в прошлом.
4. Вручную введите обновленные секретные данные. Не копируйте старые файлы .env.
5. Проверьте восстановленный веб-контент на наличие файлов, добавленных в период взлома, прежде чем снова открывать к нему доступ.
6. Усильте безопасность перед выводом сервера в сеть: используйте только SSH-ключи, рабочую учетную запись без прав root, входящий файрвол с политикой default-deny и не публикуйте сервисы шире, чем это необходимо. Выполните инструкции из первые десять минут на новом VPS, затем правильно настройте SSH, после чего добавьте fail2ban на Ubuntu 24.04 для снижения шума в логах авторизации. Назначьте каждому сервису собственную учетную запись с минимальными привилегиями, чтобы следующая точка закрепления злоумышленника не стала доступом к root.
7. Выключите старый сервер и сохраните его снимок до завершения расследования и закрытия всех тикетов о злоупотреблениях.
8. Исправьте систему резервного копирования. Если на этапе 3 вам пришлось действовать наугад, значит, глубина архива была недостаточной для восстановления до момента взлома. Версионные резервные копии на внешнем хранилище с длительным сроком хранения — это гарантия чистого восстановления в будущем: резервное копирование restic на VPS обеспечивает и то, и другое.

Если вы не можете определить дату взлома, вы не сможете выбрать безопасную резервную копию. В этом случае восстанавливайте только те данные, которые можно проверить визуально: SQL-дамп, который можно прочитать, или каталог с изображениями, содержимое которого можно просмотреть. Считайте любой исполняемый файл подозрительным и переустанавливайте его из репозиториев.

Что означает уведомление о злоупотреблениях от хостинг-провайдера

Большинство пользователей узнают о том, что их сервер был взломан, от своего провайдера, а не из собственных систем мониторинга. Хостинг-провайдеры видят исходящий трафик: перебор паролей по SSH в других сетях, рассылку спама через 25 порт или участие в отраженной DDoS-атаке. Тикет обычно содержит временные метки, порты и примеры потоков данных, а также крайний срок реакции, измеряемый в часах.

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

Взлом клиентского сервера — это рутинная работа для хостинг-провайдера, и грамотное реагирование на инцидент не будет поставлено вам в вину. Более широкий вопрос о том, безопасен ли VPS-хостинг, в основном сводится к тому, как именно клиент настроил систему, что как раз и является той частью работы, которую вам теперь предстоит выполнить заново с нуля.

Когда следует обратиться к специалистам

• На сервере хранились персональные данные других лиц. Согласно GDPR (General Data Protection Regulation), об утечке персональных данных необходимо без неоправданной задержки уведомить надзорный орган, по возможности в течение 72 часов с момента обнаружения инцидента. Определение того, начался ли отсчёт этого времени, является юридической задачей, а не задачей системного администратора.
• В зоне риска находились данные платёжных карт. Правила платёжных систем требуют привлечения сертифицированного эксперта по криминалистике, а самостоятельное вмешательство может повредить расследованию.
• Поступило требование о выкупе или ваши данные были зашифрованы.
• Машина имела доступ к другим узлам: внутренней сети, гипервизору, CI-раннеру, содержащему производственные учётные данные. Один скомпрометированный хост в группе считается инцидентом для всей группы, пока не доказано обратное.
• Вам необходимо сохранить доказательства для страховой компании или правоохранительных органов. Остановитесь на этапе создания снимка (snapshot), сделайте полный образ диска и зафиксируйте, кто и когда имел к нему доступ.

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

FAQ

Можно ли очистить взломанный VPS вместо его переустановки?

Нельзя, если вы хотите быть уверены в результате, так как вы просите скомпрометированную систему отчитаться о самой себе. Замененный ps скрывает процесс, строка в /etc/ld.so.preload внедряет код в каждую динамически скомпонованную утилиту, которую вы запускаете, а модуль ядра может скрыть файлы от всех программ одновременно. Вы можете найти следы, поэтому положительный результат поиска имеет значение. Вы не можете доказать отсутствие следов, поэтому отрицательный результат ничего не значит. Очистка оправдана только в том случае, если на сервере нет ничего важного, и вы готовы к тому, что его снова взломают.

Нужно ли выключать скомпрометированный сервер или оставить его включенным?

Сначала отключите его от сети на стороне провайдера, затем оставьте включенным на время, достаточное для создания снимка (snapshot) и просмотра запущенных процессов. Выключение уничтожает список процессов и полностью удаляет журнал, если /var/log/journal не существует, так как в этом случае journald записывает данные в оперативную память по пути /run. Тем не менее выключайте сервер, если он активно атакует другие сети, а у вас нет возможности заблокировать его исходящий трафик. Прекращение вредоносной активности важнее сохранения доказательств.

Как определить, когда злоумышленник получил доступ?

Найдите самую раннюю строку в Accepted password или Accepted publickey, которую вы не можете объяснить, в файле /var/log/auth.log или в журнале. Сверьте её с данными о времени изменения файлов, find / -xdev -newerct 'YYYY-MM-DD' -type f, так как ctime подделать сложнее, чем mtime. Затем сравните оба показателя с отметками времени в уведомлении о нарушении от вашего провайдера, которые были зафиксированы вне машины и не могли быть изменены. Выберите резервную копию, созданную до самой ранней из этих трёх дат. Если ничего не совпадает, считайте, что компрометация произошла раньше, чем началась история ваших резервных копий, и восстанавливайте только те данные, которые вы можете проверить.

Безопасно ли восстанавливать резервные копии после компрометации?

Данные обычно безопасны, если их проверить. Системные файлы — нет. Резервная копия, сделанная после вторжения, содержит бэкдор, поэтому восстановление всей корневой файловой системы вернет и злоумышленника. Проверьте также само хранилище резервных копий: если учетные данные для него хранились на скомпрометированном сервере, история могла быть удалена или изменена, что является аргументом в пользу использования хранилищ с доступом только на добавление (append-only) или архитектуры с вытягиванием данных (pull-based). Восстанавливайте данные приложений, а затем устанавливайте программное обеспечение заново из репозиториев дистрибутива.

Должен ли я кому-то сообщать о том, что мой VPS был взломан?

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