Даже считая себя опытным специалистом в какой-то сфере нужно периодически вспоминать о базовых вещах.

К такому выводу я пришел просмотрев видеов духе “20 секретов Excel для начинающих” 🙂

Ну а раз так, то вполне себе можно перенести эту идею на безопасность инфраструктуры и поговорить о LDAP Simple Bind 🙂

С одной стороны – то, что Simple Bind используется в инфраструктуре – это плохо. С другой – из личного опыта – в 90% компаний, с которыми мне пришлось работать, я лично видел пролетающие по сети пароли в открытом виде.

Итак, подтвердим в тестовой среде, что LDAP Simple Bind это действительно небезопасно.

Для этого используем контроллер домена (Windows 2016), клиента, который будет подключаться к контроллеру по LDAP (Windows 10, IP: 10.0.0.200, ПК в домене, на этот ПК установлены инструменты RSAT) и ПК потенциального злоумышленника (Windows 10 с установленным Wireshark)

Запускаем LDP клиент –

 

На ПК злоумышленника не забываем запустить Wireshark –

Подключаемся с доменного ПК к контроллеру –

И выполняем bind, используя тип simple bind –

 

Проверяем, что все в порядке –

 

Переходим на ПК “злоумышленника”. Т.к. нас интересует протокол LDAP – установим соответствующий фильтр  –

 

Ищем bind request, так как именно в нем живет все самое интересное 🙂 –

 

Если “злоумышленник” терпелив и в вашей инфраструктуре находится длительное время – крайне велика вероятность, что рано или поздно он соберет большинство логинов\паролей из вашего активного каталога.

Перейдем ко второй части упражнения. Ответим на вопрос “А насколько все плохо?”. Ничего новго изобретать не будем, а использум статью, которая уже упоминалась в блоге.

На контроллере домена фильтруем журнал событий  Directory Service нас интерсуют 2 типа событий 2886 и 2887 –

 

Эти события помогут нам оценить масштабы бедствия. Но для того чтобы ответить на вопрос “Кто виноват” необходимо пойти дальше.

Microsoft идет нам в этом на встречу и позволяет включить расширенное протоколирование событий LDAP Interface Events.

Для включения логирования нужно в ветке реестра HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics изменить значение параметра “16 LDAP Interface Events” с 0 на 2. (Очевидно, для отключения нужно поменять 2 на 0) –

 

Проверим результат –

 

Теперь мы имеем полное представление какая учетная запись потенциально скомпроментирована и какой хост в этом виноват.

Выводы?

Нужно проанализировать конфигурацию “инициатора” небезопасных подключений и сделать так, чтобы критическая информация не путешествовала по сети в открытом виде 🙂