Взломали сервер: пошаговый план

MAATRIX

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

Первое действие: изолировать сервер

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

Если у вас есть доступ к панели провайдера, самый чистый вариант — закрыть весь трафик фаерволом, оставив только своё подключение:

# разрешаем SSH только со своего IP, остальное режем
ufw default deny incoming
ufw default deny outgoing
ufw allow from ВАШ_IP to any port 22 proto tcp
ufw enable

Если фаервол уже скомпрометирован или вы не доверяете системе, отключите сетевой интерфейс из панели управления сервером (режим rescue или отключение порта). Сервер продолжит работать, но перестанет быть опасен для сети и недосягаем для атакующего. После изоляции сразу меняйте все пароли и SSH-ключи, к которым сервер имел доступ, — считайте их скомпрометированными.

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

Собираем улики, пока они живы

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

# кто и куда подключён прямо сейчас
ss -tunap
# процессы, отсортированные по нагрузке
ps auxf --sort=-%cpu | head -30
# кто заходил по SSH
last -30
grep -Ei 'accepted|failed password' /var/log/auth.log | tail -50
# автозагрузка и cron
crontab -l; ls -la /etc/cron.*; cat /etc/rc.local 2>/dev/null
systemctl list-units --type=service --state=running

Особое внимание — процессам с бессмысленными именами (наборы букв), майнерам (высокий CPU, соединения на пулы), и cron-заданиям, которые каждые несколько минут что-то скачивают через curl или wget. Скопируйте вывод в отдельный файл на своей машине — это ваш протокол инцидента.

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

Находим закладки и бэкдоры

Взломщик почти всегда оставляет способ вернуться: новый пользователь с sudo, свой SSH-ключ в authorized_keys, подменённый системный бинарник или веб-шелл в папке сайта. Проверьте всё по списку:

# новые пользователи с UID 0 или sudo-правами
awk -F: '
==0{print 
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Заказать чистый VPS
Находим закладки и бэкдоры
Взломщик почти всегда оставляет способ вернуться: новый пользователь с sudo, свой SSH-ключ в authorized_keys, подменённый системный бинарник или веб-шелл в папке сайта. Проверьте всё по списку:
# новые пользователи с UID 0 или sudo-правами
awk -F: '$3==0{print $1}' /etc/passwd
getent group sudo; getent group wheel
# чужие SSH-ключи
for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do echo "== $f"; cat "$f" 2>/dev/null; done
# недавно изменённые файлы за 5 дней
find / -xdev -mtime -5 -type f 2>/dev/null | grep -vE '/proc|/sys|/var/log' | head -60
# веб-шеллы в корне сайта
grep -RilE 'eval\(|base64_decode|system\(|passthru\(' /var/www 2>/dev/null | head
Любой SSH-ключ, который вы не добавляли, — это дверь атакующего, удаляйте её. Пользователи с UID 0, кроме root, недопустимы. Если находите подменённые ls, ps, netstat (руткит скрывает свои процессы), доверять системе больше нельзя — переходите к полной переустановке.
Решаем: чистить или переустанавливать
Здесь важна честность. Если взлом поверхностный — подобрали слабый пароль, залили веб-шелл через дырявый плагин, — сервер реально вычистить. Но если есть признаки руткита, подменённых системных утилит или вы просто не уверены в масштабе, единственный надёжный путь — переустановить систему с нуля. Полудоверенный сервер опаснее, чем очевидно взломанный: вы будете считать его чистым, а бэкдор останется.
Практичный компромисс — поднять новый чистый VPS, перенести на него только данные (не бинарники и не конфиги целиком), а старую машину сохранить в изоляции для расследования. Это быстрее и надёжнее, чем неделю вычищать заражённую систему и всё равно сомневаться. По времени переустановка почти всегда выигрывает: развернуть свежий образ и накатить данные — это часы, а полная ревизия скомпрометированной системы с гарантией — это дни, и без гарантии в конце.
Есть и рациональный аргумент про доверие. Пока вы не уверены на сто процентов, что нашли все закладки, вы будете держать в голове тревогу при каждом странном поведении сервера. Чистая машина снимает этот фон полностью: вы точно знаете, что стартовали с проверенного состояния. Для боевого сервиса, от которого зависят клиенты, это спокойствие стоит больше, чем сэкономленное на переустановке время.
Восстанавливаем доступ и данные
На чистой машине наводите порядок сразу правильно. Данные переносите выборочно: дампы баз, файлы пользователей, статику сайта — но проверяйте их на те же веб-шеллы перед заливкой. Пароли и ключи генерируйте новые, старые нигде не используйте повторно.
# новый SSH-ключ на вашей машине
ssh-keygen -t ed25519 -C "new-key-2026"
# перенос ключа на чистый сервер
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@НОВЫЙ_IP
# восстановление базы из проверенного дампа
mysql -u root -p mydb < dump.sql
После восстановления обновите все пакеты (apt update && apt upgrade), закройте лишние порты и только потом открывайте сайт наружу. Не спешите возвращать сервис в бой, пока не убедились, что дыру, через которую вошли, вы закрыли.
Почему вообще смогли войти
Чтобы взлом не повторился, поймите причину. В 90% случаев это одно из трёх: слабый или переиспользованный пароль root по SSH, устаревшее ПО с известной уязвимостью (старый WordPress, плагин, панель), или открытый наружу сервис без пароля (Redis, база данных, Docker API). Проверьте логи на брутфорс SSH — если видите тысячи Failed password, вход был именно там.
Реже, но бывает: утёкший ключ из чужого репозитория, скомпрометированный CI, доступ через соседний сайт на том же аккаунте шаред-хостинга. Определив вектор, вы закроете именно ту дверь, а не будете угадывать.
Профилактика: чтобы не повторилось
Базовая гигиена снимает подавляющее большинство рисков. Настройте её один раз на чистом сервере:
Вход по SSH только по ключу, пароль отключён: PasswordAuthentication no в /etc/ssh/sshd_config.
Фаервол по умолчанию закрыт, открыты только нужные порты.
Автоматические обновления безопасности: unattended-upgrades.
fail2ban для блокировки брутфорса.
Базы и кэши (MySQL, Redis) слушают только 127.0.0.1, не наружу.
Регулярные бэкапы на отдельное хранилище, которые атакующий не сможет стереть с самого сервера.
Отдельный момент — начинать с чистой машины. Брать VPS у провайдера, где вы контролируете образ и IP, надёжнее, чем разбираться с чужим наследством. У MAATRIX можно поднять свежий сервер в RU, US или UK за пару минут и с оплатой из России картой или криптой — удобно, когда старую машину нужно срочно заменить.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Заказать чистый VPS
}' /etc/passwd
getent group sudo; getent group wheel
# чужие SSH-ключи
for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do echo "== $f"; cat "$f" 2>/dev/null; done
# недавно изменённые файлы за 5 дней
find / -xdev -mtime -5 -type f 2>/dev/null | grep -vE '/proc|/sys|/var/log' | head -60
# веб-шеллы в корне сайта
grep -RilE 'eval\(|base64_decode|system\(|passthru\(' /var/www 2>/dev/null | head

Любой SSH-ключ, который вы не добавляли, — это дверь атакующего, удаляйте её. Пользователи с UID 0, кроме root, недопустимы. Если находите подменённые ls, ps, netstat (руткит скрывает свои процессы), доверять системе больше нельзя — переходите к полной переустановке.

Решаем: чистить или переустанавливать

Здесь важна честность. Если взлом поверхностный — подобрали слабый пароль, залили веб-шелл через дырявый плагин, — сервер реально вычистить. Но если есть признаки руткита, подменённых системных утилит или вы просто не уверены в масштабе, единственный надёжный путь — переустановить систему с нуля. Полудоверенный сервер опаснее, чем очевидно взломанный: вы будете считать его чистым, а бэкдор останется.

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

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

Восстанавливаем доступ и данные

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

# новый SSH-ключ на вашей машине
ssh-keygen -t ed25519 -C "new-key-2026"
# перенос ключа на чистый сервер
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@НОВЫЙ_IP
# восстановление базы из проверенного дампа
mysql -u root -p mydb < dump.sql

После восстановления обновите все пакеты (apt update && apt upgrade), закройте лишние порты и только потом открывайте сайт наружу. Не спешите возвращать сервис в бой, пока не убедились, что дыру, через которую вошли, вы закрыли.

Почему вообще смогли войти

Чтобы взлом не повторился, поймите причину. В 90% случаев это одно из трёх: слабый или переиспользованный пароль root по SSH, устаревшее ПО с известной уязвимостью (старый WordPress, плагин, панель), или открытый наружу сервис без пароля (Redis, база данных, Docker API). Проверьте логи на брутфорс SSH — если видите тысячи Failed password, вход был именно там.

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

Профилактика: чтобы не повторилось

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

• Вход по SSH только по ключу, пароль отключён: PasswordAuthentication no в /etc/ssh/sshd_config.
• Фаервол по умолчанию закрыт, открыты только нужные порты.
• Автоматические обновления безопасности: unattended-upgrades.
• fail2ban для блокировки брутфорса.
• Базы и кэши (MySQL, Redis) слушают только 127.0.0.1, не наружу.
• Регулярные бэкапы на отдельное хранилище, которые атакующий не сможет стереть с самого сервера.

Отдельный момент — начинать с чистой машины. Брать VPS у провайдера, где вы контролируете образ и IP, надёжнее, чем разбираться с чужим наследством. У MAATRIX можно поднять свежий сервер в RU, US или UK за пару минут и с оплатой из России картой или криптой — удобно, когда старую машину нужно срочно заменить.

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