Fail2Ban: настройка защиты SSH на Linux — почему одного инструмента недостаточно

Диагноз: ты поставил Fail2Ban и думаешь, что теперь защищён?

Поздравляю. Потратил вечер, воткнул fail2ban, прописал jail для SSH, посмотрел как он бодро банит IP в логе — лёг спать с чистой совестью. А утром обнаружил, что сервер живёт своей жизнью, в /root/.ssh/authorized_keys появился незнакомый ключ, а в крон-таблице что-то майнит.

Знакомо? Я через это прошёл. Не один раз, и не на своих серверах — что неприятнее вдвойне.

Давай без соплей: Fail2Ban — полезный инструмент, но он не серебряная пуля. Закрывает ровно одну дыру из десяти. Оставшиеся девять — открыты, потому что большинство туториалов заканчиваются на apt install fail2ban и systemctl enable fail2ban.

Времени нужно: 20–30 минут на настройку. Потребуется root или sudo, твой публичный SSH-ключ и голова на плечах.

Что делает Fail2Ban — простыми словами

Fail2Ban читает лог-файлы (auth.log, nginx/error.log, mail.log) и ищет в них паттерны неудачных попыток. Нашёл 3 провала с одного IP за 10 минут — добавил этот IP в iptables или nftables и заблокировал. Через заданное время — разблокировал (или нет, если bantime постоянный).

Всё. Это вся логика. Никакого ML, никакого анализа поведения, никакого понимания контекста. Счётчик событий плюс блокировка по IP. Это не плохо — просто нужно понимать ограничения.

Где Fail2Ban реально помогает

Вот тут он честно зарабатывает своё место в системе:

• Одиночные боты с одного IP — классический ssh брутфорс от скриптокидди. Fail2Ban убивает это без вопросов.
• Сканеры портов и веб-краулеры — с jail для Nginx банит агрессивных ботов, которые долбят 404 страницы или /wp-admin.
• Снижение шума в логах — когда IP забанен, его попытки перестают засорять auth.log. Читаемость растёт.
• Автоматизация рутины — не нужно вручную добавлять IP в iptables каждый раз, когда кто-то решил побрутить.

Смотри, это реальная польза. Но читай дальше — потому что именно здесь большинство останавливается и считает задачу решённой.

Почему Fail2Ban НЕ спасает: три вектора, которые он не видит

Distributed brute force: математика против счётчика

Современный ботнет работает просто. Есть 100 000 IP-адресов. Каждый делает 2–3 попытки за сутки. Твой maxretry = 5 не срабатывает ни для одного из них. А суммарно за ночь они перебирают миллионы комбинаций логин/пароль.

Fail2Ban на это смотрит и молчит. Ни одного бана. Потому что порог не достигнут ни с одного адреса.

Credential stuffing: правильный пароль с первой попытки

Утечки баз данных происходят постоянно. На даркнет-маркетах продаются миллиарды пар логин/пароль из взломанных сервисов. Если твой пользователь использует один и тот же пароль на Gmail и на твоём сервере — атакующий просто попробует его один раз. Одна попытка. Успешная авторизация. Fail2Ban спит.

Fail2Ban реагирует на неудачные попытки. Удачная попытка для него — это норма.

Exploits: атака не через SSH

Fail2Ban защищает то, что ты ему сказал защищать. Если у тебя открыт порт 8080 с устаревшим WordPress, живёт phpMyAdmin на стандартном URL, или торчит наружу Redis без пароля — fail2ban смотрит в другую сторону. Уязвимость в приложении вообще не оставляет записей в auth.log.

CVE эксплойт отрабатывает за один HTTP-запрос. В лог попадёт что-то вроде POST /xmlrpc.php 200 — и это выглядит как обычный трафик.

Таблица: атака vs защита Fail2Ban

Реальный кейс взлома: как это выглядит изнутри

Пятница. Вечер. Звонок от клиента: «сервер тормозит, нагрузка 40 при 4 ядрах». Захожу — и вижу картину маслом.

В top — процесс kworker/u4:2 с нагрузкой 380%. Это не ядро. Это майнер, который замаскировался под системный процесс. В /tmp/.cache/ — бинарник. В крон-таблице root — задача каждые 5 минут перезапускает этот бинарник с нового URL если его убить.

Fail2Ban стоял. Работал. Банил IP. Показывал красивую статистику. Просто взлом пришёл не через брутфорс SSH — пришёл через необновлённый плагин на WordPress, который висел на том же сервере. Один POST-запрос с base64-encoded полезной нагрузкой. Всё.

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

Практика: настройка Fail2Ban — jails и конфиги

Подготовка

Прежде чем трогать SSH — открой второй терминал с активной сессией. Это не паранойя, это гигиена. Если что-то пойдёт не так — не потеряешь доступ к серверу.

Нужно:

• Ubuntu 20.04 / 22.04 или Debian 11/12
• Root или sudo
• Публичный SSH-ключ — если его нет, сначала сгенерируй (инструкция ниже)

Шаг 1: Установка инструментов

apt update && apt upgrade -y
apt install -y fail2ban ufw iptables-persistent net-tools curl wget

Проверяем статус:

systemctl status fail2ban
fail2ban-client status

Шаг 2: SSH-ключи — если их нет, сначала это

Генерируем на своей машине, не на сервере:

ssh-keygen -t ed25519 -C "myserver-$(date +%Y%m%d)" -f ~/.ssh/myserver_ed25519

Копируем на сервер:

ssh-copy-id -i ~/.ssh/myserver_ed25519.pub root@YOUR_SERVER_IP

Проверяем, что вход по ключу работает — до отключения паролей:

ssh -i ~/.ssh/myserver_ed25519 root@YOUR_SERVER_IP echo "Key auth works"

Результат: должна появиться строка Key auth works без запроса пароля.

Шаг 3: Укрепление SSH-конфига

Бэкапим оригинал:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.<a class="wpil_keyword_link" title="Резервное копирование" href="https://it-apteka.com/category/rezervnoe-kopirovanie/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="1369">backup</a>.$(date +%Y%m%d)

Создаём drop-in конфиг (чище, чем редактировать основной файл):

cat > /etc/ssh/sshd_config.d/99-hardening.conf << 'EOF'
Port 2222
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
PermitEmptyPasswords no
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
LoginGraceTime 20
MaxAuthTries 3
MaxSessions 5
MaxStartups 3:50:10
LogLevel VERBOSE
EOF

Проверяем синтаксис и перезапускаем:

sshd -t && systemctl restart sshd

Разбор конфигов Fail2Ban: что значит каждая строка

Главное правило: никогда не редактируй /etc/fail2ban/jail.conf — он перезапишется при обновлении. Только jail.local.

SSH jail — основа

cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 YOUR_HOME_IP/32
bantime  = 7d
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 30d
findtime = 1h
maxretry = 3
backend = systemd

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 1h
bantime = 7d
EOF

Разбираем параметры — вот тут важно понять логику:

SSH aggressive jail — для злостных нарушителей

cat >> /etc/fail2ban/jail.local << 'EOF'

[sshd-aggressive]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 10
findtime = 24h
bantime = 30d
EOF

Логика: кто за сутки сделал 10 попыток — получает месяц бана. Без разговоров.

Nginx HTTP auth jail

cat >> /etc/fail2ban/jail.local << 'EOF'

[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log
maxretry = 5
findtime = 10m
bantime = 1h
EOF

Защищает: /admin, /wp-admin, /.htpasswd-зоны. Кто 5 раз неверно ввёл пароль к админке — в бан на час.

Nginx bad bots jail

cat >> /etc/fail2ban/jail.local << 'EOF'

[nginx-badbots]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/access.log
maxretry = 2
findtime = 1h
bantime  = 24h
EOF

Два хита с подписью бота — и IP в бане на сутки. Хорошо работает против агрессивных сканеров типа Masscan и ZGrab.

Postfix jail — если есть почтовый сервер

cat >> /etc/fail2ban/jail.local << 'EOF'

[postfix]
enabled = true
port    = smtp,465,submission
logpath = /var/log/mail.log
maxretry = 3
findtime = 10m
bantime = 1h
EOF

Защищает от спам-ботов, которые пытаются использовать твой сервер как открытый relay. Без этого jail — mail.log будет полон мусора.

Recidive jail — ВАЖНО, многие забывают

cat >> /etc/fail2ban/jail.local << 'EOF'

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = iptables-allports
bantime  = 30d
findtime = 1d
maxretry = 5
EOF

Это особый jail. Он читает лог самого fail2ban и банит тех, кого уже банили 5 раз за сутки — теперь на 30 дней и по всем портам, не только SSH. Рецидивисты улетают надолго.

Перезапускаем и проверяем все jails:

systemctl restart fail2ban
fail2ban-client status
fail2ban-client status sshd
fail2ban-client status sshd-aggressive
fail2ban-client status recidive

Настройка UFW — правильный firewall рядом с Fail2Ban

UFW и Fail2Ban — не конкуренты, они работают вместе. UFW задаёт базовые статичные правила, Fail2Ban динамически добавляет баны.

ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp comment 'SSH custom port'
# ufw allow 80/tcp comment 'HTTP'
# ufw allow 443/tcp comment 'HTTPS'
ufw --force enable
ufw status verbose

iptables rate limiting — то, чего Fail2Ban не умеет

Физически ограничиваем количество новых соединений с одного IP на SSH-порт. Даже если fail2ban не успел сработать — iptables просто дропает лишнее.

iptables -N SSH_LIMIT 2>/dev/null || iptables -F SSH_LIMIT
iptables -A INPUT -p tcp --dport 2222 -m state --state NEW -j SSH_LIMIT
iptables -A SSH_LIMIT -m recent --set --name SSH_TRACK --rsource
iptables -A SSH_LIMIT -m recent --update --seconds 60 --hitcount 4 --name SSH_TRACK --rsource -j DROP
iptables -A SSH_LIMIT -j ACCEPT
netfilter-persistent save

Результат: не более 3 новых TCP-соединений с одного IP за 60 секунд. Для нормальной работы достаточно. Для брутфорса — нет.

Как тестировать Fail2Ban — убеждаемся что всё работает

Не верь на слово — проверяй. Вот как проверить, что fail2ban действительно банит.

Тест 1: принудительный бан тестового IP

# Баним тестовый IP вручную
fail2ban-client set sshd banip 192.168.1.100

# Проверяем что IP в бане
fail2ban-client status sshd | grep "Banned IP"

# Разбаниваем
fail2ban-client set sshd unbanip 192.168.1.100

Тест 2: реальный тест через SSH-соединения

С другой машины (не с той, что в ignoreip) делаем 4 неудачные попытки входа:

# С тестовой машины (не с основной!)
for i in 1 2 3 4; do
  ssh -p 2222 -o ConnectTimeout=5 -o PasswordAuthentication=yes wronguser@YOUR_SERVER 2>/dev/null
  echo "Attempt $i done"
  sleep 2
done

На сервере смотрим результат:

fail2ban-client status sshd
# В поле "Banned IP list" должен появиться IP тестовой машины

Тест 3: проверка regex фильтра

# Проверяем, что фильтр sshd правильно парсит лог
fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf | tail -20
# Смотрим на строку "Lines: X matched, Y missed, Z ignored"
# matched должен быть > 0

Проверка статуса всех jails

fail2ban-client status
# Покажет список всех активных jails

fail2ban-client status sshd
# Детали: Total banned, Currently banned, Banned IP list

Troubleshooting: Fail2Ban не банит, забанил себя, атаки продолжаются

Проблема 1: Fail2Ban не банит — что проверить

# Смотрим что fail2ban читает
fail2ban-client get sshd logpath

# Проверяем работает ли фильтр на реальных строках
fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf | tail -20

# Проверяем журнал fail2ban на ошибки
journalctl -u fail2ban -n 50 --no-pager

На Ubuntu 22.04 auth.log может не существовать без rsyslog:

ls -la /var/log/auth.log
# Если нет:
apt install rsyslog -y && systemctl enable --now rsyslog
# Или переключаем на journal:
sed -i 's/backend = .*/backend = systemd/' /etc/fail2ban/jail.local
systemctl restart fail2ban

Проблема 2: Fail2Ban забанил меня самого

Классика. Лечится через консоль хостинга (VNC/KVM):

# Разбаниваем свой IP в конкретном jail
fail2ban-client set sshd unbanip YOUR_IP

# Разбаниваем из всех jails сразу
for jail in $(fail2ban-client status | grep "Jail list" | sed 's/.*Jail list://;s/,//g'); do
  fail2ban-client set $jail unbanip YOUR_IP 2>/dev/null
done

# Добавляем IP в белый список чтобы не повторилось
echo "ignoreip = 127.0.0.1/8 ::1 YOUR_IP/32" >> /etc/fail2ban/jail.local
systemctl restart fail2ban

Проблема 3: Атаки продолжаются несмотря на баны

Это distributed brute force. Смотрим разброс IP:

grep "Failed password" /var/log/auth.log | \
  grep "$(date '+%b %_d')" | \
  grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | \
  sort | uniq -c | sort -rn | head -20

Если видишь десятки разных подсетей — fail2ban тут не поможет. Нужен geo-blocking или переход на VPN-only доступ к SSH. Но это уже следующий уровень.

Проблема 4: После настройки SSH не могу войти

# Через консоль хостинга:
sshd -t
# Проверяем на каком порту слушает
ss -tlnp | grep sshd
# Разрешён ли порт в ufw?
ufw status | grep 2222
# Откатываемся на бэкап если всё плохо
cp /etc/ssh/sshd_config.backup.* /etc/ssh/sshd_config
systemctl restart sshd

Проблема 5: Fail2Ban не запускается после перезагрузки

journalctl -u fail2ban -n 50 --no-pager

# Фикс зависимости (iptables должен быть до fail2ban)
systemctl edit fail2ban
# Добавить в файл:
# [Unit]
# After=network.target iptables.service ip6tables.service

SSH Honeypot: ловушка для сканеров на порту 22

Необязательно, но эффективно. Логика простая: настоящий клиент никогда не постучится на порт 22, если знает что SSH сидит на 2222. Значит, любой кто пришёл на 22 — это бот или сканер. Баним сразу.

Создаём фильтр для fail2ban:

cat > /etc/fail2ban/filter.d/port22-honeypot.conf << 'EOF'
[Definition]
failregex = .*Connection from <HOST> port \d+ on .* port 22$
ignoreregex =
EOF

Добавляем jail:

cat >> /etc/fail2ban/jail.local << 'EOF'

[port22-honeypot]
enabled = true
filter = port22-honeypot
logpath = /var/log/auth.log
maxretry = 1
bantime = 30d
findtime = 1d
EOF

systemctl restart fail2ban

Один стук на порт 22 — 30 дней бана. Никаких предупреждений.

Минимальный security baseline: слоёная защита сервера Linux

Вот тут важно понять главное: Fail2Ban — только один слой. Сам по себе он ничего не гарантирует.

Чеклист администратора

Экстренный чеклист: если взламывают прямо сейчас

Альтернативные решения: что ещё кроме Fail2Ban

CrowdSec — современная альтернатива

CrowdSec работает похоже на Fail2Ban, но с общей базой репутации IP. Когда один сервер видит атаку — остальные сразу получают предупреждение. Более умный, но сложнее в настройке. Хорошо подходит если управляешь несколькими серверами.

sshguard — легковесная альтернатива

Проще Fail2Ban, меньше возможностей. Хорошо когда нужна защита только SSH без всего остального. Ставится за 2 минуты.

VPN-only доступ к SSH

Самый надёжный вариант: SSH вообще не торчит в интернет. Только через WireGuard VPN. Тогда fail2ban вообще не нужен — к SSH физически не может подключиться посторонний. Но требует настройки VPN и дисциплины.

Профилактика: как не сломать снова

Мониторинг

# Ежедневная проверка статуса
fail2ban-client status
# Топ атакующих за сутки
grep "Failed password" /var/log/auth.log | grep "$(date '+%b %_d')" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | sort | uniq -c | sort -rn | head -10

Автоматические обновления безопасности

dpkg-reconfigure --priority=low unattended-upgrades
# Включаем автоустановку security-патчей

Автозапуск и постоянство правил

systemctl enable fail2ban
systemctl enable ufw
# Сохраняем iptables правила
netfilter-persistent save

Регулярный аудит

Раз в неделю — быстрая проверка:

# Статус всех jails
fail2ban-client status
# Новые пользователи в системе
awk -F: '$3 >= 1000 {print $1, $3}' /etc/passwd
# Новые SSH-ключи
find /root /home -name "authorized_keys" -newer /etc/passwd 2>/dev/null

FAQ: частые вопросы про Fail2Ban и защиту SSH

Зачем вообще нужен Fail2Ban если есть SSH-ключи?

SSH-ключи закрывают авторизацию по паролю, но не закрывают шум. Боты всё равно будут стучать в SSH-порт, тратить ресурсы сервера, засорять логи. Fail2Ban этих ботов банит, и через некоторое время ботнет перестаёт обращаться к твоему серверу — адрес помечается как «дорогой». Плюс Fail2Ban защищает другие сервисы — веб, почту.

Почему Fail2Ban не банит несмотря на атаки?

Три самые частые причины: (1) неправильный logpath — fail2ban смотрит не туда; (2) неправильный backend — на Ubuntu 22.04 часто нужен backend = systemd потому что auth.log не существует без rsyslog; (3) атакующий IP в ignoreip — проверь белый список. Диагностика: fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Сколько ставить bantime для SSH?

Минимум 24 часа. По факту — 7 дней. Дефолтные 10 минут это просто подарок для ботнета: подождал, пришёл снова. С прогрессивным bantime (bantime.increment = true) каждый новый бан длиннее предыдущего — после 3–4 банов один IP улетает на месяц.

Как проверить что конкретный IP забанен?

fail2ban-client status sshd | grep "Banned IP"
# Или прямо в iptables:
iptables -L f2b-sshd -n | grep YOUR_IP

Что если Fail2Ban сам падает под нагрузкой?

Это ban amplification attack через IPv6 — атакующий генерирует уникальные IP быстрее чем fail2ban успевает их обработать, таблица iptables распухает. Решение: ограничить диапазон банов через ipset вместо прямых правил iptables, или отключить IPv6 на сервере если он не используется (AddressFamily inet в sshd_config).

Можно ли полностью автоматизировать проверку безопасности?

Да. Добавь в крон скрипт который каждое утро проверяет статус jails, топ атакующих IP, изменения в authorized_keys и крон-таблицах. Результат пишет в лог или шлёт на почту. Простая автоматизация, которая несколько раз спасала от неприятных сюрпризов.

Итог: что построили и что теперь работает

Мы собрали не «просто fail2ban», а многоуровневую защиту SSH. Слой 1 — SSH-конфиг: отключили пароли, оставили только ключи, порезали MaxAuthTries. Убивает 80% векторов авторизации. Слой 2 — UFW: закрыли всё лишнее. Слой 3 — iptables rate limiting: физическое ограничение соединений. Слой 4 — Fail2Ban с нормальными настройками: bantime 7 дней, прогрессивные баны, несколько jails. Слой 5 — Honeypot: кто постучался на порт 22 — сразу 30 дней без разговоров.

По факту после этих настроек 99% автоматизированных атак проходят мимо — не потому что fail2ban такой умный, а потому что нет парольной аутентификации, нет стандартного порта, есть rate limiting и ловушка. Fail2Ban в этой схеме — полезный, но не главный игрок.

Что это не закрывает, честно: уязвимости в других сервисах на том же сервере, утечку приватного ключа, целенаправленные атаки с ресурсами. Для этого нужны отдельные инструменты: IDS, централизованный logging, VPN-only доступ.

Author: Андрей Анатольевич

Руководитель ИТ / Кризис-менеджер 25 лет в IT: от инженера в МегаФоне до руководителя отдела. Знаю, как выглядит бардак: нестабильные сети, устаревшая инфраструктура, конфликты в команде, раздутые сроки. Помогаю бизнесу выходить из кризиса: навожу порядок в легаси, стабилизирую то, что разваливается, выстраиваю прогнозируемые процессы. Не раз возвращал к жизни ИТ-структуры — знаю цену хаосу. 📍 Ищу проект для полной реорганизации / стабилизации. 📬 Telegram: @over_dude ✉️ mail@it-apteka.com