Налаштування Fail2Ban на

Конфігурація

Основне налаштування Fail2Ban здійснюється через файл jail.local. Ми скопіюємо базовий конфіг і потім змінимо його під наші потреби.

1. Створення jail.local

Скопіюйте файл jail.conf у jail.local, щоб почати налаштування:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Тепер усі зміни будемо вносити в jail.local.

2. Базова конфігурація jail.local

Відкрийте файл jail.local для редагування:

sudo nano /etc/fail2ban/jail.local

На початку файлу ви знайдете секцію [DEFAULT]. Тут можна задати глобальні параметри. Рекомендовані налаштування:

[DEFAULT]
# Час, на який IP-адреса блокується (у секундах). 1 година.
bantime = 3600

# Час, за який враховуються спроби (у секундах). 10 хвилин.
findtime = 600

# Максимальна кількість невдалих спроб до блокування.
maxretry = 5

# IP-адреси, які ніколи не будуть заблоковані (ваш IP, локальні мережі).
# Можна вказати кілька, розділяючи пробілами.
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8

# Дія за замовчуванням при блокуванні. 'iptables-multiport' - блокує IP
# на всіх портах, зазначених у jail.
banaction = iptables-multiport

# Сповіщення поштою (необов'язково, потребує налаштування поштового сервера)
# destemail = [email protected]
# sendername = Fail2Ban
# mta = sendmail
# action = %(action_mw)s # Надсилає лист з Whois-інформацією

Пояснення:

• bantime: Задає тривалість блокування IP-адреси. 3600 секунд = 1 година. Можна збільшити до 86400 (24 години) або навіть -1 для перманентного блокування (використовуйте обережно).
• findtime: Період часу, протягом якого Fail2Ban відстежує невдалі спроби. Якщо maxretry спроб відбудеться за findtime, IP буде заблоковано.
• maxretry: Кількість невдалих спроб входу, після яких IP-адреса буде заблокована.
• ignoreip: Список IP-адрес або підмереж, які ніколи не будуть заблоковані. Обов'язково додайте свою статичну IP-адресу сюди!
• banaction: Дія, яка буде виконана для блокування IP. iptables-multiport — стандартна та ефективна.

3. Налаштування "в'язниць" (jails)

Нижче секції [DEFAULT] йдуть окремі секції для кожного сервісу, що називаються "в'язницями" (jails). За замовчуванням багато з них вимкнені. Щоб увімкнути захист для сервісу, встановіть enabled = true.

3.1. Захист SSH

Це один з найважливіших захистів. Знайдіть секцію [sshd] та увімкніть її:

[sshd]
enabled = true
port = ssh # або ваш кастомний порт SSH, якщо змінювали (наприклад, 2222)
filter = sshd
logpath = /var/log/auth.log # або /var/log/secure для CentOS/RHEL
maxretry = 3 # Можна зробити менше для SSH
bantime = 86400 # Блокувати SSH на 24 години

Якщо ви змінили стандартний порт SSH (з 22 на інший), не забудьте вказати його в параметрі port. Рекомендується використовувати довший час блокування (наприклад, 24 години) для SSH, оскільки спроби підбору пароля часто походять від ботів.

3.2. Захист Nginx (HTTP/HTTPS)

Для захисту веб-сервера Nginx від атак на автентифікацію (наприклад, на /admin панель) або DoS-подібних атак (занадто багато запитів), можна використовувати фільтри nginx-http-auth та nginx-dos.

Спочатку переконайтеся, що Nginx логує помилки. Якщо ви використовуєте Nginx, встановіть його:

sudo apt install nginx -y

Потім додайте наступні секції до jail.local:

[nginx-http-auth]
enabled = true
port = http,https
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 6
bantime = 1200

[nginx-dos]
enabled = true
port = http,https
filter = nginx-dos
logpath = /var/log/nginx/access.log
maxretry = 300 # Припустимо, 300 запитів за 5 хвилин
findtime = 300 # 5 хвилин
bantime = 600 # Блокувати на 10 хвилин

Примітка: Для nginx-dos, filter = nginx-dos може бути відсутнім за замовчуванням. Вам може знадобитися створити файл /etc/fail2ban/filter.d/nginx-dos.conf з наступним вмістом:

[Definition]
failregex = ^ -."(GET|POST|HEAD).HTTP/" (403|404|401)
ignoreregex =

Це дуже простий фільтр. Складніші фільтри для Nginx можна знайти в офіційній документації Fail2Ban або на GitHub.

3.3. Захист Postfix (SMTP)

Якщо ви використовуєте Postfix для відправлення пошти:

[postfix]
enabled = true
port = smtp,ssmtp,submission,imap,imaps,pop3,pop3s
filter = postfix
logpath = /var/log/mail.log
maxretry = 5
bantime = 1800

4. Перевірка синтаксису та перезапуск Fail2Ban

Після внесення всіх змін збережіть файл jail.local. Перед перезапуском сервісу рекомендується перевірити конфігурацію на помилки:

sudo fail2ban-client -d # Перевіряє конфігурацію без застосування

Якщо помилок немає, перезапустіть Fail2Ban, щоб застосувати нові налаштування:

sudo systemctl restart fail2ban

5. Перевірка працездатності Fail2Ban

Щоб переконатися, що Fail2Ban працює коректно, можна перевірити статус активних "в'язниць":

sudo fail2ban-client status # Загальний статус Fail2Ban
sudo fail2ban-client status sshd # Статус конкретної в'язниці (наприклад, sshd)

Вивід для sshd повинен показати кількість заблокованих IP-адрес, якщо такі були. Щоб протестувати, спробуйте кілька разів (більше, ніж maxretry) ввести неправильний пароль при підключенні по SSH з іншої IP-адреси (або з вашої, якщо вона не в ignoreip). Потім перевірте статус sshd jail.

Status for jail sshd:
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     5
|  - File list:        /var/log/auth.log
- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   192.168.1.100 (приклад заблокованої IP)

Це означає, що Fail2Ban успішно заблокував IP-адресу 192.168.1.100 після 5 невдалих спроб.

6. Інтеграція з Docker (опціонально)

Якщо ви використовуєте Docker, логи контейнерів можуть бути недоступні для Fail2Ban безпосередньо з /var/log/. Для захисту Docker-контейнерів вам потрібно буде налаштувати контейнери для виведення логів у формат, зрозумілий Fail2Ban, або використовувати спеціалізовані рішення. Один з підходів — налаштувати Docker-контейнери для використання syslog або json-file драйвера логів з подальшою передачею їх у централізований лог-файл, який Fail2Ban зможе читати. Наприклад, для Nginx у Docker:

Додайте до docker-compose.yml для вашого сервісу:

services:
  nginx:
    image: nginx:stable-alpine
    # ... інші настройки ...
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
    volumes:
      - /var/log/nginx-docker:/var/log/nginx # Мапінг логів Nginx з контейнера

Потім змініть logpath у відповідній jail для Nginx на /var/log/nginx-docker/error.log та /var/log/nginx-docker/access.log відповідно.

Інший варіант — використовувати log-driver: syslog та налаштувати rsyslog на хості для запису логів Docker в окремі файли, які Fail2Ban зможе моніторити.

Резервні копії та обслуговування

Навіть з налаштованим Fail2Ban, резервні копії залишаються критично важливим елементом безпеки та відмовостійкості. Крім того, необхідно регулярно обслуговувати систему.

1. Що резервувати

Для Fail2Ban та загальної стабільності сервера важливо резервувати наступне:

• Конфігураційні файли Fail2Ban: /etc/fail2ban/jail.local та будь-які створені вами .conf файли в /etc/fail2ban/jail.d/, а також користувацькі фільтри в /etc/fail2ban/filter.d/.
• Інші важливі конфіги: /etc/ssh/sshd_config, конфігурації веб-сервера (Nginx: /etc/nginx/, Apache: /etc/apache2/), брандмауера (/etc/ufw/).
• Дані ваших застосунків: Бази даних, файли веб-сайтів, користувацькі дані, якщо такі є.

2. Простий скрипт авторезервування

Для створення регулярних резервних копій можна використовувати комбінацію rsync та cron. Для більш надійних та інкрементальних резервних копій розгляньте інструменти на кшталт BorgBackup або Restic.

Приклад простого скрипта для резервування конфігурацій Fail2Ban та SSH:

#!/bin/bash
BACKUP_DIR="/var/backups/configs"
DATE=$(date +%Y%m%d_%H%M%S)
TAR_FILE="$BACKUP_DIR/fail2ban_configs_$DATE.tar.gz"

mkdir -p "$BACKUP_DIR"

# Створюємо архів з важливими конфігураціями
tar -czvf "$TAR_FILE" \
    /etc/fail2ban/jail.local \
    /etc/fail2ban/jail.d/ \
    /etc/fail2ban/filter.d/ \
    /etc/ssh/sshd_config \
    --exclude='.swp'

# Видаляємо старі резервні копії (залишаємо останні 7 днів)
find "$BACKUP_DIR" -type f -name "fail2ban_configs_.tar.gz" -mtime +7 -delete

echo "Резервна копія створена: $TAR_FILE"

Збережіть цей скрипт як /usr/local/bin/backup_fail2ban.sh і зробіть його виконуваним:

sudo chmod +x /usr/local/bin/backup_fail2ban.sh

Потім додайте його до cron для щоденного виконання. Відкрийте crontab:

sudo crontab -e

І додайте рядок для виконання скрипта щодня о 3:00 ночі:

0 3   * /usr/local/bin/backup_fail2ban.sh > /dev/null 2>&1

3. Куди зберігати резервні копії

Ніколи не зберігайте резервні копії на тому ж сервері, що й оригінальні дані. Якщо сервер вийде з ладу, ви втратите і дані, і резервні копії. Рекомендовані варіанти:

• Зовнішнє S3-сумісне сховище: Такі сервіси, як AWS S3, Backblaze B2, DigitalOcean Spaces або інші хмарні сховища, пропонують надійне та масштабоване зберігання.
• Окремий VPS: Ви можете використовувати інший, менш потужний VPS як сховище для резервних копій, використовуючи rsync по SSH.
• Локальне сховище: Для невеликих проєктів можна використовувати локальний диск на вашій робочій станції, але це вимагає ручної синхронізації.

Для автоматичного надсилання резервних копій на S3 можна використовувати s3cmd або rclone.

4. Оновлення: Rolling vs Maintenance Window

Регулярні оновлення ПЗ критично важливі для безпеки. Ви можете обрати одну зі стратегій:

• Rolling updates: Застосовуються в міру виходу, зазвичай для некритичних сервісів. Для Fail2Ban, який оновлюється нечасто, це може бути прийнятно.
• Maintenance window: Оновлення проводяться в заздалегідь визначений час, зазвичай вночі або у вихідні, коли навантаження мінімальне. Це дозволяє контролювати процес та мінімізувати ризики.

Для Fail2Ban достатньо виконувати sudo apt update && sudo apt upgrade -y раз на тиждень або раз на місяць. Завжди перевіряйте логи після оновлень. Для Fail2Ban також важливо стежити за актуальністю його фільтрів. Періодично перевіряйте офіційний репозиторій Fail2Ban на GitHub для нових або оновлених фільтрів, особливо якщо ви використовуєте специфічні сервіси.

Вирішення проблем + FAQ

У цьому розділі зібрані відповіді на поширені запитання та рішення типових проблем, які можуть виникнути під час роботи з Fail2Ban.

Fail2Ban не блокує IP-адреси, хоча в логах є помилки. Що перевірити?

Переконайтеся, що Fail2Ban дійсно "бачить" логи. Перевірте шлях до логів у файлі jail.local (параметр logpath) для відповідної "в'язниці". Переконайтеся, що фільтр (filter) правильно налаштований і відповідає формату ваших логів. Можна протестувати фільтр вручну за допомогою команди fail2ban-regex /шлях/до/логу /etc/fail2ban/filter.d/ваш_фільтр.conf. Також перевірте, що maxretry та findtime встановлені коректно і IP-адреса не знаходиться у списку ignoreip.

Як розблокувати IP-адресу вручну?

Якщо ви випадково заблокували свою IP-адресу або потрібно розблокувати легітимну, використовуйте команду: sudo fail2ban-client set НАЗВА_JAIL unbanip IP_АДРЕСА. Наприклад, для SSH: sudo fail2ban-client set sshd unbanip 1.2.3.4. Після цього IP-адреса буде негайно розблокована.

Як перевірити, які IP-адреси заблоковані?

Для перегляду всіх активних "в'язниць" та заблокованих IP-адрес використовуйте: sudo fail2ban-client status. Для перегляду статусу конкретної "в'язниці" (наприклад, sshd): sudo fail2ban-client status sshd. У виводі буде список заблокованих IP-адрес та їх кількість.

Який VPS-конфіг мінімально підійде для Fail2Ban?

Для самого Fail2Ban достатньо мінімального VPS з 1 ядром CPU, 1 ГБ RAM та 20 ГБ NVMe/SSD диска. Однак, якщо на сервері працюватимуть й інші сервіси (веб-сервер, база даних, пошта), то рекомендується 2 ядра CPU, 2-4 ГБ RAM та 40-80 ГБ NVMe/SSD, щоб забезпечити стабільну роботу всіх застосунків та мати запас ресурсів.

Що обрати — VPS чи dedicated для цього завдання?

Для налаштування Fail2Ban та захисту більшості типових сервісів (кілька веб-сайтів, поштовий сервер для невеликої команди, ігровий сервер для друзів) VPS буде оптимальним та економічно вигідним вибором. Dedicated-сервер виправданий лише для високонавантажених проєктів, що вимагають максимальної продуктивності, повної ізоляції або специфічного обладнання, де віртуалізація може бути небажаною.

Fail2Ban споживає занадто багато ресурсів. Що робити?

Перевірте, які "в'язниці" активні та наскільки часто вони спрацьовують. Занадто агресивні фільтри або моніторинг дуже великих лог-файлів можуть збільшити споживання ресурсів. Спробуйте збільшити findtime та bantime, а також зменшити maxretry для менш критичних сервісів. Переконайтеся, що Fail2Ban використовує оптимальний бекенд (за замовчуванням auto, що зазвичай добре). Якщо проблема у дуже великій кількості логів, розгляньте ротацію логів (logrotate) для більш ефективного керування файлами.

Чи можна захистити Docker-контейнери за допомогою Fail2Ban?

Так, це можливо, але вимагає додаткового налаштування. Fail2Ban працює з логами, тому контейнери повинні виводити свої логи на хост-систему, де Fail2Ban зможе їх читати. Найпоширеніший підхід — це мапінг лог-файлів з контейнера на хост-систему через Docker volumes або налаштування Docker logging driver на syslog, щоб логи передавалися до системного журналу хоста. Потім Fail2Ban налаштовується на читання цих файлів або системного журналу.

Як оновити Fail2Ban?

Для систем на базі Debian/Ubuntu достатньо виконати стандартні команди оновлення пакетів: sudo apt update && sudo apt upgrade -y. Fail2Ban буде оновлено разом з рештою системи. Після оновлення рекомендується перезапустити сервіс sudo systemctl restart fail2ban, щоб переконатися, що застосовуються нові версії компонентів.

Висновки та наступні кроки

Вітаємо! Ви успішно налаштували Fail2Ban на вашому VPS, значно підвищивши його стійкість до брутфорс-атак. Ваш сервер тепер автоматично відстежує підозрілу активність та блокує зловмисників, звільняючи вас від рутинного моніторингу та дозволяючи зосередитися на розвитку ваших проєктів. Це фундаментальний крок у забезпеченні базової безпеки будь-якого сервера, що керується самостійно.

Подальші кроки щодо зміцнення безпеки та оптимізації вашого сервера можуть включати:

• Моніторинг та логування: Налаштуйте централізовану систему логування (наприклад, ELK Stack або Grafana Loki) для більш глибокого аналізу подій безпеки та продуктивності.
• Регулярні аудити безпеки: Використовуйте інструменти для сканування вразливостей (наприклад, Nessus, OpenVAS) та регулярно перевіряйте конфігурації на відповідність найкращим практикам.
• Масштабування та висока доступність: У міру зростання вашого проєкту розгляньте можливість переходу на кластерні рішення, балансувальники навантаження та резервні сервери для забезпечення безперебійної роботи.
• Автоматизація розгортання: Використовуйте інструменти на кшталт Ansible, Puppet або Chef для автоматизації налаштування нових серверів та керування конфігураціями, що заощадить час та знизить ймовірність помилок.