Ростелеком ТВ 

Включение аудита на файловом сервере. Аудит доступа к ресурсам. Не только файлы

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

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

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

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

Контроль на двух уровнях

Чтобы следить за доступом к объектам, необходимо организовать аудит Windows 2000 как на уровне системы, так и на уровне объектов. Сначала следует активизировать категорию Audit object access для успешных и неудачных событий. (Подробнее о том, как использовать системную политику аудита, рассказано в статье «Контроль событий регистрации в Windows 2000». Полный список статей этого автора о журналах безопасности Windows 2000 и Windows NT приведен во врезке «В предыдущих выпусках» - прим. ред.) Затем необходимо обеспечить аудит контролируемого объекта. Каждый объект имеет два ACL (список управления доступом): разграничительный ACL (DACL) и системный ACL (SACL).

Экран 1. Упрощенный вид DACL объекта.

Список DACL. В списке DACL перечислены пользователи, имеющие право доступа к объекту, и способы доступа. (Часто вместо DACL используется термин ACL.) Чтобы открыть DACL объекта из Windows Explorer (для папок и файлов) или в окне Printers (для принтеров), следует щелкнуть на объекте правой кнопкой мыши, выбрать пункт Properties и перейти к закладке Security (см Экран 1). На этой закладке дан упрощенный вид списка DACL, т. е. показаны разрешения только для одного пользователя или группы. Чтобы просмотреть полный список DACL, нужно щелкнуть на кнопке Advanced. Откроется диалоговое окно Access Control Settings объекта, показанное на Экране 2.

Список SACL. В списке SACL перечислены действия над объектом, подлежащие аудиту Windows 2000. SACL объекта состоит из элементов управления доступом (ACE). Элемент ACE точно определяет типы доступа, регистрируемые в журнале безопасности Windows 2000, когда конкретный пользователь или группа обращается к объекту. Специальный флаг каждого ACE показывает, к успешным или неудачным попыткам доступа относится данный элемент. Чтобы обратиться к SACL объекта, следует открыть диалоговое окно Access Control Settings и перейти к закладке Auditing. Каждый элемент в разделе Auditing Entries - это ACE. Из приведенного на Экране 3 списка SACL для файла примера (payroll.xls) видно, что Windows 2000 будет проверять успешные попытки записи и неудачные попытки чтения, предпринятые членами группы Everyone.
Экран 3. SACL объекта.

Контроль попыток доступа к объекту

Windows 2000 производит аудит доступа в тот момент, когда пользователь пытается получить доступ к объекту через прикладную программу. Когда пользователь обращается к объекту из приложения, программа запрашивает у Windows 2000 дескриптор (handle) объекта. С помощью дескриптора приложение выполняет операции над объектом. Прежде чем предоставить дескриптор, Windows 2000 сопоставляет DACL объекта с учетной записью пользователя, запустившего прикладную программу, и типами доступа (например, запись или чтение), запрошенными приложением. Затем Windows 2000 определяет, предусмотрена ли системной политикой аудита запись результатов этого сравнения в журнал. Например, если попытка доступа неудачна, система выясняет, активизирована ли политика аудита для регистрации неудачных обращений к объектам.

Если системной политикой аудита предусмотрена запись результата в журнал, то Windows 2000 обрабатывает SACL объекта. Система исследует каждый элемент ACE, имеющий отношение к результату, и определяет, какие из элементов идентифицируют учетную запись пользователя, запустившего приложение, и все группы, к которым он принадлежит. Затем Windows 2000 исследует типы доступа, указанные в этих ACE. Если хотя бы один тип доступа в ACE совпадает с любым из типов доступа, запрошенных приложением, то Windows 2000 генерирует событие с ID 560 «объект открыт» с соответствующим типом события (Failure Audit или Success Audit). В оснастке Event Viewer консоли Microsoft Management Console (MMC) сообщения о неудачном завершении какой-либо операции отмечены пиктограммой замка, а записи об успешном завершении операции - изображением ключа.

Предположим, что пользователь Гарольд работает с Microsoft Excel и пытается открыть файл payroll.xls. Excel запрашивает у Windows 2000 дескриптор для payroll.xls. Windows 2000 сравнивает DACL файла с учетной записью Гарольда и запросом на чтение, поступившим от Excel; согласно DACL, у Гарольда нет права на чтение payroll.xls. Как показано на Экране 2, доступ к payroll.xls имеют только Administrators и группа HR, а Гарольд не является членом ни одной из этих групп. Windows 2000 выясняет, что системной политикой аудита предусмотрена регистрация неудачных попыток обращения к объекту, поэтому она просматривает SACL файла payroll.xls и исследует каждый элемент ACE, контролирующий неудачные попытки доступа. Windows 2000 определяет, какие из этих элементов ACE указывают на учетную запись Гарольда или группу, к которой он принадлежит. Как показано на Экране 3, SACL объекта содержит ACE, который относит неудавшуюся операцию чтения к группе Everyone, поэтому Windows 2000 регистрирует событие с ID 560 (см. Экран 4).

Экран 4. Событие с ID 560 неудачной попытки доступа.

Предположим, что пользователь Салли также пытается открыть файл payroll.xls из Excel. Поскольку Салли является членом группы HR, она имеет право выполнять операции чтения и записи в файле payroll.xls. Системная политика аудита настроена на регистрацию успешных попыток доступа к объектам, и SACL файла содержит ACE, относящийся к успешным операциям записи и группе Everyone, поэтому Windows 2000 регистрирует событие с ID 560 (см. Экран 5).

Экран 5. Событие с ID 560 успешного доступа.

Разобраться в полях события с ID 560 нетрудно. Значение параметра Object Server всегда Security. В поле Object Type идентифицируется объект аудита - файл, папка, раздел реестра, принтер или служба. Windows 2000 заполняет поле New Handle ID лишь в том случае, если доступ к объекту был предоставлен. Если пользователь не имеет соответствующих полномочий, то доступ не предоставляется, и Windows 2000 не создает ID дескриптора. Operation ID - просто число, которое увеличивается на единицу для каждой операции, выполняемой в Active Directory (AD).

Теоретически, с помощью поля Process ID можно вычислить приложение, через которое пользователь открыл объект. Однако соответствующее событие с ID 592 (новый процесс), генерируемое категорией Audit process tracking, показывает ID процесса в другом формате, нежели все остальные события Windows 2000. По некоторым сведениям, разработчики Microsoft устранят эту проблему в версиях Windows XP и Windows Server - известных под названием Whistler. Для событий, отображающих непрямой доступ к объектам, Process ID идентифицирует серверное приложение, а не клиентскую программу, через которую пользователь открыл объект. Если пользователь открывает файл в каталоге общего доступа, то Process ID указывает на процесс System как на программу, открывшую объект. Чтобы проверить эту информацию, можно открыть Task Manager, перейти к закладке Processes и посмотреть идентификатор процесса в столбце PID.

Поля Primary User Name и Primary Domain идентифицируют учетную запись пользователя, напрямую обратившегося к объекту. Когда пользователь обращается к объекту со своего локального компьютера через настольное приложение, такое, как Microsoft Word или Excel, то Primary User Name и Primary Domain показывают учетную запись компьютера, а поля Client User Name и Client Domain - учетную запись пользователя. Например, на Экране 6 показано событие с ID 560, которое было зарегистрировано, когда пользователь Джон подключился к сетевому диску на файл-сервере Tecra и открыл документ budget.doc. Тогда в поле Primary User Name стоит имя TECRA$, соответствующее учетной записи файл-сервера в домене. Client User Name идентифицирует Джона как пользователя, работающего на клиентской стороне.

Экран 6. Событие с ID 560 непрямого доступа.

Поля Primary Logon ID и Client Logon ID содержат идентификатор logon ID, присваиваемый при регистрации с учетной записью пользователя, обратившегося к объекту. Чтобы определить, в каком сеансе был произведен доступ, следует посмотреть на событие с ID 540 (удаленная регистрация) или с ID 528 (все другие виды регистрации) с этим идентификатором (подробнее эти события описаны в статье «Контроль событий регистрации в Windows 2000».) Если пользователь напрямую открывает объект на своей локальной машине, то Primary Logon ID события с ID 560 соответствует Logon ID события с ID 528, зафиксированного Windows 2000 при регистрации пользователя в системе; поле Client Logon ID остается пустым. Если пользователь обращается к файлу на удаленной машине, то поле Primary Logon ID события с ID 560 идентифицирует сеанс, связанный с учетной записью локального компьютера, а поле Client Logon ID события с ID 528 соответствует Primary Logon ID.

В поле Accesses указаны типы доступа, запрошенные приложением. Одни типы доступа специфичны для определенного класса объектов, другие применимы к любому объекту. В Таблице 1 перечислены и описаны самые распространенные типы доступа.

Когда пользователь открывает файл или папку, в поле Accesses отмечаются предоставленные пользователю типы доступа, специфичные для данной папки или файла. Эти типы доступа соответствуют специальным разрешениям, приведенным в DACL файла. Параметры ReadAttributes и WriteAttributes указывают, что пользователь открыл файл с возможностью изменения его свойств (только чтение, архивный, скрытый, системный). ReadEA и WriteEA применяются к расширенным атрибутам файла, определяемым конкретными приложениями. Чтобы увидеть расширенные атрибуты файла, нужно открыть Windows Explorer и щелкнуть на файле правой кнопкой мыши. Выбрав Properties, следует перейти к закладке Custom, а затем к закладке Summary.

Тип AppendData означает, что пользователь имеет право добавить данные в открытый файл. ReadData и WriteData означают, что пользователь, открывший файл, имеет возможность прочитать или изменить его данные. Если задан режим аудита запуска исполняемых файлов, то Windows 2000 регистрирует доступ типа Execute при каждом запуске программы.

Те же типы доступа - с небольшими отличиями - используются Windows 2000 для контроля работы с папками. AppendData указывает, что пользователь создал в папке подпапку. Windows 2000 регистрирует тип WriteData, если в папке создается новый файл. Чтобы определить имя нового файла или подпапки, нужно посмотреть на последующее событие с ID 560, соответствующее новому дочернему объекту. Windows 2000 регистрирует тип ReadData, если пользователь просматривает содержимое папки (например, командой Dir или через Windows Explorer).

Завершение работы с объектом

Когда пользователь открывает объект из приложения, Windows 2000 регистрирует событие с ID 560, а при закрытии объекта операционная система регистрирует событие с ID 562 (дескриптор закрыт). Поля события с ID 562 частично совпадают с полями события с ID 560.

Экран 7. Событие с ID 562.

Следует обратить внимание на поле New Handle ID события с ID 560 (см. Экран 5) и поле Handle ID события с ID 562 (см. Экран 7). Windows 2000 генерирует различные Handle ID для каждого открытого объекта. Таким образом, связав событие с ID 560 и событие с ID 562 с одинаковыми Hand-le ID, можно определить, как долго объект оставался открытым. Из оснастки Event Viewer следует открыть событие с ID 560 и запомнить Handle ID события. Затем нужно щелкнуть правой кнопкой мыши на журнале Security и выбрать функции View, Find. В поле Event ID следует ввести значение 562, а в поле Description - значение Handle ID. Если Event Viewer показывает сначала новые объекты, то следует изменить направление поиска на Up, а затем щелкнуть Find Next.

Не только файлы

Категория Audit object class используется не только для контроля доступа к файлам. Например, с помощью программы regedt32 можно запустить аудит разделов реестра и затем контролировать доступ к разделам и элементам реестра. Элементы реестра не имеют собственных списков DACL и SACL; как и операции управления доступом, операции аудита проводятся через родительский раздел реестра. Windows 2000 регистрирует типы доступа, соответствующие разрешениям в списке DACL раздела, и описывает разрешения, указанные в событии с ID 560. Если обращение к разделу реестра вызывает событие с ID 560, то Windows 2000 указывает в поле Object Type значение Key. Значение в поле Object Name начинается с REGISTRY, за которым следует ветвь и остальной путь к разделу. Например, подраздел HKEY_LOCAL_MACHI-NESOFTWAREAcme отображается как REGISTRYMACHINESOFT-WAREAcme.

Из меню Settings, Printers можно получить доступ к спискам SACL принтеров и реестра. Для этого достаточно выполнить те же операции, что и при доступе к SACL файла или папки, но отправной точкой будет служить не Windows Explorer, а меню Settings, Printers.

В статье Microsoft «Monitoring and Auditing for End Systems» (http://www.microsoft.com/technet/ security/monito.asp ) говорится, что можно выполнять аудит системных служб, но в действительности это не так. Даже если в SACL службы режим аудита включен (с помощью политик Group Policy через ComputerConfiguration, Windows Settings, Security Settings, System Services), Windows 2000 не заносит в журнал безопасности сведений о запуске, остановке и отключении службы. Идентификаторы событий документированы для некоторых других операций (например, удаления объекта), но этот механизм пока не функционирует.

Наследование SACL

В Windows 2000 схема наследования SACL повторяет схему DACL. По умолчанию, элементы SACL автоматически переходят от родительских папок и разделов реестра к дочерним объектам. Например, если разрешить аудит неудачных операций записи в папку, то все файлы и подпапки наследуют этот элемент SACL. Существует несколько уровней настройки наследования SACL.

Дочерний уровень. Чтобы блокировать передачу элементов родительского SACL дочернему объекту, следует открыть окно Access Control Settings (параметры управления доступом) дочернего объекта, перейти к закладке Auditing и снять флажок Allow inheritable auditing entries from parent to propagate to this object. Затем нужно щелкнуть OK или Apply. Если к моменту сброса флажка какие-то наследуемые элементы SACL уже были переданы объекту-потомку, Windows 2000 потребует подтвердить необходимость их удаления или создать их копии без наследования.

Родительский уровень. Чтобы разблокировать наследование в дочерних объектах, следует открыть диалоговое окно Access Control Settings родительского объекта, показанное на Экране 8, перейти к закладке Auditing и установить флажок Reset auditing on all child objects and enable propagation of inheritable auditing entries. После щелчка на кнопке OK или Apply операционная система отменяет аудит на всех дочерних объектах и сбрасывает флажок, чтобы администратор мог выборочно блокировать наследование на дочерних объектах. Данная функция сброса полезна, если администратор не знает, какой режим наследования установлен в системе, и хочет начать все сначала.

Можно также контролировать глубину наследования и указать последний дочерний объект, на который распространяется действие каждого элемента SACL. Чтобы отредактировать отдельный элемент SACL, нужно открыть диалоговое окно Access Control Settings родительского объекта, перейти к закладке Auditing, выбрать элемент и открыть окно Auditing Entry щелчком на кнопке View/Edit, как показано на Экране 9. В данном диалоговом окне предусмотрено два способа реализации наследования дочерними объектами. Раскрывающийся список Apply onto определяет типы объектов, которым передается запись об аудите. По умолчанию из списка выбирается значение This folder, subfolders and files (данная папка, подпапки и файлы), но пользователь может выбрать любое сочетание этих объектов. (На Экране 9 выбран режим аудита неудачных операций чтения только файлов, но не папок.) С помощью флажка Apply these auditing entries to objects and/or containers within this container можно определить, передаст ли Windows 2000 запись объектам, расположенным непосредственно в папке, или рекурсивно распространит эту запись на все дочерние уровни ниже данной точки.

Как лучше провести аудит

Какую стратегию избрать для аудита объектов? Во-первых, если требуется проверить определенный каталог или раздел реестра на нескольких машинах, нужно использовать групповые политики. Например, чтобы исследовать неудачные попытки записи в каталоге \%systemroot% на всех компьютерах домена, следует открыть оснастку MMC Active Directory Users and Computers и щелкнуть правой кнопкой мыши на корневом домене. Затем, выбрав Properties, необходимо перейти к закладке Group Policy. Отметив пункт Default Domain Policy Group Object (GPO), следует щелкнуть на кнопке Edit и пройти по Computer Configuration, Windows Settings, Security Settings, File System. Щелкнув правой кнопкой мыши на File System, нужно выбрать пункт Add File. Затем введите с клавиатуры

%systemroot%

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

Неопытным администраторам может показаться, что на самом деле активность системы не столь велика, как можно предположить исходя из событий Audit object access. Следует помнить, что Windows 2000 не выполняет аудит собственно операций (например, чтения и записи) над объектами; вместо этого проверяются запросы на доступ к объектам, поступающие из приложений. Поэтому в поле Accesses события с ID 560 указывается только тип доступа, который мог получить пользователь, но не сам факт выполнения пользователем каких-либо операций. Проблема усугубляется прикладными программами, которые автоматически запрашивают все типы доступа, независимо от того, нужны ли они пользователю. Представители Microsoft заявляют, что в конечном итоге в Windows 2000 может быть реализован аудит действительных операций, а не возможностей доступа.

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

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

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

Для начала нам необходимо включить через групповую политику расширенный аудит и применить ее к нужным серверам. Я буду проделывать на тестовом сервере 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 мало. Или вообще аудит перестал работать. В общем, мониторьте хоть изредка работу аудита.

Друзья! Вступайте в нашу

Оптимальный инструмент - групповые политики (применять к 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 – маска доступа – определяет для каких целей была попытка доступа к файлу

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

Тип доступа Hex Описание
ReadData (or ListDirectory) 0×1 ReadData – чтение данных из файла или объекта директории.ListDirectory – просмотр содержимого директории.
WriteData (or AddFile) 0×2 WriteData – запись данных в файл.AddFile – создание файла в директории.
AppendData (or AddSubdirectory or CreatePipeInstance) 0×4 AppendData – дописывание данных в файл. Не перезаписывает существующие данные, если дополнительно не содержит флага WriteData.AddSubdirectory – создание поддиректорий.
DELETE 0×10000 Удаление объекта.

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

Любой администратор 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 и пр.

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