Безопасность VPS: UFW, Fail2Ban и SSH-hardening — полный чеклист 2026

Новый VPS сервер по умолчанию уязвим: открытый SSH-порт 22, пустой файрвол, root-пароль для входа. Каждую минуту боты сканируют IP-адреса и пытаются подобрать пароль по словарю. Без базовой защиты сервер компрометируют за часы.

В этом гайде — пошаговая настройка безопасности VPS на Ubuntu 22.04/24.04: UFW файрвол, Fail2Ban защита от брутфорса, SSH-hardening. 20.10.2026 мы прошли команды этой статьи на чистом сервере с Ubuntu 24.04 — что пришлось исправить, сказано на своих местах и в разделе «Проверка на сервере 20.10.2026».

Шаг 1. Обновить систему и создать non-root пользователя:

apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy

Шаг 2. Настроить SSH-ключи (на ВАШЕМ компьютере):

ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id deploy@YOUR_VPS_IP

После копирования ключа проверьте подключение: ssh deploy@YOUR_VPS_IP — должен пустить без пароля.

Если образ запрещает вход по паролю, ssh-copy-id не сработает. Проверить: sudo sshd -T | grep passwordauthentication — ответ «no» значит запрет. Так было на проверке 20.10 у Timeweb Cloud при заказе с SSH-ключом: запрет ставил файл /etc/ssh/sshd_config.d/50-cloud-init.conf. Тогда скопируйте ключ из сессии root:

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh && chmod 600 /home/deploy/.ssh/authorized_keys

Порядок решает всё: сначала ключ и проверка входа по ключу (шаг 2 выше), потом — отключение паролей. Наоборот — и сервер закроется для вас самих. Ниже — как это устроено на Ubuntu 24.04; так настроен и наш сервер.

Настройки SSH лежат не только в /etc/ssh/sshd_config, но и в файлах /etc/ssh/sshd_config.d/*.conf — их кладут образ провайдера и cloud-init. Строка Include с ними стоит в начале основного файла, а sshd берёт первое встреченное значение (так в man sshd_config). Сначала посмотрите, что уже задано:

sudo grep -v '^#' /etc/ssh/sshd_config.d/*.conf
sudo sshd -T | grep -E '^(port|passwordauthentication|permitrootlogin) '

Если в одном из этих файлов стоит PasswordAuthentication yes, строка no в основном файле не сработает: пароль останется включённым, хотя в конфиге написано обратное. Свои настройки положите отдельным файлом с номером меньше 50 — он прочитается первым:

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

Содержимое файла:

# Нестандартный порт вместо 22
Port 2222
# Запрет входа root (нужен свой пользователь с sudo — шаг 1)
PermitRootLogin no
# Только ключи: пароль не пройдёт ни напрямую, ни через PAM
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
# Не больше трёх попыток за подключение
MaxAuthTries 3
# Обрыв зависших сессий
ClientAliveInterval 300
ClientAliveCountMax 2

Если отдельного пользователя с sudo нет и вы входите под root, вместо PermitRootLogin no поставьте prohibit-password: root будет входить только по ключу. Так у нас.

Проверка конфига перед перезапуском — пустой вывод значит, что ошибок нет; с ошибкой sshd не поднимется:

sudo sshd -t

Если UFW уже включён, сначала откройте новый порт, иначе после перезапуска не пустит:

sudo ufw allow 2222/tcp

Как перезапустить, зависит от образа. На чистой Ubuntu 22.10 и новее порт слушает сокет systemd (ssh.socket), но образ провайдера может быть настроен иначе: на проверке 20.10 у Timeweb Cloud ssh.socket был masked, его перезапуск падал с ошибкой, а SSH слушала обычная служба. Поэтому сначала спросите систему:

systemctl is-enabled ssh.socket
# enabled          → sudo systemctl daemon-reload && sudo systemctl restart ssh.socket
# masked, disabled → sudo systemctl restart ssh
sudo ss -ltnp | grep sshd

Проверяйте ss, а не systemctl show ssh.socket -p Listen: на проверке 20.10 она показывала 2222, когда сервер ещё слушал 22. Закрой вы 22 по такой проверке — доступ к серверу пропал бы.

Не закрывайте текущую сессию, пока новое подключение не пустит: откройте второе окно и войдите ssh -p 2222 deploy@YOUR_VPS_IP. Только после этого закрывайте порт 22 в UFW.

UFW (Uncomplicated Firewall) — стандартный файрвол Ubuntu. Принцип: запрещаем всё, разрешаем только нужное.

# Базовая политика
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Разрешаем SSH (используйте ВАШ порт!)
sudo ufw allow 2222/tcp comment 'SSH'

# Веб-сервер
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Включаем файрвол
sudo ufw enable
sudo ufw status verbose

Не открывайте порты приложений (3000, 8080, 1337) напрямую — используйте Nginx reverse proxy.

Fail2Ban анализирует логи и блокирует IP-адреса после неудачных попыток входа.

sudo apt install fail2ban -y
sudo nano /etc/fail2ban/jail.d/sshd.local

Не копируйте jail.conf в jail.local целиком: секция [sshd] в нём уже есть, и вторая такая же роняет Fail2Ban при запуске. На проверке 20.10 так и вышло — «section 'sshd' already exists», служба в состоянии failed, защиты от перебора нет. Свои настройки — отдельным файлом в jail.d: он дополняет стандартные.

Содержимое /etc/fail2ban/jail.d/sshd.local:

[sshd]
enabled = true
port = 2222
maxretry = 3
findtime = 600
bantime = 3600

Jail для Nginx — только когда Nginx уже стоит. Фильтра nginx-badbots в Fail2Ban 1.0.2 из Ubuntu 24.04 нет — в поставке nginx-botsearch, nginx-http-auth, nginx-limit-req и nginx-bad-request (проверено 20.10). Каждый новый jail проверяйте командой fail2ban-client -t до перезапуска.

sudo fail2ban-client -t
sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

До перезапуска fail2ban-client -t должна ответить «OK: configuration test is successful». На проверке 20.10 с этим файлом после трёх неудачных входов адрес попал в бан: четвёртое подключение оборвано, пятое — «Connection refused».

Добавьте ignoreregex для поисковых ботов (Googlebot, YandexBot), чтобы они не попадали под бан.

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

• Автообновления безопасности: на образе Ubuntu 24.04 у Timeweb Cloud они уже включены (проверка 20.10: в /etc/apt/apt.conf.d/20auto-upgrades оба значения «1»); если нет — sudo apt install unattended-upgrades && sudo dpkg-reconfigure -plow unattended-upgrades
• 2FA для SSH: Google Authenticator (libpam-google-authenticator) для критически важных серверов
• Мониторинг: logwatch для ежедневных отчётов по email, journalctl для оперативного анализа
• Резервное копирование: ежедневный бэкап конфигов (/etc/), еженедельный полный бэкап

1. Обновить систему (apt update && upgrade)
2. Создать non-root пользователя с sudo
3. Настроить SSH-ключи (ed25519)
4. Отключить парольную аутентификацию SSH
5. Запретить root-логин по SSH
6. Сменить SSH-порт с 22 на нестандартный
7. Установить и настроить UFW
8. Установить и настроить Fail2Ban
9. Включить автоматические обновления безопасности
10. Настроить резервное копирование

Наш замер 20.10.2026. На чистом сервере Timeweb Cloud (2 vCPU, 2 ГБ, Ubuntu 24.04, заказ с SSH-ключом) мы прошли шаги статьи дословно; вход и порты проверяли снаружи, с другого компьютера, а перебор паролей — с нашего сервера.

• Образ провайдера уже запрещал вход по паролю (файл 50-cloud-init.conf, заказ с SSH-ключом), поэтому ssh-copy-id из шага 2 ключ не скопировал бы — нужен вариант из сессии root.
• Файл 10-hardening.conf проходит sshd -t. После перезапуска deploy по ключу на 2222 входит, root получает «Permission denied», вход по паролю отклонён, порт 22 закрыт.
• ssh.socket на этом образе отключён (masked): его перезапуск падает, а systemctl show ssh.socket показывает 2222 при фактическом 22. Сработал systemctl restart ssh.
• UFW по статье включается, снаружи отвечает только 2222.
• Fail2Ban по прежней редакции (копия jail.conf плюс вторая секция [sshd]) не запускался: «section 'sshd' already exists». С отдельным файлом jail.d/sshd.local запускается, и после трёх неудачных входов адрес банится.
• Автообновления безопасности на образе уже были включены.

Чего проверка не показывает: образы, где ssh.socket включён, заказ сервера с паролем вместо ключа и защиту Nginx — веб-сервер мы не ставили.

• AdminVPS — Anti-DDoS входит в тарифы VPS, от 349 руб/мес при помесячной оплате
• Timeweb Cloud — защита от DDoS на уровне всего облака по умолчанию, фильтрация L3, L4 и L7 подключается отдельно; серверы от 1 380 ₽/мес при оплате за месяц
• Timeweb — та же линейка Cloud MSK и те же цены, от 1 380 ₽/мес при оплате за месяц

Защита без наблюдения работает вслепую: атаку видно только по логам постфактум. Как поднять мониторинг VPS на Grafana и Prometheus с готовой панелью Node Exporter Full и алертами в Telegram — в отдельном руководстве.