Мониторинг журнала событий windows server

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

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

Не так давно, для успешного прохождения аудита на соответствие стандартам PCI DSS, потребовалось включить аудит событий Windows серверов и что самое главное — настроить отправку уведомлений о критичных событиях на E-mail. Для Linux серверов вопрос решается установкой и настройкой OSSEC (ну еще могут понадобиться syslog ws loganalyzer и auditd), для Windows Server 2012 R2 да еще и русской версии он не подошел (в последствии нам таки удалось его адекватно настроить, если будет интересно — смогу описать как). Так что решили искать другие способы…

Первым дело следует включить аудит всех необходимых операций (управление учетными записями и контроль целостности файлов) в доменной политике. И если с аудитом операций над объектами Active Directory все просто, то вот с аудитом файловых операций придется повозиться. Тут, как нельзя кстати, компания Netwrix (не сочтите за рекламу, — компания автор коммерческого софта для аудита) подготовила замечательную статью: «Настройка аудита файловых серверов: подробная инструкция и шпаргалка» (.pdf).

Но вернемся к нашим «костылям». После успешной активации аудита всех необходимых операций и обнаружения в журналах Windows интересующих нас событий, встал вопрос об их отправке на сервер мониторинга… Логично было бы воспользоваться встроенными инструментами («Attach Task To This Event» не самый информативный инструмент, зато «родной» для Windows), но тут всплывает первый любопытный и не приятный момент от Microsoft — «Send an email and Display a message are deprecated for from Windows Server 2012 and Windows 8».

Send an e-mail (deprecated)

…

Согласно рекомендациям от Microsoft, как замену встроенному «deprecated» функционалу решили использовать скрипты PowerShell для фильтрации журналов и отправки по E-mail, благо есть подробные инструкции:
«Аудит Active Directory средствами Powershell с оповещением об изменениях».
«Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell»
Но тут возникла сложность другого характера: приведенные выше скрипты отсылали на E-mail только заголовки (темы) событий, тело письма было пустым При всем при этом — если скрипт PowerShell запустить в PowerShell ISE «as Administrator», то приходит полное сообщение, как и было задумано!

пример скрипта отправки уведомления о событии ‘Заблокирован аккаунт’ — Event ID 4725:

$time =  (get-date) - (new-timespan -min 60)

$Subject = “Заблокирован аккаунт" 
$Theme = “Только что был заблокирован аккаунт” 
$Server = “smtp.server.local” 
$From = “AD@domain.local” 
$To = “support@domain.local” 
$encoding = [System.Text.Encoding]::UTF8

#Выбирается последнее произошедшее событие с таким ID.
$TimeSpan = new-TimeSpan -sec 1
foreach($event in $events)
{
    $PrevEvent = $Event.Запись
    $PrevEvent = $PrevEvent - 1
    $TimeEvent = $Event.TimeCreated
    $TimeEventEnd = $TimeEvent+$TimeSpan
    $TimeEventStart = $TimeEvent- (new-timespan -sec 1)

$Body=Get-WinEvent -maxevents 1 -FilterHashtable @{LogName=”Security”;ID=4725;StartTime=$TimeEventStart;} | Select TimeCreated,@{n=”Account Name”;e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq “TargetUserName”} |%{$_.’#text’}}},@{n=”Computer”;e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq “TargetDomainName”}| %{$_.’#text’}}} 
$body = $body -replace "@{" -replace "}" -replace "=", ": " -replace ";","`n" -replace "TimeCreated","Время события" -replace "^","`n" 
$BodyM = $Body
}
Send-MailMessage -From $From -To $To -SmtpServer $server -Body “$BodyM `n$Theme” -Subject $Subject -Encoding $encoding

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

Мы же перешли к другому способу (вдохновила вот эта статья: «Мониторинг и оповещение о событиях в журналах Windows: триггеры событий» и выручила эта утилита: sendEmail):

Добавляем в Task Scheduler задание по интересующему нас событию (прямо из журнала «Security» -> «Attach Task To This Event…«
В Actions указываем запуск скрипта, в котором с помощью утилиты wevtutil делаем выборку из журнала и сохраняем результат в файл.
пример скрипта — выборка событий с Event ID 4726
```
del c:\Audit\query_ID4726.txt
wevtutil qe Security /q:"*[System[(EventID=4726)]]" /f:text /rd:true /c:1 > c:\Audit\query_ID4726.txt
```
Вторым действием, с помощью утилиты sendEmail отправляем сохраненный файл по назначению:
пример аргументов для команды запуска sendEmail:
```
-f audit_AD@domain.local -s smtp.domain.local:25 -t support@domain.local -m "AD User Account Management - Event ID 426 - Account was Deleted" -a C:\Audit\query_ID4726.txt
```

В результате должны получать что-то типа этого:

P.S. Спасибо всем авторам источников, указанных ранее!

Источник

Как посмотреть ошибки системы в Windows Server 2019

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

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

После этого как открылось новое окно мы можем посмотреть логи системы — нажимаем на «Журналы Windows» и выбираем «Система». Тут мы можем посмотреть все логи, которые связаны с самой системой.

Как сохранить логи системы

Если вы хотите посмотреть логи на другом ПК, вы можете их сохранить. Нажимаем на «Сохранить все события как», выбираем где мы хотим сохранить лог и нажимаем на «Сохранить».

Сохранить лог вы можете также в текстовом формате, если вам будет удобнее смотреть логи именно так.

Источник

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

Возможность запуска задач при наступлении определенных событий Windows основана на тесной интеграции Task Scheduler и Event Viewer. Назначить задание планировщика на любое событие Windows можно прямо из консоли журнала просмотр события (Event Viewer). В качестве реакции на произошедшее событие планировщик может запустить скрипт или отправить почтовое уведомление администратору (или любому другому пользователю).

Допустим, наша задача – настроить оповестить администратора безопасности о блокировке учетной записи пользователя в Active Directory.

Событие блокировки учетной записи в AD отмечается на контроллере домена в журнале Security (Безопасность). Event ID события блокировки – 4740. Открываем консоль журнала событий Windows (Event Viewer — eventvwr.msc) и ищем интересующее нас событие. Щелкаем по нему ПКМ и выбираем пункт Attach Task To This Event (Прикрепить задачу к этому событию).

Запускается мастер создания нового задания планировщика. Мастер предложит указать имя задания. Оно генерируется автоматически — Security_Microsoft-Windows-Security-Auditing_4740 и нас устраивает.

На следующем шаге указаны вид журнала событий, источник и Event ID события (все поля заполняются автоматически и не доступны для редактирования на этом шаге).

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

Start a program – запуск программы (скрипта)
Send an e-mail – отправка почтового уведомления
Display a message – отображение сообщения в консоли

Нас интересует оповещение по Email. Указываем отправителя, получателя, адрес SMTP сервера, тему и текст письма.

На последнем шаге мастера можно посмотреть получившиеся настройки триггера. В результате в планировщике задач появится новое задание, привязанное к нашему событию. Откроем консоль Task Scheduler (в Administrative Tools). Созданное задание можно найти в разделе Task Scheduler Library -> Event Viewer Tasks.

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

Совет. Если нужно один триггер привязать к множеству EventID, их нужно указывать через запятую.

Триггер является активным. Теперь при блокировке любой учетной записи AD – на указанный email будет отправляться письмо с уведомлением.

Примечание. Аналогичный функционал в Windows Server 2003 и более ранних версиях Windows реализовывался с помощью консольной утилиты — eventtriggers.exe. Данная утилита также позволяла отслеживать события в журналах системы и «вешать» на определенные события триггеры. Для нашего пример, когда к событию 4740 нужно привязать выполнение скрипта vbs или powershell, который отправляет письмо на ящик администратора, команда может быть такой:

eventtriggers /create /TR “Lock Account” /TK “C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe c:\script\SendEmail.ps1″ /L Security /EID 4740

Такое уведомление не очень информативно, и для просмотра подробной информации о событии приходится открывать журнал Event Viewer. Попробуем прикрепить к письму данные из журнала событий. В этом нам поможет утилита wevtutil, позволяющая выгрузить из журналов Windows информацию о любом событии. Так, чтобы получить данные о последнем событии с кодом 4740 из журнала Security, нужно выполнить:

wevtutil qe Security /q:"*[System[(EventID=4740)]]" /f:text /rd:true /c:1

Создадим скрипт (query.cmd) из двух строчек: первая удаляет старый файл с логом, вторая – выгружает из журнала последнее событие и сохраняет его в файл лога:

del c:\script\query.txt wevtutil qe Security /q:"*[System[(EventID=4740)]]" /f:text /rd:true /c:1 > c:\script\query.txt

Осталось еще раз открыть настройки созданного ранее триггера в журнале планировщика задач. На вкладке Actions добавим новое действие – запуск скрипта query.cmd. Затем нужно изменить порядок выполнения действий, перенесем его вверх списка с помощью стрелок справа (скрипт должен выполняться первым).

Далее отредактируем второе действие – отправку электронного письма, выбрав в качестве вложения к письму файл c:\script\query.txt .

Примечание. В нашем примере, чтобы задание заработало корректно, нужно запускать его с повышенными привилегиями. Для этого в его настройках нужно установить галку Run with highest privileges.

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

Совет. Использование функционала триггеров событий Window для оповещения администратора о критичных проблемах на серверах не является полноценной заменой системы мониторинга, такой как System Center Operations Manager и Zenoss. Однако как простое встроенное средство мониторинга и оповещения для малого бизнеса, не требующего вложений во внедрение и обучение персонала, вкупе с возможностью консолидации логов сразу с нескольких серверов (Forwarded Events), оно вполне юзабельно.

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

Источник

How to check Windows server logs (Windows Event Log Types. Microsoft Windows Server is an operating system that provides network administrators with a collection of enterprise level management features. Accordingly, some of these features include data storage, applications, security, network, and hardware management.

Similarly, Microsoft’s collection of desktop operating systems allow you to view event logs through a set of Administrative Tools. So, Windows Server offers similar features but in a more enterprise capacity. After all, event logging and tracing are important parts of running servers. Thus, this guide will explore how you can find Windows server logs and how to interpret the information from them.

Shall we start with How to check Windows server logs (Windows Event Log Types).

Understanding The Windows Event Log

If your servers are positioned in a fairly medium or large company, they may be collecting thousands of events hourly. Especially if you have not configured your Windows Server Event Logs. Basically, the event log is separated into channels. The four most important are:

System: Features events related to system software and/or hardware. For instance, driver failures or installations.
Application: Contains events logged by (mostly) Windows applications.
Security: Contains events pertaining to the security of the Windows system. This may include failed login attempts.
Setup: Features system related event logs for setups and updates. For instance, Windows updates.

Besides, Microsoft also has channels for its features such as BitLocker, AppLocker, and Windows Firewall. Additionally, the event log may also contain channels for third party software. As a result, Windows Server allows you to collect all your events from separate servers and combine them in a central location. Alternatively, you could feed event logs to a Security Information and Event Management (SIEM) solution that isn’t Microsoft based.

While there is a lot of information collected by the events log by default, it is the auditing feature in Windows that determines what information gets collected and logged.

How to Check Windows Server Logs

There are two main graphical ways you can access the Windows Server event log:

Event Viewer Microsoft Management Console (MMC)
Windows Admin Center (WAC)

The WAC isn’t as fully-featured as the Event Viewer. Nonetheless, you can access the Event Viewer from the server or client machine(s) using Windows Administrative Tools. Alternatively, you can use the Windows Server Manager to run the Event Viewer.

Launching The Windows Server Manager

Again, there are quite a few ways you can check server event logs from Windows Server. One of the best ways is using Windows Server Manager which acts as a central hub for our server. By default, Windows Server Manager is a Windows Server start up application. This means that it’s one of the first applications to run when you launch Windows Server. However, you can also run the Server Manager from the start menu or search bar:

Open the Start Menu (WinKey).
Search through the applications list for Server Manager or type it into the search field.
Double click on the Server Manager item.

How to Launch The Event Viewer

Once again, the best way to check Windows Event Logs is through the Event Viewer. You can launch it from the Server Manager using the following steps:

Click on the top Tools menu button.
Search the list for Event Viewer.
Double click on it to open it .

Using The Roles and Server Groups Section To Check Events

You may have noticed that the Events Viewer isn’t the only place you can view events from the Server Manager. As seen, the Server Manager also allows you to view roles and server specific events on the dashboard. You can view File and Storage, Local Server, and All Servers events by using the various widgets in the dashboard.

Clicking on one of the Events options in these widgets will launch a screen similar to this one:

This is called the Events Detail View. It gives you a list of filtration options including:

Event Security Levels: Filter events according to their severity.
Event Sources: Origin of an event (applications, services, etc).
Servers: The machine the event occurred on.
Time Period: The hours and/or minutes the event occurred in between.
Event IDs: Each event has a unique ID. You can filter events using these IDs.

Again, we’ll stick to using the Event Viewer because it’s the most fully featured option.

Navigating Through the Event Viewer

One of the most unfortunate facts about Windows Server’s event management system is its lack of built in alerts or notifications. However, you can apply a script or run a program that is triggered when a particular event enters one of your custom views.

Nevertheless, you should be able to see the four channels we previously mentioned under the Windows Logs folder. You can use the above image as a reference. Ultimately, this is where you will check your Windows Servers Log.

You will notice that the above image features an additional channel called Forwarded Events. This channel is used by servers that have been set up as event collectors. It allows you to see events from other servers.

If you scan through the Event Viewer tree, you should notice a top folder labeled Applications and Services Log. It contains event channels related to installed server software and hardware.

Event Log Levels

When checking Windows Server Logs through the Event Viewer, you’re bound to run into a plethora of event types. They include:

Information: Logs information event. For instance, when a task is completed successfully or when the system informs the user of something.
Warning: Used to log system and software warnings. They don’t demand immediate action. However, they may warn you of a future problem, like disk space running out.
Error: Indicates a system, software, or hardware issue that requires immediate action. For instance, a driver failing to load upon start up.
Success Audit (Security log): This signifies the success of an audited security event. For instance, a user successfully logging onto the server or client.
Failure Audit (Security log): This signifies the success of an audited security event. For instance, a user failing to log onto a server or client.

It is time to explain How to Check Windows Server Logs (Windows Event Log Types).

Event Log Types

In this section of the guide, you’ll explore the event types (Event Sources) you should be monitoring. Ultimately, keeping track of important logs requires you to use event sources to identify vulnerabilities in your system. Certainly, you’ll be able to find the event source by using the Source tab for each event.

Alternatively, you can create a custom view by:

Right clicking on any one of the folders or objects on the right tree panel eg. Windows Logs.
Next, select Create Custom View… from the context menu.

If you execute the above steps correctly, you should be presented with this screen.

You can then use either the filer screen or XML screen to create an event source-based view.

1. Application Whitelisting

As shown, you should have a list of approved services and applications. Anything that doesn’t appear on your whitelist should be flagged as suspicious. Consequently, there are two systems built into the latest versions of Windows for application control:

AppLocker
Microsoft Defender Device Guard

You can either use these systems individually or in tandem. Regardless, DeviceGuard is considered the most difficult to configure but also the most secure. As such, admins may elect to use it over AppLocker. AppLocker is easy to bypass by compromising the Windows NT Kernel. Comparatively, the Device Guard is much more robust and much more secure against exploits against the Windows NT Kernel.

However, if it’s your first time working with application control software, it is recommended that you use AppLocker with the Event Viewer.

What Should You Do When You Encounter This Event?

Your event source is dependent on the application control solution you’ve chosen to use for black and whitelisting. For instance, any event related to the AppLocker will use AppLocker as a source. Likewise, if you use Microsoft Defender, Device Guard events will use DeviceGuard as a source. It’s important that you investigate any suspicious events related to these sources. Correspondingly, bad actors may be trying to whitelist apps that you’ve previously blacklisted because of the vulnerabilities they impose on your system. You should:

Check your app control configurations.
Consult with a network security specialist to track down the person that may have changed your rules.
Change all necessary Passovers.

2. Randomly Cleared Events and Audit Logs

If you notice that some of your events have been randomly cleared, then your network/system has most likely been compromised by bad actors. Especially, these bad actors may be trying to hide malicious activity by purging events. At this time it’s important to remember that event logs are not typically cleared during normal operations. As such, if you notice the following event logs, you should be worried:

What Should You Do When You Encounter This Event?

Nevertheless, collecting logs centrally on a server that only you (or your network’s admin) can access is the best way to protect yourself against cleared event logs. This will allow you to view deleted or cleared event logs without restoring your server from a backup. You can then confirm if a bad actor compromised your system.

3.Account Usage

A variety of users will log in to your server(s). You can use these event types and IDs to detect unauthorized account usage and remote desktop logins. Some users can use Windows Remote Desktop to configure systems that they should not be allowed to. Equally, users should not be logging into your server using Remote Desktop when there are other tools such as Power Share, Windows Admin Console (WAC), etc.

You (or your network administrator) should especially be paying attention to privileged Active Directory groups such as the domain and enterprise admin groups. Furthermore, you must make sure that your system isn’t adding or removing users from these groups without permission.

Account lockouts are important events that should be monitored. They can often signify brute force attempts by malicious actors. These bad actors may be trying to guess a user’s password. Nevertheless, the following are the events that fall under this category:

What Should You Do When You Encounter This Event?

When you encounter this event, it’s important to connect all related users and/or groups. First step is to investigate why a specific user was locked out. Was it indeed a bad actor or have they forgotten their password? Once you’ve fully ascertained the reasons for the user’s failed login attempts, you can act accordingly.

4. Group Policy Errors

Evidently, you use Group Policy Objects (GPOs) to configure and enforce your organization’s security policy. Thus, if the group policies you’ve set aren’t enforced, then your system may be compromised. In most cases, it may be the result of a bad actor attempting to prevent your system from enforcing certain policies so they can enact their own.

However, it can also be something benign or innocent. For instance, the group policy client may be failing for some reason. Regardless, it’s always important to monitor your group policies as they may indicate something nefarious occurring on your network..

What Should You Do When You Encounter This Event?

Your group policies can be viewed in the GroupPolicy channel (Microsoft > Windows > GroupPolicy). It allows you to see if your system is applying Group Policy Objects (GPOs) successfully. Once you encounter any errors in this view, you should first determine why the error is concerning. It may not be the result of a breach or attempted exploit. One of your machines may be struggling with low system resources. Make sure to check if your GroupPolicies are operational.

5. Software and Service Installation

By the same token, you may be regularly installing and updating software and services on your server. However, installations occur daily. Of course, this depends on the server’s usage and age. Freshly commissioned servers may require daily installations, backups, and updates. Nonetheless, if you see suspicious software and service-related events, then it may be a sign of malicious activity carried out by a bad actor.

What Should You Do When You Encounter This Event?

Look out for keywords in events such as “Installed”, “New”, “Removed”, “Update”, and ”Updated”. You can find the above keywords by using a search or a custom view of your creation. You must investigate every suspicious occurrence you find and review logs to ensure that every software/service installation and removal has been approved.

6. Windows Updates

As with the desktop version of the operating system, Windows Server also requires regular updates. These updates are imperative because they often contain important system patches. If these Windows updates fail, it may leave your system vulnerable.

Consequently, you must check the WindowUpdateClient and Servicing event sources from the System channel. Alternatively, you can create a custom view filtered according to these event sources. Nevertheless, you must validate that there are no errors or information events that indicate Windows Update failures.

What Should You Do When You Encounter This Event?

The first thing you must do is investigate why your Windows Updates are being interrupted. It may not be a result of a malicious. Your server(s) may be low on system resources or your system may be experiencing a network error. As you investigate the source of the issue, you must ensure that your Windows Server operating system is up to date. You can manually download and install Windows Server Cumulative Updates.

7. Windows Firewall

The Windows Firewall is enabled by default. It protects servers and clients against malicious activities from your internal trusted network. Henceforth, it’s just as important as any firewall you have segregated in your network. Thus, you must check that your firewall is it’s working, and if the status and/or rules have been updated or changed, etc.

Event sources to look out for include: Firewall, Firewall-Client, Firewall-CPL, Firewall-Driver, and Firewall-Service. Again, you can create a custom view with these event sources.

What Should You Do When You Encounter This Event?

Again, you must determine the source of the issue. Is someone trying to reconfigure your firewall? You should consider using third party firewalls for your internal system. There are other steps you can take to improve your overall cybersecurity.

8. Application Crashes

Application crashes are fairly common. However, they may indicate a malicious attack where a bad actor is forcing processes and services to shut down. Therefore, you or your system administrator must check the event logs for instances of Blue Screen of Death (BSOD), Windows Error Reporting (WER), Application Crashes, and Hang events.

What Should You Do When You Encounter This Event?

Again, you should determine the source of the crash, freeze, etc. Are the affected applications important to the security of your network? Which machines are they specifically related to? This will help you decide if you must investigate further or change the posture of your network’s security.

Thank you for reading How to Check Windows Server Logs (Windows Event Log Types Explained). We shall conclude.

How to Check Windows Server Logs (Windows Event Log Types) Conclusion

Источник

В этой статье автор осуществил описание централизованной системы мониторинга событий безопасности для 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. Полное руководство.

Источник