Сбор логов с серверов windows

Блог

Введение

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

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

С визуализацией данных из windows журналов проблем нет никаких. Winlogbeat из коробки умеет парсить логи и добавлять все необходимые метаданные. Со стороны logstash не нужны никакие фильтры. Принимаем все данные как есть с winlogbeat.

Централизованный сбор Windows Event Logs с помощью ELK (Elasticsearch — Logstash — Kibana)

Передо мной встала задача организовать сбор Windows Event Logs
в некое единое хранилище с удобным поиском/фильтрацией/возможно даже визуализацией. После некоторого поиска в интернете я натолкнулся на чудесный стек технологий от Elasticsearch.org — связка ELK
( Elasticsearch
— Logstash
— Kibana
). Все продукты являются freeware
и распространяются как в виде архива с программой, так и в виде пакетов deb
и rpm
.

Что такое ELK?

Elasticsearch

Elasticsearch — это поисковый сервер и хранилище документов основанное на Lucene
, использующее RESTful
интерфейс и JSON
-схему для документов.

Logstash

Logstash – это утилита для управления событиями и логами. Имеет богатый функционал для их получения, парсинга и перенаправления\хранения.

Kibana

Kibana – это веб-приложение для визуализации и поиска логов и прочих данных имеющих отметку времени.

В данной статье я постараюсь описать некий HOW TO для установки одного сервера на базе Ubuntu Server 14.04
, настройки на нем стека ELK
, а так же настройки клиента nxlog
для трансляции логов на сервер. Хочу однако отметить что данный стек технологий можно использовать гораздо шире. Какие логи вы будете пересылать, парсить, хранить и в последствии пользоваться поиском\визуализацией по ним зависит только от вашей фантазии. По использованию данных технологий есть множество вебинаров на сайте http://www.elasticsearch.org/videos/ .

Установка Ubuntu 14.04

Дабы не повторяться с установкой дистрибутива Ubuntu 14.04
приведу ссылку на статью моего коллеги по блогу, Алексея Максимова — Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 1. Установка ОС на ВМ Hyper-V Gen2 . Все действия по настройке можно проделать аналогичные, за исключением установки минимального UI и настройки второго сетевого интерфейса – его можно исключить на стадии создания виртуальной машины, ведь сервер будет находиться внутри периметра вашей сети.

Установка JAVA 7

Так как два из трех используемых продуктов написаны на JAVA нам придется его установить. Устанавливать будем Oracle Java 7
, так как Elasticsearch
рекомендует устанавливать именно его.

Добавляем Oracle Java PPA
в apt:

И устанавливаем последнюю стабильную версию Oracle Java 7
:

Проверить версию Java
можно набрав команду

Установка Elasticsearch

Хотя документация по Logstash
рекомендует использовать Elasticsearch
версии 1.1.1, он прекрасно работает и с последней стабильной версией 1.3.1. Именно ее мы и установим.

Добавляем публичный GPG ключ в apt:

Создаем source list apt:

И устанавливаем Elasticsearch
1.3.1:

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

И раcкомментируем строки “cluster.name: elasticsearch” и “node.name: «Franz Kafka»”. Вместо значений по умолчанию можно указать свои.

Создаем скрипты автозапуска elasticsearch
:

Перед стартом сервера я рекомендую установить еще два плагина к elasticsearch
– head
и paramedic
. Первый позволяет управлять сервером поиска и индексами документов, второй следит за “здоровьем” пациента, выводя графики с различной полезной информацией.

Плагины к elasticsearch
устанавливаются с помощью команды plugin
прямо из github
:

Доступ к результатам работы плагинов можно получить через url вида http://elasticsearch.server.name:9200/_plugin/head/ или http://elasticsearch.server.name:9200/_plugin/paramedic/

После чего можно запускать сам сервер:

Установка Kibana

Так как Kibana
это веб-приложение, перед его установкой нужно установить веб-сервер. Я воспользовался простейшим nginx
.

Создаем папку www
для будущего приложения:

Даем nginx
права на папку:

Скачиваем последний архив с файлами Kibana
(на настоящий момент это kibana-3.1.0.tar.gz
):

И копируем его содержимое в папку /var/www
:

Скачиваем файл конфигурации для работы Kibana
под nginx
:

Открываем его в редакторе nano
и указываем в какой папке лежат файлы Kibana
:

на строку

root /var/www;

Копируем данный файл как файл по умолчанию для nginx
:

И перезапускаем nginx
:

Теперь если перейти по адресу http://elasticsearch.server.name/ мы увидим стартовый дашборд Kibana
. Если вы не планируете создавать других дашбордов, то можно сразу поставить по умолчанию дашборд Logstash
.

Для этого нужно заменить файл дашборда по умолчанию на файл дашборда Logstash
:

Основные настройки Kibana
находятся в файле config.js
по адресу /var/www/config.js
, однако “из коробки” все работает замечательно.

Установка Logstash

Добавляем source list Logstash в apt:

И устанавливаем Logstash
:

Logstash
установлен, однако конфигурации у него нет. Конфигурационный файл Logstash
состоит из 3х частей – input
, filter
и output
. В первой определяется источник событий или логов, во второй с ними производятся необходимые манипуляции, и в третей части описывается куда обработанные данные нужно подавать. Подробно все части описаны в документации http://logstash.net/docs/1.4.2/ и есть некоторые примеры.

Для текущей задачи, мною была написана следующая простая конфигурация:

Создадим файл в папке конфигураций Logstash

И поместим туда следующую конфигурацию

Разберем по порядку:

В разделе input

tcp
<> — открывает tcp порт и слушает его

type => “eventlog”
говорит Logstash
что на входе будут данные типа eventlog
(известный формат полей для Logstash
)

port => 3515
– номер потра

format => ‘json’
– говорит Logstash
о том, что данные придут “обернутые” в JSON

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

В разделе output

elasticsearch
<> – оправляет данные в elasticsearch

cluster => “elasticsearch”
– указывает на имя кластера, что мы указывали при конфигурировании Elasticsearch

node_name => “Franz Kafka”
– указывает на имя ноды.

Сохраняем файл и запускаем Logstash

Можно проверить что порт tcp 3515
слушается командой:

Установка nxlog

Идем на сайт nxlog
( http://nxlog.org/download) и скачиваем саму свежую версию для Windows
.

Устанавливаем на нужной Windows
машине данный клиент. Настройки он хранит в файле nxlog.conf
по адресу по умолчанию “c:\Program Files (x86)\nxlog\conf\” (для 32-битной версии “c:\Program Files\nxlog\conf\”).

Для решения данной задачи я написал конфигурационный файл следующего содержания:

У nxlog
конфигурационный файл так же состоит из нескольких частей – это Extension
, Input
, Output
и Route
. Об устройстве конфигурационного файла nxlog
можно почитать в документации к nxlog
( http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html) .

Могу отметить следующие детали – в разделе Input
используется модуль im_msvistalog
(для операционных систем Vista/2008 +
) для более старых ОС нужно раскомментировать строку с указанием на модуль im_mseventlog
. Модуль im_msvistalog
позволяет фильтровать логи через XPath
запрос (подробнее тут — http://msdn.microsoft.com/en-us/library/aa385231.aspx) . В приведенном конфигурационном файле выбираются логи из трех источников – это журналы Application
, Security
и System
, причем из Application
и System
выбираются только Critical
, Error
и Warning
логи, для Security
выбираются все логи, так как они там другого типа – Info
. Команда Exec to_json;
“оборачивает” данные в JSON
формат.

В разделе Output
указывается модуль om_tcp
для отправки данных по протоколу tcp
, указывается хост и порт подключения.

Раздел Route
служит для указания порядка выполнения действий, так как клиент nxlog
умеет читать из множества источников и отсылать во множество приемников. Все это можно подчерпнуть из документации к продукту.

Настроив конфигурационный файл не забудьте его сохранить и можно запускать клиент через оснастку Службы
( Services
) или через командную строку:

Использование

Открыв в браузере Kibana
(и перейдя на дашборд Logstash
, если он у Вас не по умолчанию) мы увидим после всего проделанного следующую картину.

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

Обратив свое внимание на таблицу данных мы увидим что данные показаны в “сыром” виде, однако слева от таблицы есть список полей. Щелкнув последовательно по чекбоксам с полями EventID
, EventTime
, EventType
, Hostname
, Sevirity
, Message
, Channel
, мы получим уже более читабельный вид таблицы:

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

Если кликнуть по символу лупы рядом с именем процесса, то создастся фильтр по этому имени.

А данные в таблице отобразятся в соответствии с фильтрами.

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

Ну и наконец если я просто хочу поискать по всем полям словосочетание “System Center” в поле запроса я пишу “System Center”. В случае поиска по конкретному полю можно воспользоваться конструкцией FieldName:”SearchQuery”, например ProcessName:»System Center». Что бы исключить из выборки данные найденные с помощью конструкции можно воспользоваться оператором “-“, например -ProcessName:»System Center» или -“System Center”. Так же работают операторы OR и AND.

Более подробно о возможностях Kibana
+ Logstash
+ Elasticsearch
можно узнать из документации и вебинаров на сайте elasticsearch.org. Здесь я показал лишь малую толику того что может эта замечательная связка инструментов.

При подготовке статьи я пользовался следующими источниками:

Рубрики

• Аудит ИБ
• Вакансии
• Закрытие уязвимостей (97)
• Книги
• Мануал (1 740)
• Медиа
• Мероприятия
• Мошенники
• Обзоры (644)
• Обход запретов
• Опросы
• Скрипты (98)
• Статьи (262)
• Философия
• Юмор

10 Inav

От глупой командной строки, не требующих настройки инструментов до полномасштабной обработки данных — все это здесь!

Я что-то пропустил? Конечно, я сделал это!

Пожалуйста, дайте мне знать в комментариях, и я буду рад добавить эту сюда

Добавить комментарий Отменить ответ

2 Logstash

Если вы являетесь поклонником или пользователем стека Elastic, стоит попробовать Logstash (стек ELK )

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

Но не вводите себя в заблуждение: Logstash — это иснтрумент, возможности которого намного превосходят любые скромные средства ведения журналов.

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

Конечно, единственным ограничением является то, что он работает только с набором продуктов Elastic, но если вы скоро начнете и хотите масштабироваться, Logstash — это то, что вам нужно!

Практика ИБ. Централизованный сбор логов с Windows-устройств

Руслан Рахметов, Security Vision

Коллеги, в предыдущей статье

мы обсудили инвентаризацию ИТ-активов и кратко рассмотрели простейшие способы сбора технической информации с устройств. Разумеется, кроме сведений о самих активах, в целях решения задач информационной безопасности следует собирать и журналы аудита с контролируемых устройств. В данной статье мы рассмотрим централизованный сбор логов с Windows-устройств посредством использования штатного функционала Windows Event Forwarding и пересылку собранных событий в SIEM-систему (на примере IBM QRadar). Приступим!

Для начала следует напомнить читателям о том, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Microsoft предлагает использовать также бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit
, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Можно также пользоваться и веб-версией рекомендаций

по настройке аудита.

Разумеется, рекомендуемые в «лучших практиках» настройки аудита следует привести в соответствие конкретной инфраструктуре: например, будет нецелесообразно включать аудит платформы фильтрации (т.е. встроенного брандмауэра Windows) в случае, если в компании применяется другое наложенное хостовое СЗИ с функционалом межсетевого экранирования. Не стоит забывать и о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Итак, настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и централизованного их хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull / Collector initiated), так и отправлены самим источником (режим Push / Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push на коллекторе служба WinRM слушает входящие соединения, а на клиентах-источниках WinRM не находится в режиме прослушивания и только периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальных атак на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

2. На сервере-коллекторе выполнить команду wecutil qc
, согласиться на включение службы сборщика событий Windows. При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» («Windows Remote Management (WS-Management)»), при этом TCP:5985 не начинает слушаться.

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers ( «Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита ( eventvwr.msc
) и находим внизу раздел «Подписки» («Subscriptions»). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Source Computer Initiated» (это означает предпочтительный режим Push). Нажимаем на кнопку «Select Computer Groups», выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Select Events» и вводим XPath-запрос (пример для сбора журналов Security):

<Query Id=»0″ Path=»Security»>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На коллекторе в event
v
wr.msc

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

9. Далее, решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему (возьмем для примера SIEM security систему IBM QRadar (Курадар)). Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect
.

Рекомендуем использовать управляемый («Managed») режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM

и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil

ss

SubscriptionName

/
cf
:
RenderedText
/
l
:
en
—
US
(где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM Q Radar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника «Microsoft Security Event Log», в поле «Target Destination» в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box «Forwarded Events»).

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

<!—->









<!—->

<!—

—>

×

To install this Web App in your iPhone/iPad press and then Add to Home Screen.

<!—

—>

<!—
document.getElementById(‘prod’).setAttribute(‘disabled’, ‘enabled’);
// функция возвращает cookie с именем name, если есть, если нет, то undefined
function getCookie(name) {
let matches = document.cookie.match(new RegExp(
«(?:^|; )» + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, ‘\\$1’) + «=([^;]*)»
));
return matches ? decodeURIComponent(matches[1]) : undefined;
}
let cookiecook = getCookie(«cookiecook»),
cookiewin = document.getElementsByClassName(‘cookie_notice’)[0];
// проверяем, есть ли у нас cookie, с которой мы не показываем окно и если нет, запускаем показ
console.log(«!»+cookiecook);
if (cookiecook != «no») {
// показываем
cookiewin.style.display=»block»;
// закрываем по клику
document.getElementById(«cookie_close»).addEventListener(«click», function(){
cookiewin.style.display=»none»;
// записываем cookie на 1 день, с которой мы не показываем окно
let date = new Date;
date.setDate(date.getDate() + 1);
document.cookie = «cookiecook=no; path=/; expires=» + date.toUTCString();
});
}
—>

Централизованный сбор логов в Windows с разных компьютеров штатными средствами

А вы в курсе, что в винде, начиная с 2008R2 есть замечательная возможность – собирать логи с разных компьютеров в сети, в одном месте? Эта функция называется Windows Event Forwarding. Сегодня покажу как её настроить.

Настраивать функцию можно двумя способами.

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

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

Я покажу как собирать логи на примере Collector Initiated.

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

Для этого на них должно быть включено удаленное управление, или другими словами – должен быть настроен winrm. Чтобы его настроить необходимо выполнить команду от имени администратора:

Либо можно воспользоваться powershell

Дальше необходимо добавить учетную запись пользователя, или компьютера, на который будут отправляться логи (если вы по какой-то причине не захотите указывать при настройке учетную запись пользователя) в группу Event Log Readers. Но, в некоторых случаях членства в данной группе может быть недостаточно, тогда придется добавлять учетки в группу администратора.

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

Тут все указанные SIDы – стандартные, мы добавляем запись (A;;0x1;;;S-1-5-20).

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

Если у вас много компьютеров, тогда процесс выдачи прав можно сильно упростить выполнив команду в PowerShell:

Как вы поняли, в папке, откуда вы выполните эту команду должно быть 2 файла:

Computers.txt – список компьютеров, на которых нужно выполнить команду. Каждый – с новой строки.

Security.ps1 – тут только наша команда — wevtutil set-log security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

На этом настройка отдающих – завершена. Переходим к настройке сервера, где всё будет храниться.

Первым делом включим службу Windows Event Collector, для этого, от имени администратора выполним:

В оснастке службы должна будет появиться данная служба, с типом запуска Delayed Start.

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

Запускаем оснастку просмотр событий – eventvwr.msc, windows logs, правой кнопкой по Forwarded Events. И ограничиваем размер, чтобы логи не терялись – лучше выбрать Archieve the log when full, do not owerride events. И конечно указываем путь, где файл должен лежать.

Дальше, создадим подписку – правой кнопкой по Subscriptions – Create Subscription

Тут нужно ввести имя, выбрать лог, куда должны складываться события (по умолчанию – Forwarded Events, по этом ему мы и меняли расположение и размер).

Сразу идем в Advanced Settings и указываем пользователя, от имени которого будет действовать сборщик (если вы указывали имя компьютера ранее на клиентах, тогда этот шаг пропускаем).

Выбираем события, которые должны собираться – select events. Тут можете настроить под себя, как вам угодно. Но не стоит выбирать абсолютно всё, то есть и стандартные логи, и логи приложений, иначе практически наверняка у вас выскочит ошибка, во время сбора логов, о слишком большом запросе.

Осталось только добавить компьютеры, с которых хотим собирать информацию – select computers. После добавления каждого из компьютеров лучше сразу жать test, чтобы удостовериться, что всё будет работать как надо.

Выжидаем некоторое время, и смотрим на статус созданного коллектора. Если он активный, значит в скором времени в forwarded events начнут появляться записи.

Но на этом еще не всё. Когда к вам начнут прилетать записи, вы скорее всего увидите, что для записи отсутствуют описания. Что-то вроде:

The description for Event ID X from source A cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

Частично данную незадачу можно решить, выполнив команду:

И перезапустив службу Windows Event Collector. По умолчанию, за место events установлен RenderedText. И по умолчанию события пререндерятся на удаленных компьютерах и отправляются с локализованными строками, из-за чего есть вероятность, что события не будут распознаны. Кроме того, изменение на Events немного снизит нагрузку на сеть и компьютеры – источники.

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

Все источники и то, на какие DLL они завязаны можно посмотреть в реестре – HKLM\SYSTEM\CurrentControlSet\services\eventlog. Тут всё разбито по логам, типа Application, System и т.п. Соответственно если нужного источника тут нет, то его необходимо экспортировать с компьютера, где он есть. Соответственно и нужные, как правило, DLLки, со словарями можно посмотреть в этих ветках реестра – это параметры, где есть file в названии. Пути до файлов, для удобства, после импорта можно менять.

Если события пишет небольшое приложение, то источников для него, скорее всего будет 1-2, и их можно спокойно перенести руками, но вот если это что крупное, например exchange, то источников там уже 147. Согласитесь, такое количество руками переносить – мазохизм. Поэтому был написан скрипт, который всё сделает за нас.

Копируем скрипт export-log на сервер, где нужная служба есть, переходим в папку со скриптом и запускаем его от имени администратора с ключом, которым является часть имени источника событий. Например, если мы увидели в просмотре событий, что нет описаний для MSExchange Certificate, то скрипт можно запустить так:

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

Далее нужно скопировать созданную папку на сервер сборщик логов, в папку со скриптом import-log, перейти в powershell запущенном от имени администратора в папку со скриптом, и запустить его с тем же самым ключом.

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

Во время настройки этого хозяйства я столкнулся с некоторыми неприятными моментами, оставлю описание этих моментов тут.

1. На парочке серверов были непонятки с WinRM. В диспетчере серверов статус удаленного управления был обозначен как неизвестный. При попытке выполнить winrm qc выскакивало сообщение

WinRM service is already running on this machine.

WSManFault

Message

ProviderFault

WSManFault

Message = Unable to check the status of the firewall.

Error number: -2147024894 0x80070002

The system cannot find the file specified.

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

Google настойчиво предлагал добавить правила в firewall:

Но для меня это результата не дало, равно как и его включение, отключение и изменение его конфигурации.

Как выяснилось, именно данная ошибка была связана с локализацией системы, на нее был установлен языковой пакет. После изменения языка системы – ошибка ушла, и команда отработала штатно, но доступа – не появилось.

Посмотрел на прослушиваемые порты командой netstat -ant — обнаружил, что порт winrm ( 5985) слушается только на адресе 127.0.0.1

показало, что iis слушает только на адресе 127.0.0.1

Помогло выполнение команд:

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

2. Мы подцепили лог на диск iSCSI и после перезагрузки системы, данный лог стабильно отваливается. Связано это, скорее всего с тем, что после перезагрузки – iSCSI диски, либо переподключаются, либо изначально долго подключаются, и всё это происходит уже после запуска службы event log. Тут помогло указание в свойствах неправильного пути до лога, и когда система ругнется, что путь не верен – нужно указать верный путь, тогда файл подцепится.

Я добавил в планировщик заданий, на событие start up — простенький файл содержащий следующие строчки:

9 Syslog-ng

Инструмент Syslog-ng был разработан как способ обработки файлов системного журнала (установленный протокол клиент-сервер для регистрации в системе) в режиме реального времени.

Однако со временем он стал поддерживать другие форматы данных: неструктурированные, SQL и NoSQL.

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

syslog-ng — это надежный инструмент для сбора и классификации журналов промышленного уровня, написанный на языке Си и давно известный в отрасли.

Лучшая часть — это расширяемость, позволяющая вам писать плагины на C, Python, Java, Lua или Perl.

Наш Telegram

4 Flume

Если на самом деле вам нужны действительно большие наборы данных, и вы в конечном итоге захотите объединить все в нечто вроде Hadoop, Flume — один из лучших вариантов.

Это «чистый» проект с открытым исходным кодом, в том смысле, что он поддерживается нашим любимым Apache Foundation, что означает отсутствие корпоративного плана.

Это может быть то, что вы точно ищете. ?

Написанный на Java (который продолжает удивлять меня, когда дело доходит до революционных технологий), исходный код Flume полностью открыт.

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

6 LOGalyze

LOGalyze был коммерческим продуктом, который недавно стал инструментом с открытым исходным кодом.

Хотя я не смог реализовать проект на GitHub, они сделали установщик Windows и весь исходный код загружаемым.

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

LOGalyze — это относительно гибкое и мощное предложение, которое отлично подойдет для развертываний в одной системе, которые стремятся объединить ведение журналов из известных источников, таких как Postfix, Apache и т. д. и выводить их в форматах CSV, PDF, HTML или аналогичных.

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

Социальные сети

Настраиваем сбор логов Windows Server в ELK Stack

Продолжаю цикл статей по настройке централизованной системы сбора логов ELK Stack. Сегодня расскажу, как собирать логи с Windows Server различных версий в elasticsearch. Данные предложенным способом можно будет собирать не только с серверных систем, но и со всех остальных, где используется журнал windows.

Поделиться

Anything in here will be replaced on browsers that support the canvas element

Сбор и анализ логов Windows Fileserver

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

• Имена пользователей, которые обращаются к файлам (поле event_data. SubjectUserName)
• Типы запросов, которые выполняются (поле file_action)
• Список доступа к файлам (формируется из сохраненного фильтра поиска)

Возможно, кому-то будет актуально выводить на дашборд еще и информацию об именах файлов, к которым идет доступ. Информация об этом хранится в поле event_data. ObjectName. Лично я не увидел в этом необходимости.

8 Logwatch

Я уверен, что среди нас есть те, кто не хочет, чтобы вся церемония была связана с «единой», «централизованной» системой ведения журналов.

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

Ну тогда, скажи привет Logwatch.

После установки LogWatch может сканировать системные журналы и создавать отчеты нужного вам типа.

Это несколько устаревшее программное обеспечение (читай «надежное»), хотя оно было написано на Perl.

Итак, вам понадобится Perl 5.6+ на вашем сервере для его запуска.

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

Если вы наркоман CLI и любите стиль старой школы, вам понравится Logwatch!

Dashboard в Kibana для Windows Server

После того, как данные из логов windows серверов начали поступать в elk stack, можно приступить к их визуализации. Я предлагаю такую информацию для Dashboard в kibana:

• Количество логов с разбивкой по серверам
• Количество записей в каждом журнале
• Разбивка по уровням критичности (поле level)
• Разбивка по ID событий в логах (поле event_id)
• Список имен компьютеров, фигурирующих в логах (поле event_data. Workstation)
• Список пользователей в логах (поле event_data. TargetUserName)
• Разбивка по IP адресам (поле event_data. IpAddress)

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

А вот какой Dashbord у меня получился в итоге:

В самом низу идет список логов с сырым текстом события. Отдельно представляю дашборд для файлового сервера windows.

Сбор windows логов

Приступим к настройке. Устанавливаем последнюю версию winlogbeat на сервер, с которого мы будем отправлять логи в elk stack. Вот конфиг с тестового сервера, по которому пишу статью:

Теперь настраивает logstash на прием этих логов. Добавляем в конфиг:

Я формирую месячные индексы с логами windows серверов. Если у вас очень много логов или хотите более гибкое управление занимаемым объемом, то делайте индексы дневные, указав winsrv-%<+YYYY. MM .dd
>

Перезапускайте службы на серверах и ждите поступления данных в elasticsearch.

10 сборщиков логов с открытым исходным кодом для централизованного ведения журнала

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

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

Прежде чем мы перейдем к централизованному ведению журналов, давайте сначала рассмотрим, почему ведение журналов ( логирование ) так важно.

Два типа (уровня) регистрации сообщений журналов

Компьютеры являются детерминированными системами, кроме случаев, когда это не так.

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

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

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

Обращаем ваше внимание, что этих различий и классификации нету в учебниках, и цитирование меня по этой терминологии доставит вам неприятности. ?

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

В данном конкретном случае это система WordPress, регистрирующая непредвиденное состояние (уведомление) при запуске некоторого кода PHP.

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

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

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

Но автоматически сгенерированные журналы могут помочь только так сильно.

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

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

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

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

Вот пример того, как может выглядеть такая схема регистрации:

Логгирование это сила

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

Боевой дух и продуктивность команды

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

И вот в чем дело с отладкой — она требует свежего, любопытного ума с самого начала.

И что затрудняет отладку?

По моему опыту, отсутствие ведения журнала или отсутствие знаний о ведении журнала.

Для начала вы можете не осознавать, что ваша любимая база данных — это просто еще одна часть программного обеспечения, которая генерирует журналы, или вы не будете интенсивно регистрировать события в своем приложении (см. Журналы, сгенерированные программистом выше).

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

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

Потому что никто не удосужился посмотреть журналы,и никто не мог понять, почему система упала.

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

Часто такие небольшие изменения работают лучше, чем удвоение емкости оборудования.

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

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

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

7 LogPacker

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

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

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

По этому критерию LogPacker — мой любимый.

5 Octopussy

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

По моему мнению, Octopussy покрывает потребности большинства продуктов (оценочная статистика бесполезна, но, если бы мне пришлось угадывать, я бы сказал, что в реальном мире она учитывает 80% случаев использования)

У Octopussy нет отличного пользовательского интерфейса:

но он компенсирует скорость и отсутствие раздувания.

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

Information Security Squad

stay tune stay secure

Онлайн курсы

3 Fluentd

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

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

Fluentd построен на Ruby, является продуктом с полностью открытым исходным кодом и пользуется большой популярностью благодаря своей гибкости и модульности.

С такими крупными компаниями, как Microsoft, Atlassian и Twilio, использующим эту платформу, Fluentd нечего доказывать. ?

Заключение

Материал написан исключительно на основании своего видения и небольшого опыта использования elk stack. Нигде не видел статей и мыслей на данную тему, так что буду рад предложениям, замечаниям. Ко всему прочему, я практически не администрирую windows сервера. Пишите обо всем в комментариях.