###
  • Интернет
  • Программы
  • Игры
  • Проблемы
  • Windows
  • Социальные сети
  • Android
  • Ios

    • Аудит доступа к файлам и папкам. Аудит доступа к объектам

    29.03.2019 Звуковые устройства

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

    Включение аудита за определенным объектом

    Мы уже активировали возможность аудита доступа к объекту файловой системы NTFS. Теперь нам осталось только указать за какими объектами необходимо наблюдать. Для этого откройте окно Свойства выбранного объекта и перейдите во вкладку Безопасность . Далее необходимо нажать кнопку Дополнительно и в открывшемся окне перейти во вкладку Аудит . Дальнейшие действия можно описать следующим планом:

    1. Жмём кнопку Добавить и добавляем пользователя или группу пользователей, за действиями которых мы хотим следить.
    2. Настраиваем область действия аудита(аудит только папки, аудит папки и его содержимого и т. д.)
    3. Выбираем либо аудит успешных, либо аудит неудачных действий по отношении к объекту.
    4. Выбираем те действия, которые должны документироваться. Например, выбрав пункт Удаление , Вы укажете компьютеру документировать только те действия пользователей, которые связаны с удалением объекта. Все предложенные действия являются правами доступа к файлу или папке , можете ознакомится с ними.
    5. Сохранить изменения.

    Как просмотреть результаты аудита доступа к объекту?

    За результатами аудита файловой системы NTFS прошу пожаловать в Журнал Windows и пройти в окно Безопасность . Там Вы получите необычайно длинный список всех действий, которые связаны с безопасностью компьютера. Именно среди них Вы и найдете документацию по попыткам доступа к Вашему объекту. Применяя сортировку, я уверен, Вы легко найдете интересующую Вас документацию.

    Как активировать возможность аудита файловой системы NTFS через Реестр?

    Данный пункт, как я уже говорил, будет интерес для обладателей Windows Starter или Home Basic. У них нет доступа к Редактору локальной групповой политики, но за то есть доступ к Реестру. А Реестр позволяет проделать те же действия, что и Редактор локальной политики. Только, к сожалению, я не нашел второй параметр, который дублирует вторую политику. С первым же параметром я Вас познакомлю: параметр

    HKLM\System\CurrentControlSet\Control\Lsa\SCENoApplyLegacyAuditPolicy

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

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

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

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

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

    Оснастка 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 не смогла записать новую информа-

    Всем привет!

    Продолжаем публиковать шпаргалки по настройке аудита различных систем, в прошлый раз мы говорили об AD habrahabr.ru/company/netwrix/blog/140569 , сегодня обсудим файловые серверы. Надо сказать, что чаще всего мы выполняем именно настройки аудита файловых серверов – в ходе пилотных инсталляций у заказчиков. Ничего сложного в этой задаче нет, всего лишь три простых шага:

    • Настроить аудит на файловых ресурсах (file shares)
    • Настроить и применить общую и детальную политики аудита
    • Изменить настройки журналов событий
    Если у вас большое количество файловых шар, доступ к которым часто требуется сотрудникам – рекомендуем контролировать только изменения объектов аудита. Отслеживание всех событий может привести к тому, что в журналы будет попадать большой объем избыточных данных, которые не представляют особой важности.

    Настройка аудита на файловых ресурсах

    Настройка общей политики аудита

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

    Настройка детальной политики аудита

    Настройка журналов событий

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

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

    Перед запуском скрипта нужно отредактировать строчку 19 - вписать вместо «your_ou_name» и «your_domain» необходимые значения. Скрипт необходимо выполнять от имени учетной записи, имеющей права администратора домена.

    Получить скрипт можно в нашей базе знаний или сохранить в файл.ps1 следующий текст:

    #import-module activedirectory #$path = $args; # \\fileserver\share\folder $account = "Everyone" # $args; $flavor = "Success,Failure" #$args; $flags = " ReadData, WriteData, AppendData, WriteExtendedAttributes, DeleteSubdirectoriesAndFiles, WriteAttributes, Delete, ChangePermissions, TakeOwnership " $inheritance = "ContainerInherit, ObjectInherit" $propagation = "None" $comps = Get-ADComputer -Filter * -SearchBase "OU=your_ou_name,DC=your_domain,DC=your_domain" | select -exp DNSHostName foreach ($comp in $comps) { $shares = get-wmiobject -class win32_share -computername $comp -filter "type=0 AND name like "%[^$]"" | select -exp name foreach ($share in $shares) { $path = "\\"+$comp+"\"+$share $path $acl = (Get-Item $path).GetAccessControl("Access,Audit") $ace = new-object System.Security.AccessControl.FileSystemAuditRule($account, $flags, $inheritance, $propagation, $flavor) $acl.AddAuditRule($ace) set-acl -path $path -AclObject $acl } }

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

    В процессе аудита используются три средства управления: политика аудита, параметры аудита в объектах, а также журнал «Безопасность» , куда заносятся события, связанные с безопасностью, такие как вход/выход из системы, использование привилегий и обращение к ресурсам. В этой статье мы рассмотрим именно политики аудита и последующий анализ событий в журнале «Безопасность» .

    Политика аудита

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

    Рис. 1. Узел «Политика аудита»

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

    Рис. 2. Свойства политики аудита «Аудит доступа к службе каталогов»

    После настройки политики аудита события будут заноситься в журнал безопасности. Просмотреть эти события можно в журнале безопасности. Рассмотрим подробно каждую политику аудита:

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

    Аудит доступа к объектам . Данная политика безопасности выполняет аудит попыток доступа пользователей к объектам, которые не имеют отношения к Active Directory. К таким объектам можно отнести файлы, папки, принтеры, разделы системного реестра, которые задаются собственными списками в системном списке управления доступом (SACL). Аудит создается только для объектов, для которых указаны списки управления доступом, при условии, что запрашиваемый тип доступа и учетная запись, выполняющая запрос, соответствуют параметрам в данных списках.

    Аудит доступа к службе каталогов . При помощи этой политики безопасности вы можете определить, будет ли выполняться аудит событий, указанных в системном списке контроля доступа (SACL), который можно редактировать в диалоговом окне «Дополнительные параметры безопасности» свойств объекта Active Directory. Аудит создается только для объектов, для которых указан системный список управления доступом, при условии, что запрашиваемый тип доступа и учетная запись, выполняющая запрос, соответствуют параметрам в данном списке. Данная политика в какой-то степени похожа на политику «Аудит доступа к объектам» . Аудит успехов означает создание записи аудита при каждом успешном доступе пользователя к объекту Active Directory, для которого определена таблица SACL. Аудит отказов означает создание записи аудита при каждой неудачной попытке доступа пользователя к объекту Active Directory, для которого определена таблица SACL.

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

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

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

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

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

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

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

    Пример использования политики аудита

    Допустим, у нас есть домен testdomain.com, в котором есть пользователь с учетной записью DImaN.Vista. в данном примере мы применим для этого пользователя политику и увидим, какие события записываются в журнал безопасности при попытке несанкционированного доступа в систему. Для воспроизведения подобной ситуации выполните следующие действия:

    Заключение

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