Какие уровни важности имеют события в журналах windows

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

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

В
соответствии с требованиями ФСТЭК к
уровню защиты 2А, к АС предъявляются
требования по регистрации и учету
запуска/завершения программ и процессов
(заданий, задач), поэтому максимальный
размер журнала следует установить с
запасом, чтобы обнаруживать ошибки или
иные системные события, а 7 дней –
достаточно для обнаружения нужного
системного события.

 Приложение
«Просмотр
событий»
можно открыть следующими способами:

• Нажмите
  на кнопку «Пуск»
  для открытия меню, откройте «Панель
  управления»,
  из списка компонентов панели управления
  выберите «Администрирование»
  и из списка административных компонентов
  стоит выбрать «Просмотр
  событий»;

• Воспользоваться
  комбинацией клавиш WIN+R для открытия
  диалога «Выполнить»
  (или
  запустить диалог из меню кнопки «Пуск»).
  В диалоговом окне «Выполнить»,
  в поле «Открыть»
  введите eventvwr.msc
  и нажмите на кнопку «ОК»;

Картинка с сайта: studfile.net

• Откройте
  «Консоль
  управления MMC».
  Для этого нажмите на кнопку «Пуск»,
  в поле поиска введите mmc,
  а затем нажмите на кнопку «Enter».
  Откроется пустая консоль MMC. В меню
  «Консоль»
  выберите команду «Добавить
  или удалить оснастку»
  или воспользуйтесь комбинацией клавиш
  Ctrl+M.
  В диалоге «Добавление
  и удаление оснасток»
  выберите оснастку «Просмотр
  событий»
  и нажмите на кнопку «Добавить».
  Затем нажмите на кнопку «Готово»,
  а после этого — кнопку «ОК»;

Стандартный
набор включает 3 журнала:

Приложение
– хранит важные события, связанные с
конкретным приложением. Например,
почтовый сервер сохраняет события,
относящиеся к пересылке почты, в том
числе события информационного хранилища,
почтовых ящиков и запущенных служб.

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

Система
– хранит события операционной системы
или ее компонентов, например неудачи
при запусках служб или инициализации
драйверов, общесистемные сообщения и
прочие сообщения, относящиеся к системе
в целом. 

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

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

Картинка с сайта: studfile.net

В поле
«Максимальный
размер журнала (КБ)»
установите требуемое значение при
помощи счетчика или установите вручную
без использования счетчика. В этом
случае значение будет округлено до
ближайшего числа, кратного 64 КБ, так как
размер файла журнала должен быть кратен
64 КБ и не может быть меньше 1024 КБ.

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

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

Не
переписывать события (очистить журнал
вручную)
– в этом случае журнал очищается вручную,
а не автоматически.

В
зависимости от версии операционной
системы доступны другие политики
хранения журнала.

Вывод:

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

Параметры
политики безопасности являются правилами,
устанавливаемыми администраторами на
компьютерах и других устройствах для
защиты ресурсов в сети или на устройствах.
Редактор локальной групповой политики
позволяет определять конфигурации
безопасности как часть объекта групповой
политики (GPO). GPO связывается с контейнерами
Active Directory, такими как сайты, домены или
организационные подразделения, что
позволяет управлять настройками
безопасности для нескольких устройств
с любого устройства, подключенного к
домену. Политики параметров безопасности
являются частью общей системы безопасности
и используются для обеспечения
безопасности контроллеров доменов,
серверов, клиентов и других ресурсов в
организации.

Параметры
безопасности могут управлять:

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

• Ресурсы,
  доступ к которые разрешены пользователям.

• Запись
  действий пользователя или группы в
  журнале событий.

• Членство
  в группе.

Согласно
нормативному документу «Средства
вычислительной техники. Защита от
несанкционированного доступа к
информации. Показатели защищенности
от несанкционированного доступа к
информации» можно выделить семь классов
защищенности средств вычислительной
техники (СВТ) от НСД к информации. Самый
высокий класс — первый. 

Вторая
группа включат АС, в которых пользователи
имеют одинаковые полномочия доступа
ко всей информации, обрабатываемой
и/или хранимой в АС на носителях различного
уровня конфиденциальности. Группа
содержит два класса – 2Б и 2А.

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

Отслеживание событий — основа безопасности систем

Когда на компьютере происходит какое-либо значимое событие, операционная система записывает это событие в журнал. Входом в журналы служит Event Viewer (eventvwr.exe). Большинство администраторов открывают Event Viewer, только когда пытаются решить какую-нибудь проблему, и многие знакомые администраторы говорят мне, что используют Event Viewer только на серверах. Оба подхода ошибочны, потому что периодическая проверка системных журналов часто позволяет выявлять неполадки на ранней стадии, до того как они превратятся в серьезную проблему. Уметь пользоваться Event Viewer очень важно, поэтому я хочу предложить читателям краткий обзор по этой теме и представить свои способы работы с Event Viewer.

Общие сведения

Event Viewer открывается через меню Administrative Tools (если это меню добавлено в Programs) или через приложение Administrative Tools панели управления. Консоль программы Event Viewer содержит список доступных журналов. На компьютерах Windows по умолчанию имеются следующие журналы:

• Application (журнал приложе-ний) — содержит события, записываемые программами. Приложение определяет типы записываемых событий и язык сообщения.
• Security (журнал безопасности) — содержит события, относящиеся к безопасности компьютера, такие как попытки регистрации в системе или манипуляции с файлами.
• System (журнал системы) — содержит события, записываемые компонентами Windows.

В системах Windows Server 2003 и Windows 2000 Server в зависимости от роли сервера можно также использовать следующие журналы:

• Directory Service — содержит события, имеющие отношение к Active Directory (AD), и доступен только на контроллерах домена (DC).
• File Replication Service — содержит события, записываемые во время репликации между DC, и доступен только на DC.
• DNS Server — содержит события, относящиеся к разрешению имен DNS, и доступен только на серверах DNS.

Event Viewer отображает типы событий, каждое из которых имеет собственный уровень важности и собственную пиктограмму в журнале. Например:

• Error (ошибка) — сигнализирует об актуальной проблеме, которая может касаться потери функциональности, такой как нарушение корректного запуска служб и драйверов.
• Warning (предупреждение) — указывает на проблему, которая впоследствии может стать серьезной, если не обращать внимания на предупреждение. Предупреждения сугубо информативны и не свидетельствуют о наличии проблемы в настоящем или обязательном ее появлении в будущем.
• Success Audit (аудит успехов) — это событие, имеющее отношение к системе безопасности, которое произошло и записывается потому, что система или администратор включили аудит данного события.
• Failure Audit (аудит отказов) — это событие, имеющее отношение к системе безопасности, которое не произошло, но запись о нем делается потому, что система или администратор включили аудит данного события.

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

Настройка Event Viewer

Системные журналы начинают функционировать автоматически при запуске операционной системы. Размеры журнальных файлов ограничены, и система записывает события, удаляя старые записи в соответствии с выбором параметров журнала. Чтобы просмотреть или изменить конфигурацию, нужно щелкнуть правой кнопкой на имени журнала в списке Event Viewer и выбрать в раскрывающемся меню пункт Properties. Должно появиться соответствующее диалоговое окно свойств, как показано на экране 1.

Менять конфигурацию следует в зависимости от ситуации. Если вы не вносите существенных изменений в конфигурацию журнала или не видите необходимости в аудите событий, то работа настроек по умолчанию должна вас устроить. Настройка по умолчанию для максимального размера файла журнала составляет 512 Кбайт, и когда журнал заполнен, система автоматически заменяет старые записи новыми через 7 дней. Однако, если в систему вносятся существенные изменения или вводится в действие подробный аудит, журналы, скорее всего, начнут заполняться многочисленными записями. Если журнал оказывается заполненным и не содержит записей, хранящихся более 7 дней, утилите Event Viewer будет нечего удалить, чтобы освободить место для новых записей, и система прекратит записывать события. В этой ситуации нужно увеличить размер журнального файла или выполнить настройку журнала на затирание старых записей по мере необходимости (вариант Overwrite events — as needed).

Фильтры

Когда администратор исследует журнал, чтобы решить какую-либо проблему, или проверяет реакцию компьютера на существенное изменение конфигурации, он может ускорить этот процесс, избавившись от не имеющих отношения к делу записей в панели Details. Диалоговое окно Properties каждого журнала имеет вкладку Filter, с помощью которой выбираются типы отображаемых событий. Например, вы не хотите видеть информационные записи от определенных компьютеров или вы хотите видеть только события, произошедшие в течение недели после внесения системных изменений. Следует просто нужным образом выбрать фильтры (или отменить выбор). Помните, что фильтры влияют только на то, что отображается в окне; система продолжает записывать в журнал события тех типов, которые были отфильтрованы. Например, если есть основания полагать, что возникла угроза системе безопасности в виде вторжения извне, можно оставить для отображения события только тех типов, быстрый взгляд на которые позволяет обнаружить аномалии в регистрации, такие как события с ID 675 и 681, соответствующие неудачным попыткам аутентификации, или событие с ID 644, означающее блокировку учетной записи вследствие многократного некорректного ввода пароля.

Сортировка журнала

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

Общее событие Userenv имеет ID 1000 в журнале приложений и его описание гласит, что Windows не смогла определить имя пользователя или компьютера. Это означает, что конфигурация TCP/IP компьютера для обращения к DNS-серверу установлена некорректно. Администраторы сплошь и рядом используют неправильные адреса при настройке DNS на клиентских компьютерах; я часто нахожу IP-адрес шлюза в поле для адреса DNS. Проверку журнала компьютера-«обидчика» со своей рабочей станции обычно выполнить проще, чем идти к клиентскому компьютеру и проверять настройки TCP/IP.

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

Очистка журнала

Любой журнал можно очистить, чтобы освободить дополнительное место для записей. Если выбрана настройка Do not overwrite events (clear log manually) —«Не затирать события (очистка журнала вручную)», необходимо периодически чистить журнал.

Чтобы очистить журнал, следует щелкнуть правой кнопкой на названии журнала в списке консоли Event Viewer и выбрать пункт Clear all Events («Стереть все события»). Система спрашивает, нужно ли сохранить журнал перед тем, как очистить его. Если в журнале есть записи, которые могли бы пригодиться в будущем (например, при длительном отслеживании проблемы), можно выполнить архивацию содержимого журнала.

Архивация журнала

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

Чтобы создать архивную копию журнала, нужно щелкнуть правой кнопкой мыши по названию журнала в консоли и выбрать в меню Save Log File As («Сохранить файл журнала как…»). По умолчанию Windows сохраняет файл в папке Administrative Tools, расположенной в папке C:documentssettingsusernamestart menuprograms. Можно указать другую папку или создать отдельную папку для хранения архивных копий журналов. Я обычно присваиваю журналам имя в формате имя_журнала-дата (например, apps-dec012003). Windows добавляет расширение .evt.

Архивные копии журналов являются отдельными файлами на жестком диске, но открывать их можно только через программу просмотра событий Event Viewer. Для этого следует выбрать пункт Open Log File («Открыть файл журнала») в меню Action (или щелкнуть правой кнопкой по любому объекту в консоли и выбрать Open Log File). В диалоговом окне открытия файла требуется выбрать нужный архив, указать тип журнала (т. е. Application, Security) в меню со списком Log Type, затем щелкнуть Open.

Чтобы удалить архив из консоли, следует щелкнуть правой кнопкой по его названию в списке и выбрать Delete. Это действие не удаляет файл с жесткого диска — только из консоли. Удаление архивной копии журнала с жесткого диска выполняется так же, как и удаление любого другого файла.

Просмотр событий на удаленном компьютере

Чтобы облегчить себе задачу, администратор может со своей рабочей станции просматривать журналы удаленных компьютеров, на которых у него есть административные привилегии. На удаленном компьютере должна быть установлена Windows 2003, Windows XP, Windows 2000 Professional, Windows 2000 Server, Windows NT Server или NT Workstation.

На локальной консоли просмотра событий нужно щелкнуть правой кнопкой Event Viewer (Local) и выбрать Connect to another computer («Подключиться к другому компьютеру»). Следует ввести имя удаленного компьютера, с которым предстоит работать, или щелкнуть Browse, чтобы открыть диалоговое окно, показанное на экране 2, затем выбрать компьютер. Кроме того, если имя удаленного компьютера известно, нет необходимости вводить его в виде имени UNC. Вид консоли Event Viewer меняется таким образом, что отображает имя UNC удаленного компьютера. На удаленном компьютере можно производить те же действия, что и на локальном Event Viewer. Чтобы вернуться на локальный компьютер, следует щелкнуть правой кнопкой Event Viewer (имя компьютера), выбрать Connect to another computer, а затем Local computer.

Что искать при просмотре событий

Большинство реальных и потенциальных проблем проявляют себя посредством записи событий в тот или иной журнал. Когда вы видите запись с пометкой Error или Warning, будьте внимательны. Поищите информацию об этом событии в Microsoft Knowledge Base или на Web-сайте Windows & .NET Magazine. Если медлить с просмотром журналов, вы упустите возможность предотвратить проблему. Приведу пример. Во время периодических просмотров журналов на всех компьютерах своей сети я обнаруживаю запись в системном журнале, которая показана на экране 3. Никаких видимых признаков неполадок на компьютере не было.

Я быстро выполняю резервное копирование данных компьютера и запускаю программу Chkdsk, которая перемещает файлы (это были системные файлы) из испорченной области и помечает ее как испорченную, чтобы предотвратить дальнейшую запись в эту часть диска. Затем я начинаю ежедневно проверять системный журнал в течение нескольких недель и, только убедившись, что никаких новых сообщений об ошибках не появляется, возвращаюсь к еженедельному просмотру Event Viewer. Увидев дополнительные сообщения об ошибках, я бы заменила диск. Если бы я периодически не проверяла журналы компьютера, диск мог бы продолжать разваливаться и резервное копирование оказалось бы бесполезным из-за порчи файлов.

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

Следует также просматривать все события в журнале безопасности. Этот журнал будет оставаться пустым до тех пор, пока вы не установите аудит событий безопасности. Если аудит событий безопасности установлен, ищите значительные события в зависимости от настроек аудита. Журнал безопасности — единственный журнал в Event Viewer, для просмотра которого необходимы административные полномочия. Более подробную информацию об аудите событий безопасности можно найти в статье «Мониторинг событий безопасности» (Windows & .NET Magazine/RE, №7 за 2003 год, и на Web-странице http://www.osp.ru/win2000/2003/07/019.htm).

Как остановить запись нежелательных событий

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

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

Можно изменить выбор событий печати, записываемых в системный журнал, в папке Printers компьютера (в Windows 2003 и XP она называется Printers and Faxes). Выберите File, Server Properties и перейдите на вкладку Advanced, показанную на экране 4. Можно просто отменить выбор событий, которые вы не хотите регистрировать в журнале.

Возьмите за правило

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

Кэти Ивенс (kivens@win2000mag.com) — редактор Windows & .NET Magazine. Является соавтором более 40 книг по компьютерной тематике, включая «Windows 2000: The Complete Reference»

Время на прочтение5 мин

Количество просмотров78K

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

Картинка с сайта: habr.com

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

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

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

Картинка с сайта: habr.com

Перебор пользователей и групп (события 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

• 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 утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.

Картинка с сайта: habr.com

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но 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

Картинка с сайта: habr.com

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

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

Картинка с сайта: habr.com

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

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

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

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

Журнал событий Windows Server — это инструмент, без которого администраторы не смогут контролировать состояние целой системы. В статье рассказали, как посмотреть журнал событий Windows Server и разобрали методы работы с логами сервера.

Журнал событий Windows Server — это инструмент, который помогает администраторам контролировать состояние системы, выявлять проблемы и диагностировать ошибки. Этот компонент является важной частью управления сервером, позволяя отслеживать действия пользователей, работу приложений и состояние оборудования.

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

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

Ранее в блоге рассказали, как установить Windows Server.

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

Windows Server организует данные в логах по категориям, что делает их использование интуитивно понятным. Вот ключевые категории и их значение:

• Системные события. Эта категория фиксирует все события, связанные с работой самого Windows Server, включая запуск и остановку служб, обновления системы, ошибки оборудования или драйверов. Например, если служба DNS перестала работать, системный журнал покажет причину сбоя.
• Приложения. Этот раздел хранит события, связанные с установленным на сервере ПО. Логи из этой категории помогают понять, почему приложение, например, SQL Server или «1С», работает некорректно.
• Безопасность. Категория «Безопасность» содержит информацию о попытках входа в систему, изменении учётных записей или прав доступа. Это важнейший раздел для отслеживания несанкционированного доступа и построения аудита безопасности.

Эти три категории — основа, но в Windows Server 2019 появились дополнительные инструменты, такие как каналы «Перенаправленные события», которые нужны для агрегирования событий с нескольких серверов для централизованного анализа.

Как журнал событий помогает в работе

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

Другой пример — анализ неудачных попыток входа в систему. Если кто-то неоднократно вводит неправильный пароль для учётной записи администратора, события в разделе «Безопасность» покажут IP-адрес источника и время каждой попытки. Эти данные помогут быстро идентифицировать возможную атаку.

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

В ИТ-инфраструктуре отказоустойчивость и безопасность являются приоритетами, и журнал событий Windows Server создаёт фундамент для их достижения. Он не только позволяет восстанавливать систему после сбоя, но и помогает предупреждать проблемы, выявляя аномалии в работе служб или аппаратного обеспечения.

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

Возможности журнала событий

Windows Server можно интегрировать с системой уведомлений и автоматизации. Например, используя PowerShell, администратор может настроить автоматическое создание предупреждений, если в журнале появляется определённое событие. Допустим, если сервер регистрирует высокую загрузку процессора, система может отправить уведомление на электронную почту или создать задачу в системе мониторинга.

Каналы событий (Event Channels) — это специализированные журналы для отдельных служб или приложений, например, событий, связанных только с Hyper-V или Windows Firewall. Работа с этими каналами даёт возможность получать точечную информацию, избегая перегруженности основного журнала.

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

Услуга аренды VPS/VDS с опцией «Всё включено» у хостера AdminVPS избавит вас от необходимости администрирования — её на себя возьмут наши специалисты.

Инструкция по работе с журналом событий Windows Server

Для просмотра журнала событий в Windows Server используется встроенное приложение «Просмотр событий». Оно доступно во всех версиях сервера, включая Windows Server 2019.

Шаг 1. Откройте меню «Пуск» на сервере и найдите приложение «Просмотр событий». Вы также можете запустить его с помощью команды eventvwr через окно «Выполнить» (сочетание клавиш Win+R).

Картинка с сайта: adminvps.ru

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

Картинка с сайта: adminvps.ru

Шаг 2. Для анализа выберите интересующий вас раздел и откройте его. Здесь вы найдёте список событий с такими параметрами, как дата и время, уровень серьёзности (ошибка, предупреждение или информация), источник и идентификатор события.

Если вы работаете с сервером Windows Server 2019, вы можете воспользоваться дополнительными функциями фильтрации, чтобы быстрее найти интересующую информацию. Например, для поиска конкретной ошибки можно использовать параметры «Источник» или «Идентификатор события». Это значительно упрощает работу с большими объёмами данных.

Логи сервера Windows и их использование

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

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

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

Автоматизация сбора данных с помощью syslog

Если вы администрируете крупную сеть серверов или несколько экземпляров Windows Server, использование syslog поможет значительно упростить управление логами. Хотя Windows Server по умолчанию не использует протокол syslog, сторонние утилиты, такие как NxLog, позволяют настроить интеграцию.

Картинка с сайта: adminvps.ru

Протокол syslog необходим для централизованного сбора данных с разных серверов и устройств, что особенно полезно в распределённых системах. Вы можете настроить отправку событий из журнала Windows Server на syslog-сервер, где данные будут обработаны и визуализированы. Это ускоряет диагностику и позволяет оперативно реагировать на проблемы.

Типичные ошибки и как их исправить

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

Одной из наиболее частых проблем является переполнение журнала событий. В крупных системах с активным сетевым взаимодействием количество событий может быстро нарастать, что приводит к исчерпанию доступного пространства для хранения логов. Когда это происходит, система перестаёт записывать новые события, что создаёт риск упустить важную информацию, например, о сбое службы или попытке взлома. Чтобы избежать этого, администратор должен заранее настроить автоматическое удаление старых записей. В Windows Server это можно сделать через настройки журнала событий, выбрав опцию «Перезаписывать события». Альтернативным решением является увеличение максимального размера файла журнала, что позволит хранить больше записей перед началом перезаписи.

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

Кроме этих типичных случаев встречаются ошибки, связанные с повреждением файлов журнала событий. Это может произойти из-за сбоев в работе дисковой подсистемы или некорректного завершения работы сервера. При повреждении файлов логов система может перестать записывать новые события или выдавать ошибки при попытке открыть журнал. Для восстановления работы в таком случае рекомендуется очистить повреждённый журнал через консоль «Просмотр событий» или команду PowerShell Clear-EventLog. Однако перед этим важно создать резервную копию файла журнала, если это возможно, так как он может содержать ценные данные для анализа.

Также следует учитывать возможность пропуска важных событий из-за неправильной настройки фильтров. Например, администратор может случайно исключить из отображения определённые источники событий или уровни серьёзности. Это приводит к тому, что важные предупреждения остаются незамеченными. Чтобы исправить ситуацию, необходимо пересмотреть настройки фильтрации в «Просмотре событий» или использовать PowerShell для экспорта всех записей в отдельный файл и их последующего анализа.

Ещё одна ошибка — это проблемы с интеграцией журнала событий Windows Server с внешними системами мониторинга, такими как syslog. Если события из Windows Server не поступают на syslog-сервер, причиной может быть неправильная конфигурация отправки данных или проблемы с сетевым подключением. В таком случае важно проверить настройки программы-коннектора, например, NxLog или SolarWinds, и убедиться, что порты, используемые для передачи данных, открыты на брандмауэре.

Заключение

Журнал событий Windows Server — это незаменимый инструмент для диагностики и мониторинга, который позволяет поддерживать стабильную работу сервера.

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

Читайте в блоге:

• Автоматическая загрузка Windows Server: способы настройки
• Установка Windows Server: комплексный подход к сетевой инфраструктуре и защите данных
• Настройка DFS на Windows Server
• Устанавливаем бесплатный сертификат Let’s Encrypt на IIS с Windows Server 2016/2012 R2
• Популярные способы защиты VPS/VDS на Windows Server