Типы входа в систему

Типы входа в систему

В описаниях некоторых событий журнала безопасности, связанных с сессиями входа в системы (например, 4624 и 4625) присутствует параметр Тип входа (Logon type), но его описание слишком короткое:

В поле "Тип входа" указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).

В статье https://technet.microsoft.com/en-us/library/cc787567(v=ws.10).aspx (Audit Logon Events) приводится более детальное описание этого параметра. Эта статья на сайте Microsoft описывает аудит событий входа для старых систем, до Windows Vista. Но константы Типа входа актуальны и для более новых операционных систем Windows.

Так что сейчас мы рассмотри описания от Microsoft и прокомментируем их.

Тип входа 2: Интерактивный. Пользователь непосредственно вошел на этот компьютер.

Событие с типом входа = 2 записывается в журнал безопасности когда пользователь вошел или попытался войти в систему непосредственно локально, используя клавиатуру и введя имя пользователя и пароль в окне входа в систему. Событие с типом входа = 2 возникает при использовании как локальной так и доменной учетной записи.
Если пользователь входит с доменной учетной записью, событие с типом входа = 2 появится если пользователь будет действительно аутентифицирован в домене (контроллером домена)
В случае, если контроллер домена недоступен, но пользователь предоставил валидный пароль, закэшированный в локальном компьютере, Windows поставит тип входа = 11.

Тип входа 3: Сетевой. Пользователь по сети подключился к этому компьютеру и авторизовался на нем.

Обычно такое событие появляется при подключении по сети к разделяемым (shared) ресурсам — папкам, файлам, принтерам. Подключение с типом входа = 3 может быть установлено и с локального компьютера.

Тип входа 4: Пакетный.

Этот тип входа используется при выполнении пакетных заданий без непосредственного участия пользователя. Например, когда запускается задание планировщика. Когда используется планировщик Windows и приходит время запустить задание, Windows может создать новую пользовательскую сессию, чтобы выполнить задание от имени пользователя. При этом регистрируются события (4648, 4624/4625).
Если запланированное задание сконфигурировано так, что не должно запускаться без интерактивного сеанса пользователя, то новая сессия не создается и события не регистрируются.

Тип входа 5: Служба. Service Control Manager запустил службу (service).

Такое событие возникает когда Windows запускает службу от имени пользователя. Windows создает новую сессию для запуска такой службы. Так происходит только, если служба использует обычную учетную запись. Если используется специальная учетная запись, например, “Local System”, “NT AUTHORITYLocalService” или “NT AUTHORITYNetworkService”, то Windows не создает новых сессий. Когда сервис остановится, новая сессия будет закрыта и будет зарегистрировано событие выхода (4634). Имейте ввиду, что описание события не содержит информации о запускаемом сервисе или процессе. Когда регистрируется событие Аудит отказа (4625) с типом входа = 5, это обычно означает что пароль учетной записи для запуска сервиса был изменен пользователем и следует обновить пераметры учетной записи для запуска службы в настройках того приложения, чья служба запускается.

Тип входа 7: разблокирование. Рабочая станция разблокирована.

Событие с типом входа = 7 происходит когда пользователь разблокировывает (или пытается это сделать) ранее заблокированный компьютер. Имейте ввиду, что когда пользователь разблокировывает компьютер, Windows создает новую сессию (или даже 2 сессии в зависимости от полномочий пользователя) и сразу же их завершает, после прохождения аутентификации (событие 4634).
При переключении между учетными записями уже осуществившими вход в систему с помощью функции быстрого переключения учетной записи (Fast User Switching), Windows создает событие 4624 с типом входа = 2 (интерактивный).
Когда регистрируется событие отказа 4625 с типом входа = 7, это обычно означает что вы ошиблись при вводе пароля или кто-то пытался подобрать пароль, чтобы разблокировать компьютер.

Тип входа 8: NetworkCleartext. Пользователь вошел на данный компьютер через сеть. Пароль пользователя передан в пакет проверки подлинности в его нехешированной форме. Встроенная проверка подлинности упаковывает все хешированные учетные записи перед их отправкой через сеть. Учетные данные не передаются через сеть открытым текстом.

Это событие возникает, если пароль пользователя был получен по сети открытым текстом. Такое событие может произойти когда пользователь входит в IIS (Internet Information Services) с базовым методом аутентификации.
Передача паролей в формате открытого текста опасна потому что пароли могут быть перехвачены и раскрыты. Если нет возможности использовать более надежную аутентификацию, то стоит хотя бы защитить сетевое соединение (используя зашифрованные протоколы типа SSL/TLS, создав защищенную виртуальную частную сеть и т.д.).

Тип входа 9: NewCredentials. Посетитель клонировал свой текущий маркер и указал новые учетные записи для исходящих соединений. Новый сеанс входа в систему имеет ту же самую локальную тождественность, но использует отличающиеся учетные записи для сетевых соединений.

Это событие регистрируется, когда используется команда "Запустить от имени" вместе с опцией "/netonly". Это нужно для запуска программы с дополнительными привилегиями для сетевых компьютеров.
Например, нужно запустить Event Log Explorer и дать ему дополнительные права для некоторого компьютера или домена (это может понадобиться если вы захотите использовать определенный компьютер в качестве сервера описаний событий, но ваших текущих прав не достаточно для доступа к администраторским ресурсам этого сервера).
В таком случае вы можете запустить Event Log Explorer через командную строку со следующими параметрами:
runas.exe /netonly /user:SERVERAdministrator “c:program filesevent log explorerelex.exe”
где SERVER — имя сервера, с которого предполагается брать описания событий (также потребуется настроить имя сервера в программе).
При запуске программы, Windows потребует ввести пароль пользователя Administrator для сервера SERVER.
Event Log Explorer запустится даже если вы введете неправильный пароль. При этом будет создана новая пользовательская сессия с учетными данными текущего пользователя и в журнал будет записано событие 4624 с типом входа = 9. А событие выхода из системы для этой сессии будет записано после того, как приложение будет завершено.
Также, в журнале безопасности сервера SERVER будут записаны события 4624 или 4625 с типом входа = 3, но только в момент обращения нашего приложения к разделяемым ресурсам сервера SERVER. То есть, когда Event Log Explorer попытается открыть файл описаний событий на сервере SERVER.

Тип входа 10: RemoteInteractive. Пользователь выполнил удаленный вход на этот компьютер, используя Terminal Services или Remote Desktop.

Этот тип входа похож на 2 (интерактивный), но пользователь подключаетс к компьютеру с удаленного компьютера через RDP, используя Удаленный рабочий стол (Remote Desktop), сервисы терминального доступа (Terminal Services) или Удаленный помощник (Remote Assistance).

Тип входа 11: CachedInteractive. Пользователь вошел на этот компьютер с сетевыми учетными данными, которые хранились локально на компьютере. Контроллер домена не использовался для проверки учетных данных.

Когда пользователь входит в домен, Windows кэширует учетные данные пользователя локально, так что он позже может войти даже если контроллер домена будет недоступен. По умолчанию, Windows кэширует 10-25 последних использованных доменных учетных записей (это зависит от версии Windows). Когда пользователь пытается войти с доменной учетной записью, а контроллер домена не доступен, Windows проверяет учетные данные по сохраненным хэшам и регистрирует события 4624 или 4625 с типом входа = 11.

В этой статье автор осуществил описание централизованной системы мониторинга событий безопасности для Windows Server 2008.

Андрей А. Бирюков

Чтение журналов событий является неотъемлемой частью работы любого администратора безопасности. Сетевое оборудование, операционные системы и практически все бизнес приложения осуществляют журналирование событий безопасности, таких как, удачный/неудачный вход в систему, запуск/остановка системы, обращение к закрытому порту для межсетевых экранов и другие события. Однако при наличии в сети даже десяти серверов, чтение журналов событий на каждом из них становится довольно трудоемкой задачей, требующей затраты большой части рабочего времени. Для того, чтобы автоматизировать процесс обработки журналов событий, например в части поиска попыток неудачного входа в систему, существует множество различных решений. Для Unix систем существует множество бесплатных сценариев на Перл, позволяющих осуществлять автоматический поиск заданного события в журнале и реакцию на данное событие, например отправку почтового сообщения администратору. Для Windows есть множество коммерческих продуктов, таких как ArcSight, Symantec Information Manager или Tivoli Security Operations Manager, которые умеют не только собирать события от различных источников, но и проверять данные события на соответствие различным моделям угроз (например подбор пароля или DDoS атака), реагировать на события, строить отчеты и многое другое. Но эти мощные средства мониторинга стоят очень недешево и в нынешних непростых экономических условиях многим организациям просто не по карману.

Однако, если в вашей сети на серверах используется операционная система Windows Server 2008, то вы можете самостоятельно организовать централизованный мониторинг событий безопасности. Для начала поговорим о том, какие нововведения появились в системе журналирования в Windows Server 2008.

Как и многие другие функции Windows 2008 журналы событий были существенно переделаны и дополнены новыми возможностями. По определению Майкрософт [1] событие это любое значительное проявление в операционной системе или приложении, требующее отслеживания информации. Событие не всегда негативно, поскольку успешный вход в сеть, успешная передача сообщений, или репликация данных также могут генерировать события в Windows. В каждом журнале с его событиями связаны общие свойства.

Читайте также:  Неисправен жесткий диск что делать

Level (уровень) – Это свойство определяет важность события.

Date and Time (дата и время) – Это свойство содержит информацию о дате и времени возникновения события.

Source (источник) – Это свойство указывает источник события: приложение, удаленный доступ, служба и так далее.

Event ID (Код события) – Каждому событию назначен идентификатор события ID, число, сгенерированное источником и уникальное для всех типов событий.

Task Category (Категория задачи) – Это свойство определяет категорию события. Например Security или System. .
Итак, мы разобрались с тем, что представляет из себя событие в журнале Windows Event Log. Теперь нам необходимо сначала настроить аудит событий информационной безопасности. Далее будем предполагать, что у нас используется домен Active Directory и все сервера входят в этот домен.

Для настройки аудита необходимо зайти на контроллер домена и открыть редактор групповых политик Start->Administrative Tools->Group Policy Management. Далее выбираем домен и нажав правую кнопку мыши указываем Create a GPO in this domain… Вообще, для включения аудита можно воспользоваться политиками домена по умолчанию, но лучше создать отдельную политику с соответствующим названием, так как это упрощает администрирование. Далее в новой политике идем в Computer Configuration-> Windows Settings -> Security Settings -> Local Policies -> Audit Policy. Откроется список возможных параметров настройки аудита. Включать все подряд параметры нет особого смысла, так как в таком случае журнал событий наполнится огромным количеством малоинформативных сообщений. Рекомендую следующий набор параметров:

Audit account logon events

Audit account management

Audit directory service access

Audit logon events

Audit object access

включить, только если необходимо отслеживать доступ к определенным объектам (например, каталогам на диске).

Audit policy change

Audit privilege use

Audit process tracking

Audit system events

Теперь мы настроили аудит в нашем домене. Открыв журнал событий Security можно убедиться в том, какое количество событий сыпется в него ежесекундно. Для того, чтобы не нагружать контроллеры домена и другие сервера задачами по обработке событий мы должны сначала переслать события безопасности на выделенный сервер, на котором и будет осуществляться автоматическая обработка всех полученных событий. Данный выделенный сервер также должен работать под управлением операционной системы Windows Server 2008 и входить в домен Active Directory. Для пересылки событий нам необходимо воспользоваться Subscriptions, подписками на события.

Подписки на события

Эта функция аналогична службе Syslog в Unix. Данная функциональная возможность позволяет удаленным компьютерам пересылать сообщения о событиях, в результате чего их можно просматривать локально из центральной системы.
Настроим пересылку событий с нескольких серверов на выделенный сервер сбора событий. Для этого на каждый из серверов источников событий необходимо зайти под учетной записью, обладающей административными правами. В окне командной строки ввести:

Сервер, собирающий сообщения о событиях необходимо добавить в группу локальных администраторов на каждом из серверов источников событий. Затем войдите на сервер, собирающий сообщения, и также выполните:

После этого, выполните на нем же следующую команду:

При необходимости, вы можете изменять параметры оптимизации доставки событий. Например, вы можете изменить параметр Minimize Bandwidth (минимизация пропускной способности) для удаленных серверов, с ненадежным каналом связи.

Теперь необходимо собственно создать подписку, указав события, которые должны извлекаться из логов серверов источников. Для этого на собирающем сервере запустите утилиту просмотра событий с учетной записью, обладающей административными привилегиями. Затем щелкните на папке Subscriptions в дереве консоли и выберите команду Create Subscription (Создать подписку). В поле Subscription Name нужно указать имя подписки. При необходимости в поле Description можно привести описание. Затем, в поле Destination Log (журнал назначения) выберите файл журнала, в котором будут храниться собранные события. По умолчанию эти события будут храниться в журнале перенаправленных событий в папке Windows Logs дерева консоли. После этого, щелкните на кнопке Select Computers, чтобы выбрать исходные сервера, которые будут перенаправлять события. Как уже упоминалось ранее, данные сервера должны находиться в домене. Затем выберите события, нажав на кнопке Select Events. Сконфигурируйте журналы и типы событий, предназначенные для сбора. Щелкните ОК чтобы сохранить подписку.

Журналы

Теперь зайдем на выделенный сервер сбора событий и рассмотрим типы журналов, появившиеся в Windows Server 2008. В папке журналов Windows Logs находятся как традиционные журналы безопасности, приложений и системы, так и два новых журнала – Setup (настройка) и Forwarded Events (Пересланные события). Первые три типа событий уже присутствовали в предыдущих версиях системы, поэтому о них рассказывать нет смысла. А о последних двух следует рассказать подробнее. Журнал Setup фиксирует информацию, связанную с установкой приложений, ролями сервера и их характеристиками. Так, например, сообщения о добавлении на сервере роли DHCP будет отражены в этом журнале. В журнале Forwarded Events собираются сообщения, присланные с других машин в сети.

Папка Applications and Services Logs (журналы приложений и служб) представляют собой новый способ логической организации, представления и сохранения событий, связанных с конкретным приложением, компонентом или службой Windows вместо использовавшейся ранее, регистрации событий, которые оказывают влияние на всю систему. Эти журналы включают четыре подтипа: Admin (события, предназначенные для конечных пользователей и администраторов), Operational (Рабочий журнал событий, также предназначенный для администраторов), Analytic (журнал позволяет отслеживать цепочку возникновения проблемы и часто содержит большое количество записанных событий), Debug (используется для отладки приложений). По умолчанию журналы Analytic и Debug скрыты и отключены. Для того, чтобы их просмотреть, щелкните правой кнопкой мыши на папке Applications and Services Logs, а затем в контекстном меню выберите пункт View, Show Analytic and Debug Logs.

Рисунок 1.
Настройка Debug

Фильтры

Настраиваемые представления – это специальные фильтры, созданные либо автоматически системой Windows 2008, во время добавления в систему новых ролей сервера или приложений, таких как Directory Certificate Services (Службы сертификатов каталогов), сервер DHCP, либо администраторами вручную. Для администраторов одной из важнейших функций при работе с журналами событий является возможность создавать фильтры, позволяющие просматривать только интересующие события, чтобы можно было быстро диагностировать и устранять проблемы в системе. В качестве примера, рассмотрим папку Custom Views в навигационной панели утилиты просмотра событий. Если в этой папке щелкнуть правой кнопкой мыши по Administrative Events и затем выбрать Properties, то после нажатия Edit Filter, можно увидеть как информация из журнала событий преобразуется в набор отфильтрованных событий. Настраиваемые представления оснастки Administrative Events фиксируют все критические события, а события ошибок и предупреждений фиксируются для всех журналов событий (в отличие от предыдущих версий Windows). Таким образом, с помощью данного фильтра администратор может обращаться к единственному источнику для быстрой проверки потенциальных проблем, присутствующих в системе. Это средство может пригодиться при обработке событий, приходящих с серверов источников событий.

Созданные настраиваемые представления можно экпортировать в XML-файл для последующего распространения на другие машины.

Реагируем на события

Еще одной интересной функцией, о которой хотелось бы упомянуть, является возможность ответной реакции на события. Например, если у вас пользователь указал неверные учетные данные для аккаунта, имеющего административные привилегии, то на появление данного события в журнале необходимо отреагировать, послав уведомление администратору безопасности. Данная функция является долгожданным решением проблем с автоматизацией работы серверов, так как раньше требовалось устанавливать дополнительное программное обеспечение или писать сценарии для того чтобы заставить сервер автоматически реагировать на определенные события.

В качестве примера настроим отправку сообщения администратору в случае неудачного входа пользователя в систему (Обратите внимание на то, что теперь это событие имеет другой ID 4625, отличный от использовавшегося в Windows 2003 ID 529).

Для этого необходимо зайти в журнал событий Event Viewer, открыть раздел Windows Logs, затем Security, выбрать нужное событие, нажать правую кнопку мыши, и указать Attach Task To This Event… (прикрепить задачу к этому событию).

Рисунок 2.
Настройка ответной реакции на событие

В открывшемся окне необходимо выбрать название события и его описание. На следующем шаге указывается используемый журнал, источник и номер события. Содержимое этого журнала нельзя изменить. Потом выбирается тип ответного действия. Это может быть выполнение какого-либо приложения, отправка электронного письма или вывод сообщения на экран. Выберем отправку письма. На следующем шаге нужно указать, от кого и на чей адрес отправлять письмо, тему письма, его текст. Можно также прикрепить какой-либо файл к данному сообщению. Не забудьте указать IP-адрес SMTP сервера. На следующем шаге поставьте галочку в соответствующем поле, для того, чтобы после создания задачи, открылось окно с ее свойствами.

Рисунок 3.
Свойства задач

Окно свойств задачи аналогично интерфейсу Scheduled Tasks, для заданий, выполняющихся по расписанию. Здесь можно указать учетную запись, под которой выполняется задача, при необходимости ее можно выполнять только когда пользователь работает на машине.

В закладке Triggers, вы можете добавлять или изменять условия выполнения задачи. В Actions вы можете добавлять различные действия. В закладке Conditions прописаны условия, при которых выполняется задача. В Settings можно прописать, какие действия должны быть выполнены при различных условиях. Например, что нужно делать в случае, если такая задача уже выполняется. Наконец, в закладке History вы можете наблюдать все события, которые вызвали выполнение задачи.

Читайте также:  Прописные и строчные буквы как писать

Немного о построении отчетов

Иногда возникает необходимость в построении отчетов о событиях информационной безопасности. Например, руководители различного уровня очень любят, когда им предоставляют распечатки отчетов, в которых представлена информация, о том сколько попыток несанкционированного проникновения было осуществлено, к примеру за месяц. Благодаря отчетам многие руководители ИТ-отделов выбивают бюджеты на развитие, так что не стоит пренебрегать отчетами.

Итак, нам нужно осуществить выборку событий из журнала. Делать мы это будем с помощью средств PowerShell.

Для начала построим отчет о неудачных входах в систему. Для этого нам необходимо выбрать все события с кодом 4625.

get-eventLog -LogName Security -Newest 100 | Where-Object < $_.EventID —
eq 4625 >

Еще один пример. Узнаем, сколько пользователей осуществляло вход в систему в нерабочее время. Код события Success Logon – 4624.

В завершении, узнаем, сколько удачных входов систему было осуществлено пользователем administrator.

get-eventLog -LogName Security | Where-Object

Здесь приведены только простейшие сценарии работы с журналом событий в Windows Server 2008. При необходимости на их основе можно построить более сложные запросы для релшения соответствующих задач информационной безопасности.

Заключение

В этой статье мы рассмотрели построение системы мониторинга событий информационной безопасности с помощью штатных средств Windoiws Server 2008. С помощью описанных инструментов можно существенно автоматизировать процесс мониторинга событий безопасности.

Использованная литература

1. Р. Моримото, М. Ноэл, О. Драуби Microsoft Windows Server 2008. Полное руководство.

Подписывайтесь на каналы "SecurityLab" в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Журнал безопасности Security Log может использоваться для отслеживания (аудита) большинства действий пользователей в системе.

Существует три основные категории такого аудита — это аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач. Эти категории дают основную информацию при наблюдении за действиями пользователей. Системная политика аудита настраивается в меню Policies-Audit-Audit Policy, вызываемом из программы User Manager (см. Экран 1). Данное диалоговое окно позволяет выбрать, какие из семи категорий фиксировать в локальном журнале безопасности, а какие нет.

Сеансы работы пользователей

ЭКРАН 1. Настройка аудита системы.

Многие администраторы просматривают журнал безопасности Windows NT и видят события входа пользователей в систему и выхода из нее, однако часто не могут правильно оценить увиденное. Здесь следует обращать внимание на отдельные параметры событий. Так, событие успешной регистрации пользователя в системе имеет номер (ID) 528 (см. Рисунок 1). При отказе в регистрации пользователя фиксируется событие с другим номером, который зависит от причины отказа. Полный список событий можно найти в документе Microsoft «Описание событий аутентификации» (см. http://support.microsoft.com/support/kb/articles/q174/0/74.asp). Событие с номером 538 означает завершение сеанса, начало которого зафиксировано событием 528. Событие номер 528 имеет несколько очень важных дополнительных параметров. Имя пользователя и домен определяют вошедшего в систему пользователя или то, чья учетная запись была при этом задействована. Номер сеанса пользователя Logon ID — это уникальный для системы код, присваиваемый любому активному сеансу работы пользователя с системой. Именно он будет записан в событии завершения сеанса. Это позволяет определить общее время работы пользователя при анализе событий 528 и 538 с одним и тем же номером сеанса.

РИСУНОК 1. Событие номер 528.

Событие входа в систему также фиксирует информацию о типе входа Logon Type, т. е. то, как пользователь вошел в систему. Тип входа 2 соответствует интерактивному входу с консоли, например, с помощью монитора и клавиатуры. Если пользователь подключается к диску на другом компьютере или как-либо еще использует сетевой ресурс, то выполняется сетевой вход с типом 3. Так, если был зафиксирован тип входа 2, то кто-то вошел в систему с локальной консоли именно этого компьютера, а если тип 3, значит, кто-то подключился к системе по сети. Тип входа 5 фиксируется при запуске службы с указанием конкретной учетной записи пользователя. При использовании планировщика задач производства независимых компаний, например Argent Queue Manager компании Argent Software, система фиксирует событие номер 528 с типом входа 4, что соответствует заданию на выполнение командного файла. При разблокировании рабочей станции записывается событие с типом входа 7.

Фиксируются также все неудачные попытки входа в систему Logon Failure. При этом чаще всего записывается системное событие 529, соответствующее указанию неверного имени пользователя или пароля — Unknown user name or bad password.

ЭКРАН 2. Выбор рабочих станций, с которых пользователь имеет право войти в систему.

Если учетная запись пользователя недоступна или заблокирована, то попытка входа отвергается, и записывается событие с номером соответственно 531 или 539. Событие номер 530 указывает, что пользователь пытался войти в систему в недозволенное ему время или день недели. Если учетная запись пользователя просрочена или устарел пароль, то фиксируется соответственно событие 532 или 535. Если пользователь ограничен входом лишь на некоторые рабочие станции (см. Экран 2), а он пытается войти с другого компьютера, то запишется событие номер 533. Можно ограничить права пользователя на выполнение определенных типов входа в различные системы. Если пользователь, которому запрещен доступ к какому-то компьютеру по сети, все же пытается обратиться к его ресурсу или реестру, то он получит отказ, а в журнал безопасности запишется событие с номером 534. Такое же событие будет зафиксировано при попытке пользователя войти в систему с консоли, если это ему запрещено. При попытке запустить службу с использованием учетной записи пользователя, не имеющей права на запуск служб (права Logon as a service), также будет зафиксировано событие номер 534. Кроме того, событие 534 запишется и при попытке запуска задания с исполнением командного файла от имени учетной записи без права Logon as a batch job. При всех других отказах в аутентификации фиксируется событие с номером 537, т. е. An unexpected error occurred during logon — отказ по неизвестной причине. Тип входа фиксируется при всех попытках входа в систему, независимо от их результата. Более подробную информацию можно найти в документе Microsoft «Аудит аутентификации пользователей» (см. http://support.microsoft.com/support/kb/articles/q174/0/73.asp).

Аутентификация в Windows NT имеет распределенную природу. Особенно ярко это проявляется при слежении за входом в систему и выходом из нее. Зачастую аудит на рабочей станции, имеющей учетную запись в домене, воспринимается уже как «вход в домен», вместо настоящего момента входа в домен или же входа на контроллер домена с использованием учетной записи домена. Аудит на рабочей станции означает лишь регистрацию на рабочей станции. Но поскольку используется учетная запись домена, сама рабочая станция не может аутентифицировать пользователя. Рабочая станция лишь посылает сведения о пользователе на контроллер домена по протоколу NTLM (NT LAN Manager). Контроллер домена проверяет правильность пароля и сразу же забывает о пользователе. Сеанс работы пользователя поддерживает сама рабочая станция до самого момента выхода из системы. Разумеется, именно рабочая станция и записывает в свой журнал системы безопасности информацию о сессии пользователя.

Для получения общей картины работы пользователей домена зачастую можно обойтись без анализа журналов безопасности на всех без исключения рабочих станциях. Дело в том, что сразу же после успешного входа пользователя обычно выполняется автоматическое подключение сетевых дисков, расположенных на файл-серверах. Именно журналы безопасности файл-серверов и следует просматривать, отслеживая события входа в систему с типом 3. Из-за отсутствия централизованной фиксации входов в систему для домена бывает трудно отследить попытки несанкционированного доступа. Однако, хотя контроллеры домена и не фиксируют все неудавшиеся попытки входа, они записывают все блокировки учетной записи (событие номер 644), которые являются следствием нескольких безуспешных попыток входа подряд. Подробнее о блокировках учетных записей рассказано в документе Microsoft «События при блокировках учетных записей хранятся в журнале безопасности контроллера домена» (см. http://support.microsoft.com/support/kb/articles/q182/9/18.asp).

Необходимо отслеживать использование локальных учетных записей на отдельных системах. Входящие в домен рабочие станции и обычные серверы аутентифицируют пользователей на контроллерах доменов, а также ведут собственные локальные базы пользователей (SAM). И пользователи, и взломщики могут задействовать эти локальные учетные записи, чтобы попытаться войти в систему локально или через сеть. Во всех системах существует встроенная административная учетная запись Administrator. О том, как предотвратить нежелательные попытки ее использования, рассказано в мартовском номере Windows NT Magazine/RE в статье Франклина Р. Смита «Защитим права администратора!».

Для эффективного наблюдения за сеансами работы пользователей нужно хорошо знать, что и где проверять. Для отслеживания входа в систему в первую очередь следует просматривать журналы безопасности на рабочих станциях и простых серверах и искать в них события с номерами 528 и 538. Возможные попытки незаконного проникновения в систему отслеживаются среди событий с номерами от 529 до 537, а также 539 на всех потенциально доступных для нападения компьютерах.

Читайте также:  Приложения для персонализации андроид

Доступ к объектам системы

Аудит доступа к объектам включает в себя всего три события, однако он очень важен, поскольку позволяет отслеживать обращения к любым объектам, включая каталоги, файлы, принтеры и ключи реестра. Для использования перечисленных возможностей необходимо включить опцию регистрации доступа к объектам в меню настройки аудита системы, а также указать все объекты, доступ к которым требуется регистрировать. Список регистрируемых действий для объекта очень напоминает список прав доступа к этому объекту (ACL). В таком списке указаны пользователи и их действия, подлежащие регистрации.

Аудит доступа к объектам ведется в журнале событий, а не в журнале транзакций. Поэтому Windows NT не фиксирует, что именно сделал пользователь с объектом, а указывает только тип доступа к данному объекту. Так, например, можно проследить, что пользователь Иванов открыл файл Зарплата.xls для чтения, записи, выполнения и удаления, однако совершенно невозможно выяснить, внес ли он какие-то изменения, а если да, то какие именно. К тому же при аудите доступа к объектам в журнал может быть записано неоправданно много событий. Так, при активизации двойным щелчком текстового файла из программы Windows Explorer происходит запуск программы WordPad. При этом фиксируется более 20 событий, связанных с доступом к данному файлу и к каталогу, где он находится.

Аудит объектов обычно используется применительно к обычным приложениям, которые работают с отдельными файлами, например к приложениям из комплекта Microsoft Office. Специальные клиент-серверные приложения, такие, как SAP, работают с таблицами, расположенными в нескольких больших файлах базы данных SQL Server. Аудит таких файлов обычно сводится к записи одного события при запуске информационной службы и одного — при ее остановке. При этом не остается сведений о том, какой пользователь выполнял те или иные транзакции или в каких таблицах он менял данные. Эту информацию могут сохранять только сами приложения. Зато аудит таких монолитных файлов помогает выяснить, не пытался ли кто-то заменить файлы базы данных в тот момент, когда SQL Server был остановлен. Это вполне возможно, а перезапущенная прикладная служба не способна заметить подмену.

РИСУНОК 2. Событие номер 560.

Основные два события аудита доступа к объектам: object opened и handle closed. Первое фиксирует открытие объекта (номер 560) , а второе — его закрытие (событие 562). Это взаимодополняющие друг друга события, подобные событиям входа и выхода из системы. Успешное событие номер 560 (см. Рисунок 2) записывает информацию об открытом объекте, а также имя пользователя и название приложения, которое воспользовалось объектом, тип доступа и дескриптор Handle ID.

Handle ID является уникальным кодом для контроля операционной системы за каждым объектом. Он напоминает описанный выше номер сессии пользователя. Найдя пару событий открытия и закрытия (560 и 562) с одним и тем же значением Handle ID, можно выяснить время работы пользователя с данным объектом. Вместе с этим дескриптором событие номер 560 записывает и номер сессии пользователя (см. Рисунок 2), что позволяет выяснить, в какой именно сессии тот обращался к объекту.

События хранят информацию о двух пользователях — об основном и о клиенте. При открытии файла на локальном компьютере с помощью обычного приложения, такого, как Microsoft Word, существенна только информация об основном пользователе. Однако при доступе к объекту из клиент-серверных приложений, которые разграничивают доступ к данным на основе базы пользователей системы, фиксируются оба типа пользователей: основной — соответствует учетной записи клиент-серверного приложения, а клиентский — соответствует пользователю, от имени которого работает сервер. Типичным примером является доступ к файловым ресурсам сервера. Так, при доступе к файлу на другом компьютере через сеть служба Workstation обращающегося к файлу компьютера соединяется со службой Server компьютера с предоставляемым ресурсом, при этом происходит тип 3 входа в систему. Перед обработкой любого запроса сервер аутентифицирует пользователя и записывает события доступа к объекту с указанием основного пользователя и клиента. В этом случае основным пользователем будет SYSTEM, поскольку именно под данной учетной записью запускается служба Server. Информация о клиенте соответствует имени пользователя, которое применялось для доступа к ресурсу; обычно это одна из учетных записей пользователей домена.

Поле типа доступа Accesses в событии номер 560 хранит вид использованного метода доступа к объекту. Значения этого поля соответствуют возможным типам полномочий доступа к объектам ACL. Так, при редактировании текстового файла в редакторе WordPad Windows NT фиксирует событие 560 с типом доступа для чтения ReadData, записи WriteData и добавления AppendData.

Событие 560 также сохраняет информацию о номере процесса Process ID. Этот номер позволяет определить, какая именно программа обратилась к объекту. Например, можно точно выяснить, использовалось ли при редактировании текстового файла приложение Word, WordPad или Notepad. Однако это при условии, что редактировался локальный файл. Если же пользователь обращался к объекту через сеть, фиксируется номер процесса, соответствующий серверному приложению.

Третьим важным событием в категории аудита объектов является событие номер 564, удаление объекта — object deleted. Оно записывает только дескриптор и номер процесса. Чтобы разобраться, какой именно объект и каким пользователем был удален, необходимо отыскать по значению Handle ID соответствующее событие 560 открытия объекта. В событии номер 560 есть вся необходимая информация о пользователе, так что событие 564 удаления объекта следует связывать именно с ним.

Аудит и анализ доступа к объектам представляется очень мощным средством. Однако анализ — процесс весьма трудоемкий, а аудит может снизить быстродействие системы при активном использовании и большом количестве регистрируемых объектов. Не следует злоупотреблять этим типом аудита. Кроме защиты особо важных ресурсов он часто используется службой безопасности предприятия для сбора сведений о неблагонадежных пользователях. Известны случаи, когда аудит ставился на специально подбрасываемые пользователям файлы типа Зарплата.xls только лишь с целью выявить потенциальных злоумышленников. Подобный подход требует строгой проработки. Ну и, конечно, не надо забывать включать аудит доступа к объектам системы в приложении User Manager на той системе, где эти объекты находятся, а не только на рабочей станции пользователя.

Аудит выполняющихся задач

РИСУНОК 3. Событие номер 592.

Эта категория аудита в приложении User Manager называется аудитом выполняющихся задач — process tracking, а в документации по Windows NT и в программе Event Viewer используется термин «детальный аудит» — detailed tracking. Как бы то ни было, данная категория позволяет проследить за тем, какие именно программы были запущены на рабочей станции и какие программы выполнялись на сервере. В этой категории также существуют два основных события — создание нового процесса, событие номер 592, и завершение процесса, событие номер 593. Найдя пару событий 592 и 593, имеющих один и тот же номер процесса Process ID, можно определить общее время работы того или иного приложения. Поле названия исполнительного модуля Image File Name хранит имя файла, соответствующего приложению. Так, при запуске WordPad это поле будет содержать значение WORDPAD.EXE (см. Рисунок 3). К сожалению, событие не записывает полный путь, и судить о точном размещении исполняемого файла нельзя. В поле имени пользователя User Name хранится информация о том, кто запустил приложение. Кроме того, по значению поля номера сеанса Logon ID пользователя можно отыскать соответствующее событие номер 528 и выяснить все подробности о сеансе, в котором запускалось приложение. С помощью поля номера запустившего приложение процесса Creator Process ID можно найти соответствующее событие номер 592, из которого выяснить, какая программа инициировала запуск нового процесса.

Аудит выполняющихся задач может оказаться очень полезным на рабочих станциях, в особенности при изучении активности тех или иных пользователей. Если при этом задействовать аудит доступа к объектам на серверах, то можно построить довольно четкую картину работы пользователей.

Аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач являются тремя важнейшими категориями в журнале безопасности Windows NT. Можно связать сеансы работы пользователей, процессы и доступ к объектам и построить точную картину деятельности пользователей (см. Рисунок 4). К сожалению, Event Viewer не способен фильтровать события по значениям их параметров, так что использовать номера Logon ID, Process ID и Handle ID весьма трудно. Однако можно применить функцию поиска по значению параметра и вручную составить необходимые цепочки событий. Можно также воспользоваться другими программами обработки журнала безопасности Windows NT, которые позволяют отфильтровывать события по различным критериям.

При настройке аудита журнала для этих трех категорий нужно знать, какие компьютеры (рабочие станции, серверы, контроллеры домена) в какие журналы будут записывать те или иные события. Следует помнить, что аудит доступа к объектам системы и аудит выполняющихся задач могут существенно понизить быстродействие системы. В следующий раз мы рассмотрим остальные категории аудита, как-то: аудит управления учетными записями пользователей, изменения системной политики, использования полномочий и системных событий.

Поделитесь материалом с коллегами и друзьями

Ссылка на основную публикацию
Adblock detector