Firewall на VPS: настройка ufw и fail2ban

Короткий ответ: на VPS нужны два разных механизма. ufw закрывает порты — он решает, какие службы вообще доступны из интернета. fail2ban реагирует на поведение — он читает логи и временно блокирует адреса, с которых идёт перебор паролей. Один не заменяет другой: ufw не заметит подбор пароля к разрешённому порту SSH, а fail2ban не закроет лишний открытый порт базы данных.

Порядок настройки важен: сначала включается firewall с разрешённым SSH, и только потом всё остальное. Если включить ufw, забыв разрешить SSH, доступ к серверу будет потерян.

Часть 1. ufw

ufw — надстройка над iptables с человеческим синтаксисом. Ставится и включается так:

apt install -y ufw

# СНАЧАЛА разрешаем SSH, иначе доступ будет потерян
ufw allow OpenSSH
# или конкретный порт, если SSH перенесён
# ufw allow 2022/tcp

ufw default deny incoming
ufw default allow outgoing
ufw enable
ufw status verbose

Порядок команд здесь не декоративный. ufw default deny incoming задаёт политику по умолчанию, а ufw enable применяет её немедленно. Правило для SSH должно существовать к этому моменту.

Что открывать

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

Проверка

ufw status numbered          # список правил с номерами
ufw delete 3                 # удалить правило по номеру
ufw allow from 203.0.113.7 to any port 22   # доступ только с одного адреса
ufw reload                   # применить изменения

Отдельно стоит проверить, что сервер не слушает лишнего:

ss -tlnp

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

Часть 2. fail2ban

fail2ban читает логи и на время блокирует адреса, которые ведут себя подозрительно: перебирают пароли, сканируют пути, превышают лимит запросов.

apt install -y fail2ban

Основную конфигурацию правят не в jail.conf, а в jail.local — файл jail.conf перезаписывается при обновлении пакета.

Файл /etc/fail2ban/jail.local:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled  = true
port     = ssh
backend  = systemd
maxretry = 3
bantime  = 24h

Директива backend = systemd указывает читать журнал через systemd вместо файла. Это надёжнее: расположение логов аутентификации отличается между выпусками Ubuntu, а journalctl есть всегда.

Применение и проверка:

systemctl enable --now fail2ban
systemctl restart fail2ban
fail2ban-client status
fail2ban-client status sshd

Вывод покажет число неудачных попыток и список заблокированных адресов. Если список пуст, а в логах попытки есть — значит выбран неверный backend или фильтр не совпадает с форматом записей.

Разблокировка

fail2ban-client set sshd unbanip 203.0.113.7

Свой адрес нужно добавить в ignoreip заранее. Если fail2ban заблокирует вашу рабочую машину, доступ к серверу придётся восстанавливать через панель хостинга.

Дополнительно

• Смените порт SSH. Это не защита сама по себе, но убирает основную массу автоматического шума из логов.
• Отключите вход по паролю. Ключи надёжнее: PasswordAuthentication no в /etc/ssh/sshd_config. Перед этим убедитесь, что вход по ключу работает.
• Запретите вход root. PermitRootLogin prohibit-password — работать под отдельным пользователем с sudo.
• Проверяйте обновления. unattended-upgrades закрывает дыры в пакетах автоматически.
• Не полагайтесь только на firewall. Он не защитит от уязвимости в приложении, которому разрешён порт 443.

Следующий шаг после закрытия портов — установка nginx и выпуск сертификата через Let’s Encrypt.