Подозрение на взлом VPS обычно начинается с конкретных симптомов: резкий рост исходящего трафика на графиках панели хостера, письмо от провайдера об abuse-жалобе, нагрузка CPU под 100% без запущенных вами задач или невозможность войти по SSH под своим паролем. Любой из этих признаков — повод немедленно проверить сервер, а не ждать, пока хостер заблокирует машину за рассылку спама или участие в DDoS.
В этой статье разберём, как отличить взлом от обычной перегрузки, какие логи и процессы проверять в первую очередь, как отрезать злоумышленника от сервера и какие меры защиты снизят риск повторной компрометации. Материал ориентирован на владельцев VPS под управлением Linux, которые администрируют сервер самостоятельно.
Типичные признаки компрометации VPS
Взлом редко бывает полностью незаметным. Злоумышленники используют чужой сервер для конкретных задач — майнинга, рассылки спама, брутфорса других машин или размещения фишинговых страниц, и каждая из них оставляет следы в системе.
- 🔥 Постоянная нагрузка CPU или диска без ваших процессов — частый признак скрытого майнера.
- 📤 Аномальный исходящий трафик — сервер может участвовать в атаках или рассылке спама.
- 🔑 Невозможность войти по SSH при верном пароле — пароль или ключи могли быть изменены.
- 📄 Незнакомые файлы в каталогах
/tmp,/dev/shm, веб-каталогах сайтов. - ✉️ Abuse-уведомление от хостера — часто это первое официальное подтверждение взлома.
Один признак сам по себе ещё ничего не доказывает: высокая нагрузка бывает и от «утёкшего» скрипта, а трафик — от резервного копирования. Тревожиться стоит, когда совпадают два-три симптома одновременно.
Как проверить сервер: процессы, сеть, логи
Начните со списка процессов. Команда top или htop покажет, что потребляет ресурсы. Обращайте внимание на процессы со странными именами, запущенные от неизвестных пользователей или из нестандартных путей.
ps aux --sort=-%cpu | head -20
ss -tulpn
last -20
Команда ss -tulpn покажет открытые порты и связанные с ними процессы — так можно обнаружить бэкдор, слушающий нестандартный порт. Вывод last отобразит историю входов в систему: ищите сессии с IP-адресов, которые вам не принадлежат.
Далее проверьте логи авторизации. В системах на базе Debian/Ubuntu это /var/log/auth.log, в RHEL-подобных — /var/log/secure. Массовые строки Failed password говорят о брутфорсе, а успешный вход с чужого IP после серии неудачных попыток — о том, что подбор, возможно, удался.
Проверка автозагрузки и учётных записей
Закрепление в системе — стандартный шаг после взлома. Проверьте механизмы автозапуска, через которые вредоносное ПО переживает перезагрузку сервера.
- ⏰ Cron:
crontab -lдля каждого пользователя и содержимое/etc/cron.d/,/etc/crontab. - ⚙️ Systemd-сервисы: незнакомые юниты в
/etc/systemd/system/. - 👤 Новые пользователи: записи в
/etc/passwdс UID 0 или недавно созданные учётные записи. - 🗝️ SSH-ключи: файл
~/.ssh/authorized_keys— туда часто добавляют свой ключ для беспарольного доступа.
Особое внимание уделите файлу authorized_keys у root: чужой ключ в нём — почти стопроцентное подтверждение взлома и готовый канал повторного доступа, даже если вы смените пароль.
Что делать при подтверждённом взломе
Если компрометация подтвердилась, действуйте по порядку. Сначала изолируйте сервер: ограничьте сетевой доступ через файрвол или панель хостера, оставив только свой IP для SSH. Это остановит утечку данных и использование машины для атак.
Затем смените все пароли — root, пользователей системы, панели управления, баз данных. Удалите чужие SSH-ключи и подозрительные учётные записи. Однако полная очистка заражённой системы вручную ненадёжна: руткиты умеют скрывать процессы и файлы от стандартных утилит.
⚠️ Внимание: единственный способ гарантированно вернуть доверие к системе после взлома — переустановка ОС с нуля и восстановление данных из заведомо чистой резервной копии. «Почищенный» сервер может содержать скрытые бэкдоры, которые вы не нашли.
☑️ Действия при взломе VPS
Откуда берутся взломы: типичные векторы атак
Понимание источника атаки важно, чтобы не наступить на те же грабли после переустановки. Наиболее распространённые причины компрометации VPS — это слабые пароли к SSH с открытым 22 портом, устаревшее ПО с известными уязвимостями и взломанные сайты через дыры в CMS или плагинах.
| Вектор атаки | Как обнаружить | Как закрыть |
|---|---|---|
| Брутфорс SSH-пароля | Массовые Failed password в auth.log | Ключевая аутентификация, запрет входа по паролю |
| Уязвимость в CMS/плагине | Чужие файлы в каталогах сайта, web-shell | Обновление CMS и плагинов, WAF |
| Устаревшее ПО сервера | Старые версии пакетов с публичными CVE | Регулярные обновления системы |
| Утечка пароля панели хостера | Входы в панель с чужих IP | Двухфакторная аутентификация, новый пароль |
Иногда вектор установить не удаётся — логи могли быть очищены атакующим. В этом случае применяйте весь комплекс защитных мер, а не только точечную заплатку.
Базовая защита VPS от взлома
Защита сервера строится вокруг нескольких понятных мер. Первая — аутентификация по SSH-ключам с отключением входа по паролю: в файле /etc/ssh/sshd_config параметр PasswordAuthentication no. Это одно изменение отсекает подавляющее большинство автоматических атак подбора.
Вторая мера — минимизация открытых портов. Файрволом (ufw, iptables или nftables) разрешайте только те порты, которые реально используются: SSH, HTTP/HTTPS для веб-сервера. Дополнительно можно установить fail2ban, который временно блокирует IP после серии неудачных попыток входа.
Стоит ли менять порт SSH с 22 на нестандартный?
Смена порта сокращает объём автоматического сканирования в логах, но не является реальной защитой — целевая атака найдёт открытый порт сканированием. Используйте нестандартный порт как дополнение к ключам и fail2ban, а не как замену им.
Третий блок — регулярные обновления и резервные копии. Автоматические обновления безопасности (например, unattended-upgrades в Debian/Ubuntu) закрывают свежие уязвимости без вашего участия. Бэкапы храните вне сервера: копия на той же машине при взломе будет скомпрометирована вместе с основными данными.
Чего делать не стоит после обнаружения взлома
Паника приводит к ошибкам, которые мешают разбору инцидента или усугубляют его. Не удаляйте подозрительные файлы и логи до того, как сохранили их копии, — это улики, по которым определяется вектор атаки.
⚠️ Внимание: не ограничивайтесь сменой пароля root и продолжением работы. Если атакующий получил root-доступ, он мог установить несколько независимых механизмов возврата в систему, и смена пароля закроет лишь один из них.
Также не стоит запускать случайные «антивирусные скрипты для Linux» из форумов от имени root — часть таких «решений» сама является вредоносной. Используйте известные инструменты вроде rkhunter или chkrootkit только как вспомогательную проверку, понимая, что они не гарантируют обнаружение всех руткитов.
Ответы на частые вопросы
Хостер заблокировал VPS за спам — это точно взлом?
Очень вероятно, но не гарантированно. Спам может рассылать и скомпрометированный сайт через уязвимую форму обратной связи. Проверьте очередь почты, логи веб-сервера и список процессов, прежде чем делать выводы.
Достаточно ли сменить пароль root после взлома?
Нет. При root-доступе атакующий мог добавить SSH-ключи, создать новых пользователей, прописать задачи в cron и установить бэкдоры. Надёжный вариант — переустановка системы с восстановлением данных из чистой копии.
Можно ли вычислить, кто взломал сервер?
IP-адрес в логах обычно ведёт на другой взломанный сервер, VPN или прокси, поэтому реального исполнителя установить практически невозможно. Практическая ценность анализа логов — определить вектор атаки и закрыть его.
Защищён ли VPS, если я пользуюсь только панелью управления хостера?
Нет. Панель управления — лишь интерфейс: сам сервер с открытым SSH, слабыми паролями и устаревшим ПО остаётся уязвимым. Защита настраивается на уровне операционной системы и приложений.
Как часто нужно делать резервные копии?
Зависит от того, какой объём данных вы готовы потерять. Для активно обновляемых проектов разумна ежедневная копия, для статичных — реже. Главное условие: бэкапы должны храниться отдельно от самого сервера и периодически проверяться на восстановление.