- Вопрос или проблема
- Fail2Ban на Ubuntu 10.04
- Файлы конфигурации
- /etc/fail2ban/jail.local
- по умолчанию /etc/pam.d/common-session-noninteractive
- изменено /etc/pam.d/common-session-noninteractive
- Журналы
- извлечение из /var/log/auth.log с использованием по умолчанию /etc/pam.d/common-session-noninteractive
- Итог
- Мой вопрос:
- Редактировать
- Версия Fail2Ban
- Ответ или решение
- Понимание PAM и Fail2Ban
- Последствия изменений
- Заключение
Вопрос или проблема
Fail2Ban на Ubuntu 10.04
Файлы конфигурации
/etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1
bantime = 10 # сделано для целей тестирования
maxretry = 3
backend = polling
destemail = [email protected]
banaction = iptables-multiport
mta = sendmail
protocol = tcp
action = %(action_mw)s
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
[pam-generic]
enabled = true
filter = pam-generic
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/auth.log
maxretry = 6
Остальные конфигурации fail2ban являются просто значениями по умолчанию.
по умолчанию /etc/pam.d/common-session-noninteractive
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_unix.so
session optional pam_winbind.so
session required pam_loginuid.so
изменено /etc/pam.d/common-session-noninteractive
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
session required pam_unix.so
session optional pam_winbind.so
session required pam_loginuid.so
Обратите внимание, что единственное отличие — это добавление session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid.
Журналы
извлечение из /var/log/auth.log с использованием по умолчанию /etc/pam.d/common-session-noninteractive
May 22 15:30:01 node1 CRON[16029]: pam_unix(cron:session): session opened for user root by (uid=0)
May 22 15:30:01 node1 CRON[16029]: pam_unix(cron:session): session closed for user root
May 22 15:35:01 node1 CRON[16514]: pam_unix(cron:session): session opened for user root by (uid=0)
May 22 15:35:01 node1 CRON[16514]: pam_unix(cron:session): session closed for user root
Итог
- Если я выполню
fail2ban-client set ssh banip 1.2.3.4
в 15:26, IP будет заблокирован в 15:30. Поэтому я связываю это с вышеуказанной задачей cron. - Если я изменю
/etc/pam.d/common-session-noninteractive
и повторю команду fail2ban-client, не будет записей в/var/log/auth.log
и блокировки.
Больше информации:
-
по умолчанию
/etc/pam.d/common-session-noninteractive
:fail2ban-client set ssh banip 1.2.3.4
-> IP блокируется невидимой задачей cron, которая выполняется каждые 5 минут. Я проверил каждый файл в/etc/cron*
и/var/spool/cron/*
, и такой задачи не было. В итоге: ручная блокировка работает с задержкой до 5 минут. -
добавил
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
в/etc/pam.d/common-session-noninteractive
по предложению здесь:fail2ban-client set ssh banip 1.2.3.4
-> невидимая задача cron не выполняется и блокировки не происходит.
Мой вопрос:
как изменение в /etc/pam.d/common-session-noninteractive
предотвращает fail2ban-client от блокировки IP? И почему?
Редактировать
- Работа в режиме отладки:
root@node1:~# fail2ban-client set loglevel 4 Текущий уровень ведения журналов - DEBUG root@node1:~# fail2ban-client -vvv set ssh banip 1.2.3.4 DEBUG Чтение /etc/fail2ban/fail2ban DEBUG Чтение файлов: ['/etc/fail2ban/fail2ban.conf', '/etc/fail2ban/fail2ban.local'] INFO Использование файла сокета /var/run/fail2ban/fail2ban.sock DEBUG OK : '1.2.3.4' DEBUG Форматирование '1.2.3.4' с помощью ['set', 'ssh', 'banip', '1.2.3.4'] 1.2.3.4 root@zap:~# tail -f /var/log/fail2ban.log 2013-05-24 21:32:07,695 fail2ban.comm : DEBUG Команда: ['set', 'ssh', 'banip', '1.2.3.4'] 2013-05-24 21:32:07,696 fail2ban.filter : DEBUG В данный момент есть неудачи от 1 IP: ['1.2.3.4'] 2013-05-24 21:32:07,696 fail2ban.filter : DEBUG В данный момент есть неудачи от 1 IP: ['1.2.3.4'] 2013-05-24 21:32:07,696 fail2ban.filter : DEBUG В данный момент есть неудачи от 1 IP: ['1.2.3.4']
Результат: Нет блокировки.
- Удаление
quiet
изsession [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
в/etc/pam.d/common-session-noninteractive
:
Результат: Успешная блокировка.
/var/log/auth.log
:
May 24 22:00:01 node1 CRON[22483]: pam_succeed_if(cron:session): требование "service in cron" было выполнено пользователем "root"
May 24 22:00:01 node1 CRON[22483]: pam_succeed_if(cron:session): требование "service in cron" было выполнено пользователем "root"
/var/log/fail2ban.log
:
2013-05-24 21:56:07,955 fail2ban.comm : DEBUG Команда: ['set', 'loglevel', '4']
2013-05-24 21:56:20,155 fail2ban.comm : DEBUG Команда: ['set', 'ssh', 'banip', '1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG В данный момент есть неудачи от 1 IP: ['1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG В данный момент есть неудачи от 1 IP: ['1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG В данный момент есть неудачи от 1 IP: ['1.2.3.4']
2013-05-24 22:00:01,079 fail2ban.filter : DEBUG /var/log/auth.log был изменен
2013-05-24 22:00:01,079 fail2ban.filter.datedetector: DEBUG Сортировка списка шаблонов
2013-05-24 22:00:01,853 fail2ban.filter : DEBUG /var/log/auth.log был изменен
2013-05-24 22:00:01,853 fail2ban.filter.datedetector: DEBUG Сортировка списка шаблонов
2013-05-24 22:00:01,870 fail2ban.actions: WARNING [ssh] Блокировка 1.2.3.4
2013-05-24 22:00:01,870 fail2ban.actions.action: DEBUG iptables -n -L INPUT | grep -q fail2ban-ssh
2013-05-24 22:00:01,876 fail2ban.actions.action: DEBUG iptables -n -L INPUT | grep -q fail2ban-ssh успешно выполнено
2013-05-24 22:00:01,877 fail2ban.actions.action: DEBUG iptables -I fail2ban-ssh 1 -s 1.2.3.4 -j DROP
2013-05-24 22:00:01,919 fail2ban.actions.action: DEBUG iptables -I fail2ban-ssh 1 -s 1.2.3.4 -j DROP
2013-05-24 22:00:01,920 fail2ban.actions.action: DEBUG
2013-05-24 22:00:01,923 fail2ban.actions.action: DEBUG успешно выполнено
...
Версия Fail2Ban
fail2ban 0.8.7.1-2~ppa7~lucid из здесь. Стоковая версия (0.8.4) постоянно выдавала ошибку:
"global name 'time' is not defined"
что побудило меня искать более новую версию.
Я думаю (но не подтверждено), что fail2ban просто ждет новых строк в auth.log перед применением команды fail2ban-client, так что блокировка происходит не за счет “невидимой задачи cron, которая выполняется каждые 5 минут”, а “за счет бесконечного цикла, который читает ‘logpath'”, auth.log в данном случае. Если это правда, изменение, которое вы внесли в /etc/pam.d/common-session-noninteractive, не предотвращает fail2ban-client от блокировки IP, а откладывает его до появления новой строки в auth.log. Новые строки журналов появляются реже, потому что вы отключили сообщения cron, и необходимо ждать дольше для блокировки IP.
Ответ или решение
Изменения в файле /etc/pam.d/common-session-noninteractive
могут оказать значительное влияние на работу сервисов, таких как Fail2Ban, особенно в контексте записи логов и обработки событий аутентификации. Давайте рассмотрим, что именно происходило до и после внесения изменений, а также как это повлияло на функциональность Fail2Ban и возможные другие программы.
Понимание PAM и Fail2Ban
PAM (Pluggable Authentication Modules) — это система, используемая для аутентификации пользователей в UNIX-подобных операционных системах. Файл common-session-noninteractive
используется для определения правил сессии, в частности, для неинтерактивных сессий, таких как те, которые инициируются процессами, выполняемыми по расписанию, например, через cron.
Fail2Ban — это инструмент для защиты серверов от брутфорс-атак путем бана IP-адресов, основываясь на логах аутентификации (в вашем случае это /var/log/auth.log
). Он работает, проверяя, были ли новые записи в логах, и если находит IP, который превышает порог попыток аутентификации, он инициирует действие (например, заносит IP в черный список).
Последствия изменений
-
Изменение в PAM: Ваша модификация, добавляющая строку
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
, управляет тем, какие сессионные логирования происходят для процессов, инициируемых через cron. Конкретно, это изменение отключает сообщения, которые иначе записывались бы в логи при запуске cron-задач. -
Воздействие на Fail2Ban:
-
Прежнее состояние: Когда вы использовали стандартный конфигурационный файл, каждый раз, когда cron выполнял задание, генерировались записи в логах (
auth.log
), которые отслеживались Fail2Ban. Эти записи акцентировали внимание на том, что выполняетсяsession для пользователя root, и в случае, если срабатывали условия для бана, Fail2Ban регистрировал это событие и применял бан к заданному IP. -
Новое состояние: После внесения изменений в PAM, записи для cron задач стали отсутствовать (или стали реже записываться), что, как вы и заметили, повлияло на возможность Fail2Ban обнаруживать частоту неудачных попыток входа. В результате, команды
fail2ban-client set ssh banip 1.2.3.4
, которые изначально инициировали бан, не приводили к ожидаемому результату, так как новая информация не фиксировалась в логах.
-
Заключение
Ваши модификации в common-session-noninteractive
косвенно затруднили успешное выполнение программы Fail2Ban. Это связано с тем, что записи логов, которые Fail2Ban использует для определения, была ли предпринята попытка входа с указанного IP-адреса, стали менее частыми или исчезли вовсе из-за отключения логирования при запуске cron.
Вывод заключается в том, что изменение PAM повлияло на видимость событий, на основе которых работает Fail2Ban, что приводит к тому, что, хотя и не нарушается функция самой программы, её реакция на входящие события становится менее эффективной. Чтобы исправить это, можно модифицировать файл так, чтобы отключение логирования не влияло на важные события, которые должны быть записаны. Например, удаление слова quiet
из строки позволяет вернуть полное логирование cron-задач, что затем позволит Fail2Ban производить баны в обычном режиме.
Следовательно, при изменении конфигураций PAM необходимо тщательно анализировать последствия для любых сервисов, которые зависят от журналов аутентификации и мониторинга активности пользователей.