Материал подготовлен командой Simple-Server для администраторов VPS. Команды проверяйте на тестовом сервере или через отдельную SSH-сессию, чтобы не потерять доступ.
Что делать, если VPS пытаются взломать
На публичном VPS с открытым SSH (порт 22) сотни и тысячи попыток входа в сутки — обычное дело. Боты сканируют весь IPv4-интернет и перебирают логины root, admin, ubuntu с типовыми паролями.
Это не значит, что сервер уже взломан. В 99% случаев это фоновый brute-force — шум, который нужно правильно отфильтровать и закрыть базовой защитой.
Ниже — как отличить «шум» от реальной проблемы и что сделать прямо сейчас.
Шаг 0. Паниковать или нет?
| Ситуация | Что это | Срочность |
|---|---|---|
В логах Failed password for root с разных IP | Автоматический перебор паролей | Низкая — настройте защиту |
Появились успешные входы Accepted password с незнакомых IP | Возможный взлом | Высокая |
| Незнакомые процессы, 100% CPU, исходящий майнинг | Компрометация | Критическая |
| Письма от хостера об abuse / спам с вашего IP | Взлом почты или relay | Высокая |
Если есть успешный вход с чужого IP или подозрительная активность — переходите сразу к разделу «Если сервер уже взломан». Если только неудачные попытки — достаточно усилить SSH.
Шаг 1. Посмотреть, что происходит
Подключитесь по SSH и проверьте логи. Подробнее — в статье про логи SSH.
Неудачные попытки (brute-force)
# Ubuntu/Debian — классический auth.log
grep 'Failed password' /var/log/auth.log | tail -30
# Системы с journald
journalctl -u ssh -n 100 --no-pager | grep -i 'failed\|invalid'
# Кто и с каких IP стучался
grep 'Failed password' /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20Успешные входы — критично проверить
grep 'Accepted' /var/log/auth.log | tail -30
last -20
lastb | head -20Если в Accepted есть IP, которых вы не знаете, или вход под root с паролем — считайте инцидентом.
Топ IP по количеству попыток
grep 'Failed password' /var/log/auth.log \
| grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' \
| sort | uniq -c | sort -rn | head -15Шаг 2. Быстрая защита — Fail2ban (15 минут)
Fail2ban читает логи и временно блокирует IP после нескольких неудачных попыток. Это первое, что стоит включить на любом VPS с SSH.
apt update
apt install -y fail2ban
cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
backend = systemd
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 5
bantime = 86400
EOF
systemctl enable --now fail2ban
fail2ban-client status sshdПосле запуска:
# Заблокированные IP
fail2ban-client status sshd
# Разблокировать свой IP, если забанили себя
fail2ban-client set sshd unbanip ВАШ_IPПолная серия: Fail2ban — оглавление. Детальная настройка jail: Fail2ban для SSH.
Шаг 3. Усилить SSH (обязательный минимум)
Комбинация из трёх мер закрывает большинство автоматических атак:
3.1. SSH-ключи вместо пароля
# На своём ПК (не на сервере):
ssh-keygen -t ed25519 -C "admin@simple-server"
# Скопировать ключ на VPS:
ssh-copy-id root@IP_VPSПодробно: SSH-ключи вместо пароля.
3.2. Отключить вход root по паролю
# Сначала убедитесь, что ключ работает в другой сессии!
adduser deploy
usermod -aG sudo deploy
# скопируйте ключ и для deploy
nano /etc/ssh/sshd_configРекомендуемые параметры:
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
bash
sshd -t && systemctl reload sshdСтатья: Как отключить вход root по SSH.
3.3. Firewall — только нужные порты
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable
ufw status verboseКомбо UFW + Fail2ban: базовая защита VPS.
Дополнительно (по желанию)
- Ограничить SSH по IP — если у вас фиксированный офисный IP
- Сменить порт SSH — убирает часть «шума», но не заменяет ключи и Fail2ban
Шаг 4. Обновить систему и проверить сервисы
apt update && apt upgrade -y
ss -tulpnОткройте только то, что реально нужно:
| Порт | Обычно |
|---|---|
| 22 | SSH |
| 80, 443 | Веб |
| 25, 587, 465 | Почта (mailcow и т.п.) |
| 3306, 5432 | БД — не открывать наружу без VPN |
Если MySQL или Redis слушают 0.0.0.0 — закройте firewall или привяжите к 127.0.0.1.
Шаг 5. Мониторинг — не пропустить взлом
Раз в несколько дней (или через cron + почту):
# Подозрительные процессы и нагрузка
ps aux --sort=-%cpu | head -15
# Неожиданные слушающие порты
ss -tulpn | grep LISTEN
# Cron и автозапуск
ls -la /etc/cron.d/ /etc/cron.daily/
systemctl list-units --type=service --state=runningПодробнее: подозрительные процессы на Linux.
Можно поставить logwatch или auditd для еженедельных отчётов на e-mail.
Если сервер уже взломан
Действуйте быстро и не пытайтесь «лечить» production на месте, если не уверены в масштабе:
- Изолируйте — закройте лишние порты в UFW, смените пароли на других сервисах, если использовались повторно.
- Сохраните доказательства — скопируйте логи:
auth.log,journalctl, список процессов,crontab -lдля всех пользователей. - Не доверяйте скомпрометированной системе — злоумышленник мог оставить backdoor в cron,
.bashrc,authorized_keys, бинарниках. - Разверните новый VPS из чистого образа, восстановите данные из проверенного бэкапа (до даты взлома).
- Смените все секреты — SSH-ключи, пароли БД, API-токены, SMTP, панели.
- Разберите причину — слабый пароль, открытая БД, уязвимый плагин, старый Docker-образ.
Импортированный материал по восстановлению: см. также серию безопасность VPS.
Чек-лист «VPS под атакой, но не взломан»
- Проверил логи: есть только
Failed, нет чужихAccepted - Установил и настроил Fail2ban для
sshd - Включил UFW: deny incoming, allow SSH + нужные порты
- Перешёл на SSH-ключи, отключил
PasswordAuthentication - Отключил root по паролю или создал отдельного sudo-пользователя
- Выполнил
apt upgrade - БД и админки не торчат в интернет без необходимости
- Настроил бэкапы (снимки / rsync / restic)
Частые вопросы
Это атака на Simple-Server или только на мой VPS?
Brute-force идёт на ваш публичный IP, не «на хостинг целиком». У каждого VPS свой адрес — боты бьют по всему интернету. DDoS на L3–L4 фильтруется на стороне провайдера; brute-force по SSH — ваша зона ответственности (ключи, Fail2ban, firewall).
Нужно ли менять IP?
Обычно нет. Достаточно Fail2ban и отключения паролей. Смена IP имеет смысл, если IP попал в чёрные списки из-за спама/ abuse после реального взлома.
Поможет ли смена порта SSH с 22 на другой?
Частично — меньше шума в логах. Не заменяет ключи и Fail2ban. См. смена порта SSH.
Что делать, если Fail2ban не банит?
См. Fail2ban не банит IP — часто проблема в backend, пути к логам или journald.
Что дальше
→ Как защитить SSH от brute-force
→ Оглавление серии «Безопасность VPS»
VPS с защитой на Simple-Server
На VPS с DDoS-защитой фильтруется объёмный вредоносный трафик; SSH и приложения по-прежнему нужно harden'ить по этой инструкции. Заказать VPS — KVM, NVMe, root-доступ, поддержка 24/7.