Каким образом изменения в /etc/pam.d/common-session-noninteractive влияют на 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

Итог

  1. Если я выполню fail2ban-client set ssh banip 1.2.3.4 в 15:26, IP будет заблокирован в 15:30. Поэтому я связываю это с вышеуказанной задачей cron.
  2. Если я изменю /etc/pam.d/common-session-noninteractive и повторю команду fail2ban-client, не будет записей в /var/log/auth.log и блокировки.

Больше информации:

  1. по умолчанию /etc/pam.d/common-session-noninteractive:

    fail2ban-client set ssh banip 1.2.3.4 -> IP блокируется невидимой задачей cron, которая выполняется каждые 5 минут. Я проверил каждый файл в /etc/cron* и /var/spool/cron/*, и такой задачи не было. В итоге: ручная блокировка работает с задержкой до 5 минут.

  2. добавил 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 в черный список).

Последствия изменений

  1. Изменение в PAM: Ваша модификация, добавляющая строку session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid, управляет тем, какие сессионные логирования происходят для процессов, инициируемых через cron. Конкретно, это изменение отключает сообщения, которые иначе записывались бы в логи при запуске cron-задач.

  2. Воздействие на 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 необходимо тщательно анализировать последствия для любых сервисов, которые зависят от журналов аутентификации и мониторинга активности пользователей.

Оцените материал
Добавить комментарий

Капча загружается...