Журнал ошибок windows server 2008 r2

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

6. Получаем 10 последних ошибок журнала событий
7. Сбрасываем контроль доступа к папке
8. Вычисляем время работы сервера (uptime)
9. Получаем информацию о Service Pack

Оригинал статьи здесь. Заинтересованных приглашаем под кат.

6. Получаем 10 последних ошибок журнала событий

Каждое утро, вы возможно просматриваете журналы событий в поисках 10 последних ошибок в системном журнале событий на одном или нескольких компьютерах. Упростить эту задачу можно с помощью командлета Get-EventLog.
Нужно уточнить имя журнала событий и тип записи. Типичная команда для конкретной задачи выглядит так:

В нашем случае взят журнал событий ‘system’ и тип записи ‘Error”. Если мы не уточняем имя компьютера, информация собирается с локальной машины.
Обратите внимание на сообщения (Колонка Message), которые выведены не полностью. Давайте немного изменим команду, что бы мы могли их видеть полностью.

Мы просто передали выход предыдущей команды в ft, сокращение для Format-Table и задали отображения для таблицы следующих свойств: Timewritten, Source, EventID и Message. Мы также добавили -wrap и -auto для более красивого отображения. -wrap активирует обтекание текстов, а -auto – автоматическое форматирование.
Как это выглядит:

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

Пример:

Обратите внимание, что элементы сгруппированы по источнику. Сначала идет EventLog, затем Microsoft-Windows-GroupPolicy. — More – указывает на завершения отображения, необходимо нажать любую клавишу для того, чтобы посмотреть дополнительную информацию.
Все эти Get-EventLog команды, которые были продемонстрировали, запущены на локальном компьютере. Теперь покажем, как это сделать на удаленной машине.
Например, мне необходимо посмотреть 5 последний ошибок на контроллерах домена в офисе в Чикаго (имена компьютеров chi-dc01 и chi-dc02). Предположим, что мне необходимо отсортировать и сгруппировать результаты по Machine Name. Я также хотел бы отобразить следующие свойства Timewritten, Source, EventID и Message. И снова добавляю -wrap, -auto и more “для красоты”.

Получаем на выходе.

В предыдущем посте, рассматривая задачу №5 (получение информации по свободному месту на дисках), мы рассматривали как можно сделать HTML отчет и выложить его на Интернет сервер; то же можно сделать и с данной задаче.

7. Сброс контроля доступа к папке

Примеров, когда NTFS права на папку настроены не так, как надо, множество. Если это случается, вы, возможно, захотите, спросить контроль доступа к этой папке. Это реализуется с помощью командлета Set-Acl (Set-ACL).
Самый просто подход – использовать Get-Acl для извлечения ACL (Access Control List) из “хорошей” папки и копировать его в проблематичную папку. Произведется замена имеющегося ACL. Хотя и можно создать ACL объект с нуля, первый метод (копирование) желателен, и сейчас я продемонстрирую почему.
Предположим, что имеется на компьютере CHI-FP01 папка sales и у этой папки есть “хорошая” копия ACL. Копируем ACL и сохраняем в переменную $acl.

Давайте взглянем на информацию в ACL:

Видите свойство Access справа? Фактически это другой объект. Чтобы посмотреть его содержимое, выполним команду:

Что внутри:

Как Вы видите, это записи контроля доступа. Если Вы хотите видеть только ссылки (identity references), чьи имена совпадают с “Sales”, то выполните следующую команду:

Теперь если мы используем ту же команду, чтобы посмотреть содержимое свойства Access, принадлежащего созданной папке chicagosales, мы ничего не получим. Обратите внимание на использование сокращений:

Одной из возможных причин, почему значения не выводятся, может быть некорректная выдача NTFS прав.
Очевидно, что решение этой проблемы – копировать “хороший” ACL в “плохой”. Но для начала нужно получить текущие NTFS права папки chicagosales и сохранить в XML файл. Это необходимо для восстановления ACL, если вдруг что-то пойдет не так (импортируем XML файл).

После того, как это сделано, запускаем команду Set-Acl для chicagosales, используя $acl, скопированную из хорошей папки.

Проверим, успешно ли осуществлена процедура: Используем ту же команду, которую мы использовали ранее для отображения ссылок на тех, чьи имена совпадают с “Sales”.

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

8. Получение информации о времени работы сервера (uptime)

Вашем руководству возможно будет интересно регулярно получать информацию о времени работы сервера. Используем для этого WMI класс Win32_OperatingSystem. Он выведет время работы. Возможен локальный и удаленный запуск команды. Свойство, которое нас интересует, LastBootUpTime. Но так как оно отображается в WMI формате, нам нужно будет конвертировать в более приемлемый формат.
Начнем с примера запуска локально под Windows 7.
Сначала сохраним результаты GetWmiObject в переменную $wmi.

В $wmi присутствует несколько свойств, с которыми мы будем работать, а именно CSName (имя компьютера) и LastBootUpTime.

LastBootUpTime отображается WMI формате, поэтому его нужно отконвертировать. Сохраним отконвертированное значение в переменную $boot.

Мы используем метод ConverToDateTime, который включен во все WMI объекты, которые вы получаете, когда запускаете GetWmiObject. Параметр, который вы передаете в этот метод — свойство LastBootUpTime WMI объекта $wmi.
Запросив информацию о $boot, вы получите следующее, что гораздо нагляднее предыдущего варианта LastBootUpTime:

Для определения времени работы машины, вычитываем $boot из текущих даты/времени, которые могут быть получены с помощью Get-Date.

Результат выводится как TimeSpan объект. Отконвертируем его в строку для более наглядного представления с помощью ToString().

Мы видим, что машина была запущена 2 дня 5 часов 46 минут и т.д.
А теперь все, что мы рассмотрели, запишем в виде функции под названием get-boot. Сначала посмотрим на нее полностью.

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

Затем мы используем фрагмент скрипта Process, где свойство “имя компьютера” передается в функцию. “$_” указывает, что имя компьютера задается как переменная. В противном случае имя компьютера как будет воспринято как параметр.

Включенное в фрагмент скрипта Process выражение GetWmiObject уточняет имя удаленного компьютера.

Здесь также будет несколько хеш-таблиц. Свойство CSName поменяем на Computername, так мы сможем получить более наглядное отображение. Свойство LastBoot представляет собой значение LastBootUpTime, отконвертированное с использование метода ConvertToDateTime(). И еще есть свойство Uptime, которое представляет собой TimeSpan объект, показывающий, как долго машина была запущена.

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

Как в случае с задачей 2 предыдущего поста (“Перезагрузка или выключение сервера”), Вы можете сохранить имена серверов в текстовый файл, обрабатывать те, которые пингуются и передавать их имена в функцию get-boot.

9. Получение информации о service pack

Получать информацию о service pack важно по ряду причин. Во-первых, вы можете быть в процессе установки обновления и вам важно нужно найти компьютеры с определённым SP. Во-вторых, вы можете осуществлять инвентаризацию или аудит ваших компьютеров, поэтому информация о SP вам будет нужна.
Для этого мы снова будет использовать WMI и класс Win32_Operating System. Обратите внимание на некоторые свойства: the ServicePackMajorVersion – целое число (1, 2 или 0); ServicePackMinorVersion и CSDVersion, которое выводит информацию в строку, например, “Service Pack 1”.
При работе нас интересуют в первую очередь свойства CSName (имя компьютера), Caption (ОС), CSDversion и ServicePackMajorVersion.
Типичное выражение выглядит следующим образом:

Как мы видим эта машина под Windows 7 не использует ни один SP, поэтому ServicePackMajorVersion равно 0, а CSDVersion пусто.
Создадим функцию Get-SP. В качестве параметра возьмем имя компьютера, по умолчанию совпадающее с именем локального компьютера.

И снова мы используем блок скрипта Process. Так что если имя компьютера передается, переменная $computername будет установлена в качестве передаваемого объекта. Основная часть функции – выражение класса Get-Wmiobject/Win32_operatingsystem.
Как и прежде, создадим пару хеш-таблиц. CSName переведем в ComputerName. Вместо свойства Caption используем Operating System. А вместо CSDVersion — SPName. Наконец, вместо ServicePackMajorVersion используем просто Version.

Вот пример функции, запущенной локально:

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

Можно видеть, что у CHI-DC02 отсутствует Service Pack 1, который только недавно был выпущен для Server 2008 R2. А это дает основания задуматься об обновлении Service Pack на этом компьютере.

Upd:
В посте приведен перевод статьи с портала petri.co.il
Top 10 Server 2008 Tasks done with PowerShell – Part 2

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

Чтение журналов событий является неотъемлемой частью работы любого администратора безопасности. Сетевое оборудование, операционные системы и практически все бизнес приложения осуществляют журналирование событий безопасности, таких как, удачный/неудачный вход в систему, запуск/остановка системы, обращение к закрытому порту для межсетевых экранов и другие события. Однако при наличии в сети даже десяти серверов, чтение журналов событий на каждом из них становится довольно трудоемкой задачей, требующей затраты большой части рабочего времени. Для того, чтобы автоматизировать процесс обработки журналов событий, например в части поиска попыток неудачного входа в систему, существует множество различных решений. Для 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. Откроется список возможных параметров настройки аудита. Включать все подряд параметры нет особого смысла, так как в таком случае журнал событий наполнится огромным количеством малоинформативных сообщений. Рекомендую следующий набор параметров:

Теперь мы настроили аудит в нашем домене. Открыв журнал событий 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. Полное руководство.