Как посмотреть логи windows server 2008

Содержание

Просмотр системного журнала

Если в работе Windows 2008 появляется какая-то нестабильность, или появляются ошибки запуска\установки приложений, то это может быть связано с появлениями ошибок в самой операционной системе. Все системные ошибки и предупреждения можно найти в «Журнале системы«. В нем сохраняется информация о событиях, записываемых системными компонентами Windows.

Для просмотра и сохранения системного журнала нужно выполнить шаги:

Открыть «Диспетчер сервера«. Этот пункт меню можно найти нажав на кнопку «Пуск«, затем нажав правой кнопкой мыши на «Компьютер«:

В диспетчере сервера выбрать «Диспетчер сервера» -> «Диагностика» -> «Журналы Windows» -> «Система«

Экспорт журнала

Системный журнал в полном объеме можно экспортировать для последующего изучения путем нажатия на ссылку «Сохранить события как…«

После нажатия ссылки «Сохранить события как…» нужно выбрать путь и имя файла для сохраняемого журнала.

Готово

Источник

В журналы событий записывается хронологическая информация, которая поможет вам выявить проблемы в системе и безопасности. Отслеживанием событий на системах Windows Server 2008 управляет служба Журнал событий Windows (Windows Event Log). Журналы бывают двух основных типов:

• Журналы Windows (Windows logs) Используются операционной системой для записи основных системных событий, связанных с приложениями, безопасностью, настройкой и системными компонентами.

• Журналы приложений и служб (Applications and Services logs) Используются отдельными приложениями и службами для записи событий, специфических для приложения или службы.

К журналам Windows относятся следующие журналы:

• Безопасность (Security Log) В него записываются события, для которых в локальных или глобальных групповых политиках безопасности задан аудит. По умолчанию располагается в файле %System Root%\ System32\Winevt\Logs\Security.evtx.

• Настройка (Setup Log) Сюда записываются события, зарегистрированные ОС и ее компонентами в процессе установки. По умолчанию располагается в файле %SystemRoot%\System32\Winevt\Logs\Setiip.evtx.

• Пересланные события (Forwarded Events) Если настроена пересылка событий, в этот’ журнал записываются события, пересланные с других серверов. По умолчанию располагается в файле %SystemRoot%\Systein32\ Config\EordwardedEvents.evtx.

• Приложение (Application) В него записываются события, зарегистрированные приложениями, например, ошибка при осуществлении доступа к базе данных Microsoft SQL Server. По умолчанию он располагается в файле %System Root%\System32\Winevt\Logs\Application.cvtx.

• Система (System Log) Сюда записываются события, зарегистрированные ОС и ее компонентами, например, неудачный запуск службы при загрузке. По умолчанию располагается в файле %SystemRoot%\System32\ Winevt\Logs\Systcm.cvtx.

К журналам приложений и служб относятся следующие журналы:

• Репликация DFS (DFS Replication) В этом журнале протоколируется активность служб репликации DFS. По умолчанию располагается в файле %SystemRoot%\System32\Winevt\Logs\Dfs Replication, cvtx.

• Служба каталогов (Directory Service) Сюда записываются события, зарегистрированные доменными службами Active Directory. По умолчанию располагается в файле %SystemRoot%\System32\Winevt\Logs\ Directory Service.evtx.

• Служба репликации файлов (File Replication Service) Здесь протоколируется активность службы репликации файлов. По умолчанию располагается в файле %SystemRoot%\Systcm32\Winevt\Logs\File Replication Service.evtx.

• События оборудования (Hardware Events) Если настроена регистрация событий аппаратной подсистемы, в этот журнал Записываются аппаратные события, зарегистрированные ОС. По умолчанию располагается в файле %SystemRoot%\System32\Config\Hardware.evtx.

• DNS-сервер (DNS Server) Сюда записываются DNS-запросы, ответы и прочая активность DNS. По умолчанию располагается в файле %SystemRoot%\System32\Winevt\Logs\DNSServer.evtx.

• Microsoft\Windows Журналы событий, относящихся к определенным службам и компонентам Windows. Журналы организуются по типу компоиентов и категории событий. В операционных журналах регистрируются события, вызванные текущими операциями соответствующего компонента. В некоторых случаях вы увидите также дополнительные журналы для анализа, отладки и регистрации административных задач.

• Windows PowerShell В этом журнале записываются события, относящиеся к использованию Windows PowerShell. По умолчанию располагается в файле %SystemRoot%\System32\Winevt\Logs\ Windows PowerShell.evtx.

Источник

Содержание

Просмотр системного журнала

Если в работе Windows 2008 появляется какая-то нестабильность, или появляются ошибки запускаустановки приложений, то это может быть связано с появлениями ошибок в самой операционной системе. Все системные ошибки и предупреждения можно найти в «Журнале системы«. В нем сохраняется информация о событиях, записываемых системными компонентами Windows.

Для просмотра и сохранения системного журнала нужно выполнить шаги:

В диспетчере сервера выбрать «Диспетчер сервера» -> «Диагностика» -> «Журналы Windows» -> «Система«

Экспорт журнала

После нажатия ссылки «Сохранить события как…» нужно выбрать путь и имя файла для сохраняемого журнала.

Готово

К журналам Windows относятся следующие журналы:

• Настройка (Setup Log) Сюда записываются события, зарегистрированные ОС и ее компонентами в процессе установки. По умолчанию располагается в файле %SystemRoot%System32WinevtLogsSetiip.evtx.

К журналам приложений и служб относятся следующие журналы:

• Репликация DFS (DFS Replication) В этом журнале протоколируется активность служб репликации DFS. По умолчанию располагается в файле %SystemRoot%System32WinevtLogsDfs Replication, cvtx.

• Служба репликации файлов (File Replication Service) Здесь протоколируется активность службы репликации файлов. По умолчанию располагается в файле %SystemRoot%Systcm32WinevtLogsFile Replication Service.evtx.

• DNS-сервер (DNS Server) Сюда записываются DNS-запросы, ответы и прочая активность DNS. По умолчанию располагается в файле %SystemRoot%System32WinevtLogsDNSServer.evtx.

• MicrosoftWindows Журналы событий, относящихся к определенным службам и компонентам Windows. Журналы организуются по типу компоиентов и категории событий. В операционных журналах регистрируются события, вызванные текущими операциями соответствующего компонента. В некоторых случаях вы увидите также дополнительные журналы для анализа, отладки и регистрации административных задач.

• Windows PowerShell В этом журнале записываются события, относящиеся к использованию Windows PowerShell. По умолчанию располагается в файле %SystemRoot%System32WinevtLogs Windows PowerShell.evtx.

Обновлено 23.03.2022

Всем привет, тема стать как посмотреть логи windows. Что такое логи думаю знают все, но если вдруг вы новичок, то логи это системные события происходящие в операционной системе как Windows так и Linux, которые помогают отследить, что, где и когда происходило и кто это сделал. Любой системный администратор обязан уметь читать логи windows.

Примером из жизни может служить ситуация когда на одном из серверов IBM, выходил из строя диск и для технической поддержки я собирал логи сервера, для того чтобы они могли диагностировать проблему. За собирание и фиксирование логов в Windows отвечает служба Просмотр событий. Просмотр событий это удобная оснастка для получения логов системы.

Как открыть в просмотр событий

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

Win+R и вводите eventvwr.msc

Откроется у вас окно просмотр событий windows в котором вам нужно развернуть пункт Журналы Windows. Пробежимся по каждому из журналов.

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

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

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

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

Так же есть логи windows для более специфических служб, например DHCP или DNS. Просмотр событий сечет все :).

Фильтрация в просмотре событий

Предположим у вас в журнале Безопасность более миллиона событий, наверняка вы сразу зададите вопрос есть ли фильтрация, так как просматривать все из них это мазохизм. В просмотре событий это предусмотрели, логи windows можно удобно отсеять оставив только нужное. Справа в области Действия есть кнопка Фильтр текущего журнала.

Вас попросят указать уровень событий:

Критическое
Ошибка
Предупреждение
Сведения
Подробности

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

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

Как очистить просмотр событий с помощью PowerShell
Как почистить все журналы windows с помощью скрипта

Посмотреть логи windows PowerShell

Было бы странно если бы PowerShell не умел этого делать, для отображения log файлов открываем PowerShell и вводим вот такую команду

Get-EventLog -Logname ‘System’

В итоге вы получите список логов журнала Система

Тоже самое можно делать и для других журналов например Приложения

Get-EventLog -Logname ‘Application’

небольшой список абревиатур

Код события — EventID
Компьютер — MachineName
Порядковый номер события — Data, Index
Категория задач — Category
Код категории — CategoryNumber
Уровень — EntryType
Сообщение события — Message
Источник — Source
Дата генерации события — ReplacementString, InstanceID, TimeGenerated
Дата записи события — TimeWritten
Пользователь — UserName
Сайт — Site
Подразделение — Conteiner

Например, для того чтобы в командной оболочке вывести события только со столбцами «Уровень», «Дата записи события», «Источник», «Код события», «Категория» и «Сообщение события» для журнала «Система», выполним команду:

Get-EventLog –LogName ‘System’ | Format-Table EntryType, TimeWritten, Source, EventID, Category, Message

Если нужно вывести более подробно, то заменим Format-Table на Format-List

Get-EventLog –LogName ‘System’ | Format-List EntryType, TimeWritten, Source, EventID, Category, Message

Как видите формат уже более читабельный.

Так же можно пофильтровать журналы например показать последние 20 сообщений

Get-EventLog –Logname ‘System’ –Newest 20

Или выдать список сообщение позднее 1 ноября 2014

Get-EventLog –LogName ‘System’ –After ‘1 ноября 2014’

Дополнительные продукты

Так же вы можете автоматизировать сбор событий, через такие инструменты как:

Комплекс мониторинга Zabbix
Через пересылку событий средствами Windows на сервер коллектор
Через комплекс аудита Netwrix
Если у вас есть SCOM, то он может агрегировать любые логи Windows платформ
Любые DLP системы

Так что вам выбирать будь то просмотр событий или PowerShell для просмотра событий windows, это уже ваше дело. Материал сайта pyatilistnik.org

Удаленный просмотр логов

Первый метод

Не так давно в появившейся операционной системе Windows Server 2019, появился компонент удаленного администрирования Windows Admin Center. Он позволяет проводить дистанционное управление компьютером или сервером, подробнее он нем я уже рассказывал. Тут я хочу показать, что поставив его себе на рабочую станцию вы можете подключаться из браузера к другим компьютерам и легко просматривать их журналы событий, тем самым изучая логи Windows. В моем примере будет сервер SVT2019S01, находим его в списке доступных и подключаемся (Напомню мы так производили удаленную настройку сети в Windows).

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

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

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

Вот пример фильтрации по событию 19.

Очень удобно экспортировать полностью журнал в формат evxt, который потом легко открыть через журнал событий. Так, что Windows Admin Center, это мощное средство по просмотру логов.

Второй метод

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

Указываем имя другого компьютера, в моем примере это будет SVT2019S01

Если все хорошо и нет блокировок со стороны брандмауэра или антивируса, то вы попадете в удаленный просмотр событий .если будут блокировки, то получите сообщение по типу, что не пролетает трафик COM+.

Так же хочу отметить, что есть целые системы агрегации логов, такие как Zabbix или SCOM, но это уже другой уровень задач. На этом у меня все, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Аудит доменных служб Active Directory в Windows Server 2008 R2

ИТ среда не является статичной. Ежеминутно в системах происходят тысячи изменений, которые требуется отследить и запротоколировать. Чем больше размер и сложность структуры, тем выше вероятность появления ошибок в администрировании и раскрытия данных. Без постоянного анализа изменений (удачных или неудачных) нельзя построить действительно безопасную среду. Администратор всегда должен ответить, кто, когда и что изменил, кому делегированы права, что произошло в случае изменений (удачных или неудачных), каковы значения старых и новых параметров, кто смог или не смог зайти в систему или получить доступ к ресурсу, кто удалил данные и так далее. Аудит изменений стал неотъемлемой частью управления ИТ инфраструктурой, но в организациях не всегда уделяют внимание аудиту, часто из-за технических проблем. Ведь не совсем понятно, что и как нужно отслеживать, да и документация в этом вопросе не всегда помогает. Количество событий, которые необходимо отслеживать, уже само по себе сложность, объемы данных велики, а штатные инструменты не отличаются удобством и способностью упрощать задачу отслеживания. Специалист должен самостоятельно настроить аудит, задав оптимальные параметры аудита, кроме того, на его плечи ложится анализ результатов и построение отчетов по выбранным событиям. Учитывая, что в сети запущено нескольких служб – Active Directory/GPO, Exchange Server, MS SQL Server, виртуальные машины и так далее, генерирующих очень большое количество событий, отобрать из них действительно необходимые, следуя лишь описаниям, очень тяжело.
Как результат, администраторы считают достаточными мероприятия резервного копирования, предпочитая в случае возникновения проблем просто произвести откат к старым настройкам. Решение о внедрении аудита часто принимается только после серьезных происшествий. Далее рассмотрим процесс настройки аудита Active Directory на примере Windows Server 2008 R2.

Аудит Active Directory штатными средствами

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

— Directory Service Access (доступ к службе каталогов);
— Directory Service Changes (изменения службы каталогов);
— Directory Service Replication (репликация службы каталогов);
— Detailed Directory Service Replication (подробная репликация службы каталогов).

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

ПРИМЕЧАНИЕ: В Windows Server 2003 аудит регистрировал только имя измененного атрибута.

В Windows Server 2008 R2 аудит внедряется при помощи:

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

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

Рис.1 Включение политики аудита Directory Service Access

Второй путь — использовать для настройки утилиту командной строки auditpol, получить полный список GAP с установленными параметрами. При помощи auditpol достаточно ввести команду:
> auditpol /list /subcategory:*

Рис.2 Получаем список установок при помощи auditpol

Активируем политику “directory service access”:

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

ПРИМЕЧАНИЕ: Подробные сведения о команде можно получить, запустив ее в виде
auditpol /h

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

> gpupdate

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

Рис.3 Просмотр событий при помощи Event Viewer

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

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

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

Рис.4 Получаем список событий при помощи Get-EventLog

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

Таблица 1. Список событий аудита событий Active Directory в Windows Server 2008

Проверка учетных данных
ИДЕНТИФИКАТОР Сообщение
4774 Учетная запись была сопоставлена для входа в систему.
4775 Не удалось сопоставить учетную запись для входа в систему.
4776 Предпринята попытка проверить учетные данные для учетной записи контроллера домена.
4777 Не удается проверить учетные данные для учетной записи контроллера домена.

Управление учетной записью компьютера
ИДЕНТИФИКАТОР Сообщение
4741 Создана учетная запись компьютера.
4742 Изменена учетная запись компьютера.
4743 Удалена учетная запись компьютера.

Управление группами рассылки
ИДЕНТИФИКАТОР Сообщение
4744 Создана локальная группа с отключенной проверкой безопасности.
4745 Изменена локальная группа с отключенной проверкой безопасности.
4746 Добавлен пользователь к локальной группе с отключенной проверкой безопасности.
4747 Удален пользователь из локальной группы с отключенной проверкой безопасности.
4748 Удалена локальная группа с отключенной проверкой безопасности.
4749 Создана глобальная группа с отключенной проверкой безопасности.
4750 Изменена глобальная группа с отключенной проверкой безопасности.
4751 Добавлен пользователь к глобальной группе с отключенной проверкой безопасности.
4752 Удален пользователь из глобальной группы с отключенной проверкой безопасности.
4753 Удалена глобальная группа с отключенной проверкой безопасности.
4759 Создана универсальная группа с отключенной проверкой безопасности.
4760 Изменена универсальная группа с отключенной проверкой безопасности.
4761 Член добавлен к универсальной группы с отключенной проверкой безопасности.
4762 Удален пользователь из универсальной группы с отключенной проверкой безопасности.
Другие события управления учетными записями
ИДЕНТИФИКАТОР Сообщение
4739 Изменена политика домена.
4782 Хэш пароля учетной записи доступа к нему.
4793 Был вызван API проверку политики паролей.
Управление группой безопасности
ИДЕНТИФИКАТОР Сообщение
4727 Создана глобальная группа с включенной безопасностью.
4728 Добавлен пользователь к глобальной группе с включенной безопасностью.
4729 Удален пользователь из глобальной группы с включенной безопасностью.
4730 Удалена глобальная группа с включенной безопасностью.
4731 Создана локальная группа с включенной безопасностью.
4732 Добавлен пользователь в локальную группу с включенной безопасностью.
4733 Удален пользователь из локальной группы с включенной безопасностью.
4734 Удалена локальная группа с включенной безопасностью.
4735 Изменена локальная группа с включенной безопасностью.
4737 Изменена глобальная группа с включенной безопасностью.
4754 Создана универсальная группа с включенной безопасностью.
4755 Изменена универсальная группа с включенной безопасностью.
4756 Добавлен пользователь к универсальной группе с включенной безопасностью.
4757 Удален пользователь из универсальной группы с включенной безопасностью.
4758 Удалена универсальная группа с включенной безопасностью.
4764 Изменен тип группы.

Управление учетными записями пользователей
ИДЕНТИФИКАТОР Сообщение
4720 Учетная запись пользователя создана.
4722 Учетная запись пользователя включена.
4723 Изменен пароль учетной записи.
4724 Сброс пароля пользователя.
4725 Учетная запись пользователя отключена.
4726 Учетная запись пользователя удалена.
4738 Изменена учетная запись пользователя.
4740 Учетная запись пользователя заблокирована.
4765 Журнал SID был добавлен к учетной записи.
4766 Не удалось добавить журнал SID учетной записи.
4767 Учетная запись пользователя была разблокирована.
4780 Список управления Доступом был установлен на учетные записи, которые являются членами группы администраторов.
4781 Было изменено имя учетной записи.
4794 Была предпринята попытка задать режим восстановления служб каталогов.
5376 Диспетчер учетных данных: учетные данные были сохранены.
5377 Диспетчер учетных данных: учетные данные были восстановлены из резервной копии.

Другие события
ИДЕНТИФИКАТОР Сообщение
1102 Очищен журнал безопасности
4624 Успешный вход в систему
4625 Не удачный вход в систему

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

Рис.5 Настраиваем аудит папки с общим доступом

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

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

Рис.6 Доступные настройки Advanced Audit Policy Configuration
Активация аудита управления учетными записями пользователей позволит отслеживать: создание, изменение, удаление, блокировку, включение и прочие настройки учетных записей, в том числе пароль и разрешения. Посмотрим, как она работает на практике — выбираем подкатегорию User Account Management и активируем. Команда для auditpol выглядит так:
> auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable > gpudate

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

Рис.7 Фиксация изменения политики системой аудита

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

Рис.8 При создании новой учетной записи система аудита Windows Server 2008 генерирует несколько событий

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

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

Рис. 9 Настройка фильтра событий в консоли Event Viewer

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

Рис.10 Создание задачи в консоли Event Viewer

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

Рис.11 Система аудита Windows Server 2008 только выдает старое и новое значение атрибута, не предоставляя средств для удобного отката

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

Рис.12 Чтобы не потерять старые события безопасности, следует увеличить размер журнала и включить архивацию

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

***
Данная статья является частью «Полного руководства по аудиту Active Directory в Windows Server 2008 R2» [PDF]. Вы можете скачать его по данной ссылке, заполнив небольшую форму.

В этой статье автор осуществил описание централизованной системы мониторинга событий безопасности для Windows Server 2008.

Андрей А. Бирюков

Чтение журналов событий является неотъемлемой частью работы любого администратора безопасности. Сетевое оборудование, операционные системы и практически все бизнес приложения осуществляют журналирование событий безопасности, таких как, удачный/неудачный вход в систему, запуск/остановка системы, обращение к закрытому порту для межсетевых экранов и другие события. Однако при наличии в сети даже десяти серверов, чтение журналов событий на каждом из них становится довольно трудоемкой задачей, требующей затраты большой части рабочего времени. Для того, чтобы автоматизировать процесс обработки журналов событий, например в части поиска попыток неудачного входа в систему, существует множество различных решений. Для Unix систем существует множество бесплатных сценариев на Перл, позволяющих осуществлять автоматический поиск заданного события в журнале и реакцию на данное событие, например отправку почтового сообщения администратору. Для Windows есть множество коммерческих продуктов, таких как ArcSight, Symantec Information Manager или Tivoli Security Operations Manager, которые умеют не только собирать события от различных источников, но и проверять данные события на соответствие различным моделям угроз (например подбор пароля или DDoS атака), реагировать на события, строить отчеты и многое другое. Но эти мощные средства мониторинга стоят очень недешево и в нынешних непростых экономических условиях многим организациям просто не по карману.

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

Как и многие другие функции Windows 2008 журналы событий были существенно переделаны и дополнены новыми возможностями. По определению Майкрософт [1] событие это любое значительное проявление в операционной системе или приложении, требующее отслеживания информации. Событие не всегда негативно, поскольку успешный вход в сеть, успешная передача сообщений, или репликация данных также могут генерировать события в Windows. В каждом журнале с его событиями связаны общие свойства.

Level (уровень) – Это свойство определяет важность события.

Date and Time (дата и время) – Это свойство содержит информацию о дате и времени возникновения события.

Source (источник) – Это свойство указывает источник события: приложение, удаленный доступ, служба и так далее.

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

Task Category (Категория задачи) – Это свойство определяет категорию события. Например Security или System. .
Итак, мы разобрались с тем, что представляет из себя событие в журнале Windows Event Log. Теперь нам необходимо сначала настроить аудит событий информационной безопасности. Далее будем предполагать, что у нас используется домен Active Directory и все сервера входят в этот домен.

Для настройки аудита необходимо зайти на контроллер домена и открыть редактор групповых политик Start->Administrative Tools->Group Policy Management. Далее выбираем домен и нажав правую кнопку мыши указываем Create a GPO in this domain… Вообще, для включения аудита можно воспользоваться политиками домена по умолчанию, но лучше создать отдельную политику с соответствующим названием, так как это упрощает администрирование. Далее в новой политике идем в Computer Configuration-> Windows Settings -> Security Settings -> Local Policies -> Audit Policy. Откроется список возможных параметров настройки аудита. Включать все подряд параметры нет особого смысла, так как в таком случае журнал событий наполнится огромным количеством малоинформативных сообщений. Рекомендую следующий набор параметров:

Категория аудита	Тип аудита	Примечание
Audit account logon events	No auditing
Audit account management	success/failure
Audit directory service access	No auditing
Audit logon events	success/failure
Audit object access	No auditing	включить, только если необходимо отслеживать доступ к определенным объектам (например, каталогам на диске).
Audit policy change	success/failure
Audit privilege use	success/failure
Audit process tracking	No auditing
Audit system events	success/failure

Теперь мы настроили аудит в нашем домене. Открыв журнал событий Security можно убедиться в том, какое количество событий сыпется в него ежесекундно. Для того, чтобы не нагружать контроллеры домена и другие сервера задачами по обработке событий мы должны сначала переслать события безопасности на выделенный сервер, на котором и будет осуществляться автоматическая обработка всех полученных событий. Данный выделенный сервер также должен работать под управлением операционной системы Windows Server 2008 и входить в домен Active Directory. Для пересылки событий нам необходимо воспользоваться Subscriptions, подписками на события.

Подписки на события

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

winrm quickconfig

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

winrm quickconfig

После этого, выполните на нем же следующую команду:

wecutil qc

При необходимости, вы можете изменять параметры оптимизации доставки событий. Например, вы можете изменить параметр Minimize Bandwidth (минимизация пропускной способности) для удаленных серверов, с ненадежным каналом связи.

Теперь необходимо собственно создать подписку, указав события, которые должны извлекаться из логов серверов источников. Для этого на собирающем сервере запустите утилиту просмотра событий с учетной записью, обладающей административными привилегиями. Затем щелкните на папке Subscriptions в дереве консоли и выберите команду Create Subscription (Создать подписку). В поле Subscription Name нужно указать имя подписки. При необходимости в поле Description можно привести описание. Затем, в поле Destination Log (журнал назначения) выберите файл журнала, в котором будут храниться собранные события. По умолчанию эти события будут храниться в журнале перенаправленных событий в папке Windows Logs дерева консоли. После этого, щелкните на кнопке Select Computers, чтобы выбрать исходные сервера, которые будут перенаправлять события. Как уже упоминалось ранее, данные сервера должны находиться в домене. Затем выберите события, нажав на кнопке Select Events. Сконфигурируйте журналы и типы событий, предназначенные для сбора. Щелкните ОК чтобы сохранить подписку.

Журналы

Теперь зайдем на выделенный сервер сбора событий и рассмотрим типы журналов, появившиеся в Windows Server 2008. В папке журналов Windows Logs находятся как традиционные журналы безопасности, приложений и системы, так и два новых журнала – Setup (настройка) и Forwarded Events (Пересланные события). Первые три типа событий уже присутствовали в предыдущих версиях системы, поэтому о них рассказывать нет смысла. А о последних двух следует рассказать подробнее. Журнал Setup фиксирует информацию, связанную с установкой приложений, ролями сервера и их характеристиками. Так, например, сообщения о добавлении на сервере роли DHCP будет отражены в этом журнале. В журнале Forwarded Events собираются сообщения, присланные с других машин в сети.

Папка Applications and Services Logs (журналы приложений и служб) представляют собой новый способ логической организации, представления и сохранения событий, связанных с конкретным приложением, компонентом или службой Windows вместо использовавшейся ранее, регистрации событий, которые оказывают влияние на всю систему. Эти журналы включают четыре подтипа: Admin (события, предназначенные для конечных пользователей и администраторов), Operational (Рабочий журнал событий, также предназначенный для администраторов), Analytic (журнал позволяет отслеживать цепочку возникновения проблемы и часто содержит большое количество записанных событий), Debug (используется для отладки приложений). По умолчанию журналы Analytic и Debug скрыты и отключены. Для того, чтобы их просмотреть, щелкните правой кнопкой мыши на папке Applications and Services Logs, а затем в контекстном меню выберите пункт View, Show Analytic and Debug Logs.

Рисунок 1.
Настройка Debug

Фильтры

Настраиваемые представления – это специальные фильтры, созданные либо автоматически системой Windows 2008, во время добавления в систему новых ролей сервера или приложений, таких как Directory Certificate Services (Службы сертификатов каталогов), сервер DHCP, либо администраторами вручную. Для администраторов одной из важнейших функций при работе с журналами событий является возможность создавать фильтры, позволяющие просматривать только интересующие события, чтобы можно было быстро диагностировать и устранять проблемы в системе. В качестве примера, рассмотрим папку Custom Views в навигационной панели утилиты просмотра событий. Если в этой папке щелкнуть правой кнопкой мыши по Administrative Events и затем выбрать Properties, то после нажатия Edit Filter, можно увидеть как информация из журнала событий преобразуется в набор отфильтрованных событий. Настраиваемые представления оснастки Administrative Events фиксируют все критические события, а события ошибок и предупреждений фиксируются для всех журналов событий (в отличие от предыдущих версий Windows). Таким образом, с помощью данного фильтра администратор может обращаться к единственному источнику для быстрой проверки потенциальных проблем, присутствующих в системе. Это средство может пригодиться при обработке событий, приходящих с серверов источников событий.

Созданные настраиваемые представления можно экпортировать в XML-файл для последующего распространения на другие машины.

Реагируем на события

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

В качестве примера настроим отправку сообщения администратору в случае неудачного входа пользователя в систему (Обратите внимание на то, что теперь это событие имеет другой ID 4625, отличный от использовавшегося в Windows 2003 ID 529).

Для этого необходимо зайти в журнал событий Event Viewer, открыть раздел Windows Logs, затем Security, выбрать нужное событие, нажать правую кнопку мыши, и указать Attach Task To This Event… (прикрепить задачу к этому событию).

Рисунок 2.
Настройка ответной реакции на событие

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

Рисунок 3.
Свойства задач

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

В закладке Triggers, вы можете добавлять или изменять условия выполнения задачи. В Actions вы можете добавлять различные действия. В закладке Conditions прописаны условия, при которых выполняется задача. В Settings можно прописать, какие действия должны быть выполнены при различных условиях. Например, что нужно делать в случае, если такая задача уже выполняется. Наконец, в закладке History вы можете наблюдать все события, которые вызвали выполнение задачи.

Немного о построении отчетов

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

Итак, нам нужно осуществить выборку событий из журнала. Делать мы это будем с помощью средств PowerShell.

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

get-eventLog -LogName Security -Newest 100 | Where-Object { $_.EventID —
eq 4625 }

Еще один пример. Узнаем, сколько пользователей осуществляло вход в систему в нерабочее время. Код события Success Logon – 4624.

get-eventlog security | where
{$_.EventId —eq 4624 -and
($_.TimeGenerated.TimeOfDay
-gt ’20:00:00′ -or
$_.TimeGenerated.TimeOfDay
-lt ’08:00:00′ )}

В завершении, узнаем, сколько удачных входов систему было осуществлено пользователем administrator.

get-eventLog -LogName Security | Where-Object { $_.message -match ‘administrator’ -AND $_.EventID -eq 4624 }

Здесь приведены только простейшие сценарии работы с журналом событий в Windows Server 2008. При необходимости на их основе можно построить более сложные запросы для релшения соответствующих задач информационной безопасности.

Заключение

В этой статье мы рассмотрели построение системы мониторинга событий информационной безопасности с помощью штатных средств Windoiws Server 2008. С помощью описанных инструментов можно существенно автоматизировать процесс мониторинга событий безопасности.

Использованная литература

1. Р. Моримото, М. Ноэл, О. Драуби Microsoft Windows Server 2008. Полное руководство.

Мне очень понравилась новая возможность по работе с журналами событий в Windows 2008/7/Vista, называемая Event Log forwarding (subscription — или подписка), которая основана на технологии WinRM. Данная функция позволяет вам получить все события со всех журналов с множества серверов без использования сторонних продуктов и настраивается все это в течении всего пары минут. Возможно, именно эта технология позволит вам отказаться от столь любимых многими системными администраторами Kiwi Syslog Viewer и Splunk.

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

winrm quickconfig
По умолчанию сервер-коллектор логов не может просто собирать информацию из журналов событий источников, вам придется добавить учетную запись компьютера-коллектора в локальные администраторы на все сервера-источники логов (в том случае, если сервер-источник работает под управлением 2008 R2, то достаточно добавить учетку коллектора в группу Event Log Readers)

Теперь мы должны создать подписки (Subscriptions) на сервер коллектор. Для чего зайдите на него, откройте консоль MMC Event Viewer, щелкните правой кнопкой мыши по Subscriptions и выберите Create Subscription:

Здесь вы можете выбрать несколько различных настроек.

При каждом добавлении коллектора, неплохо было бы проверить подключение:

Далее вы должны настроить фильтр, указав какие типы событий вы хотите получать (например, Errors и Warnings), также можно собирать события по конкретным номерам Event ID или по словам в описании события. Есть один нюанс: не выбирайте слишком много типов событий в одну подписку, анализировать этот журнал можно будет бесконечно :).

Расширенные настройки (Advanced settings) могут понадобиться, если вы хотите использовать нестандартный порт для WinRM, или захотите работать по протоколу HTTPS, или же оптимизировать сьор логов по медленным каналам WAN.

После нажатия OK подписка будет создана. Здесь вы можете щелкнуть правой кнопкой мыши по подписке и получить статус выполнения (Runtime Status), или перезапустить ее (Retry) если предыдущий запуск был неудачным. Обратите внимание, что даже если ваша подписка имеет зеленый значок, в процедуре сбора логов могут быть ошибки. Поэтому всегда проверяйте Runtime Status.

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

Конфигурацию можно посмотреть на вкладке Properties -> Subscriptions.

В том случае, если сбор логов не работает, сначала на сервере-источнике логов удостоверьтесь, что локальный файрвол настроен корректно и разрешает трафик WinRM.

Один раз, когда я добавил учетную запись сервера-коллектора в группу Event Log Readers, но не добавил ее локальные админы, была такая ошибка;

[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:46:22. Code (0×5): <f:ProviderFault provider=”Event Forwarding Plugin” path=”%systemroot%system32wevtfwd.dll” xmlns:f=”http://schemas.microsoft.com/wbem/wsman/1/wsmanfault”><t:ProviderError xmlns:t=”http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog”>Windows Event Forward Plugin failed to read events.</t:ProviderError></f:ProviderFault> Next retry time: 2010-09-28 16:51:22.

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

[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:43:18. Code (0×7A): The data area passed to a system call is too small. Next retry time: 2010-09-28 16:48:18.

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

Совет. Для автоматического уведомления администратора о появлении определенного события в журнале Windows можно настроить триггер планировщика задач. Подробность в статье: Мониторинг и оповещение о событиях в журналах Windows

Как посмотреть логи windows

Как открыть в просмотр событий

Так же есть логи windows для более специфических служб, например DHCP или DNS. Просмотр событий сечет все :).

Фильтрация в просмотре событий

Вас попросят указать уровень событий:

Критическое
Ошибка
Предупреждение
Сведения
Подробности

Посмотреть логи windows PowerShell

В итоге вы получите список логов журнала Система

Тоже самое можно делать и для других журналов например Приложения

небольшой список абревиатур

Код события — EventID
Компьютер — MachineName
Порядковый номер события — Data, Index
Категория задач — Category
Код категории — CategoryNumber
Уровень — EntryType
Сообщение события — Message
Источник — Source
Дата генерации события — ReplacementString, InstanceID, TimeGenerated
Дата записи события — TimeWritten
Пользователь — UserName
Сайт — Site
Подразделение — Conteiner

Если нужно вывести более подробно, то заменим Format-Table на Format-List

Как видите формат уже более читабельный.

Так же можно пофильтровать журналы например показать последние 20 сообщений

Или выдать список сообщение позднее 1 ноября 2014

Дополнительные продукты

Так же вы можете автоматизировать сбор событий, через такие инструменты как:

Комплекс мониторинга Zabbix
Через пересылку событий средствами Windows на сервер коллектор
Через комплекс аудита Netwrix
Если у вас есть SCOM, то он может агрегировать любые логи Windows платформ
Любые DLP системы

Удаленный просмотр логов

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

Вот пример фильтрации по событию 19.

Указываем имя другого компьютера, в моем примере это будет SVT2019S01

Источник

Централизованный Event Log в Windows 2008 Server

На коллекторе логов в командной строке с правами администратора запустите следующую команду, которая запустит службу Windows Event Collector Service, измените тип ее запуска в автоматический (Automatically — Delayed Start) и включите канал ForwardedEvents, если он был отключен.
wecutil qc
На каждом из источников нужно активировать WinRM:
winrm quickconfig
По умолчанию сервер-коллектор логов не может просто собирать информацию из журналов событий источников, вам придется добавить учетную запись компьютера-коллектора в локальные администраторы на все сервера-источники логов (в том случае, если сервер-источник работает под управлением 2008 R2, то достаточно добавить учетку коллектора в группу Event Log Readers)

Здесь вы можете выбрать несколько различных настроек.

При каждом добавлении коллектора, неплохо было бы проверить подключение:

Конфигурацию можно посмотреть на вкладке Properties -> Subscriptions.

[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:46:22. Code (0×5): Windows Event Forward Plugin failed to read events. Next retry time: 2010-09-28 16:51:22.

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

[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:43:18. Code (0×7A): The data area passed to a system call is too small. Next retry time: 2010-09-28 16:48:18.

Источник

Просмотр и анализ логов RDP подключений в Windows

В этой статье мы рассмотрим, особенности аудита / анализа логов RDP подключений в Windows. Как правило, описанные методы могут пригодиться при расследовании различных инцидентов на терминальных / RDS серверах Windows, когда от системного администратора требуется предоставить информацию: какие пользователи входили на RDS сервер, когда авторизовался и завершил сеанс конкретный пользователь, откуда / с какого устройства (имя или IP адрес) подключался RDP-пользователь. Я думаю, эта информация будет полезна как для администраторов корпоративных RDS ферм, так и владельцам RDP серверов в интернете (Windows VPS как оказалось довольно популярны).

Как и другие события, логи RDP подключения в Windows хранятся в журналах событий. Откройте консоль журнала событий (Event Viewer). Есть несколько различных журналов, в которых можно найти информацию, касающуюся RDP подключения.

В журналах Windows содержится большое количество информации, но быстро найти нужное событие бывает довольно сложно. Когда пользователь удаленно подключается к RDS серверу или удаленному столу (RDP) в журналах Windows генерируется много событий. Мы рассмотрим журналы и события на основных этапах RDP подключения, которые могут быть интересны администратору:

Network Connection
Authentication
Logon
Session Disconnect/Reconnect
Logoff

Network Connection: – установление сетевого подключение к серверу от RDP клиента пользователя. Событие с EventID – 1149 (Remote Desktop Services: User authentication succeeded). Наличие этого события не свидетельствует об успешной аутентификации пользователя. Этот журнал находится в разделе Applications and Services Logs -> Microsoft -> Windows -> Terminal-Services-RemoteConnectionManager -> Operational. Включите фильтр по данному событию (ПКМ по журналу-> Filter Current Log -> EventId 1149).

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

Authentication: – успешная или неуспешная аутентификация пользователя на сервере. Журнал Windows -> Security. Соответственно нас могут интересовать события с EventID – 4624 (успешная аутентификация — An account was successfully logged on) или 4625 (ошибка аутентификации — An account failed to log on). Обратите внимание на значение LogonType в событии. При входе через терминальную службу RDP — LogonType = 10 или 3. Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.

При этом имя пользователя содержится в описании события в поле Account Name, имя компьютера в Workstation Name, а имя пользователя в Source Network Address.

Вы можете получить список событий успешных авторизаций по RDP (событие 4624) с помощью такой команды PowerShell.

Get-EventLog security -after (Get-date -hour 0 -minute 0 -second 0) | ? <$_.eventid -eq 4624 -and $_.Message -match ‘logon type:s+(10)s’>| Out-GridView

Logon: – RDP вход в систему, событие появляющееся после успешной аутентификации пользователя. Событие с EventID – 21 (Remote Desktop Services: Session logon succeeded). Этот журнал находится в разделе Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational. Как вы видите здесь можно узнать идентификатор RDP сессии для пользователя — Session ID.

Событие с EventID – 21 (Remote Desktop Services: Shell start notification received) означает успешный запуск оболочки Explorer (появление окна рабочего стола в RDP сессии).

Session Disconnect/Reconnect – события отключения / переподключения к сессии имеют разные коды в зависимости от того, что вызвало отключение пользователя (отключение по неактивности, выбор пункта Disconnect в сессии, завершение RDP сессии другим пользователем или администратором и т.д.). Эти события находятся в разделе журналов Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational. Рассмотрим RDP события, которые могут быть интересными:

Событие с EventID – 4778 в журнале Windows -> Security (A session was reconnected to a Window Station). Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID).

Событие с EventID 4799 в журнале Windows -> Security (A session was disconnected from a Window Station). Отключение от RDP сеанса.

Logoff: – выход пользователя из системы. При этом в журнале Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational фиксируется событие с EventID 23 (Remote Desktop Services: Session logoff succeeded).

При этом в журнале Security нужно смотреть событие EventID 4634 (An account was logged off).

Событие Event 9009 (The Desktop Window Manager has exited with code ( ) в журнале System говорит о том, что пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен.

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

Иногда бывает удобно с логами в таблице Excel, в этом случае вы можете выгрузить любой журнал Windows в текстовый файл и импортировать в Excel. Экспорт журнала можно выполнить из консоли Event Viewer (конечно, при условии что логи не очищены) или через командную строку:

WEVTUtil query-events Security > c:pssecurity_log.txt

get-winevent -logname «Microsoft-Windows-TerminalServices-LocalSessionManager/Operational» | Export-Csv c:psrdp-log.txt -Encoding UTF8

Список текущих RDP сессий на сервере можно вывести командой:

Команда возвращает как идентификатор сессии (ID), имя пользователя (USERNAME)и состояние (Active/Disconnect). Эту команду удобна использовать, когда нужно определить ID RDP сессии пользователя при теневом подключении.

Список запущенных процессов в конкретной RDP сессии (указывается ID сессии):

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

Источник

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

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

Еще одно важное место, где можно найти логи, – это папка Windows, где хранятся файлы журналов событий. Стандартный путь для них – C:\Windows\System32\winevt\Logs. Здесь вы найдете файлы с расширением .evtx, содержащие информацию о событиях, происходящих на сервере. Обратите внимание, что для доступа к этой папке нужны права администратора.

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

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

Содержание

Системные логи на Windows Server 2008
Аутентификационные логи на Windows Server 2008
Журналы безопасности на Windows Server 2008
Использование логов для отслеживания ошибок на Windows Server 2008
Конфигурирование и мониторинг логов на windows server 2008

Системные логи на Windows Server 2008

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

Для доступа к системным логам на Windows Server 2008 необходимо выполнить следующие действия:

Открыть «Панель управления» и выбрать «Администрирование».
В разделе «Администрирование» выбрать «Просмотр событий».
В открывшемся окне «Просмотр событий» выбрать «Журналы Windows».
В разделе «Журналы Windows» можно увидеть список различных системных логов, таких как «Система», «Приложение», «Безопасность» и т. д.
Для просмотра содержимого определенного системного лога следует выбрать его из списка.
В правой части окна появится список событий, где можно увидеть детали каждого события, такие как дата и время, источник события и описание.

Системные логи на Windows Server 2008 позволяют отслеживать различные проблемы и ошибки, а также анализировать их для улучшения стабильности и безопасности сервера.

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

Аутентификационные логи на Windows Server 2008

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

Аутентификационные логи на Windows Server 2008 хранятся в Event Viewer, который предоставляет централизованный доступ к журналам событий. Для открытия Event Viewer необходимо выполнить следующие шаги:

Откройте «Панель управления» и выберите «Администрирование».
Дважды щелкните «Журнал событий».
Выберите «Журналы Windows» и затем «Безопасность».

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

Нажмите правой кнопкой мыши на «Безопасность» и выберите «Фильтр текущего журнала».
В открывшемся окне выберите «Только следующие типы событий» и поставьте галочку напротив «Аудит учетных записей».
Нажмите «ОК».

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

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

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

Аутентификационные логи на Windows Server 2008 являются важным инструментом для анализа безопасности системы. Они позволяют отслеживать успешные и неудачные попытки аутентификации пользователей на сервере, что повышает общую безопасность вашей сети.

Журналы безопасности на Windows Server 2008

Windows Server 2008 включает три основных журнала безопасности:

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

Для просмотра и анализа журналов безопасности на Windows Server 2008 можно использовать инструмент «Журнал событий». Доступ к журналам безопасности можно получить следующим образом:

Запустите «Журнал событий» через меню «Пуск» или выполнив команду eventvwr.msc через командную строку.
Выберите журнал безопасности, журнал аудита безопасности или журнал регистрации событий в левой панели «Журналы Windows».
Просматривайте и анализируйте события, фильтруйте их по типу, источнику или времени с помощью инструментов «Журнала событий».

Записи в журналах безопасности содержат важную информацию для обеспечения безопасности Windows Server 2008. Регулярное мониторинг и анализ этих журналов помогут обнаружить потенциальные проблемы и события безопасности, а также принять меры по их устранению и предотвращению новых инцидентов.

Использование логов для отслеживания ошибок на Windows Server 2008

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

Основные логи, доступные на Windows Server 2008, включают следующие:

1. Системный журнал событий (Event Viewer): это основной механизм регистрации событий и ошибок в операционной системе. Журнал событий содержит информацию об ошибках, предупреждениях, успешных операциях и других событиях, связанных с работой сервера.

2. Журнал приложений (Application Log): этот журнал содержит информацию об ошибках и событиях, связанных с приложениями, установленными на сервере.

3. Журнал служб (Services Log): в этом журнале регистрируются события, связанные с работой системных служб, таких как службы печати, службы базы данных и другие.

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

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

Для доступа к логам на Windows Server 2008 необходимо открыть «Системный журнал событий» (Event Viewer) через «Меню Пуск» -> «Сервер» -> «Инструменты» -> «Системный журнал событий». Здесь можно выбрать нужный журнал и просмотреть детальную информацию о каждом событии.

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

Конфигурирование и мониторинг логов на windows server 2008

Для конфигурирования и мониторинга логов на Windows Server 2008 существует несколько подходов:

Использование средств операционной системы, таких как «Журнал событий» и «Учетные записи службы».
Использование сторонних программных решений для сбора и анализа логов, таких как Microsoft System Center Operations Manager или Splunk.

1. Использование средств операционной системы:

Журнал событий: Windows Server 2008 включает инструмент «Журнал событий», который позволяет просматривать логи системы, приложений, безопасности и служб. Он предоставляет информацию о различных событиях, ошибках, предупреждениях и успешных операциях. Для доступа к журналу событий необходимо открыть MMC (Microsoft Management Console) и добавить в него соответствующий снимок.
Учетные записи службы: Windows Server 2008 также поддерживает механизм учетных записей службы, который позволяет отслеживать активности служб и выполнять аудит их действий. Для конфигурирования и просмотра учетных записей службы необходимо воспользоваться утилитой «Учетные записи службы» в контекстном меню службы в MMC.

2. Использование сторонних программных решений:

Microsoft System Center Operations Manager: это решение от Microsoft, которое предоставляет централизованный механизм сбора, анализа и мониторинга логов различных систем, включая Windows Server 2008. Оно позволяет упростить процесс управления логами и предоставляет графический интерфейс для анализа данных.
Splunk: это платформа для сбора и анализа данных, включая логи. С помощью Splunk можно настроить централизованное хранение логов и их мониторинг, а также выполнять анализ данных с помощью запросов и дашбордов.

Конфигурирование и мониторинг логов на Windows Server 2008 позволяет обеспечить надежность и стабильность работы сервера, а также своевременно реагировать на возникающие проблемы.

Источник

Андрей А. Бирюков

Level (уровень) – Это свойство определяет важность события.

Date and Time (дата и время) – Это свойство содержит информацию о дате и времени возникновения события.

Source (источник) – Это свойство указывает источник события: приложение, удаленный доступ, служба и так далее.

Категория аудита	Тип аудита	Примечание
Audit account logon events	No auditing
Audit account management	success/failure
Audit directory service access	No auditing
Audit logon events	success/failure
Audit object access	No auditing	включить, только если необходимо отслеживать доступ к определенным объектам (например, каталогам на диске).
Audit policy change	success/failure
Audit privilege use	success/failure
Audit process tracking	No auditing
Audit system events	success/failure

Подписки на события

winrm quickconfig

После этого, выполните на нем же следующую команду:

wecutil qc

Журналы

Рисунок 1.
Настройка Debug

Фильтры

Реагируем на события

Рисунок 2.
Настройка ответной реакции на событие

Рисунок 3.
Свойства задач

Немного о построении отчетов

Итак, нам нужно осуществить выборку событий из журнала. Делать мы это будем с помощью средств PowerShell.

get-eventLog -LogName Security -Newest 100 | Where-Object { $_.EventID —
eq 4625 }

get-eventlog security | where
{$_.EventId —eq 4624 -and
($_.TimeGenerated.TimeOfDay
-gt ’20:00:00′ -or
$_.TimeGenerated.TimeOfDay
-lt ’08:00:00′ )}

В завершении, узнаем, сколько удачных входов систему было осуществлено пользователем administrator.

get-eventLog -LogName Security | Where-Object { $_.message -match ‘administrator’ -AND $_.EventID -eq 4624 }

Заключение

Использованная литература

1. Р. Моримото, М. Ноэл, О. Драуби Microsoft Windows Server 2008. Полное руководство.

Источник

Просмотр системного журнала

Экспорт журнала

Просмотр системного журнала

Экспорт журнала

Как открыть в просмотр событий

Фильтрация в просмотре событий

Посмотреть логи windows PowerShell

Дополнительные продукты

Удаленный просмотр логов

Аудит доменных служб Active Directory в Windows Server 2008 R2

Аудит Active Directory штатными средствами

Таблица 1. Список событий аудита событий Active Directory в Windows Server 2008

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

<img decoding="async" src="https://pyatilistnik.org/wp-content/uploads/2016/02/pyatilistnik-3.png" />

Как посмотреть логи windows

Как открыть в просмотр событий

Фильтрация в просмотре событий

Посмотреть логи windows PowerShell

Дополнительные продукты

Удаленный просмотр логов

Централизованный Event Log в Windows 2008 Server

Просмотр и анализ логов RDP подключений в Windows

Системные логи на Windows Server 2008

Аутентификационные логи на Windows Server 2008

Журналы безопасности на Windows Server 2008

Использование логов для отслеживания ошибок на Windows Server 2008

Конфигурирование и мониторинг логов на windows server 2008