Отличный вопрос
Перво-наперво - я считаю, что большинство «тестеров на проникновение» - это сценаристы. Моя предвзятость может быть не честной или точной, но я вставляю этот отказ от ответственности, чтобы, если вы обнаружите какой-либо цинизм в моем тоне, вы знаете, откуда он исходит. Я не говорю, что нет опытных пентестеров, но это моя широкая общность.
(Синяя команда на всю жизнь!)
Мой вопрос: 1) Есть ли способ заставить Active Directory регистрировать эти неудачные запросы имени пользователя в центральном месте, чтобы мы могли заметить их всплеск?
Вы не предоставили достаточно информации, чтобы кто-либо мог ответить на этот вопрос тщательно и с уверенностью. Вы сказали, что в вашем приложении обнаружена ошибка, позволяющая злоумышленникам перечислять учетные записи пользователей. Я пытаюсь понять, каким образом вы чувствуете, что AD должен выполнять ведение журнала для вашего приложения.
Очевидно, что сбои только когда-либо обнаруживались в локальном журнале событий сервера, на котором было установлено приложение.
Видимо сбои обнаружились в журнале событий на сервере? Или неудачи действительно появляются в журнале событий на сервере? Если это так, что именно сказали события? Кто их зарегистрировал? Ваше приложение? Или винда? Пойди выясни, и я смогу добавить дополнительные разъяснения к моему ответу.
Я собираюсь остановиться здесь на основе вашего предположения, что эти события должны были каким-то образом регистрироваться Active Directory ... что если ваши пентестеры на самом деле вообще не использовали изъян в вашем приложении, а вместо этого использовали очень известный недостаток в самом Kerberos для перечисления имен пользователей? Сам Kerberos содержит то, что я бы назвал недостатком проекта, в котором злоумышленник может предпринять тысячи и тысячи попыток «предварительной аутентификации» (то есть атаки методом «грубой силы»), и KDC будет реагировать по-разному в зависимости от того, существует учетная запись пользователя или нет. Это не специфичное для Active Directory поведение, но оно также применимо к MIT Kerberos, Heimdal и т. Д. KDC ответитKDC_ERR_PREAUTH_REQUIREDесли действительное имя пользователя было представлено без данных предварительной аутентификации, даже без попытки фактической аутентификации. Таким образом, вы можете перечислять имена пользователей из KDC. Но поскольку злоумышленнику (или инструменту, который использует злоумышленник, например KrbGuess - поскольку пентестеры в своих лучших проявлениях используют чужие инструменты), не нужно переходить к полной попытке аутентификации, ничего не регистрируется, потому что нет фактическая аутентификация была предпринята!
Теперь к вашему следующему вопросу:
2) Если нет, каков наилучший способ отслеживать и активно обнаруживать этот тип атаки в будущем (надеюсь, без необходимости покупать слишком много нового оборудования).
Пара вещей.
Во-первых, существуют платные продукты корпоративного уровня, предназначенные для обнаружения атак такого рода (среди многих других). Многие производители предлагают такие продукты, и рекомендации по продукту не относятся к теме Serverfault, но достаточно сказать, что они отсутствуют. там. Многие из этих продуктов работают, требуя от вас настройки зеркалирования портов между контроллерами домена и этими «сборщиками данных», чтобы они видели и анализировали буквально каждый пакет, который входит или выходит из контроллеров домена.
(Извините, это как бы относится к вашему предложению «не покупать слишком много нового».)
Еще одна вещь, которая может вам помочь, это запись в реестре:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
LogLevel = 1
Документировано здесь .
Если включить этот параметр реестра, вы должны получить затопленных с событиями в журнале событий безопасности об ошибках Kerberos , в которых упоминается , что Kerberos предварительно требуется аутентификация. Пример такого события:
A Kerberos Error Message was received:
on logon session DOMAIN\serviceaccount
Client Time:
Server Time: 12:44:21.0000 10/9/2012 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN
Server Name: krbtgt/DOMAIN
Target Name: krbtgt/DOMAIN@DOMAIN
Error Text:
File: e
Line: 9fe
Error Data is in record data.
Но это может помочь, а может и не помочь, если не будет указано, откуда именно поступает запрос цунами Kerberos. Это возвращает нас к тем продуктам для обнаружения вторжений на предприятиях, о которых я упоминал ранее.
И не забывайте о пересылке событий Windows, которая позволяет вашим серверам пересылать события в централизованное место для анализа любым инструментом, который у вас есть.
Весь этот ответ до сих пор основывался на протоколе Kerberos, который я даже не могу принять как должное, потому что вы дали так мало подробностей в своем посте. Тем не менее, я надеюсь, что это поможет хоть немного.