У нас есть Windows Server, на котором находится приложение, которое использует учетные данные домена при входе в приложение. Во время недавнего теста на проникновение тестеры смогли использовать приложение, чтобы перечислить действительные имена пользователей домена на основе ответа приложения (оно давало другой ответ для неверного имени пользователя и неверного пароля).
Приложение исправлено, поэтому оно не раскрывает эту информацию, но я также считаю, что мы должны были обнаружить эту атаку, поскольку за короткий период времени было выполнено более 2 000 000 попыток ввода неверного имени пользователя. Мы этого не видели, даже когда наши администраторы внимательно следили за Active Directory. По-видимому, сбои когда-либо появлялись только в локальном журнале событий сервера, на котором было установлено приложение.
Мой вопрос: 1) Есть ли способ заставить Active Directory регистрировать эти неудачные запросы имени пользователя в центральном месте, чтобы мы могли заметить их всплеск?
2) Если нет, то как лучше всего отслеживать и активно обнаруживать этот тип атак в будущем (надеюсь, без необходимости покупать слишком много нового оборудования).
Спасибо за вашу помощь.
Отличный вопрос.
Перво-наперво - я считаю, что большинство «тестеров на проникновение» - это скрипачи. Моя предвзятость может быть несправедливой или неточной, но я добавляю этот отказ от ответственности, чтобы, если вы заметили какой-либо цинизм в моем тоне, вы знали, откуда он. Я не говорю, что есть нет опытные пентестеры, но это мое общее мнение.
(Синяя команда на всю жизнь!)
Мой вопрос: 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, который я даже не могу принять как должное, потому что вы дали так мало деталей в своем сообщении. Тем не менее, надеюсь, это хоть немного поможет.
Это интересный вопрос, на который я хотел бы услышать правильный ответ. Я наткнулся на некоторую информацию, которую Дуг может счесть полезной, однако я считаю, что она может быть немного неадекватной. Кто-то другой, вероятно, может дать расширенный ответ:
Войдите на сервер, на котором вы хотите хранить информацию аудита, Выполнить -> RSOP.MSC -> Конфигурация компьютера -> Параметры Windows -> Параметры безопасности -> Локальные политики -> Политика аудита -> «Аудит событий входа в учетную запись» и «Аудит событий входа в систему»
В пояснении к «событиям входа в учетную запись» говорится:
Аудит событий входа в учетную запись
Этот параметр безопасности определяет, будет ли ОС проверять каждый раз, когда этот компьютер проверяет учетные данные.
События входа в учетную запись генерируются всякий раз, когда компьютер проверяет учетные данные учетной записи, для которой он является полномочным. Члены домена и машины, не присоединенные к домену, являются полномочными для своих локальных учетных записей; Все контроллеры домена являются полномочными для учетных записей в домене. Проверка учетных данных может поддерживать локальный вход в систему или, в случае учетной записи домена Active Directory на контроллере домена, может поддерживать вход в систему на другом компьютере. Проверка учетных данных осуществляется без сохранения состояния, поэтому для событий входа в учетную запись нет соответствующего события выхода из системы.
Если этот параметр политики определен, администратор может указать, следует ли проводить аудит только успехов, только неудач, как успехов, так и отказов, или не проверять эти события вообще (то есть ни успехов, ни неудач).
Пояснение к «событиям входа в систему» гласит:
Аудит событий входа в систему
Этот параметр безопасности определяет, будет ли ОС проверять каждый экземпляр пользователя, пытающегося войти на этот компьютер или выйти из него.
События выхода из системы генерируются всякий раз, когда завершается сеанс входа в систему для учетной записи пользователя. Если этот параметр политики определен, администратор может указать, следует ли проводить аудит только успехов, только неудач, как успехов, так и отказов, или не проверять эти события вообще (то есть ни успехов, ни неудач).
По сути, вам необходимо включить эти политики, определить параметры политики и выбрать «сбой», если вы просто хотите отслеживать неудачные попытки. При желании вы также можете отслеживать успехи, но это может затруднить анализ, если вы беспокоитесь только о поиске такого рода атак.
Если вас беспокоят подобные конфигурации, к которым могут быть уязвимы ваши системы, я бы рекомендовал изучить настройки STIG (ссылка на сайт), при использовании вместе со сканером SCAP, он действительно может помочь выявить некоторые риски, с которыми может столкнуться ваша организация. Программа просмотра STIG имеет тенденцию вызывать несколько ложных срабатываний, но если вы вникнете в специфику каждой проблемы, вы можете обнаружить, что она не запускается.