Аудит удаления файлов windows server 2008 r2

Для ведения аудита доступа к файлам и папкам в 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 – для аудита доступа всех пользователей):

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

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

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

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

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

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

В 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 Server.

Я думаю, многие сталкивались с задачей, когда к Вам приходят и спрашивают: «У нас тут файл пропал на общем ресурсе, был и не стало, похоже кто-то удалил, Вы можете проверить кто это сделал?» В лучшем случае вы говорите, что у вас нет времени, в худшем пытаетесь найти в логах упоминание данного файла. А уж когда включен файловый аудит на файловом сервере, логи там, мягко говоря «ну очень большие», и найти что-то там — нереально.
Вот и я, после очередного такого вопроса (ладно бекапы делаются несколько раз в день) и моего ответа, что: «Я не знаю кто это сделал, но файл я Вам восстановлю», решил, что меня это в корне не устраивает…

Начнем.

Для начала включим к групповых политиках возможность аудита доступа к файлам и папкам.
Локальные политики безопасности->Конфигурация расширенной политики безопасности->Доступ к объектам
Включим «Аудит файловой системы» на успех и отказ.
После этого на необходимые нам папки необходимо настроить аудит.
Проходим в свойства папки общего доступа на файловом сервере, переходим в закладку «Безопасность», жмем «Дополнительно», переходим в закладку «Аудит», жмем «Изменить» и «Добавить». Выбираем пользователей для которых вести аудит. Рекомендую выбрать «Все», иначе бессмысленно. Уровень применения «Для этой папки и ее подпапок и файлов».
Выбираем действия над которыми мы хотим вести аудит. Я выбрал «Создание файлов/дозапись данных» Успех/Отказ, «Создание папок/дозапись данных» Успех/отказ, Удаление подпапок и файлов и просто удаление, так же на Успех/Отказ.
Жмем ОК. Ждем применения политик аудита на все файлы. После этого в журнале событий безопасности, будет появляться очень много событий доступа к файлам и папкам. Количество событий прямопропорционально зависит от количества работающих пользователей с общим ресурсом, и, конечно же, от активности использования.

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

#Задаем период, в течении которого мы будем запускать один раз скрипт, и искать нужные нам события. Здесь период задан - 1 час. Т.е. проверяются все события за последний час.
$time =  (get-date) - (new-timespan -min 60)

#$BodyL - переменная для записи в лог-файл
$BodyL = ""

#$Body - переменная, в которую записываются ВСЕ события с нужным ID. 
$Body = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4663;StartTime=$Time}|where{ ([xml]$_.ToXml()).Event.EventData.Data |where {$_.name -eq "ObjectName"}|where {($_.'#text') -notmatch ".*tmp"} |where {($_.'#text') -notmatch ".*~lock*"}|where {($_.'#text') -notmatch ".*~$*"}} |select TimeCreated, @{n="Файл_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "ObjectName"} | %{$_.'#text'}}},@{n="Пользователь_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "SubjectUserName"} | %{$_.'#text'}}} |sort TimeCreated

#Далее в цикле проверяем содержит ли событие определенное слово (к примеру название шары, например: Secret)	
foreach ($bod in $body){
	if ($Body -match ".*Secret*"){

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

		$BodyL=$BodyL+$Bod.TimeCreated+"`t"+$Bod.Файл_+"`t"+$Bod.Пользователь_+"`n"
	}
}

#Т.к. записей может быть очень много (в зависимости от активности использования общего ресурса), то лучше разбить лог #на дни. Каждый день - новый лог. Имя лога состоит из Названия AccessFile и даты: день, месяц, год.
$Day = $time.day
$Month = $Time.Month
$Year = $Time.Year
$name = "AccessFile-"+$Day+"-"+$Month+"-"+$Year+".txt"
$Outfile = "serverServerLogFilesAccessFileLog"+$name

#Пишем нашу переменную со всеми данными за последний час в лог-файл.
$BodyL | out-file $Outfile -append

А теперь очень интересный скрипт.

Скрипт пишет лог об удаленных файлах.

#Переменная $Time тут имеет такое же назначение как в предыдущем скрипте.

$time =  (get-date) - (new-timespan -min 60)

#$Events - содержит время и порядковый номер записи евента с ID=4660. И сортируем по порядковому номеру.
#!!!!Это важное замечание!!! При удалении файла создается сразу 2 записи, с ID=4660 и ID=4663.
$Events = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4660;StartTime=$time} | Select TimeCreated,@{n="Запись";e={([xml]$_.ToXml()).Event.System.EventRecordID}} |sort Запись

#Самые важные команды поиска. Опишу принцип ниже, после листинга скрипта.
$BodyL = ""
$TimeSpan = new-TimeSpan -sec 1
foreach($event in $events){
	$PrevEvent = $Event.Запись
	$PrevEvent = $PrevEvent - 1
	$TimeEvent = $Event.TimeCreated
	$TimeEventEnd = $TimeEvent+$TimeSpan
	$TimeEventStart = $TimeEvent- (new-timespan -sec 1)
	$Body = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4663;StartTime=$TimeEventStart;EndTime=$TimeEventEnd} |where {([xml]$_.ToXml()).Event.System.EventRecordID -match "$PrevEvent"}|where{ ([xml]$_.ToXml()).Event.EventData.Data |where {$_.name -eq "ObjectName"}|where {($_.'#text') -notmatch ".*tmp"} |where {($_.'#text') -notmatch ".*~lock*"}|where {($_.'#text') -notmatch ".*~$*"}} |select TimeCreated, @{n="Файл_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "ObjectName"} | %{$_.'#text'}}},@{n="Пользователь_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "SubjectUserName"} | %{$_.'#text'}}} 
	if ($Body -match ".*Secret*"){
		$BodyL=$BodyL+$Body.TimeCreated+"`t"+$Body.Файл_+"`t"+$Body.Пользователь_+"`n"
	}
}


$Month = $Time.Month
$Year = $Time.Year
$name = "DeletedFiles-"+$Month+"-"+$Year+".txt"
$Outfile = "serverServerLogFilesDeletedFilesLog"+$name


$BodyL | out-file $Outfile -append

Как оказалось при удалении файлов и удалении дескрипторов создается одно и тоже событие в логе, под ID=4663. При этом в теле сообщения могут быть разные значения «Операции доступа»: Запись данных (или добавление файла), DELETE и т.д.
Конечно же нас интересует операция DELETE. Но и это еще не все. Самое интересное, то что, при обычном переименовании файла создается 2 события с ID 4663, первое с Операцией доступа: DELETE, а второе с операцией: Запись данных (или добавление файла). Значит если просто отбирать 4663 то мы будем иметь очень много недостоверной информации: куда попадут файлы и удаленные и просто переименованные.
Однако мной было замечено, что при явном удалении файла создается еще одно событие с ID 4660, в котором, если внимательно изучить тело сообщения, содержится имя пользователя и еще много всякой служебной информации, но нет имени файла. Зато есть код дескриптора.

Однако предшествующим данному событию было событие с ID 4663. Где как раз таки и указывается и имя файла, и имя пользователя и время, и операция как не странно там DELETE. И самое главное там имеется номер дескриптора, который соответствует номеру дескриптора из события выше (4660, помните? которое создается при явном удалении файла). Значит теперь, чтобы точно знать какие файлы удалены, необходимо просто найти все события с ID 4660, а так же предшествующие каждому этому событию, событие с кодом 4663, в котором будет содержаться номер нужного дескриптора.

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

Т.е. берутся все события с ID 4660. У них берется 2 свойства, время создания и порядковый номер.
Далее в цикле по одному берется каждое событие 4660. Выбирается его свойства, время и порядковый номер.
Далее в переменную $PrevEvent заносится номер нужного нам события, где содержится нужная информация об удаленном файле. А так же определяются временные рамки в которых необходимо искать данное событие с определенным порядковым номером (с тем самым который мы занесли в $PrevEvent). Т.к. событие генерируется практически одновременно, то поиск сократим до 2х секунд: + — 1 секунда.
(Да, именно +1 сек и -1 сек, почему именно так, не могу сказать, было выявлено экспериментально, если не прибавлять секунду, то некоторые может не найти, возможно связано с тем, что возможно два эти события могут создаваться один раньше другой позже и наоборот).
Сразу оговорюсь, что искать только по порядковому номеру по всем событиям в течении часа — очень долго, т.к. порядковый номер находиться в теле события, и чтобы его определить, нужно пропарсить каждое событие — это очень долго. Именно поэтому необходим такой маленький период в 2 секунда (+-1сек от события 4660, помните?).
Именно в этом временном промежутке ищется событие с необходимым порядковым номером.
После того как оно найдено, работают фильтры:

|where{ ([xml]$_.ToXml()).Event.EventData.Data |where {$_.name -eq "ObjectName"}|where {($_.'#text') -notmatch ".*tmp"} |where {($_.'#text') -notmatch ".*~lock*"}|where {($_.'#text') -notmatch ".*~$*"}}

Т.е. не записываем информацию об удаленных временных файлах (.*tmp), файлах блокировок документов MS Office (.*lock), и временных файлах MS Office (.*~$*)
Таким же образом берем необходимые поля из этого события, и пишем их в переменную $BodyL.
После нахождения всех событий, пишем $BodyL в текстовый файл лога.

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

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

Рекомендации

Вам придется самим определить время в течении которого вы будете искать нужные события. Чем больше период, тем дольше ищет. Все зависит от производительности сервера. Если слабенький — то начните с 10 минут. Посмотрите, как быстро отработает. Если дольше 10 минут, то либо увеличьте еще, вдруг поможет, либо наоборот уменьшите период до 5 минут.

После того как определите период времени. Поместите данный скрипт в планировщик задач и укажите, что выполнять данный скрипт необходимо каждые 5,10,60 минут (в зависимости какой период вы указали в скрипте). У меня указано каждый 60 минут. $time = (get-date) — (new-timespan -min 60).

PS

У меня оба эти скрипта работают для сетевого ресурса в 100Гб, на котором ежедневно активно работают в среднем 50 пользователей.
Время поиска удаленных файлов за час — 10-15 минут.
Время поиска всех файлов, к которым был доступ — от 3 до 10 минут. В зависимости от нагрузки на сервер.

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

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

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

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

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

В первую очередь на файловом сервере Windows нужно включить аудит событий, обеспечивающий запись информации об удалении файлов в журнал системы. Эту процедуру мы уже рассматривали в статье Аудит доступа к файлам и папкам в 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 subfoldersand files).

При успешном удалении файла в журнале безопасности системы появляется событие 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 за текущий день

$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @{LogName="Security";starttime="$today";id=4663} | Foreach {
$event = [xml]$_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$File = $event.Event.EventData.Data[6]."#text"
$User = $event.Event.EventData.Data[1]."#text"
$Computer = $event.Event.System.computer
}
}

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

Set-ExecutionPolicy RemoteSigned
Add-Type –Path ‘C:Program Files (x86)MySQLMySQL Connector Net 6.9.8Assembliesv4.5MySql.Data.dll'
$Connection = [MySql.Data.MySqlClient.MySqlConnection]@{ConnectionString='server=10.7.7.13;uid=posh;[email protected];database=aduser'}
$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 = [xml]$_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$File = $event.Event.EventData.Data[6]."#text"

$File = $File.Replace(‘’,’|’)
$User = $event.Event.EventData.Data[1]."#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)MySQLMySQL Connector Net 6.9.8Assembliesv4.5MySql.Data.dll'
$Connection = [MySql.Data.MySqlClient.MySqlConnection]@{ConnectionString='server=10.7.7.13;uid=posh;[email protected];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[0])
{
write-host "User:" $DataSet.user_name "at:" $DataSet.dt_time
}
$Connection.Close()

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

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

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

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

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

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

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

Спасибо WinItPro

Join @AdmNtsRu on Telegram

Наверняка многим из тех, кто читает эту статью, доводилось сталкиваться с ситуацией, когда пользователи обращаются к вам со следующей проблемой: пропал такой-то файл с общего ресурса, возможно, он был удален, или кто-нибудь добавил новый файл. Как можно проверить, кто это сделал? При этом поиск упоминания о данном файле в логах едва ли поможет вам найти то, что вы ищите. А при включенном на файл-сервере файловом аудите, записи в логах настолько объемные, что отыскать в них что-то «руками» попросту невыполнимо.

Но есть ли какое-нибудь более-менее эффективное решение данного вопроса? Об этом мы и поговорим в сегодняшней статье.

Включение и настройка параметров аудита доступа к объектам

Сперва необходимо включить в разделе «Групповые политики» аудит доступа к папкам и файлам. Для этого переходим в «Локальные политики бeзопасности» > «Конфигурирование расширенных политик безопасности» > «Доступ к объекту». Здесь потребуется включить функцию аудита файловой системы на отказ и успех, после чего настроить нужные папки на аудит. Для этого перейдем в свойства папок общего доступа на сервере файлов, далее в раздел «Безопасность», откуда следуем в дополнительные настройки («Дополнительно») > «Аудит». В данном разделе выбираем «Изменить», далее – «Добавить». Рекомендуется выбрать здесь «Все». На уровне применения для текущей папки и входящих в нее папок, а также файлов выберем действия, для которых будет вестись аудит.

Можно использовать следующую схему: «Создание папок» — Отказ/Успех, «Дозапись данных/создание файлов» — Отказ/Успех, «Удаление вложенных папок и файлов – Отказ/Успех. После того, как мы отметили необходимые пункты, нужно нажать «ОК» и дождаться применения выбранных политик к папкам и файлам. Далее появится множество событий, отражающих удачный и неудачный доступ к файлам, в журнале событий безопасности. В данном случае имеется прямо пропорциональная зависимость числа событий к количеству пользователей, которые работают с общим файловым ресурсом, а также их активности.

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

Скрипт поиска событий за определенный временной промежуток

Задаем поисковый параметр за промежуток, равный, к примеру, 1 часу:

$timе = (gеt-dаte) — (nеw-timеspan -min 60)

$BоdуL = «»

Переменная «$BodyL» требуется для записи события в лог файл.

$Bоdу = Gеt-WinEvеnt -FiltеrHashtable

@{LоgName=»Sеcurity»;ID=4663;StаrtTimе=$Timе

$}|whеre{ ([xml]$_.TоXml()).Evеnt.EvеntDаta.Dаta |whеre {$_.nаmе -еq «ObjеctNаmе»}|whеre {($_.’#tеxt’) -nоtmatch «.*tmp»} |whеre {($_.’#text’) -nоtmatch «.*~lоck*»}|whеre {($_.’#tеxt’) -nоtmatch «.*~$*»}} |selеct TimеCrеаtеd, @{n=»File_»;e={([xml]$_.TоXml()).Evеnt.EvеntDаta.Dаtа | ? {$_.Nаmе -еq «ОbjеctNаmе»} | %{$_.’#tеxt’}}},@{n=»User_»;e={([хml]$_.TоХml()).Еvеnt.ЕvеntDаtа.Dаtа | ? {$_.Nаmе -еq «SubjеctUsеrNаmе»} | %{$_.’#tехt’}}} |sоrt TimеCrеаted

В данном случае переменная $Body служит для записи всех событиях с требуемым ID.

Теперь необходимо проверить в цикле событие на наличие определенного слова (к примеру «Sewers»):

fоrеаch ($bоd in $bоdу){

if ($Воdу -mаtсh «.* Sewers *»){

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

$BоdyL=$BоdуL+$Bоd.TimеCrеаtеd+»`t»+$Bоd.File_+»`t»+$Bod.User_+»`n»

}

}

Поскольку число таких записей может быть очень большим, что будет также зависеть от активности общего ресурса данных, лучшим решением будет разбивка лога на составные части (например, по дням). Каждый день будет создаваться новый лог. Его имя будет состоять из даты, с указанием дня, месяца и года, а также названия Access:

$Dау = $timе.dау

$Mоnth = $Timе.Mоnth

$Yеаr = $Timе.Yеаr

$nаmе = «Ассеss-«+$Dау+»-«+$Mоnth+»-«+$Yеаr+».tхxt»

$Оutfilе = «sеrverServerLogFilеsAccеssFileLоg»+$nаmе

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

$BоdyL | оut-filе $Оutfilе -арреnd

Скрипт записи лога об удаленных файлах

$timе = (get-datе) — (nеw-timеspan -min 60)

#$Evеnts – здесь содержится порядковый номер и время записи ивента, который имеет ID= 4660. Также зададим параметр сортировки по порядковым номерам.

Когда файл удаляется, создается две записи: первая с ID=4660, и вторая с ID, равным 4663.

$Еvеnts = Gеt-WinEvеnt -FilterHаshtable

@{LоgNаmе=»Sеcurity»;ID=4660;StаrtTimе=$timе} | Sеlесt

TimeCrеаted,@{n=»Nоtе»;е={([хml]$_.ToXml()).Event.System.EvеntRecоrdID}} |sоrt Nоtе

$BоdyL = «»

$TimеSpаn = new-TimеSpan -sec 1

fоrеаch($еvеnt in $еvents){

$PrеvEvеnt = $Evеnt.Зaпись

$PrеvEvеnt = $PrеvEvеnt — 1

$TimeEvеnt = $Event.TimеCrеаtеd

$TimеEventEnd = $TimeEvent+$TimеSpan

$TimеEventStart = $TimеEvent- (new-timеspan -sеc 1)

$Bоdy = Gеt-WinEvеnt -FiltеrHаshtable @{LоgNаmе=»Sеcurity»;ID=4663;StаrtTimе=$TimеEventStart;ЕndTime=$TimеEvеntЕnd} |where {([хml]$_.ToХml()).Еvеnt.System.ЕvеntRеcоrdID -mаtch «$PrеvEvеnt»}|whеre{ ([xml]$_.TоXml()).Еvеnt.ЕvеntDаtа.Dаtа |whеre {$_.nаmе -еq «ОbjесtNаmе»}|whеre {($_.’#tеxt’) -nоtmаtсh «.*tmр»} |whеre {($_.’#tехt’) -nоtmаtch «.*~lоck*»}|whеre {($_.’#tеxt’) -nоtmatch «.*~$*»}} |sеlect TimеCrеаted, @{n=»Filе_»;e={([xml]$_.TоXml()).Evеnt.ЕventData.Dаta | ? {$_.Name -eq «ObjectName»} | %{$_.’#tеxt’}}},@{n=»User_»;e={([xml]$_.TоXml()).Evеnt.EventDаta.Data | ? {$_.Nаme -еq «SubjеctUserNаme»} | %{$_.’#text’}}}

if ($Bоdу -mаtch «.*Sewers*»){

$BоdyL=$BоdyL+$Body.TimeCrеаted+»`t»+$Bоdy.Filе_+»`t»+$Bоdу.Usеr_+»`n»

}

}

$Mоnth = $Timе.Mоnth

$Yеаr = $Time.Year

$nаmе = «DelеtedFiles-«+$Mоnth+»-«+$Yеаr+».tхt»

$Оutfile =

«serverSеrverLogFilesDeletedFilesLog»+$nаme

$BоdyL | оut-file $Оutfile –арpend

В двух словах о том, как это работает

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

Здесь мы смотрим нужную информацию с операцией «Delete». При переименовании файла будет создано два события ID=4663, отражающих операции «Запись Данных» и Delete. То есть, в логи будет попадать много лишней информации, и будет не совсем понятно, когда файлы были переименованы, а когда удалены.

В данном случае лучше ориентироваться на событие с ID, равным 4660, которое создается конкретно при удалении данных. Здесь содержится множество информации, кроме имени файла. Зато тут присутствует код дескриптора

Однако в предшествующем событии с ID=4663, такая информация, как время, а также имя файла указывается, а номер его дескриптора соответствует номеру события с ID, равным 4660.

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

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

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

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

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

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

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

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

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

При успешном удалении файла в журнале безопасности системы появляется событие 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 за текущий день

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

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

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

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

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

Источник

Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell

Начнем.

Для начала включим к групповых политиках возможность аудита доступа к файлам и папкам.
Локальные политики безопасности->Конфигурация расширенной политики безопасности->Доступ к объектам
Включим «Аудит файловой системы» на успех и отказ.
После этого на необходимые нам папки необходимо настроить аудит.
Проходим в свойства папки общего доступа на файловом сервере, переходим в закладку «Безопасность», жмем «Дополнительно», переходим в закладку «Аудит», жмем «Изменить» и «Добавить». Выбираем пользователей для которых вести аудит. Рекомендую выбрать «Все», иначе бессмысленно. Уровень применения «Для этой папки и ее подпапок и файлов».
Выбираем действия над которыми мы хотим вести аудит. Я выбрал «Создание файлов/дозапись данных» Успех/Отказ, «Создание папок/дозапись данных» Успех/отказ, Удаление подпапок и файлов и просто удаление, так же на Успех/Отказ.
Жмем ОК. Ждем применения политик аудита на все файлы. После этого в журнале событий безопасности, будет появляться очень много событий доступа к файлам и папкам. Количество событий прямопропорционально зависит от количества работающих пользователей с общим ресурсом, и, конечно же, от активности использования.

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

А теперь очень интересный скрипт.

Скрипт пишет лог об удаленных файлах.

Как оказалось при удалении файлов и удалении дескрипторов создается одно и тоже событие в логе, под При этом в теле сообщения могут быть разные значения «Операции доступа»: Запись данных (или добавление файла), DELETE и т.д.
Конечно же нас интересует операция DELETE. Но и это еще не все. Самое интересное, то что, при обычном переименовании файла создается 2 события с ID 4663, первое с Операцией доступа: DELETE, а второе с операцией: Запись данных (или добавление файла). Значит если просто отбирать 4663 то мы будем иметь очень много недостоверной информации: куда попадут файлы и удаленные и просто переименованные.
Однако мной было замечено, что при явном удалении файла создается еще одно событие с ID 4660, в котором, если внимательно изучить тело сообщения, содержится имя пользователя и еще много всякой служебной информации, но нет имени файла. Зато есть код дескриптора.

Однако предшествующим данному событию было событие с ID 4663. Где как раз таки и указывается и имя файла, и имя пользователя и время, и операция как не странно там DELETE. И самое главное там имеется номер дескриптора, который соответствует номеру дескриптора из события выше (4660, помните? которое создается при явном удалении файла). Значит теперь, чтобы точно знать какие файлы удалены, необходимо просто найти все события с ID 4660, а так же предшествующие каждому этому событию, событие с кодом 4663, в котором будет содержаться номер нужного дескриптора.

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

Т.е. не записываем информацию об удаленных временных файлах (.*tmp), файлах блокировок документов MS Office (.*lock), и временных файлах MS Office (.*

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

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

Рекомендации

Вам придется самим определить время в течении которого вы будете искать нужные события. Чем больше период, тем дольше ищет. Все зависит от производительности сервера. Если слабенький — то начните с 10 минут. Посмотрите, как быстро отработает. Если дольше 10 минут, то либо увеличьте еще, вдруг поможет, либо наоборот уменьшите период до 5 минут.

Источник

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

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

Итак, по шагам все выглядит следующим образом:

1.Включение аудита в политиках(локальных или групповых);

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

3.Настройка размера журнала событий Security;

4.Утилита auditpol, или против лома нет приема;

1.Включение аудита в политиках(локальных или групповых).

Если у вас сервер или компьютер в домене, то настройку лучше всего проводить через групповые политики, но можно и через локальные политики. Такие ситуации не редкость когда у вас домен 2003 а сервера или компьютеры в сети Windows Server 2008 и выше, Windows 7,8,10. Групповые политики вашего 2003 домена просто еще не содержат того, что появилось позже. Но это все не принципиально, просто добавляет немного работы по индивидуальной настройке вашего сервера или компьютера.

Следующие примеры я буду показывать на примере локальных политик 2008-го сервера. Итак, открываем локальные политики командой «gpedit.msc»

Разворачиваем дерево политик «Computer Configuration»—«Windows Settings»—«Security Options»

На скрине выше я выделил политики, которые включают различные виды аудита. Меня сечас интересует файловый аудит.

Если у вас Windows Server 2003 или компьютер под Windows XP, то вам необходимо включить политику «Audit: Audit the access of global system objects».

Если у вас Windows Server 2008, 2012, 2016 или Windows 7,8,10 то вам необходимо пользоваться другими политиками «Computer Configuration»—«Windows Settings»—«Advanced Audit Policy Configuration»—«System Audit Policies – Local Group Policy Object»-«Object Access».

Когда вы раскроете раздел «Object Access», то увидите более подробные политики.

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

Все эти политики переводим из состояния «Not Configured» в состояние «Configure the following audit events:»—«Success»

Таким образом, все успешные события, касающиеся действий с файлами и папками, попадут в журнал. Если вам нужны записи для неудачных попыток, тогда включите и «Failure».

Когда все политики настроены остается только включить аудит для нужных папок и файлов непосредственно в NTFS.

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

Настройка аудита для папок и файлов аналогична настройке прав.

Открываем окно свойств для нужной папки или файла

Открываем закладку «Безопасность»(«Security») и нажимаем кнопку «Advanced»(«Дополнительно»)

Переходим на закладку «Auditing»(«Аудит») и нажимаем кнопку «Edit…»(«Изменить»)

Затем нажимаем кнопку «Add»(«Добавить») и выбираем пользователя «Everyone»(«Все»)

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

После выбора пользователя добавляем нужные для аудита свойства. Обычно я выбираю только те свойства, которые отражают изменения файлов и папок. Включение аудита на чтение файла или на просмотр списка файлов в папке приводит к резкому увеличению количества записей в журнале Security. Трудно потом копаться в миллионах событий, пытаясь найти нужное. J
.
Обратите внимание, что в данном примере я включил аудит только успешных событий!

Если вы хотите отслеживать только те события, которые меняют права на папки и файлы, то вам достаточно будет включить аудит двух событий «Change permissions»(«Смена разрешений») и «Take ownership»(«Смена владельца»)

Если же вы хотите отследить только удаление файлов и папок, тогда вам нужно включить аудит для событий «Delete subfolders and files» и «Delete»

В остальном настройка аудита аналогична настройкам прав. Тоже наследование, такие же области применения(папка, эта папка и подпапки, только файлы и т.п.)

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

3.Настройка размера журнала событий Security.

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

Правой клавишей мышки на Security и открываем Properties(Свойства). В моем случае максимальный размер выставлен в 10 Гб, и события будут перезаписываться по мере достижения журналом максимального размера.

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

4.Утилита auditpol, или против лома нет приема.

Для управления настройками аудита в Windows Server 2008, 2012, 2016 или Windows 7,8,10 есть такая замечательная утилита как auditpol. Прелесть ее в том, что с ее помощью можно посмотреть фактическое положение дел в аудите. Да, вы не ослышались. Групповые и локальные политики могут быть не настроены а аудит может прекрасно работать. Многие позиционируют auditpol как последнюю инстанцию, отражающую реальное положение дел.

Я тоже столкнулся с проблемами, которые с успехом решил с помощью этой утилиты. Я не буду разбирать подробно все возможности auditpol а приведу один пример, который обеспечит работоспособность аудита в 99% случаев.

Итак, еще раз приведу скрин локальных политик рабочего сервера:

Как вы можете видеть политики «Object Access» не сконфигурированы, но! Аудит прекрасно работает!

А теперь посмотрим что показывет auditpol. Запускаем командную строку и набираем:

auditpol /get /category:*

И смотрим результат:

Как вы можете видеть в категории «Object Access» некоторые субкатегории имеют состояние «Success», хотя в политиках ничего не сконфигурировано.

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

auditpol /set /category:» » [/success: | ][/failure: | ]
auditpol /set /subcategory:» » [/success: | ][/failure: | ]

Еще лучше сделать bat-файл в котором прописать нужные действия для включения файлового аудита, описанного мной в разделе 2 этой статьи. Я использую bat файл с таким содержимым:
auditpol /set /subcategory:»File System» /success:enable
auditpol /set /subcategory:»Registry» /success:enable
auditpol /set /subcategory:»SAM» /success:enable
auditpol /set /subcategory:»Handle Manipulation» /success:enable
auditpol /set /subcategory:»Other Object Access Events» /success:enable

Если у вас русская ОС, то придется писать названия на русском:
auditpol /set /subcategory:»Файловая система» /success:enable
auditpol /set /subcategory:»Реестр» /success:enable
auditpol /set /subcategory:»SAM» /success:enable
auditpol /set /subcategory:»Работа с дескриптором» /success:enable
auditpol /set /subcategory:»Другие события доступа к объекту» /success:enable

. К сожалению одну из политик придется все-таки настроить. Это политика «Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings», ее переводим в режим «Enabled»(«Включено»). В русских ОС эта политика называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (ОС Windows Vista или более поздние версии)»

Вот собственно и все. Глубина темы бесконечна а практически хватает и этих настроек.

Если у вас нет 2003-х серверов или Windows XP, то лучше все сделать через GPO, ну а если нет, то auditpol нам поможет!

Источник

Заметки системного администратора

Грань между «Сейчас чуть-чуть подправлю» и «Ой, б#я!» — очень тонка!

Аудит создания и удаления файлов в Windows 2008, 2012 и 2016

1. Включение механизма аудита

Оптимальный инструмент — групповые политики (применять к 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»

“Create files / write data — Successful”

“Create folders / append data — Successful”

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

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

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

Event ID: 4660
Description: An object was deleted.

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

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

Ключевой источник информации – события 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.

Источник

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

Иногда бывает необходимо понять кто удалил/изменил/переименовал конкретный файл или папку. В ОС Windows для этого используется аудит доступа к объектам.

Необходимо понимать, что аудит забирает на себя.

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

В случае локальных политик необходимо запустить оснастку “Локальная политика безопасности”, для этого необходимо нажать комбинацию клавиш Win+R, в открывшееся поле ввести secpol.msc и нажать клавишу Enter.

Для этого необходимо открыть свойства файла или папки, перейти на вкладку “Безопасность”, нажать “Дополнительно” и “Аудит”.

Нажимаем “Добавить” и начинаем настраивать аудит.

Можно вписать туда имя пользователя или группы, если имя заранее неизвестно, то можно воспользоваться кнопкой “Дополнительно” которая открывает форму поиска где можно выбрать интересующих нас пользователей и группы. Чтобы контролировались действия всех пользователей необходимо выбрать группу “Все”.

Для папок поля такие:

А такие для файлов:

После этого начнется сбор данных аудита. Все события аудита пишутся в журнал “Безопасность”. Открыть его проще всего через оснастку “Управление компьютером” compmgmt.msc.

Каждое событие ОС Windows имеет свой код события. Список событий достаточно обширен и доступен на сайте Microsoft либо в интернете. Например события аудита можно посмотреть здесь.

Вручную можно, например, задать например такой фильтр:

Далее в отфильтрованных событиях необходимо найти интересующее нас по имени объекта.

Открыть его двойным щелчком мыши и увидеть кто удалил данный файл в поле субъект.

Источник

Добрый день, друзья и коллеги. Сегодня поговорим о том, как же все-таки отслеживать изменения на ваших файловых серверах, а именно кто и что делал с файлом; не удалил ли случайно; создал зачем-то ненужный файл и т.д. Конечно же, с этой темой тесно связаны как минимум три вещи: документальное описание файловых шар, применение файловых фильтров (запрет на определенный тип файлов) и систему ограничения размера хранилища (система квот). Но эти вещи уже сильно выйдут за пределы одной статьи. Если тема будет востребована, появятся в будущем статьи и по данным темам.

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

Для начала нам необходимо включить через групповую политику расширенный аудит и применить ее к нужным серверам. Я буду проделывать на тестовом сервере Windows Server 2008 R2, у себя в сети все проделал на 2012 R2. Принцип и интерфейс примерно тот же. Вообще система аудита появилась еще со времен Windows Server 2000 (может даже и в NT, но не суть важно), его активно используют и применяют многие админы. С версии 2008 в строю начал стоять еще и расширенный аудит (Advanced audit). Я использовал у себя как старый аудит, так и новый, пока не заметил прям сильных инноваций. Но в целом новый аудит более гибок в управлении и настройках. Самый главный плюс этой технологии – возможность ведения аудита только на том ресурсе, который нам необходим. Отсюда практически все события безопасности отображаются в журнале в нужном нам порядке, где нет ничего лишнего. Отсюда и размер журнала существенно меньше.

В управлении групповых политик переходим в раздел групповых политик и создаем там новый GPO:

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

В параметрах безопасности нам необходимо “подрегулировать” параметры журнала безопасности (в разделе “Журнал событий”) и настроить, собственно, сам аудит (в разделе “Конфигурация расширенной политики аудита”):

Объясню по минимуму, т.к. все сугубо индивидуально. Ставим размер (100-200 Мб за глаза скорее всего, в зависимости от размера сетевой папки и количества пользователей), ставим максимальный срок хранения событий (мне 2 недели вполне достаточно), метод сохранения “по дням” подставляется автоматом. Думаю, здесь ничего сложного. Теперь настроим аудит, самое главное для нас:

Как до него добраться: лучше всего увидеть глазами на скриншоте. Обращаю внимание, что несмотря на то, что мы будем вести аудит общего файлового ресурса, нам необходимо выбрать все же “Аудит файловой системы”. Сейчас постараюсь объяснить почему. Дело в том, что если выбрать “Аудит сведений об общем файловом ресурсе”, что, казалось бы, логичнее, то будет вестись очень (повторяю – “очень”) подробный аудит ВСЕХ сетевых папок ВСЕХ событий, в т.ч. просто просмотров, сетевых синхронизаций, чтения атрибутов и много-много других событий. Лично у меня журнал рос примерно так: один час = 50-100 МБ журнала днем, ночь при нулевой активности = 30 Мб. В общем, я настоятельно не рекомендую включать эту галочку. Нас интересует конкретная папка и конкретные события (изменение/создание/удаление), поэтому выбираем файловую систему. Именно этот момент (процесс выбора аудита) мало описан в интернете, все указано поверхностно. Даже в официальном учебнике я не нашел объяснения всех нюансов. Тип событий “успех” (когда операция с файлом и папкой удалась), хотя можно вести аудит и “неудач”, т.е. попыток что-то сделать при отсутствии прав. Тут уже смотрите сами.

Теперь оптимизируем политику. Сначала применяем ее к серверу. В моем случае я делаю все на контроллере домена и поэтому применяю к подразделению Domain Controllers. Файловые службы работают на контроллере домена, что не есть хорошо. Но в силу причин так сложилось. Удаляем “прошедшие проверку”, чтобы политика не применялась на остальные серверы (у меня на остальные контроллеры домена):

Нажимаем “Добавить”, указываем тип объектов “Компьютеры” и прописываем туда имя нашего сервера:

Отшлифуем политику еще круче. Для того, чтобы ускорить применение политик, Microsoft рекомендует всегда указывать, какие конфигурации применять, а какие нет. Иначе идет попытка применить конфигурации сразу и компьютера, и пользователя. У нас политика применяется на компьютер, поэтому в состоянии политики можем это указать. В технете пишут, что таким образом мы разгружаем контроллер домена.

Контрольная проверка политики. Сверяем результаты:Первая часть выполнена. Теперь идем на файловый сервер. Убедимся, что папка настроена на сетевой общий доступ:

.. и идем во вкладку “Безопасность”, а точнее в раздел “дополнительно”:

Нас интересует вкладка “Аудит”:

Там сейчас пусто, потому что ничего не настроено. Сейчас мы добавим  так называемый список SACL (системные списки управления доступом). От NTFS’ного ACL он отличается тем, что это только аудит, никаких прав на папку мы по сути не даем, поэтому не стоит относиться к этому списку как к списку реального доступа к папке. Помните, что это совсем другое. Поэтому я и добавляю группу Все и даю нужный критерий аудита:

Галочку “Добавить элементы аудита, наследуемые…” я убираю, на будущее может пригодиться. Ведь мы можем в будущем вести аудит сетевой шары в другой шаре. Если оставите галку, ничего страшного.

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

Настройки аудита на папку могут применяться какое-то время (появляется окно применения  статуса). После всех этих дествий давайте перейдем к третьей части – проверке.

Применяем на файловом сервере новую политику и смотрим, применилась ли она (команды gpupdate /force  и gpresult /r):

У меня применилось. Теперь я иду в журнал безопасности и чищу его:

Теперь самое интересное. Пробую с другого ПК зайти на папку по сети и что-нибудь поменять. По идее сразу после этого появляется событие типа “кто сделал/что сделал/когда и т.д.”:

В событии все отображается. Но когда событий много, пользоваться журналом не так удобно. Поэтому рекомендуется сохранить журнал в удобный формат (csv, txt, evtx, xml) и уже сформировавшийся файл мучить дальше. На этом все. Пользуйтесь аудитом, коллеги. Когда на руках есть доказательство чьей-то вины, это очень полезно и сильно прикрывает админу одно место.

Обновлено: Друзья, вы должны понимать, что аудит нагружает сервер, с ним производительность может немного упасть. Из личного опыта я рекомендую через недельку эксплуатации зайти на сервер и проверить размер журнала, а также тип событий. Вдруг журнал сильно вырос и вашего размера в GPO мало. Или вообще аудит перестал работать. В общем, мониторьте хоть изредка работу аудита.

Друзья! Вступайте в нашу группу Вконтакте, чтобы не пропустить новые статьи! Хотите сказать спасибо? Ставьте Like, делайте репост! Это лучшая награда для меня от вас! Так я узнаю о том, что статьи подобного рода вам интересны и пишу чаще и с большим энтузиазмом!

Также, подписывайтесь на наш канал в YouTube! Видео выкладываются весьма регулярно и будет здорово увидеть что-то одним из первых!

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

Итак, создал объект групповой политики и связал этот объект групповой политики на OU контроллеров домена.

Ниже моя групповая политика

Включить политику аудита: на контроллере домена (файловом сервере), где я хочу отслеживать удаление файлов, перейдите в Администрирование-> Локальная политика безопасности-> Политика аудита, дважды щелкните «Аудит доступа к объектам» на правой панели и включите «Успех». «&» Отказ «.

Во-вторых, я включил аудит папки, в которой я хотел бы включить аудит.

Включить аудит для пользователя / группы:

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

• Щелкните правой кнопкой мыши на целевой папке (например, D:share1), выберите Свойства и перейдите на вкладку Безопасность.
• Нажмите на Advanced и выберите вкладку Auditing.
• Добавил сюда группу безопасности, я добавил ВСЕХ.
• На следующем экране выберите «Успешно» и «Не удалось» в «Удалить подпапки и файлы» и «Удалить». Применить новые настройки и выйти из свойств.

Но когда я удалил файл или папку на share1, у меня не было четного сообщения, связанного с удалением файла, обычно должен быть четный номер 560, но это не так ….