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

Краткий ответ: Изолируйте сервер (блокировка файрволом или выключение из Клиентской панели), оцените ситуацию через KVM Console, сохраните доказательства, смените все учётные данные с чистого устройства, а затем отстройте заново: переустановите ОС и восстановите данные из бэкапа, сделанного до компрометации. Чистке системы, где у атакующего был root, «на месте» почти никогда нельзя доверять.

Обзор

Как только атакующий получил root, подозрительны каждый бинарник, cron-задача и аккаунт на машине. Профессиональный план: сдержать → расследовать → отстроить, именно в этом порядке. Скорость важна вдвойне: чтобы ограничить ущерб вашим данным и чтобы сервер не атаковал других — это также вопрос политики по злоупотреблениям.

Что нужно иметь

• Доступ к Клиентской панели (управление питанием, KVM Console) с доверенного устройства.
• Последний чистый бэкап и его дату.
• Чистую машину для всей работы по восстановлению — считайте, что ваши обычные ключи/пароли могли украсть.

Пошаговая инструкция

1. Сдержите: заблокируйте весь входящий/исходящий трафик, кроме вашего админ-IP, на файрволе или остановите сервер со страницы услуги, если он активно атакует других.
2. Оцените через KVM Console: ищите неизвестных пользователей (/etc/passwd), процессы (ps auxf), сокеты (ss -tulpn), записи cron, SSH-ключи в authorized_keys и следы входа в логах аутентификации и веб-логах.
3. Сохраните доказательства: скопируйте нужные логи с сервера перед очисткой, если нужен разбор причин или отчёт.
4. Смените учётные данные с чистого устройства: пароль Клиентской панели, SSH-ключи, секреты приложений, ключи БД и API — всё, что знала машина.
5. Отстройте: переустановите ОС, защитите её (чек-лист), закройте уязвимость-вход, затем восстановите данные приложений из докомпрометационного бэкапа — см. также инструкцию с фокусом на восстановление.
6. Проверьте перед запуском: обновлённые пакеты, отсутствие восстановленных веб-шеллов (просканируйте восстановленные данные — инструкция по сканированию), мониторинг на месте.

Типичные проблемы

• Удалить вредонос и жить дальше: персистентность живёт в cron, systemd-юнитах, SSH-ключах и подменённых бинарниках — лучше отстройте заново.
• Восстановление заражённого бэкапа: сканируйте восстановленное содержимое и берите бэкап с даты до вторжения.
• Не закрытая точка входа: тот же уязвимый плагин эксплуатируют повторно за считаные дни.

Когда обращаться в поддержку

Сообщите поддержке Cloud2Y, если сервер рассылал abuse (спам, сканирования, флуды), если вы получили abuse-уведомление или нужна помощь с питанием/KVM во время сдерживания. Проактивная коммуникация делает восстановление сотрудничеством, а не принуждением.

Частые вопросы

Какой самый первый шаг после обнаружения взлома?

Сдерживание: заблокируйте трафик на файрволе, кроме вашего админ-IP, или выключите сервер из Клиентской панели, если он активно атакует других. Расследование — после изоляции.

Можно просто удалить вредоносное ПО и работать дальше?

Это рискованно — атакующие с root оставляют закладки в cron, systemd-юнитах, SSH-ключах и подменённых бинарниках. Единственное надёжное состояние — чистая переустановка ОС плюс восстановленные данные.

Должен ли я сообщать Cloud2Y о взломе сервера?

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

Похожие статьи

• Что делать, если сервер скомпрометирован
• Как проверить сервер на вредоносное ПО
• Как читать логи аутентификации
• Политика по злоупотреблениям и запрещённые действия

Нужна помощь? Связаться с поддержкой Cloud2Y →