Расшифровка событий аутентификации на ваших контроллерах домена

Хотите больше советов от Рэндалла Ф. Смита? Посмотрите его семинар ниже:

Посетите единственный двухдневный семинар, посвященный журналу безопасности Windows

Начиная с Windows 2000, Microsoft представила новую политику аудита под названием «Аудит событий входа в учетную запись», которая устранила один из самых больших недостатков журнала безопасности Windows. До появления этой новой категории было невозможно отслеживать действия по входу в систему для учетных записей домена с помощью журналов безопасности контроллеров домена. (Вы можете просмотреть и настроить политику аудита контроллеров домена с помощью ярлыка «Политика безопасности контроллеров домена по умолчанию» в «Инструментах администрирования». Используйте «Просмотр событий» для просмотра журнала безопасности.) До Windows 2000 у вас была только категория «Аудит событий входа в систему», которая не сработало так, как ожидало большинство людей. Когда вы включаете «аудит событий входа в систему» на контроллерах домена NT и более поздних версий, единственными событиями входа, которые вы увидите в журналах безопасности контроллеров домена, являются пользователи и компьютеры, регистрирующиеся на самом контроллере домена. Если «аудит событий входа в систему» включен, контроллеры домена не регистрируют никаких действий, связанных с входом пользователей домена на свои рабочие станции или другие серверы. Причина в том, что концепция входа в систему отличается от аутентификации. Когда вы входите на свою рабочую станцию с учетной записью домена, вы входите на рабочую станцию, а не на контроллер домена. Контроллер домена просто выполняет проверку подлинности. Поэтому старая политика аудита «аудит событий входа в систему» не очень полезна для отслеживания активности пользователей домена при входе в систему или неудачных попыток входа в систему. Вам придется включить «аудит событий входа в систему» на каждой рабочей станции и сервере в вашей сети, а затем отслеживать эти журналы, и вы все равно не увидите неудачных попыток входа в систему со стороны злоумышленников, использующих свои собственные рабочие станции. Таким образом, появилась необходимость в новой политике аудита, появившейся в Windows 2000 – «аудит событий входа в учетную запись». Когда вы включаете эту политику на контроллере домена Windows 2000 или 2003, эта политика записывает все проверки подлинности учетной записи домена, которые происходят на этом контроллере домена, в журнале безопасности этого контроллера домена. Это действие классифицируется как «Вход в учетную запись» в журнале безопасности, в отличие от «Вход/выход из системы» для политики «аудит событий входа в систему». Когда вы анализируете комбинированную активность «Вход в учетную запись» всех ваших контроллеров домена, вы получаете полную картину активности входа в систему всех учетных записей домена в вашем домене, независимо от того, откуда инициируются попытки входа — с компьютеров локального или доверенного домена или даже неизвестные компьютеры полностью за пределами вашего леса AD и внешних доверенных доменов.

Контроллеры домена Windows 2000 и 2003 поддерживают протоколы проверки подлинности Kerberos и NTLM. Когда компьютеру с Windows 2000 или более поздней версии необходимо выяснить, является ли учетная запись домена подлинной, компьютер сначала пытается связаться с контроллером домена через Kerberos. Если он не получает ответа, он возвращается к NTLM. В лесу AD, состоящем из компьютеров под управлением Windows 2000 и более поздних версий, вся аутентификация между рабочими станциями и серверами должна осуществляться по протоколу Kerberos. Контроллеры домена Windows 2000 и более поздних версий регистрируют разные идентификаторы событий для проверки подлинности Kerberos и проверки подлинности NTLM, поэтому их легко отличить. В лесу AD компьютеров Windows 2000 или более поздней версии любые события проверки подлинности NTLM, которые вы видите на контроллерах домена, могут иметь лишь несколько объяснений. Во-первых, Windows вернется к NTLM, если маршрутизаторы по какой-то причине заблокируют трафик Kerberos (UDP-порт 88). Во-вторых, если ваш домен доверяет другому домену за пределами вашего леса (определенному в Active Directory Domains and Trusts), вы увидите события NTLM на своих контроллерах домена, поскольку Kerberos не работает для внешних доверительных отношений. (Примечание. Windows Server 2003 поддерживает новый тип доверительных отношений между лесами. Доверительные отношения между лесами — это транзитивное двустороннее доверие между двумя доменами Windows Server 2003. Доверительные отношения между лесами используют Kerberos, а не NTLM.) Третье объяснение для События NTLM в журнале безопасности вашего контроллера домена — это мошеннические компьютеры. Вопреки распространенному заблуждению, Windows не запрещает пользователю компьютера из ненадежного домена или автономного компьютера (компьютер Windows, не принадлежащий ни к какому домену) подключаться к серверу в вашем домене с использованием учетной записи домена. Чтобы доказать это, просто подключите диск к компьютеру в ненадежном домене с помощью команды «net use». Например, в приведенном ниже примере я подключаюсь к файловому серверу с именем NYC-FS-1 в домене NYC, используя учетную запись администратора домена и пароль #dk32HE4.

net use \nyc-fs-1.nyc.acme.localc$ #dk32HE4 /user:nycadministrator

Если у вас есть приложение, такое как веб-приложение IIS, которое использует аутентификацию NTLM, вы также увидите NTKM. Единственное другое объяснение событий NTLM в журналах безопасности вашего контроллера домена более приземленное — у вас просто есть несколько компьютеров до Win2k где-то в вашем локальном домене или в общем лесу.

Суть в том, что если посторонний атакует учетные записи в вашем домене, вы, скорее всего, увидите их как ошибки аутентификации NTLM, а не Kerberos. Windows 2000 регистрирует только 2 идентификатора события для всех типов проверки подлинности NTLM — 680 и 681. Успешная проверка подлинности NTLM дает событие с идентификатором 680, а неудача — событие с идентификатором 681. Оба события перечисляют имя пользователя, не прошедшего проверку подлинности, а также имя компьютера с момента попытки аутентификации (обычно это рабочая станция пользователя). Чтобы определить, почему аутентификация не удалась, вам нужно посмотреть код ошибки в описании события с идентификатором 681. На рисунке 1 приведен список кодов ошибок NTLM. NTLM создает событие проверки подлинности всякий раз, когда пользователь входит в систему на компьютере в интерактивном режиме или по сети. Например, представьте, что пользователь входит в свою рабочую станцию NT с учетной записью домена, а затем использует общую папку на сервере A и сервере B. На любом контроллере домена, который обрабатывает эти запросы аутентификации, вы увидите в общей сложности 3 события. ID 680 — один для входа в интерактивную рабочую станцию и 2 для входа в сеть на серверах A и B.

Однако в Windows Server 2003 все немного по-другому. Досадно, что в Windows Server 2003 Microsoft убрала событие с идентификатором 681 и вместо этого использует событие с идентификатором 681 как для успешных, так и для неудачных попыток аутентификации NTLM. Таким образом, в Windows Server 2003 не ищите событие с идентификатором 681 и обязательно учитывайте состояние успеха/неудачи появления события с идентификатором 680.

Поэтому включите аудит «аудит событий входа в учетную запись» на ваших контроллерах домена и следите за событиями с идентификаторами 680 и 681 — они могут выявить некоторые компьютеры, которые пропустили обновление, или, что еще хуже, атаку со стороны постороннего. Если у вас есть несколько контроллеров домена и серверов, полезно иметь такой инструмент, как спонсор этого сайта — LANGuard SELM от GFI, — который может объединять все эти действия в одну базу данных и предоставлять централизованные оповещения и отчеты. Хотя отслеживание проверки подлинности NTLM важно, не забывайте об проверке подлинности Kerberos, которая, вероятно, будет основной частью действий по проверке подлинности в журналах безопасности вашего контроллера домена. Мы рассмотрим события безопасности Kerberos в моей следующей статье.

Рэнди Франклин Смит, президент Monterey Technology Group, Inc. и сертифицированный специалист по системной безопасности, является создателем и эксклюзивным инструктором пятидневного семинара Ultimate Windows Security на сайте UltimateWindowsSecurity.com.

Максимальная безопасность Windows: информация

Ultimate Windows Security — это 5-дневный практический технический курс, посвященный каждой области безопасности Windows. Курс посвящен Windows Server 2003, но Рэнди рассматривает каждый пункт, относящийся к Windows 2000, XP и даже NT. Ultimate Windows Security охватывает основы безопасности Windows, такие как политика учетных записей, разрешения, аудит и управление исправлениями с первого дня. Во второй день вы сосредоточитесь на безопасности Active Directory и групповой политики. День 3 познакомит вас со службами сертификации, службами маршрутизации и удаленного доступа и службами проверки подлинности в Интернете. На 4-й день вы узнаете, как объединить эти 3 технологии для решения реальных задач в области безопасности, таких как двухфакторная безопасность VPN, безопасность Wi-Fi с помощью 802.1x и WPA, надежное и безопасное внедрение шифрованной файловой системы и использование IPSec для работы с различными сетями. проблемы с безопасностью. Пятый день погрузит вас в таинственный мир журнала безопасности Windows. Рэнди раскроет эту прискорбно недокументированную область Windows и покажет вам, как отслеживать аутентификацию, изменения политик, активность администратора, фальсификацию, попытки вторжения и многое другое. Вы можете посетить Ultimate Windows Security публично в учебных центрах по всей Америке или провести курс самостоятельно, запланировав мероприятие в офисе или на месте. Чтобы зарегистрироваться или узнать больше, перейдите на сайт UltimateWindowsSecurity.com.