У меня есть сервер OpenLDAP (с паролями пользователей), открытый по всему миру, и я пытаюсь обеспечить его безопасность.
Шаг 1 — ограничить доступ к данным для аутентифицированных пользователей с помощью списков контроля доступа.
Шаг 2, для предотвращения атак методом подбора, было внедрение ppolicy. Кажется, работает отлично, круто.
Шаг 3 — «разобраться с пользователем, который был заблокирован и клянется, что это не его вина», выявляя блокировки DN как можно раньше и устанавливая их возможные причины.
Я начал писать скрипты, которые проверяют наличие атрибута pwdAccountLockedTime, предупреждают по электронной почте, звонят в колокольчики и т. д. Это нормально, но мне сложно связать это с данными в журналах, говорящими о том, когда происходили инкриминируемые входы, откуда они были сделаны и т. д. Все данные есть, но свести их воедино — настоящая головная боль. Я уверен, что я не единственный, кто столкнулся с этой проблемой (или я пытаюсь решить не ту проблему?), и что решения существуют, просто я не смог их найти. Я не прав?
Забыл сказать, fail2ban не очень подходит. Есть много клиентов, адреса которых я не обязательно знаю, которые, скорее всего, будут делать законные массовые запросы к каталогу и не пройдут fail2ban. Звучит странно, я знаю, но наша конфигурация здесь сложная, и нам приходится с этим справляться. Вот почему я смотрю на ppolicy.
Короче говоря, я хотел бы иметь способ отслеживать возникновение pwdAccountLockedTime и, когда это происходит, немедленно получать информацию о том, какой пользователь затронут, значения pwdFailureTime, какие запросы были сделаны в это время и с какого IP-адреса(ов) в одном, легко читаемом файле журнала. Это было бы здорово, наверняка он существует?
решение1
Я бы поставил под сомнение шаг 3. Просмотр журналов с целью поиска потенциально затронутых пользователей не решает фактическую проблему, которая заключается в том, что они не могут войти в систему.
Все, что вам нужно, — это административное действие по сбросу учетной записи с временным новым паролем, который вы сообщите ему, когда он пожалуется (после его аутентификации каким-либо другим способом), и который он должен будет изменить при следующем входе в систему. Все это можно осуществить с помощью политики.