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

Добрый день!. Если вы еще не превратились в Шерлока Холмса в вашем домене, то теперь самое время. Ежеминутно в системах происходят тысячи изменений, которые требуется отследить и запротоколировать. Чем больше размер и сложность структуры, тем выше вероятность появления ошибок в администрировании и раскрытия данных. Без постоянного анализа изменений (удачных или неудачных) нельзя построить действительно безопасную среду. Системный администратор всегда должен ответить , кто, когда и что изменил, кому делегированы права, что произошло в случае изменений (удачных или неудачных), каковы значения старых и новых параметров, кто смог или не смог зайти в систему или получить доступ к ресурсу, кто удалил данные и так далее.

Аудит изменений стал неотъемлемой частью управления IT инфраструктурой, но в организациях не всегда уделяют внимание аудиту, часто из-за технических проблем. Ведь не совсем понятно, что и как нужно отслеживать, да и документация в этом вопросе не всегда помогает. Количество событий, которые необходимо отслеживать, уже само по себе сложность, объемы данных велики, а штатные инструменты не отличаются удобством и способностью упрощать задачу отслеживания. Специалист должен самостоятельно настроить аудит, задав оптимальные параметры аудита, кроме того, на его плечи ложится анализ результатов и построение отчетов по выбранным событиям. Учитывая, что в сети запущено нескольких служб – Active Directory/GPO, Exchange Server, MS SQL Server, виртуальные машины и так далее, генерирующих очень большое количество событий, отобрать из них действительно необходимые, следуя лишь описаниям, очень тяжело.

Как результат, администраторы считают достаточными мероприятия резервного копирования, предпочитая в случае возникновения проблем просто произвести откат к старым настройкам. Решение о внедрении аудита часто принимается только после серьезных происшествий. Далее рассмотрим процесс настройки аудита Active Directory на примере Windows Server 2008 R2, все действия описанные в статье будут применимы и к более новы редакциям Windows Server.

Кто должен заниматься аудитом домена Active Directory

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

• Маленькие
• Не имеющие достаточного количества денег, чтобы нанимать лишний персонал
• Нет необходимости

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

Аудит Active Directory средствами операционной системы

В операционных системах семейства Windows Server 2008 R2 и выше, по сравнению с предшественниками, такими как Windows Server 2003 обновлены возможности подсистемы аудита, настраиваемые через политики безопасности, а количество отслеживаемых параметров увеличено на 53. В старых ОС существовала только политика Аудит доступа к службе каталогов, контролировавшая включение и отключение аудита событий службы каталогов. Теперь управлять аудитом можно на уровне категорий. Например, политики аудита Active Directory разделены на категории, в каждой из которых настраиваются специфические параметры:

• Directory Service Access (доступ к службе каталогов);
• Аудит входов в систему
• Аудит системных событий
• Отслеживание процессов
• Аудит использования привилегий
• Управление учетными записями и группами
• Directory Service Changes (изменения службы каталогов);
• Directory Service Replication (репликация службы каталогов);
• Detailed Directory Service Replication (подробная репликация службы каталогов).

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

Включение политики аудита в домене Active Directory

Логично, что домен AD изначально был придуман, для более удобного управления его объектами по всем аспектам, и аудит информационной безопасности предприятия тут не исключение. Все настройки системный администратор будет производить на уровне всего домена или леса, через групповые политики, которые будут применяться как к компьютерам, так и к контроллерам домена. Я могу выделить из инструментов участвующих в этом, вот такие:

• глобальной политики аудита (Global Audit Policy, GAP);
• списка управления доступом (System access control list, SACL) - определяет операции, для которых будет производиться аудит;
• схемы – используется для окончательного формирования списка событий.

По умолчанию для клиентских систем аудит отключен, для серверных активна подкатегория "Доступ к службе каталогов Active Directory", остальные отключены. Для включения глобальной политики “Аудит доступа к службе каталогов” (Audit directory service access) необходимо вызвать "Редактор управления групповыми политиками " перейти в ветку Параметры безопасности/Локальные политики/Политика аудита, где активировать политику и установить контролируемые события (успех, отказ).

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

Конфигурация компьютера - Политики - Конфигурация Windows - Параметры безопасности - Конфигурация расширенной политики аудита - Политика аудита - Управление учетными записями (Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Account Management)

В нем вы обнаружите разделы:

1. Вход учетной записи
2. Управление учетными записями
3. Подробное отслеживание
4. Доступ к службе каталогов (DS)
5. Вход/выход
6. Доступ к объектам
7. Изменение политики
8. Использование привилегий
9. Система
10. Аудит доступа к глобальным объектам

Второй вариант реализации, это использовать для настройки утилиту командной строки auditpol , получить полный список GAP с установленными параметрами. При помощи auditpol достаточно ввести команду:

auditpol /list /subcategory:*

Как видите, результатом команды auditpol, стало отсутствие настроек по аудиту, каких либо событий безопасности.

Активируем политику “directory service access”, через команду:

auditpol /set /subcategory:"directory service changes" /success:enable

Подробные сведения о команде можно получить, запустив ее в виде auditpol /h

Чтобы не ждать, обновим политику контролера домена:

Подкатегория политики аудита Доступ к службе каталогов формирует события в журнале безопасности с кодом 4662, которые можно просмотреть при помощи консоли Просмотр событий (Event Viewer) вкладка Журналы Windows – Безопасность.

В качестве альтернативного варианта просмотра событий можно использовать командлет Get-EventLog оболочки PowerShell . Например:

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

Командлет Get-EventLog может принимать 14 параметров, позволяющих отфильтровать события по определенным критериям: After, AsBaseObject, AsString, Before, ComputerName, EntryType, Index, InstanceID, List, LogName, Message, Newest, Source и UserName.

Кроме этого, регистрируется ряд других событий 5136 (изменение атрибута), 5137 (создание атрибута), 5138 (отмена удаления атрибута) и 5139 (перемещение атрибута).
Для удобства отбора определенных событий в консоли Просмотр событий используют фильтры и настраиваемые представления, а также подписку, позволяющую собирать данные журналов и с других серверов.

Коллекторы событий

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

• Лично у меня для аудита Active Directory используется перенаправление всех событий с нужных мне серверов на один, так называемый сервер-коллектор, в его задачи входит агрегирование логов со всех серверов, что я настроил. Данная функциональность, так же является рядовой, у меня лично сборщик перенаправляемых логов реализован на Windows Server 2016, но это не принципиально.

• Вторая реализация, это система мониторинга Zabbix. Она полностью бесплатна, но вам придется слегка попотеть, чтобы ее должным образом настроить, но когда вы это сделаете, то получите в свое управление, очень удобный инструмент по ведению аудита в домене Active Directory. Вот пример реализации одного из тригеров, он будет выводить информацию, о событии "Вход с учётной записью выполнен успешно", ниже вы узнаете, что за это отвечает ID с номером 4624 (Более подробно читайте на https://habr.com/post/215509/)

• Еще одним замечательным решением, будет внедрение продукта Netwrix Active Directory Change Reporter. Это мега крутой комбайн для аудита безопасности информационных систем и доменной инфраструктуры Active Directory. Данный продукт разворачивается буквально за 30 минут и готов к выполнению своих задач (Более подробно вы можете почитать вот тут http://itband.ru/2011/09/audit-adds/).

Список событий аудита событий Active Directory в Windows Server 2008 R2

Ниже я постарался вам выписать самые распространенные и более используемые события, которые необходимы при аудите безопасности информационных систем, если вы хотите изучить абсолютно все доступные, то советую вам посетить портал компании Microsoft, посвященный расширенному аудиту, вот сама ссылка https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4723

Проверка учетных данных

1. 4774 Учетная запись была сопоставлена для входа в систему.
2. 4775 Не удалось сопоставить учетную запись для входа в систему.
3. 4776 Предпринята попытка проверить учетные данные для учетной записи контроллера домена.
4. 4777 Не удается проверить учетные данные для учетной записи контроллера домена.

Управление учетной записью компьютера

1. 4741 Создана учетная запись компьютера.
2. 4742 Изменена учетная запись компьютера.
3. 4743 Удалена учетная запись компьютера.

Управление группами рассылки

1. 4744 Создана локальная группа с отключенной проверкой безопасности.
2. 4745 Изменена локальная группа с отключенной проверкой безопасности.
3. 4746 Добавлен пользователь к локальной группе с отключенной проверкой безопасности.
4. 4747 Удален пользователь из локальной группы с отключенной проверкой безопасности.
5. 4748 Удалена локальная группа с отключенной проверкой безопасности.
6. 4749 Создана глобальная группа с отключенной проверкой безопасности.
7. 4750 Изменена глобальная группа с отключенной проверкой безопасности.
8. 4751 Добавлен пользователь к глобальной группе с отключенной проверкой безопасности.
9. 4752 Удален пользователь из глобальной группы с отключенной проверкой безопасности.
10. 4753 Удалена глобальная группа с отключенной проверкой безопасности.
11. 4759 Создана универсальная группа с отключенной проверкой безопасности.
12. 4760 Изменена универсальная группа с отключенной проверкой безопасности.
13. 4761 Член добавлен к универсальной группы с отключенной проверкой безопасности.
14. 4762 Удален пользователь из универсальной группы с отключенной проверкой безопасности.

Другие события управления учетными записями

1. 4739 Изменена политика домена.
2. 4782 Хэш пароля учетной записи доступа к нему.
3. 4793 Был вызван API проверку политики паролей.

Управление группой безопасности

1. 4727 Создана глобальная группа с включенной безопасностью.
2. 4728 Добавлен пользователь к глобальной группе с включенной безопасностью.
3. 4729 Удален пользователь из глобальной группы с включенной безопасностью.
4. 4730 Удалена глобальная группа с включенной безопасностью.
5. 4731 Создана локальная группа с включенной безопасностью.
6. 4732 Добавлен пользователь в локальную группу с включенной безопасностью.
7. 4733 Удален пользователь из локальной группы с включенной безопасностью.
8. 4734 Удалена локальная группа с включенной безопасностью.
9. 4735 Изменена локальная группа с включенной безопасностью.
10. 4737 Изменена глобальная группа с включенной безопасностью.
11. 4754 Создана универсальная группа с включенной безопасностью.
12. 4755 Изменена универсальная группа с включенной безопасностью.
13. 4756 Добавлен пользователь к универсальной группе с включенной безопасностью.
14. 4757 Удален пользователь из универсальной группы с включенной безопасностью.
15. 4758 Удалена универсальная группа с включенной безопасностью.
16. 4764 Изменен тип группы.

Управление учетными записями пользователей

1. 4720 Учетная запись пользователя создана.
2. 4722 Учетная запись пользователя включена.
3. 4724 Сброс пароля пользователя.
4. 4725 Учетная запись пользователя отключена.
5. 4726 Учетная запись пользователя удалена.
6. 4738 Изменена учетная запись пользователя.
7. 4765 Журнал SID был добавлен к учетной записи.
8. 4766 Не удалось добавить журнал SID учетной записи .
9. 4767 Учетная запись пользователя была разблокирована.
10. 4780 Список управления Доступом был установлен на учетные записи, которые являются членами группы администраторов.
11. 4781 Было изменено имя учетной записи.
12. 4794 Была предпринята попытка задать режим восстановления служб каталогов.
13. 5376 Диспетчер учетных данных: учетные данные были сохранены.
14. 5377 Диспетчер учетных данных: учетные данные были восстановлены из резервной копии.

Другие события

1. 1102 Очищен журнал безопасности
2. 4624 Успешный вход в систему
3. 4625 Не удачный вход в систему

В ветке Политика аудита также активируются и другие возможности (см.рис.1): аудит входа/выхода в систему, аудит управления учетными записями, доступ к объектам, изменения политик и так далее. Например, настроим аудит доступа к объектам на примере папки с общим доступом. Для этого активируем, как рассказано выше, политику Audit object access, затем выбираем папку и вызываем меню Свойства папки, в котором переходим в подпункт Безопасность и нажимаем кнопку Дополнительно. Теперь в открывшемся окне “Дополнительные параметры безопасности для..” переходим во вкладку Аудит и нажимаем кнопку Изменить и затем Добавить и указываем учетную запись или группу, для которой будет осуществляться аудит. Далее отмечаем отслеживаемые события (выполнение, чтение, создание файлов и др.) и результат (успех или отказ). При помощи списка “Применять” указываем область применения политики аудита. Подтверждаем изменения.

Теперь все указанные операции будут отображаться в журнале безопасности.
Чтобы упростить настройку аудита при большом количестве объектов, следует активировать флажок Наследование параметров от родительского объекта. При этом в поле Унаследовано от будет показан родительский объект, от которого взяты настройки.
Больший контроль событий, записываемых в журнал, достигается применением политики детализированного аудита (Granular Audit Policy), которая настраивается в Параметры безопасности/Локальные политики/Advanced Audit Policy Configuration. Здесь 10 подпунктов:

• Вход учетной записи – аудит проверки учетных данных, службы проверки подлинности Kerberos, операции с билетами службы Kerberos, другие события входа;
• Управление учетными записями – аудит управления группами приложений, учетными записями компьютеров и пользователей, группами безопасности и распространения;
• Подробное отслеживание – событий RPC и DPAPI, создания и завершения процессов;
• Доступ к службе каталогов DS – аудит доступа, изменений, репликации и подробной репликации службы каталогов;
• Вход/выход – аудит блокировки учетных записей, входа и выхода в систему, использования IPSec, сервера политики сети;
• Доступ к объектам – аудит объектов ядра, работы с дескрипторами, событий создаваемых приложениями, служб сертификации, файловой системы, общих папок, платформой фильтрации;
• Изменение политики – изменения политики аудита, проверки подлинности, авторизации, платформы фильтрации, правил службы защиты MPSSVC и другие;
• Использование прав – аудит прав доступа к различным категориям данных;
• Система – аудит целостности системы, изменения и расширения состояния безопасности, драйвера IPSec и других событий;
• Аудит доступа к глобальным объектам – аудит файловой системы и реестра.

Активация аудита управления учетными записями пользователей позволит отслеживать: создание, изменение, удаление, блокировку, включение и прочие настройки учетных записей, в том числе пароль и разрешения. Посмотрим, как она работает на практике - выбираем подкатегорию User Account Management и активируем. Команда для auditpol выглядит так:

auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
gpudate /force

Система аудита в консоли Просмотр события сразу покажет событие с номером 4719 Изменение параметров аудита, в котором показаны название политики и новые значения

Чтобы создать событие, откроем консоль Active Directory – пользователи и компьютеры и изменим один из параметров любой учетной записи - например, добавим пользователя в группу безопасности. В консоли Просмотра события сразу будут сгенерировано несколько событий: события с номером 4732 и 4735, показывающие изменение состава группы безопасности, и добавление учетной записи новой группы безопасности (на рис.8 выделены фиолетовым).
Создадим новую учетную запись – система генерирует несколько событий: 4720 (создание новой учетной записи), 4724 (попытка сброса пароля учетной записи), несколько событий с кодом 4738 (изменение учетной записи) и, наконец, 4722 (включение новой учетной записи). По данным аудита администратор может отследить старое и новое значение атрибута - например, при создании учетной записи меняется значение UAC.

Недостатки штатной системы аудита

Штатные инструменты операционной системы часто предлагают лишь базовые наборы средств анализа. Официальная документация (http://technet.microsoft.com/ru-ru/library/dd772623(WS.10).aspx) очень подобно расписывает возможности самого инструмента, практически мало помогая в выборе параметров, изменения которых необходимо отслеживать. В итоге решение этой задачи целиком ложится на плечи системного администратора, который должен полностью разбираться в технических аспектах аудита, и зависит от уровня его подготовки, а значит, велика вероятность ошибки. Кроме того, на его плечи ложится анализ результата, построение разнообразных отчетов.
Для удобства выбора определенных событий интерфейс консоли Event Viewer позволяет создавать фильтры и настраиваемые представления. В качестве параметров для отбора данных можно указать: дату, журнал и источник событий, уровень (критическое, предупреждение, ошибка и т.д.), код, пользователя или компьютер и ключевые слова. В организации может быть большое количество пользователей, объединенных в группы и подразделения, для которых аудит необходимо настроить персонально, но данная возможность в интерфейсе не предусмотрена.

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

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

Некоторые стандарты безопасности требуют хранения данных, собранных в процессе аудита, в течение продолжительного времени (например, SOX до 7 лет). Системными средствами реализовать это можно, но очень сложно. Размер журнала безопасности (как и других) ограничен 128 Мб, и при большом количестве событий данные могут быть перезаписаны (т.е. утеряны) уже через несколько часов. Чтобы этого избежать, необходимо вызвать окно свойств журнала в Event Viewer, где увеличить размер журнала и активировать его архивацию, установив флажок в “Архивировать журнал при заполнении. Не перезаписывать события”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Auditpol /list /subcategory:*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




}
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Delete subfolders and file - Successful»

«Delete - Successful»

“Create files / write data - Successful”

“Create folders / append data - Successful”

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

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

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

Event ID: 4660
Description: An object was deleted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В открывшейся оснастке в дереве слева необходимо перейти в раздел “Локальные политики” - “Политика аудита”.

Далее необходимо выбрать необходимую нам политику - в данном случае это “Аудит доступа к объектам”. Именно этой политикой регулируется доступ к объектам файловой системы (файлам и папкам) и раскрыть ее двойным щелчком мыши. В открывшемся окне необходимо выбрать какие именно типы событий будут регистрироваться - “Успех” (разрешение на операцию получено) и/или “Отказ” - запрет операции и проставить соответствующие галочки, после чего нажать “Ок”.

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

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

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

Сначала выбираем субъект - это чьи действия будут аудироваться (записываться в журнал аудита).

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

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

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

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

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

В дереве слева выбрать “Просмотр событий” - “Журналы Windows” - “Безопасность”.

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

Попробуем например найти событие удаления файла, для этого удалим файл на котором предварительно настроен аудит (если это не тестовые файл, то не забываем сделать его копию, так как аудит это всего лишь информация о действиях, а не разрешение/запрет этих действий). Нам нужно событие с кодом 4663 - получение доступа к объекту, у которого в поле Операции доступа Написано “DELETE” . Поиск событий в журналах Windows достаточно сложен, поэтому обычно используются специализированные средства анализа - системы мониторинга, скрипты и т.д.

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

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