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

В статье я расскажу как обращаться с log-файлами IIS и автоматизировать процесс удаления.

Введение

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

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

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

Логи IIS

По умолчанию логи IIS располагаются в каталоге %SystemDrive%\inetpub\logs\LogFiles. Сигналом для их очистки может служить истощающееся быстрыми темпами свободное место системного диска. В этом случае системные администраторы начинают искать что же занимает столько места и благополучно пропускают папку inetpub, поскольку по умолчанию она практически ничего не весит:

Но почему? Дело в том, что изначально вы не имеете разрешений на вложенные папки, следовательно не можете увидеть их реальный объем:

Попробуйте зайти в каждую подпапку каталога %SystemDrive%\inetpub\logs\LogFiles, соглашаясь с назначением необходимых разрешений и в итоге увидите, что реальный объем папок не так уж и мал:

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

Итак, проблема найдена, пора заняться очисткой. Теоретически её можно проводить и вручную, но в этом нет никакого смысла и проще все сделать скриптами, в некоторых случаях достаточно даже одной команды PowerShell. В одной из статей по Exchange 2013 (см. Очистка папки Logging Exchange 2013) я уже рассматривал вопрос автоматизации процесса очистки логов, но не помешает напомнить о нем и в этой статье.

Команда для очистки log-файлов в нашем случае будет выглядеть следующим образом:

PowerShell gci ‘C:\inetpub\logs\LogFiles’ -Include ‘*.log’ -Recurse | ? LastWriteTime -LT (Get-Date).AddDays(-3) | Remove-Item

1 gci ‘C:\inetpub\logs\LogFiles’ -Include ‘*.log’ -Recurse | ? LastWriteTime -LT (Get-Date).AddDays(-3) | Remove-Item

В командлете (Get-Date).AddDays(-3) вместо значения -3 задайте свое. -3 говорит о том, что будут удалены все файлы старше трех дней. Для меня это оптимальное значение, для вас оно может отличаться. В продакшене рекомендую оставлять минимум неделю истории, а если позволяет свободное место, то и целый месяц не будет лишним.

Создадим отдельную учетную запись, администратором её делать не нужно:

Дадим учетной записи права Вход в качестве пакетного задания 1 (через оснастку управления политиками ):

Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователя

Дальше необходимо выдать пользователю права на каталог %SystemDrive%\inetpub\logs\LogFiles. Достаточно прав на чтение + права на удаление файлов и папок:

Снова открываем окно назначения прав и заменяем разрешения всех дочерних элементов родительскими (без этого работать не будет, ведь на этом каталоге отключено наследование):

Следующий шаг — создание запланированного задания (в аргументах вставьте команду, о которой речь шла выше):

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

Notes:

  1. Вход в качестве пакетного задания ↩

comments powered by HyperComments

Установка и настройка сервера Rsyslog

В большинстве дистрибутивов Linux пакет rsyslog предустановлен. Если у вас его нет, установите его при помощи менеджера пакетов: Для RHEL/CentOS:

$ yum install rsyslog

Для Ubuntu/Debian:

$ apt install rsyslog

После установки rsyslog нужно запустить службу, активировать автоматический запуск при загрузке и проверить состояние при помощи команды systemctl.

$ sudo systemctl start rsyslog $ sudo systemctl enable rsyslog $ sudo systemctl status rsyslog

Главный файл конфигурации rsyslog — /etc/ Он загружает модули, определяет глобальные директивы, содержит правила по обработке сообщений логов, а также включает пути ко всем файлам конфигурации в директории /etc/rsyslog.d/ для различных приложений и служб.

$ sudo vim /etc/

По умолчанию rsyslog использует модули imjournal и imusock для импорта структурированных записей логов из журнала systemd и для приема через сокеты Unix сообщений системных логов от приложений, запущенных в локальной системе, соответственно.

Чтобы настроить rsyslog как сетевой централизованный сервер ведения логов, нужно установить протоколы (UDP, TCP или оба), которые будут использоваться для приема удаленных сообщений системных логов, а также прослушиваемые порты.

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

Читайте также:  Как открыть командную строку в Windows 10

$ModLoad imudp $UDPServerRun 514

Для использования TCP-соединения (медленнее, но надежнее) найдите и раскомментируйте следующие строки:

$ModLoad imtcp $InputTCPServerRun 514

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

_важности место_записи_лога

уровень_важности: тип сообщения логов: emerg-0, alert-1, crit-2, err-3, warn-4, notice-5, info-6, debug-7. Использование звездочки означает все уровни важности, если ничего не указывать, предполагается отсутствие уровня важности.

  • 0, emerg – система не работоспособна
  • 1, alert – система требует немедленного вмешательства
  • 2, crit – состояние системы критическое
  • 3, err – сообщение об ошибке
  • 4, warning – предупреждение о возможной проблеме
  • 5, notice – нормальное, но важное событие
  • 6, info – информационное сообщение
  • 7 , debug – отладочное сообщение
  • место_записи_лога: локальный файл или удаленный сервер rsyslog (определенный в формате IP-адрес:порт).

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

$template RemoteLogs,»/var/log/%HOSTNAME%/%PROGRAMNAME%.log» *.* ?RemoteLogs & ~

Рассмотрим набор правил более подробно. Первое правило в нем следующее: «$template RemoteLogs,”/var/log/%HOSTNAME%/%PROGRAMNAME%.log”». Директива $template дает демону rsyslog команду собирать полученные сообщения из источников и записывать их в отдельные логи в директории /var/logs в соответствии с именем узла (машины клиента) и источником (программой/приложением), от которых были получены сообщения, что определено соответствующим шаблоном.

Вторая строка «*.* ?RemoteLogs» означает запись сообщений всех уровней важности от всех источников в соответствии с шаблоном RemoteLogs.

Последняя строка «& ~» задает rsyslog прекратить обработку сообщений после их записи в файл. Если не указать «& ~», сообщения будут записаны в локальные файлы. Настройка сервера для нашего примера завершена. Теперь нужно сохранить и закрыть файл конфигурации, а также перезапустить демон rsyslog, чтобы изменения вступили в силу:

$ sudo systemctl restart rsyslog

Далее требуется проверить сетевые сокеты rsyslog. Воспользуйтесь netstat

$ netstat -nap | grep «rsyslog»

Если у вас включена служба SELinux, нужно выполнить следующие команды, чтобы разрешить трафик rsyslog:

$ sudo semanage -a -t syslogd_port_t -p udp 514 $ sudo semanage -a -t syslogd_port_t -p tcp 514

При включенном брандмауэре нужно открыть TCP и UDP порты 514, чтобы разрешить подключение к серверу rsyslog по обоим протоколам:

Для CentOS (брандмауэр firewalld):

$ sudo firewall-cmd —permanent —add-port=514/udp $ sudo firewall-cmd —permanent —add-port=514/tcp $ sudo firewall-cmd —reload

Для Ubuntu (брандмауэр ufw):

$ sudo ufw allow 514/udp $ sudo ufw allow 514/tcp $ sudo ufw reload

Читайте также:  Как сделать загрузочный диск или флешку Windows 7, 8.1, 10

Как исправить отказ в доступе

Давайте перечислим способы, позволяющие избавиться от ошибки «Групповая политика препятствует входу в систему».

Отредактируйте системный реестр

  • Нажмите Win+R, введите там regedit , нажмите Энтер. Перейдите по пути:

В панели справа поищите параметр «GPSvcGroup». Если его там нет, кликните правой клавишей мышки на пустом месте правого поля, кликните на «Создать» — «Мультистроковой параметр» и дайте ему имя (переименуйте) на GPSvcGroup .

Введите указанное значение

  • Вновь нажмите ПКМ на пустое место справа, выберите «Создать» – «Раздел», и дайте ему название GPSvcGroup.
  • Кликните на новосозданной папке GPSvcGroup, затем кликните ПКМ на пустом месте справа, выберите создать «Параметр DWORD» и назовите его AuthenticationCapabilities.
  • Нажмите ПКМ на AuthenticationCapabilities, выберите «Изменить», активируйте «Десятичная», введите 12320 и нажмите на «Ок».
  • Создайте другой параметр DWORD с именем CoInitializeSecurityParam и установите ему значение 1 .
  • Создайте перечисленные параметры

  • Перезагрузите ваш ПК и попытайтесь выполнить вход в оригинальный аккаунт.
  • Перезапустите службу групповых политик

    • Нажмите на Win+R, введите там . Найдите в перечне служб « Клиент групповой политики », дважды кликаем на ней, устанавливаем тип запуска на «Автоматически», сохраняем изменения;
    • Запускаем командную строку, там набираем:

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

    Введите данную команду

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

    Во многих случаях причинами рассматриваемой проблемы являются вирусные зловреды, изменяющие системные настройки под свои нужны. Используйте ДокторВеб Кюрейт, Trojan Remover, AdwCleaner и другие онлайн аналоги для борьбы со зловредами — 7 лучших антивирусов.

    Восстановите параметры безопасности

    Для реализации данной операции нам понадобится загрузочная флешка с нашей версией ОС. Загрузитесь с её помощью, выбираем внизу «Восстановление», запускаем командную строку, и там вводим:

    secedit /configure /cfg %windir% /db /verbose

    Как исправить отказ в доступе

    Перезагрузите ваш ПК, это поможет исправить проблему отказано в доступе.

    Удалите файл

    Перейдите в директорию C:Users, там найдите папку с названием вашего аккаунта, войдите в неё, и удалите там файл , отвечающий за хранение настроек пользовательского профиля. Если ваш аккаунт повреждён, вы можете попробовать удалить данный файл, перезагрузить ваш ПК, и попытаться войти в систему.

    Удалите указанную папку

    Выполните системное восстановление

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