Серый кардинал без посредников. Настраиваем потоки и алерты, пишем декодер для Graylog 7.1

В статье «Се­рый кар­динал мира логов» я показы­вал, как раз­вернуть сер­вер Graylog 5.2, уста­новить Java, MongoDB и OpenSearch и нас­тро­ить базовый сбор логов с хос­тов под управле­нием Linux и Windows.

Ло­ги из auditd, rsyslog, Sysmon и Winlogbeat в моей домаш­ней лабора­тории начали сте­кать­ся на цен­траль­ный сер­вер. Теперь мой «серый кар­динал» тихо сидит в локаль­ной сети и собира­ет все необ­ходимое. Но это толь­ко начало. Сегод­ня прев­ратим Graylog из прос­того сбор­щика логов в активно­го помощ­ника.

Даль­ше ты научишь­ся:

• соз­давать потоки (streams) — выделять в отдель­ные лен­ты события с кон­крет­ных сер­веров, ошиб­ки опре­делен­ных типов и подоз­ритель­ную активность;
• нас­тра­ивать алер­ты (alerts) — вклю­чать уве­дом­ления по элек­трон­ной поч­те о важ­ных событи­ях, нап­ример о десят­ке неудач­ных логинов за минуту или вне­зап­ном появ­лении сло­ва error в логах ядра.

Я про­дол­жаю работать в домаш­ней лабора­тории на хос­тах с Windows, Linux и macOS, но все при­меры уни­вер­саль­ны. Можешь выб­рать любой дис­три­бутив Linux — их бес­числен­ное мно­жес­тво.

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

Обновление Graylog

Рань­ше я исполь­зовал Graylog 5.2, но сей­час уже выш­ла вер­сия 7.1.3. Ее я и уста­новил, пред­варитель­но сох­ранив копию кон­фига /etc/graylog/server/server.conf. Это важ­но: в нем хра­нят­ся парамет­ры вза­имо­дей­ствия ком­понен­тов сис­темы и дан­ные для дос­тупа к веб‑интерфей­су. Поз­же мы допол­ним кон­фиг — я рас­ска­жу, что и зачем в него добавить. Будет инте­рес­но!

Об­новить сам Graylog мож­но так же, как и дру­гие пакеты для Linux. Есть два пути:

1. Ес­ли в спис­ке зер­кал репози­тори­ев ука­зан репози­торий Graylog, ты смо­жешь авто­мати­чес­ки обновлять ПО до пос­ледней вер­сии.
2. Дру­гой вари­ант — ска­чать пакет и уста­новить его вруч­ную.

Я выб­рал вто­рой путь — и не потому, что дос­туп к зер­калу пакетов из Рос­сии огра­ничен. Я пред­почитаю обновлять­ся вруч­ную, уста­нав­ливая пакет из ска­чан­ного фай­ла. Не буду под­робно опи­сывать про­цесс: ты и сам прек­расно зна­ешь, как это дела­ется.

На что сто­ит обра­тить вни­мание? Преж­де все­го — на сов­мести­мость вер­сий ПО в сте­ке Graylog. Судя по информа­ции, которую раз­работ­чики опуб­ликова­ли в откры­том дос­тупе, для пол­ноцен­ной работы Graylog 7.1 нуж­ны ком­понен­ты опре­делен­ных вер­сий, перечис­ленные на скрин­шоте ниже.

У меня в сис­теме как раз уста­нов­лена вер­сия 2.19.5.

И MongoDB 7.0.32.

Я ска­чал пакет Graylog 7.1.3 — на момент под­готов­ки финаль­ного вари­анта это была пос­ледняя вер­сия акту­аль­ной мажор­ной вет­ки. Затем рас­паковал пакет, заменил /etc/graylog/server/server.conf сво­ей сох­ранен­ной копи­ей и открыл веб‑интерфейс.

Осо­бых изме­нений я не заметил, но появи­лись и новин­ки. Мы раз­берем­ся, как они работа­ют и как ими поль­зовать­ся.

Создаем потоки (Streams): разделяем логи по смыслу

Что же такое потоки? Пред­ставь, что наш сер­вер — это одна сетевая пап­ка, куда сбра­сыва­ются логи. Ник­то их не сор­тиру­ет: все лежит в одном мес­те. Но хотелось бы рас­пре­делять логи в зависи­мос­ти от пред­почте­ний. При этом на уров­не сис­темы все, по сути, оста­нет­ся как преж­де.

Ло­ги пос­тупа­ют на опре­делен­ные пор­ты, то есть во вхо­ды. Непонят­но? Не паникуй, сей­час все объ­ясню.

Те­перь все логи сте­кают­ся в одно мес­то. Открой раз­дел Search — и уви­дишь сплош­ной поток сооб­щений: сис­темные события, ошиб­ки при­ложе­ний и записи ауди­та безопас­ности. В такой каше слож­но ори­енти­ровать­ся, осо­бен­но ког­да источни­ков ста­новит­ся все боль­ше.

Имен­но для это­го в Graylog пре­дус­мотре­ны потоки (Streams). Поток — логичес­кая груп­па сооб­щений, объ­еди­нен­ных по задан­ным пра­вилам. По сути, это филь­тр, который авто­мати­чес­ки рас­кла­дыва­ет вхо­дящие логи по раз­ным «пап­кам». Все сооб­щения по‑преж­нему хра­нят­ся в одном индексе OpenSearch, но в интерфей­се Graylog ты можешь перек­лючать­ся меж­ду потока­ми и работать толь­ко с нуж­ными логами.

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

За­чем нуж­ны потоки?

1. Удобс­тво работы — тебе не при­дет­ся каж­дый раз сос­тавлять слож­ные поис­ковые зап­росы, что­бы отде­лить логи Windows от логов Linux, а события безопас­ности — от отла­доч­ных сооб­щений. Ты нас­тра­иваешь поток, и в него попада­ют толь­ко сооб­щения, которые соот­ветс­тву­ют задан­ным кри­тери­ям.
2. Бе­зопас­ность и раз­гра­ниче­ние дос­тупа — для каж­дого потока мож­но задать свои пра­ва дос­тупа. Нап­ример, в про­де адми­нис­тра­торы баз дан­ных будут видеть толь­ко логи сво­их СУБД, а коман­да безопас­ности — толь­ко события аутен­тифика­ции.
3. Алер­ты и уве­дом­ления — для каж­дого потока мож­но нас­тро­ить свои уве­дом­ления. Нап­ример, ты можешь соз­дать пра­вило: если за пять минут в потоке «События безопас­ности» про­изош­ло десять неудач­ных попыток вхо­да, отпра­вить алерт в Telegram или по дру­гому каналу свя­зи.
4. Ви­зуали­зация — даш­борды мож­но стро­ить на осно­ве потоков или гло­баль­ного поис­ка. С помощью потоков ты соз­дашь отдель­ные панели монито­рин­га для раз­ных задач.

Как это работа­ет?

Соз­давая поток, ты зада­ешь одно или нес­коль­ко пра­вил. Каж­дое из них про­веря­ет ука­зан­ное поле сооб­щения. Если сооб­щение соот­ветс­тву­ет всем пра­вилам по логике И, оно попада­ет в поток. Что­бы исполь­зовать логику ИЛИ, объ­еди­ни пра­вила в груп­пу.

В зависи­мос­ти от нас­тро­ек пра­вила могут быть очень гиб­кими:

• ра­венс­тво поля задан­ному зна­чению (source == "web-server-01");
• на­личие подс­тро­ки (message содер­жит Out of memory);
• срав­нение чисел (event_id >= 4624);
• про­вер­ка по регуляр­ным выраже­ниям
• и мно­гие дру­гие усло­вия. Выбор зависит от тво­их пред­почте­ний.

Что у нас есть сей­час? Я уже нас­тро­ил получе­ние событий с хос­тов Windows и Linux. Это два типа событий, которые пос­тупа­ют на раз­ные вхо­ды сер­вера. Теперь в потоках нуж­но видеть:

1. Windows Logs — все сооб­щения от Winlogbeat и Sysmon, толь­ко с хос­тов Windows.
2. Linux Logs — сооб­щения с моих хос­тов Linux, получен­ные по Syslog через UDP. Поз­же я пере­име­новал этот поток.
3. Security Events — события аутен­тифика­ции и дос­тупа с event_id 4624, 4625, 4648 и так далее. Сюда попада­ют события с хос­тов Windows и РЕД ОС — поп­робу­ем объ­еди­нить их для обще­го ана­лиза.
4. Errors — сооб­щения со сло­вами error или critical со всех хос­тов.

Нач­нем с двух базовых потоков — для Windows и Linux. Поз­же мы нас­тро­им для каж­дой груп­пы свои алер­ты и даш­борды. Раз­берем­ся с потока­ми — даль­ше будет про­ще: они помогут раз­делить всю мешани­ну дан­ных, которая при­лета­ет на сер­вер.

Создаем потоки в Windows и Linux

От­кры­ваем веб‑интерфейс Graylog — по умол­чанию он дос­тупен на пор­те 9000 — и вхо­дим с учет­ной записью admin.