Аудит прав доступа на файловом сервере. Аудит доступа к объекту файловой системы NTFS. Настройка детальной политики аудита

Оптимальный инструмент - групповые политики (применять к OU отслеживаемых серверов). Возможно использование аналогичных локальных политик для каждого сервера

«Computer Settings \ Windows Settings \ Security Settings \ Advanced audit policy configuration \ system audit policies \ object access \ audit file system» => «audit events: success» enabled.

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

2. Настройка аудита на конкретных папках

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

«Delete subfolders and file - Successful»

«Delete - Successful»

“Create files / write data - Successful”

“Create folders / append data - Successful”

3. Мониторинг событий

После этого в логах сервера (на котором хранятся файлы) в Security Event Log будут появляться события при создании и удалении файлов и поддиректорий из указанных выше папок.

Отследить конкретных участников операции можно с помощью двух событий:

Event ID: 4660
Description: An object was deleted.

• Сообщает, что файл был удалён.
• Содержит аккаунт того, кто выполнил операцию удаления
• Не содержит имени файла. Только его Handle ID

Event ID: 4663
Description:An attempt was made to access an object.

• Сообщает о какой-либо попытке доступа к файлу.
• Содержит аккаунт того, кто выполнил операцию.
• Содержит Handle ID и имя файла (Object Name)
• Access mask – маска доступа – определяет для каких целей была попытка доступа к файлу

Виды масок доступа:

Ключевой источник информации – события 4663:

Раздел Subject содержит информацию об аккаунте, из-под которого производились операции над объектом.

Object – информация о файле (путь, имя, handle)

Process Information содержит информацию о том, какой процесс производил операции с файлом.

В разделе Access Request Information размещена информация о типе доступа и маске доступа.

При создании файла в указанной папке, в Security Event Log появляется пара событий с ID 4663 , первое с маской 0х2 , второе с маской 0х4 .

При удалении файла появляется событие с ID 4663 и маской доступа 0х10000 , а также событие 4660 . Определить какой именно файл был удалён по событию 4660 можно найдя предваряющее его событие 4663, имеющее идентичный handle.

Для анализа логов можно использовать инструмент LogParser https://www.microsoft.com/en-us/download/details.aspx?id=24659 и, например, такой запрос:

LogParser.exe -i:evt «SELECT TimeGenerated, EventID, Extract_Token(Strings, 1,’|’) AS User, Extract_Token(Strings, 6, ‘|’) AS File, Extract_Token(Strings, 7, ‘|’) AS HandleID INTO 111.docx.txt FROM ‘C:\\*.evtx’ WHERE (STRCNT(Strings, ‘111.docx’) >0) ORDER BY TimeGenerated DESC»

Где «111.docx» - искомая строка, а C:\\*.evtx – путь к лог-файлам, выгруженным в формате EVTX. LogParser понимает и другие форматы.

Цель работы: Приобрести практические навыки при работе с аудитом доступа к ресурсам.

Объём работы:

Аудит событий.

Параметры аудита для объектов.

Выбор объектов для применения элементов аудита.

Влияние наследования на аудит файлов и папок.

Просмотр журнала событий.

Теоретические сведения. Аудит: обзор

Аудит – отслеживание действий пользователей путем регистрации событий определенных типов в журнале безопасности сервера или рабочей станции.

Аудит определённых компьютеров, пользователей и событий операционной системы является необходимой частью администрирования сети. Установка параметров аудита возможна в окне свойств файлов, папок, общих папок, принтеров и объектов службы каталогов Active Directory. Аудит позволяет отслеживать и записывать события, связанные с безопасностью, такие как попытки доступа пользователей к защищенным файлам и папкам. После включения аудита в журнал безопасности Windows 2000 заносятся записи при любой попытке доступа к этому объекту. При этом определяется объект аудита, действия, подвергаемые аудиту, и точные типы действий для аудита. После установки аудита можно отслеживать доступ пользователей к определенным объектам и анализировать недостатки системы безопасности. Записи аудита показывают, кто выполнял какие-либо действия и кто пытался выполнить какие-либо неразрешенные действия.

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

Аудит событий.

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

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

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

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

Аудит доступа на файлы и папки включается и отключается при помощи групповых политик: доменный политик для домена Active Directory либо локальных политик безопасности для отдельно стоящих серверов. Чтобы включить аудит на отдельном сервере, необходимо открыть консоль управления локальный политик Start -> All Programs -> Administrative Tools -> Local Security Policy . В консоли локальной политики нужно развернуть дерево локальный политик (Local Policies) и выбрать элемент Audit Policy .

В правой панели нужно выбрать элемент Audit Object Access и в появившемся окне указать какие типы событий доступа к файлам и папкам нужно фиксировать (успешный/ неудачный доступ):

После выбора необходимой настройки нужно нажать OK.

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

После того, как активирован аудит доступа к файлам и папкам, необходимо выбрать конкретные объекты файловой системы, аудит доступа к которым будет вестись. Так же как и разрешения NTFS, настройки аудита по-умолчанию наследуются на все дочерние объекты (если не настроено иначе). Точно так же, как при назначении прав доступа на файлы и папки, наследование настроек аудита может быть включено как для всех, так и только для выбранных объектов.

Чтобы настроить аудит для конкретной папки/файла, необходимо щелкнуть по нему правой кнопкой мыши и выбрать пункт Свойства (Properties ). В окне свойств нужно перейти на вкладку Безопасность (Security ) и нажать кнопку Advanced . В окне расширенных настроек безопасности (Advanced Security Settings ) перейдем на вкладку Аудит (Auditing ). Настройка аудита, естественно, требует прав администратора. На данном этапе в окне аудита будет отображен список пользователей и групп, для которых включен аудит на данный ресурс:

Чтобы добавить пользователей или группы, доступ которых к данному объекту будет фиксироваться, необходимо нажать кнопку Add… и указать имена этих пользователей/групп (либо указать Everyone – для аудита доступа всех пользователей):

Сразу после применения данных настроек в системном журнале Security (найти его можно в оснастке Computer Management -> Events Viewer), при каждом доступе к объектам, для которых включен аудит, будут появляться соответствующие записи.

Альтернативно события можно просмотреть и отфильтровать с помощью командлета PowerShell — Get-EventLog Например, чтобы вывести все события с eventid 4660, выполним комманду:

Get-EventLog security | ?{$_.eventid -eq 4660}

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

UPD от 06.08.2012 (Благодарим комментатора ).

В Windows 2008/Windows 7 для управления аудитом появилась специальная утилита auditpol . Полный список типов объектов, на который можно включить аудит можно увидеть при помощи команды:

Auditpol /list /subcategory:*

Как вы видите эти объекты разделены на 9 категорий:

• System
• Logon/Logoff
• Object Access
• Privilege Use
• Detailed Tracking
• Policy Change
• Account Management
• DS Access
• Account Logon

И каждая из них, соответственно, делиться на подкатегории. Например, категория аудита Object Access включает в себя подкатегорию File System и чтобы включить аудит для объектов файловой системы на компьютере выполним команду:

Auditpol /set /subcategory:"File System" /failure:enable /success:enable

Отключается он соответственно командой:

Auditpol /set /subcategory:"File System" /failure:disable /success:disable

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

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

Любой администратор Windows сталкивался с ситуацией, когда разъяренные пользователи хотят узнать, кто именно удалил мега важный файл с годовым отчетом в общей папке на файловом сервере. Эту информацию можно получить только при условии ведения аудита удаления файлов и папок на файловом сервере, иначе останется только восстановить удаленный файл из резервной копии (а вы их уже делаете?) и развести руками.

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

В этой статье мы покажем пример организации на встроенных средствах Windows системы аудита удаления файлов и папок в общем сетевом каталоге (файловом сервере) с записью событий в отдельную базу данных на MySQL.

Благодаря наличию БД с информацией обо всех удаленных файлах администратор сможет дать ответы на вопросы:

• Кто и когда удалил файл
• Из какого приложения удален файл
• На какой момент времени нужно восстанавливать бэкап

В первую очередь на файловом сервере Windows нужно включить аудит событий, обеспечивающий запись информации об удалении файлов в журнал системы. Эту процедуру мы уже рассматривали в статье .

Аудит может быть включен через общую политику Audit Object Access в разделе политик Security Settings -> Local Policy -> Audit Policy

Или (предпочтительнее) через в GPO: Security Settings -> Advanced Audit Policy Configuration -> Object Access -> Audit File System .

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

В свойствах общей сетевой папки (Security -> Advanced -> Auditing), удаление файлов в котором мы хотим отслеживать, для группы Everyone включим аудит событий удаления папок и файлов (Delete subfolders and files ).

Совет . Аудит удаления файлов в конкретной папке можно включить и через PowerShell:

$Path = "D:\Public"
$AuditChangesRules = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone", "Delete,DeleteSubdirectoriesAndFiles", "none", "none", "Success")
$Acl = Get-Acl -Path $Path
$Acl.AddAuditRule($AuditChangesRules)
Set-Acl -Path $Path -AclObject $Acl

При успешном удалении файла в журнале безопасности системы появляется событие Event ID 4663 от источника Microsoft Windows security auditing . В описании события есть информация об имени удаленного файла, учетной записи из-под которой было выполнено удаление и имени процесса.

Итак, интересующие нас события пишутся в журнал, настала пора создать на сервере MySQL таблицу, состоящую из следующих полей:

• Имя сервера
• Имя удаленного файла
• Время удаления
• Имя пользователя, удалившего файл

MySQL запрос на создание такой таблицы будет выглядеть так:

CREATE TABLE track_del (id INT NOT NULL AUTO_INCREMENT, server VARCHAR(100), file_name VARCHAR(255), dt_time DATETIME, user_name VARCHAR(100), PRIMARY KEY (ID));

Скрипт сбора информации из журнала событий. Мы фильтруем журнал по событию с ID 4663 за текущий день

$event = $_.ToXml()
if($event)
{




}
}

Следующий скрипт запишет полученные данные в БД MySQL на удаленном сервере:

$Connection.Open()
$sql = New-Object MySql.Data.MySqlClient.MySqlCommand
$sql.Connection = $Connection
$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @{LogName="Security";starttime="$today";id=4663} | Foreach {
$event = $_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$File = $event.Event.EventData.Data."#text"

$File = $File.Replace(‘\’,’|’)
$User = $event.Event.EventData.Data."#text"
$Computer = $event.Event.System.computer
$sql.CommandText = "INSERT INTO track_del (server,file_name,dt_time,user_name) VALUES ("$Computer","$File","$Time","$User")"
$sql.ExecuteNonQuery()
}
}
$Reader.Close()
$Connection.Close()

Теперь, чтобы узнать, кто удалил файл «document1 — Copy.DOC », достаточно в консоли PowerShell выполнить следующий скрипт.

$DeletedFile = "%document1 - Copy.DOC%"
Set-ExecutionPolicy RemoteSigned
Add-Type –Path ‘C:\Program Files (x86)\MySQL\MySQL Connector Net 6.9.8\Assemblies\v4.5\MySql.Data.dll"
$Connection = @{ConnectionString="server=10.7.7.13;uid=posh;pwd=P@ssw0rd;database=aduser"}
$Connection.Open()
$MYSQLCommand = New-Object MySql.Data.MySqlClient.MySqlCommand
$MYSQLDataAdapter = New-Object MySql.Data.MySqlClient.MySqlDataAdapter
$MYSQLDataSet = New-Object System.Data.DataSet
$MYSQLCommand.Connection=$Connection
$MYSQLCommand.CommandText="SELECT user_name,dt_time from track_del where file_name LIKE "$DeletedFile""
$MYSQLDataAdapter.SelectCommand=$MYSQLCommand
$NumberOfDataSets=$MYSQLDataAdapter.Fill($MYSQLDataSet, "data")
foreach($DataSet in $MYSQLDataSet.tables)
{
write-host "User:" $DataSet.user_name "at:" $DataSet.dt_time
}
$Connection.Close()

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

Примечание . Т.к. была обнаружена проблема, чир символ «\» не записывается в БД, мы заменили его на «|». Соответственно если нужно указать вывести полный путь к файлу, при выборке из базы можно выполнить обратную замену $DataSet.file_name.Replace(‘|’,’\’). Спасибо Alex Kornev за замечание!

Скрипт сброса данных из журнала в БД можно выполнять один раз в конце дня по планировщику или повесить на событие удаления (), что более ресурсоемко. Все зависит от требования к системе.

Совет. Нужно убедиться, что журнал безопасности имеет достаточный размер, чтобы в него помещались все события за день. Иначе придется запускать задания сброса данных из журнала в базу чаще, чем 1 раз в день, или вообще по триггеру. Для рабочих станция Maximum Log Size как правило стоит задать не менее 64 Мб, на северах – 262 Мб. Опцию перезаписи оставляем включенной (Overwrite events as needed ).

При желании по аналогии можно реагировать простую веб страницу на php для получения информации о виновниках удаления файлов в более удобном виде. Задача решается силами любого php программиста за 1-2 часа.

Важный совет . При наличии в журнале информации об удалении файла пользователем не спешите однозначно интерпретировать его как преднамеренное или даже злонамеренное. Многие программы (особенно этим грешат программы пакета MS Office), при сохранении данных сначала создают временный файл, сохраняют документ в него, а старую версию файла удаляют. В этом случае имеет смысл дополнительной записи в БД имени процесса, которым было выполнено удаление файла (поле ProcessName события), и вести анализ удаления файлов с учетом этого факта. Либо совсем радикально отсеивать события от таких мусорных процессов, например, winword.exe, excel.exe и пр.

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