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

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

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

Изменение параметров автоматической установки в режиме аудита

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

На обслуживающем компьютере откройте диспетчер установки Windows и создайте новый файл автоматической установки. Дополнительные сведения см. в разделе Создание файла ответов.

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

Сохраните файл на переносном запоминающем устройстве, например USB-устройстве флэш-памяти. Пример: F:\Unattend-NewSettings.xml , где F: — это буква диска переносного устройства.

Отключите переносное запоминающее устройство и подключите его к компьютеру-образцу или конечному компьютеру.

В командной строке запустите средство Sysprep, указав в параметре /unattend путь к файлу.

Пример: sysprep.exe /audit /reboot /unattend:F:\Unattend-NewSettings.xml , где F: — это буква диска переносного устройства.

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

Если компьютер присоединен к домену, то запуск команды sysprep с параметром /audit приведет к исключению компьютера из домена. После загрузки компьютера в режиме аудита можно повторно присоединить компьютер к домену.

Выход из режима аудита и подготовка компьютеров для пользователей

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

Дополнительные сведения о предварительной настройке экрана приветствия Windows см. в разделе Автоматизация экранa приветствия Windows.

	Примечание.

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

Можно предварительно задать параметры экрана приветствия Windows с помощью файла содержимого oobe.xml. Дополнительные сведения см. в Техническое руководство по Oobe.xml.

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

Подготовка компьютера к развертыванию

Настройка компьютера на загрузку экрана приветствия Windows

В режиме аудита выполните команду Sysprep с параметром /oobe.

При автоматической установке задайте для параметра Microsoft-Windows-Deployment \Reseal\Mode значение oobe. Дополнительные сведения об этих параметрах см. в разделе Справочник по автоматической установке Windows®.

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

См. также

Щелкните здесь, чтобы отправить отзыв на этот раздел.

Настройка аудита в Windows для полноценного SOC-мониторинга

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

Введение

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

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

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

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

	Примечание.

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

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

Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

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

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов»

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

Выводы

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

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

Вам также может понравиться

Windows или Linux: Что лучше выбрать?

Есть много причин выбирать между Windows и Linux, но

Файл владелец изменить linux

Команда Chown в Linux Chown Command in Linux (File

Установка шлюза по умолчанию linux

Настройка сети вручную Содержание Краткое описание

Чем разбить диск для linux

ИТ База знаний Курс по Asterisk Полезно — Узнать IP —