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

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

Ищете сервер с Windows? Выбирайте наши Windows VDS

Просмотр событий для проверки логов.

После нажатия комбинации “ Win+R и введите eventvwr.msc ” в любой системе Виндовс вы попадаете в просмотр событий. У вас откроется окно, где нужно развернуть Журналы Windows. В данном окне можно просмотреть все программы, которые открывались на ОС и, если была допущена ошибка, она также отобразится.

Аудит журнал поможет понять, что и кто и когда делал. Также отображается информация по запросам получения доступов.

В пункте Установка можно посмотреть логи ОС Виндовс, например, программы и обновления системы.

Система — наиболее важный журнал. С его помощью можно определить большинство ошибок ОС. К примеру, у вас появлялся синий экран. В данном журнале можно определить причину его появления.

Логи windows — для более специфических служб. Это могут быть DHCP или DNS.

Фильтрация событий.

С помощью Фильтра текущего журнала (раздел Действия) можно отфильтровать информацию, которую вы хотите просмотреть.

Обязательно нужно указать уровень Событий:

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

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

Просмотр PowerShell логов.

Открываем 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 января 2018 года, команда

Get-EventLog –LogName ‘System’ –After ‘1 января 2018’

Надеемся, данная статья поможет вам быстро и просто читать логи ОС Windows.

Желаем приятной работы!

Как установить свой образ на ВДС сервер с Виндовс, читайте в предыдущей статье.

Просмотр журнала приложений Windows (Windows 10) View the Windows application log (Windows 10)

Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions)

Когда для SQL Server SQL Server настроено использование журнала приложений Windows, каждый сеанс SQL Server SQL Server записывает новые события в этот журнал. SQL Server SQL Server is configured to use the Windows application log, each SQL Server SQL Server session writes new events to that log. В отличие от журнала ошибок SQL Server SQL Server , новый журнал приложений не создается заново каждый раз при запуске экземпляра SQL Server SQL Server . Unlike the SQL Server SQL Server error log, a new application log is not created each time you start an instance of SQL Server SQL Server .

Просмотр журнала приложений Windows View the Windows application log

На панели поиска введите средство просмотра событий, а затем выберите классическое приложение Просмотр событий. On the Search bar, type Event Viewer, and then select the Event Viewer desktop app.

В средстве просмотра событий откройте журналы приложений и служб. In Event Viewer, open the Applications and Services Logs.

События SQL Server SQL Server идентифицируются записью MSSQLSERVER в столбце Источник (именованные экземпляры обозначаются как MSSQL$ ). SQL Server SQL Server events are identified by the entry MSSQLSERVER (named instances are identified with MSSQL$ ) in the Source column. События агента SQL Server идентифицируются записью SQLSERVERAGENT (для именованных экземпляров сервера SQL Server SQL Server события агента SQL Server SQL Server идентифицируются при помощи SQLAgent$ ). SQL Server Agent events are identified by the entry SQLSERVERAGENT (for named instances of SQL Server SQL Server , SQL Server SQL Server Agent events are identified with SQLAgent$ ). События службы Microsoft Search идентифицируются записью Microsoft Search. Microsoft Search service events are identified by the entry Microsoft Search.

Чтобы просмотреть журнал с другого компьютера, щелкните правой кнопкой мыши элемент Просмотр событий (локальных) . To view the log of a different computer, right-click Event Viewer (local). Выберите пункт Подключение к другому компьютеру и заполните поля в диалоговом окне Выбор компьютера. Select Connect to another computer, and fill in the fields to complete the Select Computer dialog box.

Чтобы отображались только события SQL Server SQL Server , в меню Вид выберите пункт Фильтр. Optionally, to display only SQL Server SQL Server events, on the View menu, select Filter. В списке Источник событий выберите MSSQLSERVER. In the Event source list, select MSSQLSERVER. Чтобы просмотреть только события агента SQL Server SQL Server , в списке Источник события вместо этого выберите SQLSERVERAGENT . To view only SQL Server SQL Server Agent events, instead select SQLSERVERAGENT in the Event source list.

Чтобы просмотреть дополнительные сведения о событии, дважды щелкните событие. To view more information about an event, double-click the event.

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

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

Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

• Logon;
• Logoff;
• Account Lockout;
• Other Logon/Logoff Events.

Account Management

• User Account Management;
• Security Group Management.

Policy Change

• Audit Policy Change;
• Authentication Policy Change;
• Authorization Policy Change.

Системный монитор (Sysmon)

Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.