Чудове запитання.
Перш за все, я вважаю, що більшість "тестувальників проникнення" - це діти. Моя упередженість може бути не справедливою або точною, але я вкладаю цю відмову, щоб, якщо ви виявите будь-який цинізм у моєму тоні, ви знаєте, звідки це походить. Я не кажу, що немає кваліфікованих пентестрів, але це моя велика загальність.
(Синя команда на все життя!)
Моє запитання: 1) Чи є спосіб отримати Active Directory для реєстрації цих невдалих запитів імені користувача в центральному місці, щоб ми могли помітити сплеск в них?
Ви не надали достатньо інформації, щоб хтось міг відповісти на це запитання ґрунтовно та впевнено. Ви сказали, що у вашій програмі було виявлено недолік, який дозволив зловмисникам перерахувати облікові записи користувачів. Я намагаюся зрозуміти, яким чином ви вважаєте, що AD повинен вести журнал для вашої програми.
Мабуть, збої відображалися лише в локальному журналі подій сервера, на якому встановлено програму.
Мабуть, помилки виявилися в журналі подій на сервері? Або невдачі дійсно з'являються в журналі подій на сервері? Якщо так, то що саме говорили про події? Хто їх реєстрував? Ваша заява? Або Windows? Ідіть, дізнайтеся, і я можу додати додаткові роз'яснення до своєї відповіді.
Я збираюся вийти сюди, виходячи з вашої презумпції, що ці події повинні були якось зареєструватись Active Directory ... що робити, якщо ваші пентетери насправді взагалі не використовували недолік у вашій програмі, а замість цього використовували дуже відомий недолік у самому Керберосі для перерахування імен користувачів? Керберос сам містить те, що я вважав би недоліком дизайну, в якому зловмисник може здійснити тисячі і тисячі спроб попередньої аутентифікації (тобто грубої атаки), а KDC буде реагувати по-різному залежно від того, існує чи ні. Це не поведінка, що стосується Active Directory, але так само добре стосується MIT Kerberos, Heimdal тощо. КДК відповість наKDC_ERR_PREAUTH_REQUIREDякщо дійсне ім'я користувача було представлено без попередніх даних, навіть без спроби фактичної автентифікації. Таким чином ви можете перерахувати імена користувачів з KDC. Але оскільки зловмисник (або інструмент, яким зловмисник користується таким, як KrbGuess, - оскільки pentesters є найкращим чином, коли вони використовують інструменти інших людей), не потрібно продовжувати повну спробу аутентифікації, нічого не реєструється, тому що ні була здійснена спроба автентифікації!
Тепер, до вашого наступного питання:
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, за допомогою яких ваші сервери можуть пересилати події в централізоване місце для аналізу, будь-яким інструментом у вас є.
Ця вся відповідь досі пророкувала протокол Кербероса, який я навіть не можу сприйняти як належне, тому що ви дали так мало деталей у своєму дописі. Тим не менш, я сподіваюся, що це допоможе хоч трохи.