Взломали сервер: что делать в первые 24 часа — план для владельца VPS

В октябре 2026 года клиенты FirstVDS получили письма, после которых откладывать было нельзя. Хостер сообщил: злоумышленники через уязвимость в VMmanager 6 подключали диски клиентских VPS и копировали с них пароли, SSH- и API-ключи, токены, конфиги и криптокошельки. Формулировка в блоге компании была прямой: «Если вы получили уведомление в личном кабинете, считайте, что данные с сервера были скопированы» (FirstVDS, 18.10.2026). У владельцев сайтов, ботов и проектов на таких серверах счёт пошёл на часы.

Ниже — план на первые 24 часа после взлома сервера: изоляция, сбор следов, смена секретов, переустановка, уведомления и действия при вымогательстве. Сбор следов построен по мотивам руководства NIST SP 800-86 по цифровой криминалистике, рекомендации — из заявлений хостеров, пострадавших в октябре 2026 года, сроки — из 152-ФЗ и КоАП. Команды мы запускали на Ubuntu 22.04.5, правила nftables проверили на синтаксис; на Ubuntu 24.04 и Debian 12 команды не запускали — известное отличие Debian 12 указано рядом. В конце — чек-лист на сутки.

Признаки взлома VPS, которые нельзя списать на сбой

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

• в ~/.ssh/authorized_keys появился чужой ключ, в системе — новый пользователь, в cron или systemd — незнакомые задания;
• пароль root или администратора сайта перестал подходить, хотя его никто не менял;
• файлы зашифрованы, рядом лежит записка с требованием выкупа;
• хостер сообщил о компрометации своей инфраструктуры или вашего сервера.

Вторая группа — симптомы, у которых бывают и безобидные причины: нагрузку даёт и кривой плагин, и бэкап по расписанию. Их проверяют сразу, не откладывая:

• процессор загружен на 100% процессом с непонятным именем — типичная картина для майнера;
• процесс запущен из удалённого файла: бинарник стёрли с диска, а программа работает из памяти;
• хостер прислал abuse-жалобу: с сервера идёт спам, сканирование портов или DDoS;
• на сайте появились редиректы, чужие ссылки или PHP-файлы в папке загрузок.

Когда взломали не вас, а хостера: случай VMmanager 6

VMmanager 6 — панель ISPsystem, через которую хостеры управляют узлами виртуализации и VPS клиентов. В октябре 2026 года через уязвимость в ней атаковали несколько провайдеров (подробности — в нашем разборе взлома FirstVDS и VMmanager 6). Владельцу VPS из этой истории важны три вывода.

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

Второй — утечь могло и то, что на диске не лежало. ForestsNet Cloud сообщила, что у атакующих оказалась база панели: IP-адреса серверов, email учётных записей, root-пароли, заданные через панель при заказе, переустановке или смене пароля, и пароли VNC-консоли (ForestsNet, 18–20.10.2026). Root-пароль, который не меняли со дня заказа сервера, после такого считается раскрытым.

Третий — дата обнаружения не совпадает с датой взлома. Senko Digital зафиксировала вход атакующего 12 октября, FirstVDS — доступ к инфраструктуре 17 октября (Senko Digital, 19.10.2026). От этого зависит выбор бэкапа для восстановления.

Отсутствие письма от хостера тоже не гарантия: по словам FirstVDS, оно значит лишь, что на узлах клиента следов атаки не нашли.

Первые 60 минут: изолировать сервер, не уничтожая улики

Перезагружать сервер и удалять подозрительные файлы в первый час не надо. Перезагрузка стирает всё, что живёт только в памяти: список процессов, сетевые соединения, вредонос, работающий без файла на диске. Руководство NIST прямо называет такие данные энергозависимыми: они теряются при выключении, а резидентные руткиты при перезагрузке могут исчезнуть вместе со следами (NIST SP 800-86, разд. 5.2). Механизм автозапуска атакующего при этом переживёт рестарт — он для того и создавался.

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

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

Шаг 3. Отрежьте сервер от сети, оставив доступ только себе. Самый надёжный путь — отключить сетевой интерфейс в панели хостера и работать через VNC-консоль. Если такой кнопки нет или нужно сохранить SSH для сбора данных, закройте всё, кроме SSH со своего адреса. Свой IP и порт SSH сервера покажет текущая SSH-сессия — первое поле адрес, второе порт:

echo "$SSH_CONNECTION" | awk '{print $1, $4}'

Подставьте свой IPv4 вместо 203.0.113.10 и фактический порт вместо 22. Если адрес IPv6, раскомментируйте строки с ip6 и впишите его туда. Проверьте, что утилита есть в системе: which nft. Если её нет, а ставить пакеты на взломанный сервер не хочется, изолируйте сервер через панель хостера. Ошибка в адресе или порте отрежет и вас, поэтому держите открытой VNC-консоль хостера как запасной вход:

cat > /root/ir.nft <<'EOF'
define ADMIN4 = 203.0.113.10
define SSHPORT = 22
table inet ir {
  chain ir_in {
    type filter hook input priority -10; policy drop;
    iif lo accept
    ip saddr $ADMIN4 tcp dport $SSHPORT accept
    # ip6 saddr 2001:db8::10 tcp dport $SSHPORT accept
  }
  chain ir_fw {
    type filter hook forward priority -10; policy drop;
  }
  chain ir_out {
    type filter hook output priority -10; policy drop;
    oif lo accept
    ip daddr $ADMIN4 tcp sport $SSHPORT accept
    # ip6 daddr 2001:db8::10 tcp sport $SSHPORT accept
  }
}
EOF
nft -f /root/ir.nft

Правила не делают исключения для уже установленных соединений: проходит только SSH-трафик между сервером и вашим адресом. Майнер теряет пул, бэкдор — управляющий сервер, сборщик данных — канал выгрузки, причём и для новых, и для уже открытых сессий. Цепочка ir_fw отрезает контейнеры Docker, если бот или сайт работает в них. Правила действуют до перезагрузки, снять их досрочно можно командой nft delete table inet ir.

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

Как сохранить следы: процессы, соединения и логи

Главное правило сбора — запускать команды со своего компьютера и сохранять вывод у себя, а не на взломанном диске. Ничего не устанавливайте на сервер: каждая запись на диск может затереть удалённые файлы атакующего. При руткитах системные утилиты способны показывать ложную картину (NIST SP 800-86, разд. 5.2.1), поэтому вместе с выводом команд копируют и сами логи.

NIST рекомендует собирать энергозависимые данные в таком порядке: сетевые соединения, сеансы входа, содержимое памяти, процессы, открытые файлы, сетевая конфигурация, время системы. Блок ниже — упрощённый сбор по мотивам этого порядка: дамп памяти и полный список открытых файлов в нём не собираются (для них нужны отдельные инструменты), время сервера фиксируется первым как точка отсчёта, а /proc/*/exe показывает только исполняемые файлы процессов. Блок выполняется на вашем компьютере (Linux или macOS), адрес сервера подставьте свой:

S=root@198.51.100.20
D=ir-$(date +%Y%m%d-%H%M%S); mkdir "$D" && cd "$D"
ssh $S 'date -u; uptime'                        > 00-time.txt
ssh $S 'ss -tunap'                              > 01-connections.txt
ssh $S 'who -a; w'                              > 02-sessions.txt
ssh $S 'ps auxwwf'                              > 03-processes.txt
ssh $S 'ls -l /proc/*/exe 2>/dev/null | grep "(deleted)"' > 04-deleted-binaries.txt
ssh $S 'last -Faiw; echo ---; lastb -Fai | head -300'     > 05-logins.txt
ssh $S 'ip addr; ip route; nft list ruleset'    > 06-network.txt

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

ssh $S 'tar czf - /var/log /etc /root/.bash_history /home/*/.bash_history' > 10-logs-etc.tgz 2> 10-tar.err; echo "tar exit=$?"
ssh $S 'journalctl -o short-iso --no-pager --since "30 days ago"' > 11-journal.txt 2> 11-journal.err; echo "journal exit=$?"
shasum -a 256 ./*.txt ./*.tgz > SHA256SUMS    # на Linux: sha256sum ./*.txt ./*.tgz > SHA256SUMS

Код 0 — архив полный. Код 1 у GNU tar означает, что файлы менялись во время чтения (для живых логов это ожидаемо), код 2 — что-то не прочиталось, причину покажет 10-tar.err. Хеши фиксируют полученные копии: по ним можно показать, что копии не менялись после сбора, но не то, что атакующий не правил логи раньше. В архив попадут /etc/shadow и ключи сервера, храните его как секрет. На Ubuntu журнал SSH-входов лежит в /var/log/auth.log. В Debian 12 этого файла по умолчанию нет — там все входы только в journald, их покажет journalctl -u ssh.service.

Оценить масштаб: как атакующий вошёл и что успел

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

# пользователи с UID 0 и с рабочей оболочкой
getent passwd | awk -F: '$3==0 || $7 !~ /(nologin|false)$/'
# ключи доступа
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys
# cron: задания пользователей, системный crontab и каталоги заданий
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
cat /etc/crontab /etc/cron.d/*
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /var/spool/cron/crontabs
# службы и таймеры systemd, свежие юниты сверху
systemctl list-units --type=service --state=running --no-pager
systemctl list-timers --all --no-pager
ls -lt /etc/systemd/system | head -30
# подмена библиотек — приём руткитов; файл обычно пустой или отсутствует, любую строку в нём нужно объяснить
cat /etc/ld.so.preload 2>/dev/null
# системные файлы, изменённые после установки пакетов (конфиги отфильтрованы)
dpkg --verify | grep -v " c /"
# файлы, изменённые за 7 дней
find / -xdev -type f -mtime -7 -not -path "/proc/*" -not -path "/var/log/*" -printf "%TY-%Tm-%Td %TH:%TM %p\n" 2>/dev/null | sort -r | head -200

Блок покрывает основные места автозапуска, но не все: задания at, скрипты в каталогах cron и профили оболочек проверяют отдельно. Ключ -xdev в find не заходит на другие файловые системы: если /home, /var, /srv или данные сайтов лежат на отдельных томах (их покажет df -hT), повторите поиск, заменив / на точку монтирования каждого тома. Время изменения файлов атакующий умеет подделать, поэтому опорной точкой служат логи: первый вход с незнакомого IP, первая ошибка в логе веб-сервера, дата появления чужого ключа. Если в dpkg --verify всплыли изменённые бинарники из /usr/bin или /usr/sbin, систему дальше не лечат — только переустановка.

Второй шаг — составить список всего, что лежало на сервере и даёт доступ куда-то ещё. Команда ниже находит типичные файлы с секретами:

find / -xdev -type f \( -name ".env" -o -name "wp-config.php" -o -name "id_rsa" -o -name "id_ed25519" \
  -o -name "*.pem" -o -name "credentials" -o -name ".git-credentials" -o -name ".pgpass" -o -name ".my.cnf" \) \
  -not -path "/proc/*" -not -path "/usr/*" -not -path "/etc/ssl/*" 2>/dev/null

Ограничение -xdev здесь то же: отдельные тома проверяют отдельно. К найденному добавьте то, что команда не ловит: токены ботов в коде, ключи в переменных окружения сервисов, пароли от репозиториев бэкапов. В октябрьской атаке сборщик искал, среди прочего, пароли бэкапов restic и Borg, токены GitHub и GitLab, ключи AWS и API-ключи ИИ-сервисов (ForestsNet). Закрытые ключи TLS-сертификатов из /etc/letsencrypt тоже считаются раскрытыми — сертификаты придётся перевыпустить.

Отдельно проверьте, куда ходил сам сервер: история команд покажет SSH-подключения к другим машинам, деплой-ключи ведут в репозитории, строки подключения — к базам на соседних хостах. Каждую такую систему проверяют теми же командами.

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

Секреты меняют с чистого устройства и в правильном месте. Если сервер продолжает работать со старой уязвимостью, новые пароли уйдут атакующему так же, как старые. Аскар Добряков из «К2 Кибербезопасность» по поводу инцидента с VMmanager предупреждал: пока уязвимость не закрыта, одной смены паролей мало (Код.ру, 20.10.2026). Порядок — от того, что ведёт к деньгам и чужим системам, к остальному:

1. Криптокошельки. Если на сервере лежали ключи кошельков или seed-фразы, переведите средства на новые кошельки, созданные на другом чистом устройстве. Смена пароля кошелька здесь не помогает — так советуют FirstVDS и ForestsNet.
2. Аккаунт хостера и регистратора домена. Новый пароль и двухфакторная аутентификация. Через эти аккаунты переустанавливают серверы и меняют DNS.
3. Облака, платёжные системы, Git. Старые ключи и токены отзывают в самом сервисе, а не только выпускают новые, иначе украденные продолжат работать. Проверьте копии старых ключей в CI/CD и скриптах.
4. Базы данных, панели сайтов, почта, токены ботов, пароли бэкапов. Для WordPress замените ключи и соли в wp-config.php: это разлогинит все активные сессии, включая сессию атакующего.
5. SSH и root. Сгенерируйте новую пару ключей на своём компьютере, удалите старые публичные ключи со всех серверов, отключите вход по паролю. Пошагово это описано в нашем гайде по настройке SSH на VPS.

ForestsNet формулирует главное так: «Переустановка сервера этого не заменяет: скопированные ключи и токены остаются рабочими, пока их не сменить».

Переустановка или лечение: как решить

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

Последняя строка таблицы — случай VMmanager 6, где сценарии у провайдеров различались. FirstVDS сообщает, что описанный ею сборщик диски клиентских серверов не менял. ForestsNet подчёркивает, что одна переустановка не спасает. MHost советовала клиентам переустановить систему и восстановиться из проверенного бэкапа (SecurityLab, 20.10.2026). Переустановка снимает вопрос о скрытых изменениях, смена секретов обесценивает украденное — и если есть сомнения в чистоте системы, делают обе.

Восстановление из проверенного бэкапа

Копии, сделанные после предполагаемого начала компрометации, могут содержать изменения атакующего. В октябрьской истории между первым следом у Senko Digital и атакой на FirstVDS прошло пять дней, у ForestsNet первые следы датированы 12 октября. Ориентир — дата самого раннего следа, найденного на этапе оценки масштаба, а не дата обнаружения. Более ранние копии тоже проверяют: самые первые следы могли не сохраниться в логах.

Восстанавливают данные, а не систему. Контент сайта, дамп базы, загруженные файлы, код из репозитория — да. Каталог /etc целиком, crontab, authorized_keys, бинарники и systemd-юниты из бэкапа — нет: их настраивают заново по документации. Перед заливкой данные проверяют: PHP-файлы в папке загрузок сайта — почти всегда шелл, в WordPress ядро сверяют с официальным дистрибутивом командой wp core verify-checksums, дамп базы просматривают на чужих учётных записях администраторов.

Сначала поднимают новый сервер с чистой ОС и закрытой точкой входа: обновления, SSH по ключам, файрвол, fail2ban. Базовую настройку покрывает наш чек-лист первых двух часов на новом сервере, правила фильтрации — гайд по файрволу на Linux. Потом данные и новые секреты. Последним шагом переключают DNS, а старый сервер со снапшотом держат до конца расследования. Как перенести проект без простоя, мы описали в статье о переезде сервера к другому провайдеру.

Если бэкапов не было или они лежали на том же сервере, после восстановления стоит сразу настроить схему 3-2-1 — по гайду о бэкапах VPS или на отдельном сервере для копий.

Кого уведомить: хостер, клиенты, юрист по 152-ФЗ

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

Роскомнадзор, если на сервере были персональные данные. Имена, телефоны, email клиентов, заказы в интернет-магазине, анкеты в боте — это ПДн. Часть 3.1 статьи 21 152-ФЗ касается случаев, когда выявлена неправомерная или случайная передача персональных данных, включая доступ к ним, повлёкшая нарушение прав субъектов. С момента выявления такого инцидента оператор обязан уведомить Роскомнадзор дважды: в течение 24 часов — об инциденте, предполагаемых причинах и вреде, принятых мерах и контактном лице; в течение 72 часов — о результатах внутреннего расследования. Уведомление подают на бумаге или в электронной форме через портал персональных данных (приказ Роскомнадзора № 187 от 14.11.2022). Кроме того, оператор обязан информировать ГосСОПКА о компьютерных инцидентах, повлёкших утечку ПДн (ч. 12 ст. 19 152-ФЗ).

За неуведомление или опоздание часть 11 статьи 13.11 КоАП предусматривает штраф: для граждан — от 50 до 100 тысяч рублей, для должностных лиц — от 400 до 800 тысяч, для юрлиц — от 1 до 3 млн рублей (редакция на 21.10.2026). Решать, был ли инцидент утечкой и что писать в уведомлении, лучше вместе с юристом — FirstVDS в своём заявлении советует пострадавшим именно это. Сроки при этом не ждут юриста: и 24, и 72 часа отсчитываются с момента выявления инцидента.

Клиенты и пользователи. Если утекли их данные или пароли, сообщите, что именно утекло и что сделать: сменить пароль, не доверять звонкам «из службы безопасности».

Взломали сервер и требуют деньги: что делать

Если файлы зашифрованы или атакующий грозит опубликовать украденное, платить не стоит. Позиция ФБР сформулирована так: выкуп не гарантирует возврата данных и подталкивает преступников к новым атакам (IC3, ФБР). Проект No More Ransom, который запустили полиция Нидерландов, Европол, «Лаборатория Касперского» и McAfee, тоже рекомендует не платить: гарантий получить ключ для расшифровки нет.

Порядок действий при вымогательстве:

• не вступайте в переписку и не удаляйте записку о выкупе — сохраните её, адреса кошельков, контакты и заголовки писем;
• определите шифровальщик по расширению зашифрованных файлов и проверьте, нет ли для него бесплатного дешифратора на No More Ransom;
• восстановите данные из бэкапа старше первого следа на новом сервере, а не на заражённом;
• если атакующий грозит слить базу с персональными данными, сразу проверьте признаки доступа к ней; при выявлении инцидента из ч. 3.1 ст. 21 152-ФЗ уведомляйте Роскомнадзор, не дожидаясь публикации;
• подайте заявление в полицию — по статье 141 УПК его можно сделать устно или письменно.

Такие действия подпадают под статьи 163 УК РФ (вымогательство) и 272 УК РФ (неправомерный доступ к компьютерной информации), окончательную квалификацию даёт следствие. К заявлению приложите собранные логи с файлом хешей, снапшот и хронологию — именно для этого их и собирали в первый час.

Чек-лист на 24 часа после взлома сервера

Что в сухом остатке

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

Если проект переезжает к другому провайдеру, варианты есть в каталоге VPS и VDS и в подборке защищённых VPS-хостингов. Спросите провайдера, закрыта ли его панель управления от интернета и как быстро он уведомляет клиентов об инцидентах — после октября 2026 года это не теоретический вопрос.