Linux сбор логов с windows

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

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

Вступление

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

В ней описывается простой и надежный способ (даже скорее простая и надежная сторонняя утилита) для передачи системных событий из Event Log’ов серверов на базе Windows в Linux syslog для удобства централизованного хранения и обработки.

Реалии таковы, что в нынешней корпоративной среде самое эффективное и надежное решение основывается на смешении серверных операционных систем из-за качества и способов решаемых ими задач. Рабочие станции, и, следовательно, групповое ими управление и администрирование проще делать на Active Directory; веб сервер, прокси сервер надежнее поставить на линукс; роутером быстрее сделать что-то из Cisco. Эта объективная реальность, с которой работают администраторы многих средних компаний (особенно знакомые с линуксом, от винды так или иначе им все равно не уйти и зачастую в фирме стоят домен-контроллеры на винде и прокси-сервер и роутер на линуксе) — в мелких фирмах можно обойтись одной виндой, в крупной фирме скорее всего раздельно существует администратор линуксоид и администратор виндузятник умело отвечающие за свои сектора. Так или иначе, эта статья не теоретизирование и не исследование на эту тему, эта статья про конкретную задачу, которая практически всегда приходит в голову любому администратору работающему в таком окружении, а вступление что-то затянулось.

Описание

Каждый работающий с серверами знает и ежедневно пользуется системой логов на своих машинах и каждый знает как они устроены — syslog на Linux и Event Log на винде.

До эры Windows Server 2008 Event Log был странной системой созданной как-будто не для серверов — каждый компьютер писал и хранил свои события локально и удобных механизмов для передачи их по сети для централизованного просмотра или хотя бы хранения не было вообще. Ну, впрочем, всем это известно. Просмотр логов для серверов напоминал квест в MMORPG — исследуй несколько локаций и собери несколько предметов в каждой. Начиная с Windows Vista был сделан шаг навстречу людям и создана система форварда локальных событий на другие Windows >Vista компьютеры. Это хорошо и прогрессивно и это именно то чего не хватало, но реальность такова что на данный момент осталось и не устарело много серверов с Windows 2003 для которых таких механизмов так и нет или они есть, но отталкивают своей монстроузной реализацией.

С другой стороны существует простая и надежная система syslog для Linux которая изначально разработана для распределённой передачи и приёма логов и содержит в себе всё что для этого необходимо. Она настолько хорошо делает своё дело что возможность отправлять логи по этому протоколу встраивают и в хардварные роутеры и в кучу разных других устройств и вполне реально сделать в сети сервер который будет собирать все логи со всех устройств в сети: серверов, роутеров, коммутаторов, принт-серверов, кофеварок, кулеров, ой что-то я разошелся… Кроме Windows. Врядли найдётся человек которому не приходила в голову мысль что если бы Windows мог отправлять свои логи в syslog это было бы идеальным решением для централизации логохранилища. Как удобно было бы все иметь в одном месте — можно было бы и хранить годами, архивируя текстовые файлы (они отлично ужимаются), и обрабатывать, разбирая один текстовый файл от нескольких серверов вылавливая одно критическое событие сразу для нескольких машин.

Задался таким вопросом и я. Задался я им несколько лет назад и потерпел неприятное фиаско — утилит позволяющих это сделать-то довольно много, но выглядят они все как кошмар профессионального администратора — какие-то ужасные утилиты иногда на C# размеров в 100 мегабайт с тысячей кнопочек и чекбоксов и что самое неприятно — _все платные_. Не знаю в чем прикол, но несколько лет назад Google был переполнен ссылками на коммерческий софт с таким функционалом. При этом софт не высокого качества, судя по стремным сайтам и скриншотам. Переполнен он ими и сейчас, и, по моим собственным наблюдениям, многие отнюдь не ленивые и не тупые администраторы способные с успехом для собственного удобства использовать такой функционал так и не нашли того что им нужно и не знают что такое бывает. По крайней мере за мой совет и ссылку меня не раз благодарили, и теперь я хотел бы поделиться и с вами. А именно некоторое время назад (довольно давно, это статью я решил написать только сейчас), мне удалось найти проект идеально подходящий под мои нужды и требования:

http://code.google.com/p/eventlog-to-syslog/

Опишу вкратце его достоинства:
— это системный сервис, т.е. ничего не надо запускать при старте, никаких странных экзешников которые можно случайно по забывчивости убить при очередной чистке хлама на сервере;
— лаконичная поставка — .dll, .exe и краткая, но всеобъемлющая документация;
— открытый исходный код;
— версия 32-bit и 64-bit;
— одинаковая работа и версия на любых версиях Windows имеющих Event Log;
— минимум настроек (настолько минимум что это командная строка при установке сервиса и текстовый файл для работы, который можно не открывать вообще при желании);
— покрывающий максимум функционала — все что должна делать эта программа она делает — умеет отправлять логи в разные facility, умеет исключать определённые события из отправления и так далее, даже получать имя log сервера по dhcp.

Добавлю от себя что во-первых вот уже полгода как эта программа на 8-ми моих серверах и 2003 и 2008 просто работает, после установки я _ни разу_ ни на одном из них не проверял, не перезапускал обвалившийся, не ковырял, не изменял и даже не смотрел в сторону этого сервиса, который так же никак не повлиял ни на одно другое приложение, он просто делает своё дело после установки — безустанно шлёт эвенты туда куда ему сказали. А во-вторых что программа очень динамично развивалась не так давно набирая функционал, после чего стабилизировалась и теперь достаточно регулярно, но не слишком часто, выходят билды которые причесывают функционал и фиксят мелкие редковоспроизводимые баги.

Перейдём к ещё большей конкретике.

Настройка

Настройка syslog на линуксе.
Включите принятие логов из сети, это ключ -r у демона syslogd. По умолчанию он почти всегда не прописан и при запуске без него syslogd сеть не слушает.

Затем вам наверняка не очень понравится если логи линуксов, роутеров и винды будут смешиваться в одном файле и превращаться в трудновоспринимаемую кашу. Для этого в системе syslog есть несколько разделов (facility) и приходящие на отдельные facility сообщения можно писать в разные файлы. Так как логи от винды не особо подходят ни под kernel, ни под mail, специально для этого в syslog есть несколько “безличных” facility которые называются local. Чтобы вынести например local1 в отдельный файл надо добавить в /etc/syslog.conf строку:

local1.* -/var/log/local1.log

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

Установка элементарна — скачиваем дистрибутив, в нём .dll и .exe, копируем их в %WINDIR%\System32\
Запускаем .exe с нужными параметрами.

Параметры evtsys.exe:
-i Установить сервис
-u Удалить сервис
-d Дебаг. Запуститься как консольная программа
-h host Имя хоста куда отправлять логи
-b host Имя второго хоста кому дублировать логи
-f facility Facility логов
-l level Минимальный уровень отсылаемых сообщений
0=Всё, 1=Критические, 2=Ошибки, 3=Предупреждение, 4=Информация
-n Отправлять только эвенты включенные в конфиге
-p port Номер порта syslog
-q bool Опросить DHCP чтобы получить имя хоста syslog и порт
(0/1 = включить/выключить)
-s minutes Интервал между сообщениями. 0 = Отключить

Необходимым является всего один параметр: -h хост. Чтобы установить evtsys как сервис надо указать и параметр -i. А так же нас интересует параметр -f, чтобы сменить facility по умолчанию (system daemons) на local1.
Evtsys использует цифровое обозначение facility, вот список:

0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)

выберите тот который вам нужен, в нашем случае это 17 (local1) и вперед, целиком команда будет выглядеть так:
%WINDIR%\System32\evtsys.exe -i -h [адрес вашего линукса с syslog] -f 17

Если вы хотите исключить какое-то событие из отправки в syslog, например огромную кучу мусора появляющуюся по поводу каждого подключения к компьтеру по сети в разделе Security, можете создать файл (или открыть, если уже запустили сервис) %WINDIR%\System32\evtsys.cfg и забить в него события которые вас не интересуют в формате EventSource:EventID. Например строка “Security-Auditing:*” полностью отключит отправку раздела Security на Windows >Vista, строка “Security-Auditing:4624” отключит отправку только события с кодом 4624 (интерактивный доступ из сети к компьютеру, браузинг его кем-то из сети). Грустная ирония такова что при разработке нового Event Log’а для нового поколения серверных ОС Микрософт полностью сменила названия разделов и коды, а так же переписала и стандартные сообщения и вообще все события, так что на поколении Windows 2003 и поколении Windows 2008 названия разделов и номера событий будут кардинально различаться. Впрочем зачастую у них будет одинаковый смысл. Какое событие что значит и какие у них названия и номера удобно узнавать с сайта http://www.eventid.net/.

После чего можно открывать список сервисов Windows и запускать сервис под названием “Eventlog to Syslog” и логи начнут появляться в файле на сервере с syslogd примерно в таком виде:

# head -n 1 /var/log/local1.log
Jun 20 09:13:30 srv SRV Security-Auditing: 4634: An account was logged off. Subject: Security ID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-2304319227-3176 Account Name: XXXXXX$ Account Domain: XXX Logon ID: 0x325f90ec Logon Type: 3 This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.

Заключение

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

Для себя я написал на perl зацикленный парсер идущего лога который из всё-таки не совсем удобочитаемой простыни лога:
а) выкусывает события которые меня не интересуют: например всё те же обращения к компьютеру из сети (любой браузинг в сети одного компа вызывает на всех компах которые он у себя в сетевом окружении увидит сообщение об этом, а это реально большая куча сообщений на серверах, особенно если сразу с нескольких). У меня ушёл всего один день на то чтобы создать список таких “не интересующих меня” событий.
б) подкрашивает события которые меня интересуют и переводит их из технического вида в человеческий, например логин на сервер по RDP окрашивается синим и пишется не полная строка из лога, навроде той что я привёл выше из которой ещё надо понять кто на ком стоял, а в виде “Remote login by ‘xxx’ (ip: x.x.x.x) to ‘XXX’”.

В результате чего я получил консольную утилиту в которой то что меня интересует всегда выделенно, а всё что произошло кроме этого будет написано так что это реально разобрать, понять и быстро отреагировать. Можно просто изредка посматривать на протяжении дня на консоль в которой довольно редко появляется текст, зато если что-то пойдёт — это сразу можно поймать. Например недавно у меня начал подходить к концу пул DHCP, и я сразу узнал об этом увидев в консоли сообщение от DHCP (стоящем на домен контроллере) о том что DHCP-pool is 90% full, а не придя на работу через два-три дня и узнав что кто-то не может попасть в сеть.

Кроме того, утилита позволяет записывать в базу те события которые я хочу хранить и как-то обрабатывать.
Например недавно тут (на хабре) была статья о том как сделать статистику того, кто что распечатал, с дикой чехардой по SNMP. В моем же случае эта незначительная проблема входящая в общую решаемую задачу централизированного логирования, если принтер подключен к серверу и расшарен, и на нём включено логирование того что напечатано, не просто решается, а решается более чем полно. Ведь в логи кроме количества страниц и ip адреса, пишется:

— кто распечатал (логин)
— имя документа

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

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

Источник

Today, we are going to explain how to forward Windows system Event logs to a Linux Syslog Server using a Syslog Agent, In the last tutorial we showed you How to Setup LogAnalyzer with Rsyslog

Downloading and Installing Datagram Syslog Agent

Go to the official site of Datagram Syslog Agent, download the Datagram Syslog Agent 64-bit software and extract the zip file under Disk C

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

– Run the SyslogAgentConfig tool and click Install under the Service Status section at the top

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

– Enter the IP address of the syslog host and the Listening port. In my case, the Log Insight syslog server’s IP address is 192.168.1.200 and the used listening port is 514

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

– Before clicking the Start button you can select which type of event logs you want to be forwarded to your your Syslog Server; it could be System logs, Security Logs, Application Logs …

– open Windows services to check that the SyslogAgent is added and running.

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

Testing Syslog

– For the purpose of desmontration, we are using a Syslog server with logAnalyzer, if you don’t installed yet you can take a look to this tutorial How to Setup LogAnalyzer with Rsyslog On CentOS 7 / RHEL 7.
Open this link http://Syslog_server_ip_address/loganalyzer and you have to recieve Windows Eventlogs from your syslog Agent

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

We hope this tutorial was enough Helpful. If you need more information, or have any questions, just comment below and we will be glad to assist you!
 

PS. If you like this post please share it with your friends on the social networks using the buttons below.Thanks.

YallaLabs

Lotfi Waderni

I’m a technical writer with a background in Linux and windows server administration.

Источник

Передо мной встала задача организовать сбор 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:

sudo add-apt-repository -y ppa:webupd8team/java

Обновляем репозиторий:

sudo apt-get update

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

sudo apt-get -y install oracle-java7-installer

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

java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

 

Установка Elasticsearch

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

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

wget -O - http://packages.elasticsearch.org/GPG-KEY-elasticsearch | sudo apt-key add -

Создаем source list apt:

echo 'deb http://packages.elasticsearch.org/elasticsearch/1.3/debian stable main' | sudo tee /etc/apt/sources.list.d/elasticsearch.list

Обновляем репозиторий:

sudo apt-get update

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

sudo apt-get -y install elasticsearch=1.3.1

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

Открываем elasticsearch.yml:

sudo nano /etc/elasticsearch/elasticsearch.yml

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

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

sudo update-rc.d elasticsearch defaults 95 10

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

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

sudo /usr/share/elasticsearch/bin/plugin --install mobz/elasticsearch-head
sudo /usr/share/elasticsearch/bin/plugin --install karmi/elasticsearch-paramedic

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

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

sudo service elasticsearch start

 

Установка Kibana

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

sudo apt-get install nginx

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

sudo mkdir /var/www

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

sudo chown -R www-data:www-data /var/www

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

wget https://download.elasticsearch.org/kibana/kibana/kibana-3.1.0.tar.gz

Распаковываем архив:

tar zxvf kibana-3.1.0.tar.gz

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

sudo cp -r kibana-3.1.0/* /var/www/

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

wget https://github.com/elasticsearch/kibana/raw/master/sample/nginx.conf

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

Заменяем строку
root  /usr/share/kibana3;

на строку
root  /var/www;

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

sudo cp nginx.conf /etc/nginx/sites-available/default

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

sudo service nginx restart

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

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

sudo cp /var/www/app/dashboards/logstash.json /var/www/app/dashboards/default.json

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

 

Установка Logstash

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

echo 'deb http://packages.elasticsearch.org/logstash/1.4/debian stable main' | sudo tee /etc/apt/sources.list.d/logstash.list

Обновляем репозиторий:

sudo apt-get update

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

sudo apt-get install logstash

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

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

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

sudo nano /etc/logstash/conf.d/10-windowslog.conf

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

input {
    tcp {
        type   => "eventlog"
        port   => 3515
        format => 'json'
    }
} filter { 
} 
 
output {
    elasticsearch {
        cluster => "elasticsearch"
        node_name => "Franz Kafka"
    }
}

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

В разделе 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

sudo service logstash start

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

sudo netstat -a | grep 3515

Установка nxlog

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

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

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

## This is a sample configuration file. See the nxlog reference manual about the
## configuration options. It should be installed locally and is also available
## online at http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html 
## Please set the ROOT to the folder your nxlog was installed into,
## otherwise it will not start.
 
#define ROOT C:\Program Files\nxlog
define ROOT C:\Program Files (x86)\nxlog
 
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
 
<Extension json>
    Module      xm_json
</Extension>
  # Windows Event Log
<Input eventlog>
# Uncomment im_msvistalog for Windows Vista/2008 and later 
   Module im_msvistalog
       Query <QueryList>                                                                         \
             <Query Id='1'>                                                                      \
              <Select Path="Application">*[System[(Level=1  or Level=2 or Level=3)]]</Select>    \
              <Select Path='Security'>*</Select>                                                 \
              <Select Path="System">*[System[(Level=1  or Level=2 or Level=3)]]</Select>         \
             </Query>                                                                            \
           </QueryList>
  # Uncomment im_mseventlog for Windows XP/2000/2003
#   Module im_mseventlog
    Exec to_json();
</Input>
 <Output out>
   Module om_tcp
   Host 10.0.2.8
   Port 3515
</Output>
 <Route 1>
   Path eventlog => out
</Route>

У 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) или через командную строку:

net start nxlog

 

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

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

Kibana1

Картинка с сайта: blog.it-kb.ru

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

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

Kibana2

Картинка с сайта: blog.it-kb.ru

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

Kibana3

Картинка с сайта: blog.it-kb.ru

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

Kibana4

Картинка с сайта: blog.it-kb.ru

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

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

Kibana5

Картинка с сайта: blog.it-kb.ru

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

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

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

http://www.elasticsearch.org/

http://nxlog.org/

https://www.digitalocean.com/community/tutorials/how-to-use-logstash-and-kibana-to-centralize-and-visualize-logs-on-ubuntu-14-04

http://www.ragingcomputer.com/2014/02/logstash-elasticsearch-kibana-for-windows-event-logs

Источник

This tutorial tells how to integrate data from Windows event log into our rsyslog configuration. We will do this integration via the UDP syslog protocol so that we finally can show this in a real case. No advanced topics are covered. We use CentOS 7 and Windows Server 2012 (because it still is in more widespread use). This is part of a rsyslog tutorial series.

Scope

We will introduce Windows Machine W into our configuration and make it forward its Event Log messages via UDP to LC. With the setup done in our last tutorial, LC will then relay the messages to syslog server LR. The choice if UDP is arbitrary. The intent is to finally have a system sending via UDP so that we can show how the configuration works. For practical deployments, TCP is probably a better option.

Note: you do not necessarily need to have followed the previous tutorial. Basically you just need to have a syslog server up and running to which we can send messages.

To configure the scenario, we only need to touch W. The rest of our tutorial scenario will remain as-is because it already provides the necessary functionality. When finished, our base lab scenario will be in the following configuration:

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

Note that we still do not configure any system to actually send data to LC. This will be done the next tutorial. Note that if you did not complete the last tutorial, it may be wise to have a look at it. We will work with the configuration it generated.

Prerequisites

You need to

  • know basic use and administration of Windows systems
  • have a working syslog server accepting messages via UDP (in the tutorial series this role is done by “LC”)

Installation

Rsyslog Windows Agent must be downloaded from the rsyslog site. It does not come pre-installed on Windows. The download page lists various versions. Pick the most current one (as of this writing: 6.0). Older versions are primarily provided for people who need a specific older version for a reason.

Note: in order to download the setup files in Windows Server hardened configuration, you need to add www.rsyslog.com to the trusted web zone.

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

Downloading the rsyslog Windows Agent.

You can download the agent software first or run it directly while downloading. In any case, a standard Windows installer will start. Accept the default and let the installation carry on. Note: depending on the components on your Windows machine, the installation make take some time and may even require a reboot. The latter is the case if parts of the .NET runtime need to be installed or updated.

Configuration

After installation, the configuration needs to be applied. The agent is configured via a Windows configuration program. Experts may also use a text-based configuration file format, but this is outside the scope of the tutorial.

Our use case of forwarding all Event Log messages to a syslog server is very common. As such, a default configuration for it already exists. We just need to make some adjustments to it.

Event Log Monitor

To apply the configuration changes, we start the program “rsyslog Windows Agent Configuration Client” and go to the predefined service.

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

The configuration already contains a so-called “Event Log Monitor V2” service. This is the service which reads the event log, formats its content in syslog-compatible format and hands it over to a rule set for processing. Reminder: although terminology and concepts between rsyslog Windows agent and rsyslog on Linux are similar, both have different code bases and slightly different methods to perform tasks.

If you like, you can also explore the additional tabs, most importantly “Event Channels”. The latter contains in-depth definitions of which exact event log channels to forward – and how to do that. As the defaults are sufficient for our simple use case, we do not modify anything there.

Forwarding to LC

To forward the messages to LC, we need a rule inside a rule set (just as on Linux). As such, we expand the default rule set and its rule. We select the “Rsyslog” action and can edit the defaults.

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

Rsyslog Windows Agent forwarding defaults right after installation.

Note that the default protocol is TCP, because it is the best choice for most environments. However, we want to use UDP for our lab, so we need to change that setting. Also note that we need to change the target syslog server address. Place to IP address or hostname of LC into that field. We do not need to change the port number, because we use the same default. If you do not follow the tutorials in sequence, be sure to place the correct port your syslog server is using into the respective dialog.

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

Rsyslog Windows Agent with configuration changes applied.

Note that we do not use most of the customization options. You can explore them via the Windows Agent documentation. You usually need to make adjustments depending on your intended enterprise configuration. For clarity, we have limited ourselves to minimal changes.

Checking that everything works

Save your configuration. Do not forget to start (or restart) the Windows Agent when you have applied configuration changes. Like rsyslog on Linux its Windows counterpart also needs a restart to activate configuration changes. It also supports centralized auto-configuration management, but this is an advanced topic we will not cover in the tutorials.

After the Windows Agent has been restarted, it will quickly send messages to LC, which in turn forwards them to LR, which in turn writes them to its local messages file. Note that LC will not record the messages itself because we prevented this in the previous tutorial. If you check both messages files, you should see this:

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

Windows messages present on LR (bottom), but not on LC (top).

If there is any problem, you can simply restart to Rsyslog Windows Agent to generate a new Windows event. A more advanced debugging technique is to reset to so-called “Last Record” to a lower value (or zero). This setting controls which event of the respective channel has been transmitted last. If you re-set it, Windows Agent will re-process all events from the record number you set it to. You can press the “Reload All LastRecords” buttons to obtain current values.

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

Important: if you modify “Last Record”, be sure to save the configuration!

This concludes the tutorial. If you have time left, I suggest to play a little bit with the several settings of Windows Agent. You may find it especially interesting to try the various format options given on the main Event Log monitor configuration dialog. Keep on your mind that Windows Agent is highly customizable and all canned formats can be overridden by formats that your enterprise setup requires. The agent can also pre-filter events. This is often used to drop “noise events” right at the source.

Result

We are now sending event log entries from Windows server W to LC, and make LC forward them to LR, which currently is the final destination. LR will write these entries to its usual log files. The Rsyslog Windows Agent on machine W is configured almost in default configuration, we just changed the protocol to UDP and adjusted the target server (LC).

Note that we use UDP not because it offers advantages here: we simply use it so that we have a system sending UDP in our lab scenario. Most often, this role is played by some (low-end) routers which do not offer any other choice.

In order to achieve this setup, we installed Windows Agent and adjusted its configuration. We did not need to change anything on the Linux systems as their setup was already done in the last tutorial – and is now actually being used for the first time in our tutorial series.

Additional Info

As a functional enhancement for Rsyslog Windows Agent, you can also use MonitorWare Agent or EventReporter.

Источник

В этой публикации я покажу пример того как осуществляется Сбор журналов Windows в Elasticsearch. Примеры развертывания кластера Elasticsearch и хоста с Kibana уже есть в моём блоге. Можете использовать их в качестве опорных руководств по развертывания соответствующих компонентов.

Схема решения

Логическая схеме решения приведена ниже.

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

Схема ниже отображает физическую топологию решения.

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

Выполним подготовку на стороне Elasticsearch.

1. Сначала я создам отдельную роль через Dev Tools для работы с индексами:

https://192.168.56.36:5601/app/dev_tools

2. Для этого я выполню следующий запрос:

POST _security/role/windows_server_logs
{
  "cluster": ["manage_index_templates", "monitor", "manage_ilm"], 
  "indices": [
    {
      "names": [ "windows*" ], 
      "privileges": ["write","create","create_index","manage","manage_ilm","view_index_metadata","auto_configure","all"]  
    }
  ]
}

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

3. Теперь я создам отдельного пользователя:

POST _security/user/windows_server_logs_user
{
  "password" : "Qwerty123",
  "roles" : [ "windows_server_logs","ingest_admin","kibana_admin"],
  "full_name" : "Logstash User for store logs from Windows Host"
}

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

4. Теперь необходимо скопировать сертификат корневого центра сертификации Elasticsearch, т.к. я использую сертификат от внутреннего ЦС, который был настроен при установке Elasticsearch. На любом из узлов Elasticsearch выполните команду:

cat /etc/elasticsearch/certs/http_ca.crt

Затем скопируйте содержимое файла в файл http_ca.crt (или любое на ваше усмотрение) на сервере с Winlogbeat. Пусть до этого сертификата корневого ЦС нужно будет указать в конфигурационном файле Winlogbeat.

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

Предварительная подготовка на стороне Elasticsearch завершена.

Настройка Winlogbeat

Для того чтобы настроить сбор журналов Windows в Elasticsearch необходимо выполнить следующие действия на хосте Windows:

1. Установить Winlogbeat.

2. Открыть на редактирование конфигурационный файл сервиса Winlogbeat.

"C:\Program Files\Winlogbeat\winlogbeat.yml"

3. Указать параметры сбора и отправки событий. Пример моего конфигурационного файла:

winlogbeat.event_logs:
  - name: Application
    ignore_older: 72h

  - name: System

  - name: Security

  - name: Microsoft-Windows-Sysmon/Operational

  - name: Windows PowerShell
    event_id: 400, 403, 600, 800

  - name: Microsoft-Windows-PowerShell/Operational
    event_id: 4103, 4104, 4105, 4106

  - name: ForwardedEvents
    tags: [forwarded]

# ====================== Elasticsearch template settings =======================

setup.template.settings:
  index.number_of_shards: 1

# ================================== General ===================================

tags: ["windows", "iis"]

# ---------------------------- Elasticsearch Output ----------------------------
output.elasticsearch:
  hosts: ["https://192.168.56.40:9200","https://192.168.56.37:9200"]
  index: "windows-%{+YYYY.MM.dd}"
  username: windows_server_logs_user
  password: Qwerty123
  protocol: https
  ssl.certificate_authorities: ["C:\\Program Files\\Winlogbeat\\http_ca.crt"]

setup.template:
  name: "windows_log"
  pattern: "windows-*"
  

# ================================= Processors =================================
processors:
  - add_host_metadata:
      when.not.contains.tags: forwarded
  - add_cloud_metadata: ~

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

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

4. Сохраняем внесенные изменения в конфигурационный файл Winlogbeat.

5. Перезапускаем службу Winlogbeat.

Restart-Service winlogbeat

Проверка

1. Сначала выполним проверку конфигурации Winlogbeat:

cd 'C:\Program Files\Winlogbeat\'
./winlogbeat test config
./winlogbeat test output
PS C:\Users\Administrator> cd 'C:\Program Files\Winlogbeat\'
PS C:\Program Files\Winlogbeat> ./winlogbeat test config
Config OK
PS C:\Program Files\Winlogbeat> ./winlogbeat test output
elasticsearch: https://192.168.56.40:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.56.40
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 8.13.2
elasticsearch: https://192.168.56.37:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.56.37
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 8.13.2
PS C:\Program Files\Winlogbeat>

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

2. Теперь перейдем в панель управления Kibana и убедимся, что наш шаблон индекса создан:

https://192.168.56.36:5601/app/management/data/index_management/templates

Шаблон индекса должен быть создан автоматически.

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

3. Теперь проверим наличие потоков данных:

https://192.168.56.36:5601/app/management/data/index_management/data_streams

Количество потоков данных зависит от даты последних событий в журналах Windows на исходной системе. В моем случае потоков было более 20 штук:

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

4. Последним шагом перейдем в панель Discover:

https://192.168.56.36:5601/app/discover

И создадим представление:

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

Имя можете указать любое, но вот шаблон нужно указать тот, что вы указывали в конфигурационном файле Winloagbeat.

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

Если вы все сделали верно, то в вашем представлении должны появиться данные с вашего хоста Windows с Winlogbeat:

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

Если что-то не работает

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

cd 'C:\Program Files\Winlogbeat\'
.\winlogbeat.exe -c .\winlogbeat.yml -e -v -d "*"

Если есть какие-то ошибки то они должны вывестись на консоль.

Журналы расположены вот тут:

C:\ProgramData\winlogbeat\Logs

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

logging.level: debug
logging.to_files: true
logging.files:
  path: C:\ProgramData\winlogbeat\Logs
  name: winlogbeat
  keepfiles: 7
  permissions: 0640

Источник

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Как сделать прозрачную панель задач windows 10 wallpaper engine
  • Pip install tkinter windows
  • Запуск приложения через rdp без рабочего стола windows 10
  • Драйвер для arduino mega 2560 windows 10
  • Красивая настройка рабочего стола в windows 10