Объяснение событий аутентификации Kerberos
Если вам нужен еще совет от Рэндалла Ф. Смита, посмотрите его семинар ниже:
Посетите единственный двухдневный семинар, посвященный журналу безопасности Windows
Отслеживание входа в систему с помощью журналов безопасности контроллера домена
В моей последней статье я показал вам, как читать события проверки подлинности NTLM в журналах безопасности ваших контроллеров домена. События NTLM помогают идентифицировать компьютеры с более ранними версиями Windows 2000 в вашем лесу, входы в систему с компьютеров за пределами леса, включая атаки с неавторизованных компьютеров. Однако большая часть событий проверки подлинности, которые вы обнаружите на своих контроллерах домена, скорее всего, являются событиями Kerberos, поскольку Kerberos является протоколом проверки подлинности по умолчанию для компьютеров под управлением Windows 2000 и более поздних версий в домене Active Directory. Чтобы понять эти события Kerberos, необходимо понять базовое функционирование протокола Kerberos. Kerberos использует концепцию билетов. Билет представляет собой небольшой объем зашифрованных данных, специфичных для сеанса, выдаваемых контроллером домена. Когда клиенту необходимо получить доступ к серверу в сети, он сначала получает билет от контроллера домена для этого сервера. Билет и другие данные, предоставленные клиентом, подтверждают личность клиента и предоставляют клиенту возможность аутентификации сервера, что означает, что Kerberos обеспечивает взаимную аутентификацию как клиента, так и сервера. Используя временные метки и другие методы, Kerberos защищает билеты от взломов или повторных атак со стороны перехватчиков в сети.
Основы Kerberos
Во-первых, позвольте мне объяснить, как работает весь процесс обработки заявок, а затем я расскажу вам о реальных действиях пользователя и о том, как они связаны с событиями Kerberos. На самом деле существует 2 типа билетов: билеты аутентификации (также известные как билеты на предоставление билетов и билеты на обслуживание). Kerberos выдает билет аутентификации, когда клиент впервые аутентифицирует себя на контроллере домена. Контроллер домена отправляет обратно билет проверки подлинности и ключ сеанса, зашифрованный личным ключом клиента (в данном случае паролем пользователя). Клиент расшифровывает сеансовый ключ своим личным ключом. Затем клиент использует свой билет аутентификации и ключ сеанса для получения служебных билетов для каждого сервера, к которому клиент должен получить доступ. Windows генерирует события журнала безопасности на каждом этапе процесса проверки подлинности Kerberos, и если вы знаете, как связать общие события Kerberos с действиями пользователя в реальном мире, вы можете внимательно отслеживать действия при входе в домен и выявлять подозрительные события.
Kerberos и журнал безопасности Windows
Представьте себе, что однажды утром Фред входит в свой офис. Фред садится перед своим компьютером XP, включает его и вводит имя пользователя и пароль своего домена. Рабочей станции Фреда необходимо знать, действительно ли Фред является Фредом, поэтому она отправляет запрос аутентификации через Kerberos на контроллер домена. В реализациях Kerberos на основе Unix Kerberos просто выдает билет аутентификации без проверки учетных данных клиента. Если клиент может успешно расшифровать ключ сеанса, поставляемый с билетом проверки подлинности, для запроса билетов службы, то пользователь является подлинным. Если клиент является самозванцем, он не сможет получить сеансовый ключ. Поэтому реализации Unix Kerberos не сразу обнаруживают неудачные попытки входа в систему из-за неправильного пароля. Однако Windows использует дополнительную функцию Kerberos, называемую предварительной аутентификацией. При предварительной аутентификации контроллер домена проверяет учетные данные пользователя перед выдачей билета аутентификации. Если Фред вводит правильное имя пользователя и пароль, Windows регистрирует успешное событие с идентификатором 672, «Билет аутентификации предоставлен». Если в описании события вы видите событие с идентификатором 672, где Фред — это имя пользователя, вы можете интерпретировать это событие как первоначальный вход Фреда на его рабочую станцию. На самом деле вы даже можете идентифицировать его рабочую станцию с помощью поля «Адрес клиента» в описании события с идентификатором 672. Все события Kerberos включают адрес клиента, который идентифицирует IP-адрес клиентского компьютера. Другим полезным полем в событии с идентификатором 672 является «Предоставленное имя области», которое идентифицирует домен учетной записи пользователя, которая на рисунке 1 является маркетингом. Другие события Kerberos идентифицируют домен как «Домен пользователя» или добавляют к имени пользователя префикс домена, как в «МаркетингФред». Но что, если Фред введет неверный пароль? В этом случае предварительная аутентификация Kerberos перехватывает это на контроллере домена, и Windows записывает в журнал событие с идентификатором 675 «Сбой предварительной аутентификации» с кодом ошибки 24 в описании события (см. рис. 2).
Предполагая, что рабочая станция успешно получает билет аутентификации от имени Фреда, затем рабочая станция должна получить билет службы для себя — это билет службы, который аутентифицирует Фреда на рабочей станции и позволяет ему войти в систему. Это событие отображается как событие с идентификатором 673, Service Ticket Granted. Поле «Имя службы» в событии с идентификатором 673 идентифицирует службу, для которой был предоставлен билет — в данном случае имя рабочей станции. Кратко напомним, когда Фред впервые за день входит в систему на своей рабочей станции, контроллер домена, обрабатывающий этот вход, регистрирует событие с идентификатором 672, за которым следует событие с идентификатором 673, где имя службы соответствует имени компьютера. рабочей станции Фреда. Однако это не конец события с идентификатором 673. Вы увидите экземпляр события с идентификатором 673 для каждого сервера, к которому пользователи обращаются после входа на свою рабочую станцию. Например, давайте представим, что сценарий входа Фреда или сопоставление постоянных дисков инициируют подключения к общей папке MktgFiles на сервере FS2. Контроллер домена зарегистрирует событие с идентификатором 673, когда рабочая станция Фреда получит билет службы для FS2, как показано на рисунке 3.
Я показал вам, что Windows регистрирует, когда пользователь вводит неверный пароль, но как насчет всех других причин, по которым вход может быть неудачным, таких как просроченный пароль или отключенная учетная запись? Windows 2000 перехватывает все эти неудачные попытки входа в систему после предварительной аутентификации и, следовательно, регистрирует событие с идентификатором 676, «Ошибка запроса билета аутентификации». Опять же, вам нужно посмотреть на код ошибки, чтобы определить проблему. Наиболее распространенные коды ошибок Kerberos показаны ниже на рис. 4. Windows Server 2003 не регистрирует событие с идентификатором 676. Вместо этого Windows Server 2003 повторно использует событие с идентификатором 672, но изменяет его тип на аудит отказов вместо аудита успехов.
Посторонние события Kerberos
Windows записывает в журнал много того, что большинство людей считает посторонними событиями Kerberos, которые вы можете просто игнорировать. Например, для поддержки функций инфраструктуры Windows, таких как Active Directory, групповая политика, динамические обновления DNS и т. д., рабочие станции, серверы и контроллеры домена должны часто взаимодействовать друг с другом. В такие моменты компьютер Windows аутентифицируется на контроллере домена, используя свою собственную учетную запись компьютера Active Directory, которая, в свою очередь, генерирует события Kerberos. Вы можете идентифицировать такой компьютер для событий проверки подлинности компьютера, поскольку имя пользователя, указанное в событии, — это компьютер, а не пользователь. Имена учетных записей компьютеров легко узнаваемы, поскольку к имени добавляется символ $. См. FS2$ на рис. 3. Вы также увидите множество вхождений события с идентификатором 677 в результате истечения срока действия билета. Срок действия билета является естественной частью работы Kerberos, и Windows автоматически обрабатывает продление билета. Из-за подобных проблем и из-за большого количества систем Windows в типичной сети критически важен какой-либо инструмент мониторинга событий, если вы хотите оставаться в курсе активности учетной записи в вашей сети. Например, Lan Guard SELM позволяет отслеживать несколько компьютеров Windows и объединять их активность в центральную базу данных для составления отчетов. Кроме того, SELM позволяет автоматически отфильтровывать посторонние события, такие как проверка подлинности между компьютерами и действия по обновлению билетов, чтобы вы могли сосредоточиться на важных данных.
Как видите, события Windows Kerberos позволяют легко идентифицировать первоначальный вход пользователя в систему на его рабочей станции, а затем отслеживать каждый сервер, к которому он впоследствии обращается, используя идентификаторы событий 672 и 673. Вы можете отслеживать события неудачной аутентификации, используя идентификаторы событий 675 и 676 или в Windows Контроллеры домена Server 2003 — идентификаторы событий 676 и неудачные события с идентификатором 672. Однако имейте в виду, что регистрация событий проверки подлинности на контроллерах домена (будь то Kerberos или NTLM) не записывает события выхода из системы. Это связано с тем, что контроллеры домена выполняют только службы аутентификации, каждая рабочая станция и сервер отслеживают, кто остается в системе. Чтобы отслеживать события выхода из системы, вы должны проанализировать локальный журнал безопасности нужной рабочей станции или сервера и в этом случае использовать «аудит событий входа в систему» вместо «аудит событий входа в учетную запись».
Рис. 1. Идентификатор события 672.
Рис. 2. Идентификатор события 675.
Тип события: Аудит отказов
Источник события: безопасность
Категория события: Вход в учетную запись
Идентификатор события: 675
Дата: 12.02.2004
Время: 3:22:32
Пользователь: NT AUTHORITYSYSTEM
Компьютер: DC1
Описание:
Предварительная аутентификация не удалась:
Имя пользователя: Фред
ID пользователя: MKTGFred
Имя службы: krbtgt/MKTG
Тип предварительной аутентификации: 0x2
Код неисправности: 24
Адрес клиента: 10.42.42.10Рис. 3. Идентификатор события 673.
Тип события: Аудит успеха
Источник события: безопасность
Категория события: Вход в учетную запись
Идентификатор события: 673
Дата: 12.02.2004
Время: 3:22:32
Пользователь: NT AUTHORITYSYSTEM
Компьютер: DC1
Описание:
Выдан сервисный билет:
Имя пользователя: Фред
Домен пользователя: MKTG.COM
Имя службы: FS2$
Идентификатор службы: MKTGFS2$
Параметры билета: 0x40810010
Тип шифрования билета E: 0x17
Адрес клиента: 10.42.42.10Рис. 4. Коды ошибок Kerberos
Код ошибки Причина 6 Имя пользователя не существует. 12 ограничение рабочей станции; ограничение времени входа в систему. 18 Учетная запись отключена, просрочена или заблокирована. 23 Срок действия пароля пользователя истек. 24 Предварительная аутентификация не удалась; обычно означает неверный пароль 32 Срок действия билета истек. Это обычное событие, которое часто регистрируется учетными записями компьютеров. 37 Часы рабочей станции слишком далеко от синхронизации с часами контроллера домена.
Другие коды Kerberos см. на http://www.ietf.org/rfc/rfc1510.txt.
Посетите двухдневный интенсивный семинар Рэнди
Секреты журнала безопасности
«Секреты журнала безопасности» — это интенсивный двухдневный курс, в ходе которого Рэнди делится своими знаниями, накопленными им за годы исследований журнала безопасности Windows. Вы подробно изучите все 9 категорий аудита безопасности и узнаете, как запрашивать журнал безопасности с помощью простых SQL-команд, таких как запросы. Вы получите множество примеров сценариев, которые помогут вам контролировать автоматизацию задач журнала безопасности, таких как мониторинг, оповещение, архивирование, очистка и многое другое. Вы также узнаете, как интерпретировать другие важные журналы, связанные с безопасностью, таких компонентов, как RRAS, IAS, DHCP-сервер и другие. Секреты журналов безопасности теперь доступны для занятий на месте и запланированы в качестве открытого семинара, который состоится 4 и 5 октября в Нью-Йорке. Чтобы зарегистрироваться и узнать больше, перейдите на страницу http://ultimatewindowssecurity.com/seclogsecrets.asp и загрузите бесплатную краткую справочную таблицу журнала безопасности.
Биография автора:
Рэнди Франклин Смит, президент Monterey Technology Group, Inc. и сертифицированный специалист по системной безопасности, специализируется на безопасности Windows. Рэнди является создателем и эксклюзивным инструктором семинара Ultimate Windows Security и нового курса Security Log Secrets.
Вы можете связаться с Рэнди по адресу [email protected]