Применение аудита 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 и укажите следующие параметры:

• Maximum Log Size = 65536 KB (для рабочих станций) или 262144 KB (для серверов)

• Overwrite events as needed.

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

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

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

Время прочтения
17 мин

Просмотры 46K

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

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

Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

 1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).

4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITYNETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTINEvent Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…) и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*</Select>
  </Query>
</QueryList>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US  (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).

После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM-системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги  https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:foldersysmon64.exe -accepteula -i C:foldersysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe  –  файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:Windowssysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box  «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку  «Подробности», а там выбрать radio-button  «Режим XML», в котором в формате  «ключ-значение» будут представлены данные события безопасности.

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

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>

 2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
  </Query>
</QueryList>

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
  </Query>
</QueryList>

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором  «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
  </Query>
</QueryList>

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв  «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке  «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку  «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант  «При событии», а в открывшейся форме отображения установить radio-button  «Настраиваемое». После этих действий появится кнопка  «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and 
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

 Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]] 
and 
*[EventData[Data[@Name='TargetImage']='C:WindowsSystem32lsass.exe']] 
and 
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
  </Query>
</QueryList>

 Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически  бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

Audit встроен в любые ОС Windows, но самостоятельная настройка может оказаться достаточно сложной, поэтому лучше заказать аудит доступа к файлам на Windows сервере.

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

Включаем Audit на объекты файловой системы в Windows Server 2008 R2

Включить или отключить аудит доступа к объектам можно с помощью групповой политики. Это может быть доменный вариант для Active Directory или локальный – безопасности, предназначенный для отдельных серверов.

Включение аудита на отдельном сервере происходит следующим образом. Следует открыть консоль управления для локальных вариантов Start -> … -> Local Security Policy. После этого развернуть дерево Local Policies, а затем выбрать Audit Policy. В правой части выбирают Audit Object Access, после чего выбирают события доступности к каждому файлу и в папки, которые необходимо фиксировать.

Выбор файлов и папок, доступ к которым будет фиксироваться

После того, как Audit на файловом сервере активирован, подобрать определенные объекты, по отношению к которым будет проводиться аудит доступа. Чтобы выполнить это, следует щелкнуть правой кнопкой и выбрать Свойства. Затем перейти в меню Безопасности (Security) и после этого нажать Advanced. Расширенные настройки безопасности открывают вкладку Аудит. Для настройки требуются права администратора. Чтобы настроить права использования, важно добавить запись в Add и указать имя пользователей. Позже указываются точные настройки, включая вход, создание/изменение или, при удалении файла, другие операции.

После этого в журнале Security (Computer Management -> Events Viewer) будет появляться при каждом входе соответствующая запись. Задачи можно отфильтровать PowerShell — Get-Event Log. Так, на операции с eventid 4660 придется выполнить Get-EventLog security | ?{$_.eventid -eq 4660.

Включаем расширенный аудит файлов и папок на файловых серверах

Аудит Windows Server 2008 R2 лучше проводить на тестовом главном устройстве. Файловый главный компьютер аудит доступа требует управления групповыми папками. Его проверка подразумевает создание нового GPO. Через Конфигурации компьютера необходимо перейти в Параметры безопасности. Там потребуется отрегулировать параметры Журнала и настроить сам аудит. Настраиваемые операции принято делать индивидуально. Обычно хватает 200 Мб, максимальное время хранения до 2 недель, поставить автоматическое сохранение по дням.

Чтобы настроить аудит файлового обслуживающего центра баз данных, потребуется использовать аудит файловой системы. Если выбрать вариант «Об общем файловом ресурсе», то запись будет вестись максимально подробно, и будут записываться любые сведения. Для оптимизации политики важно применить ее к главному аппаратному устройству. Лучше делать это на контроллере домена. Нажимают «Добавить», а в качестве объектов указывают «Компьютеры». Потом проводят контрольную проверку политики, сверяют результаты и уходят на файловый главный обслуживающий центр. Важно убедиться в том, что папка представлена с файловым доступом.

Теперь можно перейти во вкладку безопасности в раздел «Дополнительно». Затем добавляют SACL. Что касается типа, то это может быть Audit доступа к файлам, Audit удаления файлов, аудит изменения файлов – каждый механизм действия зависит от поставленных перед пользователем задач. Важно понимать, что для каждого отдельного предприятия такие задачи могут быть разными и по содержанию, и по объему.

Аудит доступа к файлам на Windows сервере

При удалении файла создаются одинаковые события под номером ID=4663. Причем в теле BodyL появляется запись данных или удаление файла DELETE. При переименовании появляется не одна запись ID=4663, а сразу две. В первом случае происходит удаление, во втором – запись данных. Нельзя обойти вариант сообщения 4660, в котором присутствует имя пользователя и другие служебные данные, в том числе и код дескриптора.

При удалении файла такие события генерируются одновременно, но их последовательность всегда 4663 в первую очередь, и только потом 4660. Причем порядковый номер различается на 1. И порядковый номер у 4660 больше на 1, чему 4663. И вот по этому свойству нужно искать требуемые задачи.

Соответственно, берут происходящие события с 4660. У них выделяется два свойства: время (Time) создания и порядковый номер. Позже в переменной $PrevEvent вносят номер операции, где содержатся данные об удаленном файле. Обязательно определяются временные рамки для поиска, при этом их нужно сократить до 2 с (с интервалом +- 1 с). Скорее всего, это дополнительное время (Time) потребуется для создания каждого выполненного задания отдельно.

Соответственно, аудит файлового сервера Windows Server 2008 R2 не записывает данные о временных доках, которые удалены (.*tmp). Не записываются документы блокировок (.*lock) и временные (.*~$*). Аналогично выбираются поля для переменной $BodyL, а после того, как будут найдены задачи, $BodyL записывается в Text файл лог.

Лог для Audit доступа к документам требует такой схемы: 1 файл на месяц с именем (Name), в котором содержится месяц и год. Дело в том, что удаленных элементов намного меньше, чем тех доков, при которых проводится аудит доступа. Именно поэтому вместо того, чтобы проверять каждый лог, открывается лог-файл в любой таблице и просматриваются данные по пользователю или самому содержимому документа.

Можно поделиться своим мнением по этому поводу и посмотреть другие комментарии (20):

….

Настройка аудита файловых серверов: подробная инструкция и шпаргалка (.pdf)

Аудит папки Windows Server 2008 осуществляется очень просто. Нужно открыть Start → Run → eventvwr.msc, далее журнал безопасности Security. Так как в нем присутствуют разные события, совершенно ненужные, то потребуется нажать View → Filter и отфильтровать события

Event Types:   Success Audit;

Event ID:     4663;

а также Category:     Object Access;

Event Source:   Security.

Превратно понимать удаления не нужно. Просто такая функция при операции Аудит Windows XP применима к обычной работе программ. В том числе большинство приложений при запуске сначала формируют временный файл, потом основной, а временный удаляют, когда происходит выход из программы. Бывает и так, что файл и целые папки (иногда – базы данных) удаляются со злым умыслом. Например, уволенный сотрудник решил навредить предприятию и удалить всю информацию. Но восстановить папки не составит труда и для обычного системного администратора. Совсем другое дело, когда можно сказать, когда и кто сделал подобное.

Аудит сетевой папки или аудит сетевых папок (как вам будет удобнее) начинается с настройки. Для этого нужно зайти в Свойства шары, зайти во вкладку безопасности и выделить «Advanced», далее вкладка Audit, где (where) нужно выбрать группу пользователей Everyone. Затем нужно выбрать Edit, и только после этого кликнуть присутствующие флажки как на скрине:

При этом список «Apply onto» должен содержать значение «This folder, subfolders…». А потом, как настройка будет завершена, следует кликнуть ОК.

Аудит Windows Server 2008 подразумевает настройку общей политики. Перед настройкой следует убедиться в том, что учетная запись есть в группе администраторов. Аудит сетевой папки Windows Server 2008 R2 Standart сравним с более ранними версиями. Но при этом сами разработчики советуют использовать расширенные возможности, а не папки или элементов(объектов), хотя с времен 2003 мало что поменялось. Поэтому искать какие-либо актуальные данные вряд ли стоит. Просто потребуется немного времени, чтобы настроить аудит Server 2008 для конкретных задач и в соответствии с теми требованиями, которые предъявляются для определенных бизнес-целей компании

В статье рассмотрим то, как мы можем проводить аудит безопасности системы Windows. Узнаем как настроить и смотреть логи связанные с аудитом.

Привилегии связанные с аудитом

С аудитом доступа связаны две привилегии:

• SeSecurityPrivilege — необходима для управления журналом событий безопасности и для просмотра или настройки SACL.
• SeAuditPrivilege — позволяет процессам, вызывать системные службы аудита для успешного генерирования записей аудита.

Настройка политики аудита

Настройка политики аудита осуществляется из оснастки “Локальная политика безопасности” (secpol.msc).

Схема работы аудита

LSASS отправляет сообщения SRM, чтобы проинформировать его о политике аудита в ходе инициализации системы, а потом при изменениях политики. В свою очередь LSASS получает события аудита от SRM, добавляет дополнительную информацию и отправляет их регистратору событий (Event Logger).

Записи аудита передаются от SRM к подсистеме безопасности LSASS одним из двух способов:

• если запись аудита невелика (меньше чем максимальный размер сообщения ALPC), она отправляется как ALPC-сообщение;
• ну а если запись аудита имеет большой размер, SRM использует общую память, чтобы сообщение было доступно LSASS, и просто передает указатель в ALPC-сообщении.

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

Аудит доступа к объекту по умолчанию выключен, как и другие политики аудита. Чтобы понаблюдать за тем, как работает аудит доступа к объекту, выполните следующие действия. В проводнике перейдите к файлу, к которому у вас есть доступ и откройте свойства этого файла, затем перейдите на вкладку “Безопасность“:

Там нажмите кнопку “Дополнительно” и перейдите на вкладку “Аудит“.

Затем нажмите кнопки “Продолжить” и “Добавить” и в открывшимся окне нажмите на ссылку “Выберите субъект“:

В открывшимся окне впишите логин своего пользователя и нажмите кнопку “Проверить имя“. Если ввели логин верно, то в списке пользователей отобразиться имя вашего пользователя:

Теперь нажмите на кнопку “ОК“, и выставьте все флажки в области “Особые разрешения” и ещё раз нажмите на кнопку “ОК“:

Затем нажмите ещё два раза на кнопку “ОК“, чтобы закрыть дополнительные параметры безопасности и свойства файла.

Дальше запустите оснастку secpol.msc и перейдите в “Локальные политики“. Там откройте “Аудит доступа к объектам” и поставьте флажок “Успех“, затем нажмите “ОК“:

Итак, политику аудита мы включили и на файле аудит настроили. Теперь откройте файл, запишите в него что нибудь и закройте сохранив изменения. Затем откройте журнал “eventvwr.exe” и перейдите в “Журналы Windows / Безопасность“:

Найдите событие с кодом 4656 — это и есть доступ к вашему файлу:

В событии вы увидите:

• ИД безопасности — это ваша учетная запись.
• Тип объекта — File.
• Имя объекта — путь к файлу.
• Имя процесса — путь к файлу программы (System32notepad.exe).
• Ключевые слова — Аудит успеха.
• И другую информацию.

Глобальная политика аудита

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

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

>auditpol /resourceSACL

Чтобы посмотреть глобальные списки SACL для файловой системы и для реестра выполните такие команды:

>auditpol /resourceSACL /type:File /view
>auditpol /resourceSACL /type:Key /view

Для установки аудита всех файлов с доступом на запись (FW) выполните:

> auditpol.exe /resourceSACL /set /type:File /user:<username> /success /failure /access:FW

В примере выше вместо имени пользователя можно ввести группу.

Чтобы выключить глобальный аудит, включенный предыдущей командой, выполните:

> auditpol.exe /resourceSACL /remove /type:File /user:<username>

Конфигурация расширенной политики аудита

В оснастке “Локальная политика безопасности” можно настроить конфигурацию расширенной политики аудита:

В этой конфигурации настройка политики аудита выполняется более тонко. Например, включение “Аудита доступа к объектам” рассматриваемое выше включало аудит для разных объектов. А тут можно выбрать тип объектов:

А “Аудит доступа к глобальным объектам” включает или отключает глобальные SACL, которые мы включали ранее из командной строки:

При включении “Аудита доступа к глобальным объектам” этот параметр нужно будет настроить, указав пользователей для аудита и тип доступа, в общем то что мы делали в командной строке выше:

Вернуться к оглавлению

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Настройка политики аудита входа пользователей в Windows

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).

1. Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
2. Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
3. Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
4. Закройте редактор GPO и обновите настройки политик на клиентах.

Поиск событий входа пользователей в журнале событий Windows

После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

   New Logon:
   Security ID: WINITPROa.khramov
   Account Name: a.khramov
   Account Domain: WINITPRO

Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.

При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView

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

|Where-Object {$_.TimeStamp -gt '5/10/22'}

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}

(c) Peter Gubarevich, 2010

1. Зачем отслеживать действия пользователей?

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

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

    — Когда и во сколько произошла  проблема?

    — Из какой наиболее близкой к этому времени резервной копии следует восстановить данные?

    — Это случилось непреднамеренно, или же кто-то действовал с умыслом?

    — Может, имел место системный сбой, который может повториться ещё раз?

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

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

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

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

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

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

    Заранее угадать, кто именно удалит файл, невозможно, поэтому слежение и указывается за Всеми (Everyone). Удавшиеся попытки удаления отслеживаемых объектов любым пользователем будут заноситься в журнал.

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

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

— Maximum Log Size = 65536 KB (для рабочих станций) или 262144 KB (для серверов)

— Overwrite events as needed.

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

3. Итак, кто же удалил документы?

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

Event Source:    Security;

Category:    Object Access;

Event Types:    Success Audit;

Event ID:    560;

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

    — Object Name. Название искомой папки или  файла;

    — Image File Name. Имя программы, с помощью которой удалили файл;

    — Accesses. Набор запрашиваемых прав.

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

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

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