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

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

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

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

нужные ОП отдела сбыта, могут сильно отличаться от ОП ф и- нансового отдела.

Оснастка Group Policy (Групповая политика)разрешает устанавливать параметры безопасности прямо в хранилище Active Directory. Папка Security Settings (Параметры безопасности)находится в узле Computer Configuration (Конфигурация компьютера)и узле User Configuration (Конфигурация пользо-

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

8.5. Аудит в Microsoft Windows

8.5.1. Обзор аудита в Windows

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

Каждая запись в журнале безопасности содержит:

сведения о выполненном действии;

сведения о пользователе, выполнившем это действие;

сведения о событии, произошедшем при этом, а также о том, было ли оно успешно.

8.5.1.1. Использование политики аудита

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

Windows записывает сведения о событии в журнал безопасности на том компьютере, на котором это событие имело

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

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

Можно настроить политику аудита на компьютере для:

отслеживания успеха/неудачи событий, таких как попытка входа в систему, попытка определенного пользователя прочесть указанный файл, изменений учетной записи пользователя или членства в группе, а также изменений в Ваших параметрах безопасности;

устранения или минимизации риска несанкционированного использования ресурсов.

Для просмотра событий, записанных Windows в журнал безопасности, можно использовать оснастку Event Viewer (Просмотр событий) . Можно также архивировать журналы для вы-

явления долговременных тенденций - например, для определения интенсивности доступа к принтерам или файлам или для контроля попыток несанкционированного доступа к ресурсам.

8.5.2.Планирование политики аудита

Администратор должен решить, на каких компьютерах вести аудит. По умолчанию аудит отключен.

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

Можно вести аудит:

доступа к файлам и папкам;

входа в систему и выхода из н ее определенных пользо-

выключения и перезагрузки компьютера с Windows

изменений учетных записей пользователей и групп;

попыток изменения объектов Active Directory.

Определив, какие события проверять, необходимо решить, отслеживать ли их успех и/или неудачу. Отслеживание успешных событий расскажет, как часто пользователи Windows или ее службы получают доступ к определенным файлам, принтерам и другим объектам. Это пригодится при планировании использования ресурсов. Отслеживание неудачных событий может предупредить о возможных нарушениях безопасности. Например, многочисленные неудачные попытки входа в систему с определенной учетной записью, особенно если они происходили вне обычного рабочего времени, могут означать, что некто, не имеющий прав доступа, пытается взломать систему.

При определении политики аудита целесообразно руководствоваться следующими принципами:

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

чаще просматривайте журнал безопасности. Составьте расписание и регулярно просматривайте этот журнал, поскольку настройка аудита сама по себе не предупредит о нарушениях безопасности;

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

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

8.5.3.Внедрение политики аудита

Необходимо продумать требования аудита и настроить его политику. Настроив политику аудита на каком-либо компьютере, можно вести аудит файлов, папок, принтеров и объектов Active Directory.

8.5.3.1. Настройка аудита

Можно выполнять политику аудита, основанную на роли данного компьютера в сети Windows. Аудит настраивается поразному для следующих типов компьютеров с Windows:

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

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

Требования для выполнения аудита

Настройка и администрирование аудита требуют выполнения следующих условий:

Вы должны иметь разрешениеManage Auditing And Security Log (Управление аудитом и журналом безопасности) для

компьютера, на котором Вы хотите настроить политику аудита или просмотреть журнал аудита. По умолчанию Windows дает такие права группе Administrators (Администраторы);

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

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

Вы должны настроить:

политику аудита, которая включает режим проверки, но не осуществляет аудит для конкретных объектов;

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

объектов Active Directory. Windows будет отслеживать и записывать в журнал эти события.

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

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

настройки, показывающие, какие попытки отслеживать: успешные или неудачные. Настраивать политики аудита можно через оснастку Group Policy (Групповая политика).

Типы событий, которые могут проверяться в Windows, представлены в таблице 8.1.

Таблица 8.1

Типы событий, которые могут проверяться в Windows

		Описание
События входа в		Контроллер домена получил запрос на проверку
систему с		правильности учетной записи пользователя
ной записью
Управление		Администратор создал, изменил или удалил
		учетную запись или группу. Учетная запись
		пользователя была изменена, включена или вы-
		ключена, или пароль был установлен или изме-
Доступ к службе		Пользователь получил доступ к объекту Active
каталогов		Directory . Вы должны указать конкретные объ-
		екты Active Directory для отслеживания этого
		типа события
События входа в		Пользователь входил в систему и выходил из нее
		или подключился/не смог подключиться по сети
		к данному компьютеру
Доступ к объе к-		Пользователь получил доступ к файлу, папке
		или принтеру. Вы должны указать файлы, папки
		или принтеры для проверки. Режим проверки
		доступа к службе каталогов проверяет доступ
		пользователя к определенному объекту Active
		Directory. Режим доступа к объекту проверяет
		доступ пользователя к файлам, папкам или
		принтерам
Изменение		Были сделаны изменения в пользовательских
		настройках безопасности, правах пользователя
		или политиках аудита
Использование		Пользователь применил права, например, по из-
привилегий		менению системного времени. (Сюда не вклю-
		чаются права, связанные с входом в систему и
		выходом из нее)
Отслеживание		Пользователь произвел действие. Эта информа-
процесса		ция полезна программистам, желающим отсле-
		дить детали выполнения программы
Системное		Пользователь перезагрузил или выключил ком-
		пьютер, или произошло событие, влияющее на
		безопасность Windows или на журнал безопас-
		ности. (Например, журнал аудита переполнен, и
		Windows не смогла записать новую информа-

Категория аудита 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 можно решить ряд трудных задач: например, выяснить, имели ли место попытки несанкционированного доступа к данным и кто мог изменить тот или иной файл. Несмотря на трудности анализа избыточных данных журнала, эта категория занимает достойное место в арсенале администратора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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