Аудит отказа входа в систему

Аудит отказа входа в систему

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

Политики аудита

Следующие политики расположены в узле Конфигурация компьютера (Computer Configuration)Конфигурация Windows (Windows Settings)Параметры безопасности (Security Settings)Локальные политики (Local Policies)Политика аудита (Audit Policy) в редакторе объектов групповой политики [или в оснастке Локальная политика безопасности (Local Security Policy)]. Вы можете настроить аудит успешных или неудачных событий.

• Аудит событий входа в систему (AuditAccountLogonEvents). Эта политика производит аудит всех входов в систему пользователя, для которого требуется проверка подлинности на контроллере домена. Для контроллеров домена эта политика определена в ОГП Default Domain Controllers . Во-первых, она создает запись в журнале безопасности на контроллере домена каждый раз, когда пользователь интерактивно или по сети входит в систему под доменной учетной записью. Во-вторых, помните, что для всесторонней оценки результатов аудита вам необходимо анализировать журналы безопасности на всех контроллерах домена, так как проверка подлинности пользователей распределена по всем контроллерам в сайте или домене.
• Аудит управления учетными записями (AuditAccountManagement). Включает аудит таких действий, как создание, удаление и модификация учетных записей пользователей, групп или компьютеров. Когда включена эта политика, события смены пароля также регистрируются.
• Аудит входав систему(AuditLogonEvents). События входа — это вход и выход из системы (интерактивно или по сетевому подключению). Если вы включили политику Аудит событий входа в систему (Audit Account Logon Events) для регистрации входа, успешно выполняемого на контроллере домена, вход на рабочие станции не будет генерировать события аудита. События входа в систему будут генерироваться только интерактивными или сетевыми входами на контроллер домена. Событие входа учетной записи (account logon event) генерируется на локальных компьютерах для локальных учетных записей, а на контроллере домена — для сетевых учетных записей. Событие входа в систему (logon event) генерируется, где бы ни осуществлялся вход в систему.

Совет Важно отличать вход в систему под учетной записью и общий вход. Когда пользователь входит на рабочую станцию под доменной учетной записью, эта станция регистрирует событие входа (logon event), а контроллер домена — событие входа учетной записи (account logon event). Когда пользователь подключается к общей папке на сетевом сервере, тот регистрирует событие входа, а контроллер домена — событие входа учетной записи.

Журнал событий безопасности

После того как вы настроили аудит, журналы безопасности начинают заполняться сообщениями о событиях. Сообщения можно просмотреть, выбрав Безопасность (Security) в оснастке Просмотр событий (Event Viewer) и дважды щелкнув нужное событие.

Лабораторная работа №5 Аудит безопасности

Цель работы: научить студентов проводить настройку аудита событий безопасности и использовать журналы безопасности для повышения защищенности системы.

Теоретическое введение

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

Аудит по умолчанию отключен, и для его настройки и введения в действие необходимо сначала активизировать аудит через настройки, управляющие политикой безопасности домена (Групповая политика) или компьютера (Локальная политика безопасности).

Затем можно выполнить настройку выбранного типа аудита применительно к объектам системы и ее пользователям.

Указания к проведению лабораторной работы

Чтобы активизировать аудит на локальном компьютере или в масштабах домена, необходимо выполнить следующие действия.

Для локального компьютера на Панели управления в разделе Администрирование выберите Локальные параметры безопасности или в качестве альтернативы запустите в строке Выполнить программу secpol.msc.

В открывшейся оснастке (рисунок 5.1) выберите пункт Локальные политики и раскройте пункт Политика аудита. В правой части окна появится список типов действий аудита. Поначалу ни один из видов аудита не проводится и необходимо активизировать аудит.

Дважды щелкните на каждой политике, для которой необходимо активизировать аудит и затем установите флажки Успех и (или) Отказ.

Аналогичные действия при управлении доменом выполняются с помощью оснастки Групповая политика безопасности в разделе Администрирование контроллера домена.

Рисунок 5.1 Выбор оснастки Локальная политика безопасности

Рисунок 5.2 Установка событий для аудита

Основные события, которые могут быть подвергнуты аудиту, описываются в таблице.

Аудит событий входа по учетной записи

Эти события возникают в контроллере домена, когда пользователь выполняет вход или выход на другом компьютере, входящем в домен

Аудит управления учетными записями

Эти события возникают при создании, изменении или удалении учетной записи или группы, переименовании, активизации или отключении учетной записи, когда задается или изменяется пароль

Аудит доступа к службе каталогов

Эти события возникают, когда выполняется доступ к объекту Active Directory

Аудит событий входа

Эти события возникают, когда пользователь выполняет вход или выход на рабочей станции или подсоединяется через сеть.

Аудит доступа к объектам

Эти события возникают, когда пользователь выполняет доступ к файлу, папке, принтеру, ключу реестра или другому объекту, для которого задан аудит

Аудит изменения политики

Эти события возникают, когда вносятся изменения в политики назначения прав пользователей, политики аудита

Аудит системных событий

Эти события возникают, когда пользователь перезагружает компьютер или завершает его работу либо при возникновении события, которое влияет на безопасность компьютера

В лабораторной работе выполняется настройка аудита для папок и файлов, т.е. выбирается тип аудита — Аудит доступа к объектам.

Для настройки аудита в качестве объекта аудита выберите папку или файл, в диалоговом окне Свойства используйте вкладку Безопасность и по кнопке Дополнительно перейдите в диалоговое окно Параметры управления доступом. Откройте вкладку Аудит (рисунок 5.3). Добавьте пользователей или группы (кнопка Добавить).

Рисунок 5.3 Выбор объектов аудита

Рисунок 5.4 Установка действий, контролируемых при аудите

Измените настройки существующих пользователей (кнопка Просмотр/Правка) в окне Параметры Аудита (рисунок 5.4).

Если устанавливаются флажки события Успех, то Windows запишет в журнал Безопасность (Security) события, их время и дату для каждой успешной попытки данного пользователя или члена группы для указанного файла или папки. Аналогичным образом, если вы устанавливаете флажок события Отказ, Windows запишет в журнал Безопасность (Security) события, их время и дату для каждой неуспешной попытки данного пользователя или члена группы для указанного файла или папки. Для просмотра зафиксированных системой событий аудита служит оснастка Просмотр Событий, доступная на локальном компьютере в разделе Администрирование Панели управления или в разделе Администрирование домена. Можно запустить оснастку командой eventvwr.msc (рисунок 5.5). Данная оснастка открывает доступ к трем журналам, заполняемым системой: System, Securitty, Application. При выполнении аудита заполняется журнал Security. В нем для каждого события для объектов аудита создается соответствующая запись, которую можно просмотреть, дважды щелкнув по ней, как это показано на рисунках 5.5 и 5.6.

Рисунок 5.5 Просмотр содержимого журнала безопасности

Рисунок 5.6 Просмотр информации о событии безопасности

Задание к лабораторной работе

С целью освоения настройки аудита и его использования для повышения безопасности системы выполните следующие действия:

Войдите на виртуальную машину с учетной записью администратора

Активизируйте средствами политики безопасности аудит доступа к объекта (Успех и Отказ).

Создайте временную папку и текстовый файл внутри ее.

Выберите эту папку как объект аудита

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

Выполните ряд типовых действий с папкой и файлом от имени администратора и затем от имени пользователя.

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

Результаты в виде экранов и текстов должны быть сохранены в файле отчета по лабораторной работе и представлены к защите.

Самостоятельно освойте настройку аудита для принтеров.

Контрольные вопросы

Какова роль аудита в обеспечении безопасности компьютерной системы?

Где и каким образом формируется информация о событиях аудита?

Какая информация может быть получена в результате аудита?

Какие типы аудита вы знаете и для чего предназначен каждый из них?

Каким образом активизируется политика аудита?

Каким образом политика аудита применяется для выбранных объектов и пользователей?

В каких случаях целесообразно учитывать Успех, а когда целесообразно фиксировать Отказ?

Как пользоваться журналами безопасности?

Какие учетные записи дают право на настройку аудита и проверку результатов аудита?

Каким образом администратор может использовать информацию об аудите для повышения безопасности системы?

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Аудит отказа входа в систему

Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Ниже на рисунке видно, как они коррелируют между собой.

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы. Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Настройка политик аудита Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Выводы

Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

Применение Аудита Windows для отслеживания деятельности пользователей

Иногда случаются события, которые требуют от нас ответить на вопрос «кто это сделал?» Такое может происходить «редко, но метко», поэтому к ответу на вопрос следует готовиться заранее.

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

В Windows имеется система Аудита, позволяющая отслеживать и журналировать информацию о том, когда, кем и с помощью какой программы были удалены документы. По умолчанию, Аудит не задействован — слежение само по себе требует определённый процент мощности системы, а если записывать всё подряд, то нагрузка станет слишком большой. Тем более, далеко не все действия пользователей могут нас интересовать, поэтому политики Аудита позволяют включить отслеживание только тех событий, что для нас действительно важны.

Система Аудита встроена во все операционные системы Microsoft Windows NT: Windows XP/Vista/7, Windows Server 2000/2003/2008. К сожалению, в системах серии Windows Home аудит спрятан глубоко, и его настраивать слишком сложно.

Что нужно настроить?

Для включения аудита зайдите с правами администратора в компьютер, предоставляющий доступ к общим документам, и выполните команду Start → Run → gpedit.msc. В разделе Computer Configuration раскройте папку Windows Settings → Security Settings → Local Policies → Audit Policies:

Дважды щёлкните по политике Audit object access (Аудит доступа к объектам) и выберите галочку Success. Этот параметр включает механизм слежения за успешным доступом к файлам и реестру. Действительно, ведь нас интересуют только удавшиеся попытки удаления файлов или папок. Включите Аудит только на компьютерах, непосредственно на которых хранятся отслеживаемые объекты.

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

Заранее угадать, кто именно удалит файл, невозможно, поэтому слежение и указывается за Всеми (Everyone). Удавшиеся попытки удаления отслеживаемых объектов любым пользователем будут заноситься в журнал. Вызовите свойства требуемой папки (если таких папок несколько, то всех их по очереди) и на закладке Security (Безопасность) → Advanced (Дополнительно) → Auditing (Аудит) добавьте слежение за субъектом Everyone (Все), его успешными попытками доступа Delete (Удаление) и Delete Subfolders and Files (Удаление подкаталогов и файлов):

Событий может журналироваться довольно много, поэтому также следует отрегулировать размер журнала Security (Безопасность), в который они будут записываться. Для
этого выполните команду Start → Run → eventvwr.msc. В появившемся окне вызовите свойства журнала Security и укажите следующие параметры:

На самом деле, указанные цифры не являются гарантированно точными, а подбираются опытным путём для каждого конкретного случая.

Итак, кто же удалил документы (Windows 2003/XP)?

Нажмите Start → Run → eventvwr.msc и откройте для просмотра журнал Security (Безопасность). Журнал может быть заполнен событиями, прямого отношения к проблеме не имеющими. Щёлкнув правой кнопкой по журналу Security, выберите команду View → Filter и отфильтруйте просмотр по следующим критериям:

• Event Source:Security;
• Category: Object Access;
• Event Types: Success Audit;
• Event ID: 560;

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

• ObjectName. Название искомой папки или файла;
• ImageFileName. Имя программы, с помощью которой удалили файл;
• Accesses. Набор запрашиваемых прав.

Программа может запрашивать у системы сразу несколько типов доступа — например, Delete+Synchronize или Delete+Read_Control. Значимым для нас правом является Delete.

Итак, кто же удалил документы (Windows 2008/Vista)?

Нажмите Start → Run → eventvwr.msc и откройте для просмотра журнал Security (Безопасность). Журнал может быть заполнен событиями, прямого отношения к проблеме не имеющими. Щёлкнув правой кнопкой по журналу Security, выберите команду View → Filter и отфильтруйте просмотр по следующим критериям:

• Event Source: Security;
• Category: Object Access;
• Event Types: Success Audit;
• Event ID: 4663;

Не спешите интерпретировать все удаления как злонамеренные. Эта функция зачастую используется при обычной работе программ — например, исполненяя команду Save (Сохранить), программы пакета Microsoft Office сначала создают новый временный файл, сохраняют в него документ, после чего удаляют предыдущую версию файла. Аналогично, многие приложения баз данных при запуске сначала создают временный файл блокировок (.lck), затем удаляют его при выходе из программы.

Мне приходилось на практике сталкиваться и со злонамеренными действиями пользователей. Например, конфликтный сотрудник некоей компании при увольнении с места работы решил уничтожить все результаты своего труда, удалив файлы и папки, к которым он имел отношение. События такого рода хорошо заметны — они генерируют десятки, сотни записей в секунду в журнале безопасности. Конечно, восстановление документов из Shadow Copies (Теневых Копий) или ежесуточно автоматически создаваемого архива не составляет особого труда, но при этом я мог ответить на вопросы «Кто это сделал?» и «Когда это произошло?».