HCL Domino v.12/14 на Rocky Linux 9: Задержка записи в console.log

Вопрос или проблема

На сервере Rocky Linux v.9 с HCL Domino v.12 (или v.14, разницы нет) я установил fail2ban, чтобы блокировать попытки доступа к SMTP-порту с неправильным именем пользователя или паролем, анализируя console.log, и он работает корректно.

В фильтр fail2ban я добавил следующую строку:

failregex = .* Authentication failed .* connecting host <HOST>

Удаленный IP-адрес блокируется fail2ban, когда строка в console.log соответствует следующему:

SMTP Server: Authentication failed for user [email protected] ; connecting host 11.22.33.44

Пока все хорошо, но проблема возникает в том, что проходит очень много времени, прежде чем эти строки будут записаны в журнал, что позволяет удаленному серверу отправлять десятки (если не сотни) запросов на аутентификацию, прежде чем fail2ban заметит и заблокирует это.

Мой вопрос: существует ли флаг в HCL Domino или строка, которую можно добавить в notes.ini, чтобы уменьшить время задержки между атакой на SMTP-порт и записью строки в журнал? И если ничего подобного нет, какие еще способы я могу использовать для блокировки этих атак и избежания всего этого ненужного трафика?

Заранее спасибо всем.

Fail2Ban – правильный подход для блокировки событий аутентификации. Мониторинг событий SNMP и Domino больше предназначен для оповещения и долгосрочного мониторинга. Fail2ban позволяет блокировать злоумышленников на уровне брандмауэра Linux.

Я не в курсе долгой задержки для IBM_TECHNICAL_SUPPORT/console.log. Что означают “очень долгое время”? Можете ли вы количественно выразить это в секундах?

Когда вы используете мой скрипт запуска Domino, в каталоге данных создается другой файл “notes.log”. В отличие от console.log, этот файл является перенаправлением стандартного вывода процесса сервера и не вращается.

Он автоматически управляется скриптом запуска.

  • Он архивируется в сжатом формате tar и правильно именуется.
  • Есть времена хранения, которые вы можете указать.

Этот журнал лучше подходит для интеграции с Fail2Ban. Проект скрипта запуска также предлагает интеграцию Fail2Ban для интернет-протоколов.

Также предоставляется скрипт для управления этой интеграцией Fail2Ban.

Вот ссылка на страницу документации, где вы также найдете скрипт запуска Domino Nash!Com Domino Fail2Ban.

Если у вас есть вопросы или обратная связь, пожалуйста, открывайте вопросы напрямую на Github.

Я думаю, что лучшее решение, чем сканирование console.log, это использование системы событий в events4.nsf, https://help.hcl-software.com/domino/14.0.0/admin/admn_monitoringthedominosystem_c.html.

Используя обработчики событий: https://help.hcl-software.com/domino/14.0.0/admin/admn_eventhandlers_t.html.

Существует множество возможных вариантов действий при возникновении события: https://help.hcl-software.com/domino/14.0.0/admin/admn_eventhandlernotificationmethods_r.html.

Вероятные кандидаты включают запись в журнал Unix или запуск агента, или, возможно, отправку SNMP trap.

Ответ или решение

Конечно, я постараюсь помочь вам с этой проблемой.

Проблема с задержкой записи в console.log при использовании HCL Domino на сервере Rocky Linux может быть критичной в случае, если вам необходимо оперативно блокировать недопустимые попытки аутентификации через SMTP. К сожалению, в HCL Domino нет известного параметра, который бы уменьшал задержку записи в console.log, и, следовательно, вам придется рассмотреть альтернативные подходы для решения этой задачи.

Вот несколько рекомендаций, которые могут помочь вам:

  1. Использование notes.log: Вместо console.log рассмотрите возможность использования файла notes.log, который генерируется с помощью альтернативного стартового скрипта для Domino. Этот файл создается на основе стандартного вывода процесса сервера и может быть более подходящим для интеграции с Fail2Ban. Вы можете найти более подробную информацию о скрипте запуска Domino здесь.

  2. Настройка Event System: Рассмотрите возможность работы с системой событий в HCL Domino. Используя events4.nsf, вы можете настроить обработчики событий, которые будут реагировать на попытки аутентификации. Вы можете создать обработчик, который будет фиксировать неудачные аутентификации и отправлять уведомления (например, через SNMP или в системный лог), что позволит быстро реагировать на атаки. Подробности можно найти в документации по обработчикам событий.

  3. Оптимизация конфигурации Fail2Ban: Убедитесь, что ваши настройки Fail2Ban оптимальны. Возможно, вам стоит уменьшить значение времени между проверками логов или количество попыток, прежде чем IP-адрес будет заблокирован. Эти параметры находятся в конфигурации конкретной "jail" в разделе /etc/fail2ban/jail.local.

  4. Отладка логирования: Если вы считаете, что задержка все же присутствует в console.log, попробуйте увеличить уровень отладки в Domino, чтобы понять, как быстро производятся записи. Проверяйте настройки notes.ini, чтобы выявить любые параметры, которые могут повлиять на производительность логирования.

  5. Дополнительные меры безопасности: Рассмотрите возможность установки брандмауэра на уровне сети, чтобы ограничить доступ к SMTP только из доверенных источников. Это может значительно уменьшить количество некорректных попыток аутентификации.

Эти шаги должны помочь вам уменьшить задержку в реагировании на атаки и обеспечить более быструю блокировку нежелательных IP-адресов. Если у вас возникли дополнительные вопросы или нужна помощь с настройками, не стесняйтесь обращаться за уточнениями.

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

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