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