Поиск данных в журналах Security Log
В журналах Windows 2000 Security Log можно найти много полезной информации. Это сведения о регистрации и активности пользователей, событиях, происходящих на уровне системы в целом, об обслуживании учетных записей и доступе к файлам — вся та информация, которая помогает вовремя обнаружить подозрительные действия и проводить аудит выполнения административных задач. Анализ журнала событий включает в себя не только наблюдение за появлением отдельных событий с ID, но также умение правильно интерпретировать те или иные записи и коды в описании событий для рабочих станций и серверов. Коды событий могут подразумевать различные ситуации в зависимости от того, где возникло событие — на рабочей станции, сервере или контроллере домена (DC). Следует также иметь в виду, что Microsoft периодически меняет кодировку событий для разных версий Windows — Windows Server 2003, Windows XP или Windows 2000.
Попытки регистрации
Мониторинг попыток регистрации в системе — это отличная возможность предупредить атаки на систему и обнаружить иную подозрительную активность. Windows 2000 предоставляет в распоряжение администратора две категории политики аудита: Audit logon events и Audit account logon events. Здесь может возникнуть небольшая путаница. Категория Audit logon events проверяет события регистрации на локальной системе, в которой, собственно, и предпринимается попытка регистрации, тогда как Audit account logon events — когда кто-то пытается пройти аутентификацию с учетной записью, которая хранится на другом компьютере, где и выполняется запись о данном событии регистрации. Windows 2000 отслеживает как регистрацию в домене, так и регистрацию в локальной базе SAM. Когда кто-то выполняет регистрацию на рабочей станции с доменной учетной записью, этот человек (процесс) не только регистрируется на станции, но и участвует в процедуре аутентификации с использованием учетной записи, хранящейся на DC. Следовательно, Audit logon events будет генерировать события в журнале Security Log рабочей станции, а Audit account logon — в журнале Security Log контроллера домена. В течение нескольких секунд, пока выполняется регистрация на рабочей станции, Audit logon events будет генерировать события и на DC, поскольку сама рабочая станция будет выполнять процедуру регистрации от имени пользователя на DC для применения Group Policy уровня пользователя. Audit logon events также будет генерировать события на серверах, являющихся членами домена, поскольку для рабочей станции в процессе регистрации может потребоваться отработка различных сценариев регистрации и подключение к общим сетевым ресурсам серверов — членов домена. Аналогично Audit logon events будет генерировать события на сервере, когда кто-то подключится к консоли сервера или обратится к нему по сети при помощи доменной учетной записи или локальной учетной записи. Что же касается Audit account logon events, то можно будет оценить активность этой политики аудита только тогда, когда кто-то попытается зарегистрироваться на сервере (локально или по сети) с использованием локальной учетной записи в SAM, а не с доменной учетной записью.
Проверяя события, сгенерированные политикой Audit logon events на контроллерах домена, нужно помнить, что они отражают локальные попытки регистрации на DC, а также регистрацию по сети. Компьютеры — члены домена — регулярно обращаются к контроллерам домена за обновлением Group Policy, причем инициатором запроса может быть как компьютер, так и только регистрирующийся пользователь. События, записанные Audit account logon events на станциях DC домена, отображают каждую попытку зарегистрироваться с использованием доменной учетной записи с любого сетевого компьютера, в том числе процедур регистрации с рабочих станций, подключения к серверам — членам домена, а также запросы на регистрацию и подключение собственно к DC.
Мониторинг сбоев при регистрации
Поскольку сбои при регистрации (Logon Failure) из-за неверно указанного пароля могут означать, что кто-то пытается подобрать пользовательский пароль, очень важно осуществлять мониторинг таких событий. Чтобы отслеживать ситуации Logon Failure с использованием доменных учетных записей, нужно выполнять мониторинг всех журналов безопасности Windows 2000 в поисках события с ID 675 (Pre-authentication failed) с кодом сбоя 0х18 и события с ID 681 (The logon to account: %2 by: %1 from workstation: %3 failed. The error code was: %4) с кодом ошибки 3221225578. На контроллерах домена Windows 2003 отслеживать события с ID 681 не нужно. В XP и более поздних версиях Windows разработчики Microsoft заменили событие с ID 681 другим, с ID 680. Windows 2000 использует событие с ID 680 только для сообщений об успешно проведенной аутентификации. В XP и более поздних версиях событие с ID 680 может означать успешную или неуспешную аутентификацию, что распознается по типу события — Failure Audit или Success Audit.
Можно отыскать код сбоя или код ошибки в описании события. DC регистрирует событие с ID 675, когда происходит сбой аутентификации Kerberos и событие с ID 680 или событие с ID 681 с кодами сбоя, когда сбой происходит во время аутентификации Windows NT LAN Manager (NTLM). Событие с ID 680 или событие с ID 681 с кодами сбоя означают, что по крайней мере один компьютер, участвующий в процедуре регистрации, — это станция не с Windows 2000, а с более ранней версией Windows (pre-Windows 2000) или же компьютер из домена, с которым не установлены доверительные отношения. Компьютер с предыдущей версией Windows может быть как рабочей станцией, так и сервером, который является членом домена (т. е. пользователь рабочей станции Windows 2000 подключается к автономному серверу с более ранней версией, чем Windows 2000, с доменной учетной записью). Идентифицировать рабочую станцию можно по IP-адресу клиента в описании события с ID 675 или по имени рабочей станции в событии с ID 680 или событии с ID 681.
Остальные типы сбоев во время выполнения процедуры регистрации генерируют событие с ID 676 (Authentication Ticket Request Failed) при выполнении аутентификации Kerberos, однако для аутентификации NTLM и Windows 2003, и XP продолжают использовать событие с ID 680 (тип Failure Audit), а Windows 2000 — событие с ID 681. Данный сбой регистрации означает неверное использование имени, истечение сроков учетной записи или пароля, работу в запрещенные часы (т. е. кто-то пытается войти в систему в то время, когда это делать запрещено). Чтобы идентифицировать причину сбоя аутентификации, следует посмотреть на код сбоя для события с ID 676 (пример приведен на рис. 1)
|
| Рисунок 1. Событие с ID 676 |
и на код ошибки для события с ID 681 (рис. 2).
|
| Рисунок 2. Событие с ID 681 |
Нужно иметь в виду, что код сбоя события с ID 676 не так детализирован, как код ошибки для события с ID 681. Код сбоя события с ID 676 соотносится с кодом сбоя протокола Kerberos.
Если администратор имеет обыкновение переименовывать группу Administrator для защиты от нападения хакеров, следует наблюдать за событием с кодом ошибки 3221225572 и событием с ID 676 с кодом сбоя 6, в которых в качестве имени пользователя фигурирует Administrator. В системах Windows 2000 нужно следить за событием с ID 681. В Windows 2003 и XP необходимо отслеживать событие с ID 680 (тип Failure Audit). Разработчики Microsoft заменили событие с ID 681 на событие с ID 680 с атрибутом сбоя. Все перечисленные события указывают на сбой при выполнении процедуры регистрации как результат неверного ввода имени пользователя для NTLM или Kerberos соответственно. В табл. 1 приводится список кодов ошибок при сбоях аутентификации.
| Таблица 1. Сбои при аутентификации и коды ошибок | |
| Код ошибки | Причина |
| Аутентификация NTLM. Коды ошибок событий с ID 680 и с ID 681 | |
| 3221225572 | Регистрация с неверной учетной записью пользователя |
| 3221225578 | Регистрация с неверным паролем |
| 3221225583 | Пользователь регистрируется в запрещенное время |
| 3221225584 | Пользователь регистрируется с запрещенной рабочей станции |
| 3221225585 | Пользователь регистрируется с паролем, срок действия которого истек |
| 3221225586 | Пользователь применяет учетную запись, заблокированную администратором |
| 3221225875 | Пользователь применяет учетную запись, срок действия которой истек |
| 3221226020 | Пользователь регистрируется с флагом Change Password at Next Logon |
| 3221226036 | Пользователь задействует заблокированную учетную запись |
| Аутентификация Kerberos. Коды ошибок событий с ID 675 и с ID 676 | |
| 0x6 | Указанное имя пользователя не существует |
| 0x12 | Ограничения по рабочей станции; ограничения на время регистрации; учетная запись отключена, срок ее действия истек или учетная запись заблокирована |
| 0x17 | Срок действия пароля истек |
| 0x18 | Неверно указанный пароль при правильно заданном имени пользователя |
| 0x25 | Часы на рабочей станции слишком сильно отстают от часов контроллера домена |
Мониторинг событий с ID 675 и ID 676, как и неудачные события с ID 680 или событие с ID 681 на серверах DC, дает полную информацию обо всех случаях неудачной регистрации с использованием доменных учетных записей, однако при этом ничего не известно о попытках регистрации на серверах — членах домена через локальную базу учетных записей SAM. Во время атак злоумышленники часто используют локальные учетные записи, чтобы попытаться получить доступ к компьютеру, поскольку локальные учетные записи сложнее поддаются мониторингу и управлению, а локальные пароли зачастую легко «взламываются». Чтобы выполнить мониторинг такой активности, нужно включить политику Audit account logon events на серверах, которые являются членами домена, и наблюдать за событиями с ID 681, появление которых означает, что кто-то пытается зарегистрироваться на сервере при помощи определенной учетной записи. Серверы — члены домена никогда не записывают события Kerberos, поскольку учетные записи локальной SAM всегда работают с аутентификацией NTLM. Важно убедиться, что системные администраторы используют оптимальные технические приемы и избегают применения локальных учетных записей вместо доменных. После этого нужно настроить мониторинг успешно проведенной регистрации на серверах с использованием локальной SAM (событие с ID 681). Если точно известно, что администраторы не применяют локальные учетные записи, подобная активность должна рассматриваться как подозрительная.
Возможно, имеет смысл отключить категорию Audit logon events на серверах — членах домена, поскольку эта политика генерирует события как при обращении к локальной SAM, так и при регистрации с использованием доменных учетных записей, но без видимого различия между ними, что сильно «засоряет» события политики Audit account logon events. Единственная польза включения политики Audit logon events на серверах заключается в том, что она дает возможность отличить локальную регистрацию от подключений по сети.
Если требуется отследить все случаи регистрации с консоли сервера, необходимо проверять записи события с ID 528 (Successful Logon) с Logon Type 2 и события Audit logon events, помеченные как неудачные (также Logon Type 2). Чтобы отследить все случаи подключения к серверу по сети, нужно фильтровать события с ID 540 (Successful Network Logon), что означает успешную регистрацию по сети. Audit logon events дает возможность установить, как долго пользователь был подключен. Следует обратить внимание на Logon ID, который указан в описании события с ID 540 и события с ID 528. Затем следует посмотреть на событие с ID 538 (User Logoff) с тем же самым Logon ID. Используя одинаковый Logon ID для событий регистрации в системе (событие с ID 540 или с ID 528) и события выхода из нее (событие с ID 538), можно будет установить, как долго продолжалась сессия.
Если политика безопасности в отношении блокировки учетных записей настроена таким образом, что происходит автоматическая разблокировка записей по истечении указанного временного периода, можно будет обнаружить блокировки как результат приглашения пользователю сбросить пароль, если не считать возможности проверить наличие записей с ID 644 (User Account Locked Out) в журнале безопасности. Для контроллеров домена событие с ID 644 означает, что учетная запись домена была заблокирована; для сервера — члена домена — что заблокирована локальная запись в SAM. Данное событие — часть категории Audit account management. Нужно иметь в виду, что это не категория процедуры регистрации. Также можно выполнить мониторинг событий, связанных с регистрацией в неурочное время, что часто свидетельствует о необычной активности пользователей (или же о том, что кто-то слишком долго задержался на работе).
Важные системные события
В журнале безопасности Windows 2000 Security Log записываются события, которые могут быть полезными для идентификации атак при физическом доступе и обнаружении некорректного использования административных полномочий (список значимых событий безопасности приведен в табл. 2).
| Таблица 2. Важные события безопасности | ||
| Категория аудита | ID события | Описание |
| Регистрация | 528 | Успешная регистрация |
| 538 | Пользователь завершил сеанс системы | |
| 540 | Успешная регистрация по сети | |
| Учетная запись | 560 | Объект открыт |
| 624 | Создана учетная запись пользователя | |
| 632 | Добавлен объект Security Enabled Global Group Member | |
| 636 | Добавлен объект Security Enabled Local Group Member | |
| 642 | Учетная запись пользователя изменена | |
| 644 | Учетная запись пользователя заблокирована | |
| 645 | Учетная запись компьютера создана | |
| 660 | Добавлен объект Security Enabled Universal Group Member | |
| 675 | Процесс аутентификации неудачен (только для Kerberos) | |
| 676 | Запрос на билет аутентификации неудачен (только для Kerberos) | |
| 680 | Аутентификация NTLM (статус failed или successful) | |
| 681 | Сбой при регистрации (только для Windows 2000) | |
| Система | 512 | Windows NT стартовала |
| 517 | Журнал аудита очищен | |
| Использование привилегий | 577 | Privileged Service Called (обратите внимание на права пользователя в описании прав пользователя - т. е. на SeSystemTimePrivilege) |
| Изменение политики | 612 | Изменение политики аудита |
Неверное изменение системного времени может нарушить нормальную работу приложений. Чтобы менять системное время, пользователь должен обладать правом Change system time, и это можно отследить с помощью категории Audit privilege use. Затем следует отыскать событие с ID 577 (Privileged Service Called), в описании которого указывается SeSystemTimePrivilege.
Обслуживание учетных записей
Категория Audit account management позволяет следить за тем, как администраторы используют свои полномочия, и фиксировать, когда они предоставляют кому-либо новые права доступа. На DC нужно отслеживать события с ID 642 (User Account Changed), это позволяет наблюдать за изменением статуса учетной записи пользователя или пароля. Поскольку данное событие с ID включает в себя практически все типы изменений учетной записи пользователя, детали выполненных изменений содержатся в описании события.
|
| Рисунок 3. Событие с ID 642 |
Событие с ID 624 (User Account Created) позволяет отследить появление на DC новой учетной записи, однако я бы рекомендовал дополнительно проводить мониторинг серверов — членов домена на предмет выявления аналогичного события. Обычно локальные учетные записи SAM с точки зрения безопасности использовать нежелательно, так как они не рассматриваются как объект централизованного менеджмента и мониторинга, поэтому событие с ID 624 может помочь при работе с локальными учетными записями SAM и обнаружении несанкционированных действий.
Наблюдение за новыми членами различных групп тоже очень важная задача. На DC событие с ID 632 (Security Enabled Global Group Member Added), событие с ID 636 (Security Enabled Local Group Member Added) и событие с ID 660 (Security Enabled Universal Group Member Added) помогут идентифицировать момент появления в группах новых членов. Поскольку SAM допускает организацию только локальных групп, на серверах, которые являются членами домена, можно ограничиться лишь наблюдением за событием с ID 636. Во всех трех приведенных выше событиях указываются группа, новый член, а также пользователь, выполнивший данное изменение. На рис. 4 показано событие с ID 632, из описания которого следует, что пользователь rsmith добавил учетную запись Guest в глобальную группу Domain Admins. Если необходимо отслеживать появление несанкционированных компьютеров, нужно использовать событие с ID 645 (Computer Account Created), с помощью которого можно зафиксировать момент добавления нового компьютера в домен.
|
| Рисунок 4. Событие с ID 632 |
Доступ к файлам
Категория Audit object access позволяет отслеживать все типы доступа к файлам, каталогам и другим объектам, таким как принтеры и разделы реестра. Включение этой категории сначала приведет к генерации ограниченного числа событий безопасности, относящихся к обслуживанию SAM. Затем в журнале Security Log начнут появляться события, описывающие доступ к разным объектам, хотя специально для этого вроде бы ничего и не делалось. Чтобы настроить аудит файла или каталога, следует выбрать в Windows Explorer файл или каталог и открыть страницу Properties. Выбрав вкладку Security, нужно щелкнуть Advanced. В окне Access Control Settings требуется выбрать вкладку Auditing (рис. 5). Вначале список записей аудита пуст. Щелкнув Add, следует выбрать пользователя или группу пользователей, которые могут обратиться к объекту аудита, и щелкнуть ОК, чтобы открыть окна Auditing Entry. Теперь можно добавить любую комбинацию пользователей или групп, но я рекомендую задействовать группу Everyone. Необходимо выбрать типы доступа, для которых аудит обязателен, и щелкнуть ОК.
|
| Рисунок 5. Настройка аудита для объекта |
Не следует включать аудит для всех типов доступа, особенно для успешного доступа на чтение. Излишне широкий диапазон мониторинга в политике аудита приведет к созданию огромного числа событий, которые лишь замедлят работу системы и забьют журнал безопасности ненужной информацией. По той же причине следует ограничить число каталогов, за которыми ведется наблюдение. Например, включение аудита в корневом системном каталоге для всех типов доступа — прекрасный способ «завалить» систему.
В зависимости от того, какой тип информации требуется защитить, придется отслеживать попытки несанкционированного чтения файла или действия всякого, кто мог бы изменить содержимое файла. Для обнаружения попыток несанкционированного чтения следует включить аудит неудачных попыток прочесть данные — Read data. Чтобы контролировать попытки изменить файл, необходимо включить аудит успешных попыток записи данных и добавления данных соответственно Write data и Append data. Но нужно иметь в виду, что Windows 2000 выполняет аудит только потенциальных изменений. Например, если пользователь открыл документ Microsoft Word, имея разрешение на запись, и тут же закрыл его без каких бы то ни было изменений, Windows 2000 зафиксирует только тот факт, что пользователь успешно открыл файл на запись. Windows 2003 решает ту же проблему иначе — в тот момент, когда пользователь что-то записал в открытый файл, в журнал помещается специфическое событие. Пользователи также могут обнаружить, когда администратор меняет разрешения файла, настроив мониторинг на успешное выполнение Change permission. Когда пользователь обращается к файлу при помощи операций, на которые настроен мониторинг, Windows 2000 генерирует событие с ID 560 (Object Open), где указывается пользователь, файл, а также тип доступа. Например, код ошибки на рис. 6 показывает, что пользователь пытался открыть файл на чтение, в то время как у него такого права не было. Можно сделать вывод, что он не получил доступа, поскольку было сгенерировано событие о сбое при обращении к объекту. Вместе с тем наверняка известно, что он пытался открыть файл на чтение, так как ReadData указано в поле Accesses.
|
| Рисунок 6. Событие с ID 560 |
Сканирование журналов
События, которые были описаны в статье, — это наиболее важные и легко обнаруживаемые события безопасности в журналах Windows 2000. Windows 2000 использует Event Viewer для обеспечения минимальной функциональности с целью проведения сканирования журналов на предмет обнаружения специфических событий. Можно использовать Event Viewer для фильтрации по ID события и некоторым другим типам информации. Следует выбрать Security Log в Event Viewer, открыть контекстное меню и выбрать View, Filter.
Event Viewer не позволяет отфильтровать события на основе значений в описании события (т. е. по Logon ID или другим кодам), что очень неудобно, поскольку в описаниях содержится огромный объем информации, на основе которой можно отделить наиболее важные события. Однако Event Viewer все же позволяет сканировать отфильтрованные события по заданному значению в описании. Когда фильтр будет установлен, следует открыть контекстное меню Security Log снова и выбрать View, Find. События можно найти, указывая некоторые поля, включая описание. Кнопка Find Next позволяет за один прием найти одно событие. Можно просканировать журнал и другим способом: сначала сохранить его в формате текстового файла с разделителями, затем открыть файл в Microsoft Excel. Но это слишком долго и неудобно, а потому не годится для мониторинга большого количества систем.
Программы независимых разработчиков
Некоторые разработчики выпускают программы, такие как GFI LANguard Security Event Log Monitor, Symantec Intruder Alert, Adiscon?s EventReporter, которые могут объединять журналы с нескольких компьютеров в одну базу данных, формировать сводные отчеты и выдавать предупреждения о тех или иных нежелательных ситуациях. Или же можно воспользоваться свободно распространяемой утилитой от SystemTools.com — DumpEvt — для создания собственного решения. DumpEvt поставляется вместе с шаблоном в формате Microsoft Access, с помощью которого можно импортировать события с большого количества компьютеров. После этого можно разработать собственный отчет, отражающий задачи мониторинга конкретной сети.
Рэнди Франклин Смит — редактор Windows & .NET Magazine и президент компании Monterey Technology Group, которая занимается обучением и консалтингом в области защиты Windows NT. Связаться с ним можно по адресу: rsmith@montereytechgroup.com