Централизованный сбор логов windows

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

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

Введение

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

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

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

Сбор windows логов

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

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

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

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

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 Fileserver

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

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

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

Заключение

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

Источник

Information Security Squad

stay tune stay secure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Graylog

2 Logstash

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

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

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

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

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

3 Fluentd

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

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

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

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

4 Flume

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

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

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

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

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

5 Octopussy

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

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

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

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

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

6 LOGalyze

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

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

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

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

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

7 LogPacker

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

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

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

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

8 Logwatch

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

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

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

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

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

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

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

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

9 Syslog-ng

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

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

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