Налаштування SIEM через Wazuh для виявлення загроз

Wazuh налаштування: чому події не перетворюються на сигнали

Збір логів і виявлення загроз — дві різні задачі, і налаштування Wazuh найчастіше спотикається саме на стику.

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

У підсумку розбір логів іде, а сигналу немає: у консолі тисячі подій, з них нуль алертів щодо реальної атаки.

Ціна такої конфігурації проявляється в момент інциденту. Підбір облікових даних до сервісу, аномальний вхід у неробочий час, серія відмов авторизації з однієї адреси — усе це лежить у логах, але не піднімає тривогу.

Інцидент виявляється постфактум, коли про нього повідомляє користувач або підрядник, а розбір починається з ручного пошуку по сирих подіях замість готової хронології.

Друга типова причина — шум. Коли правила спрацьовують на будь-яке відхилення, потік хибних спрацювань зростає швидше, ніж команда встигає його розбирати.

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

Wazuh налаштування починається не з правки конфігурації, а з інвентаризації джерел: які журнали вже збираються, які події взагалі здатні вказати на загрозу у вашому контурі, де проходить межа між нормою та відхиленням.

Далі правила кореляції прив'язуються до реальних сценаріїв — ланцюжків подій, а не одиночних записів, а пороги та винятки виставляються так, щоб прибрати фоновий шум без втрати чутливості.

Розбираємо, як це закривається: від ревізії джерел і налаштування правил до перевірки на навчальних сценаріях, коли ми навмисно відтворюємо атаку й переконуємося, що сигнал піднявся, дійшов до чергового й містить достатньо контексту для реакції.

Що дає вибудувана система виявлення загроз

Система виявлення загроз вимірюється не кількістю встановлених агентів, а часом від першої підозрілої події до зрозумілої реакції.

Поки журнали серверів, мережевого обладнання та хмарних сервісів лежать у різних місцях, а розбір інциденту починається з ручного збору логів, будь-яка атака виграє у захисників години й доби.

Саме це вікно і закриває вибудувана система на базі Wazuh: події стікаються в єдине сховище, правила кореляції спрацьовують на ланцюжок дій, а черговий отримує не потік сирих рядків, а готову картину з контекстом.

Перший вимірюваний ефект — скорочення часу до виявлення. Замість того щоб дізнаватися про проблему від користувачів або зі звіту за підсумками тижня, команда бачить аномалію в момент її розвитку: підозрілий вхід, зміна привілеїв, звернення до нестандартного порту.

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

Другий ефект — керована частка хибних спрацьовувань. Правила налаштовуються під реальну інфраструктуру: відомі адміністративні скрипти, планові завдання, легітимні сканери виводяться у винятки, а пріоритети виставляються за критичністю активу.

Черговий перестає тонути в шумі й реагує на те, що дійсно потребує уваги, — інакше за пару тижнів сигнали просто перестають читати.

Третій — покриття класів атак і видимість інфраструктури. Перевіряються сценарії підбору облікових даних, підвищення привілеїв, підозрілої активності на хостах і в контейнерах, змін цілісності файлів.

Кожне правило прив'язане до джерела подій, тому видно, які вузли та сервіси реально під наглядом, а які залишилися сліпою зоною. Реагування на інциденти стає відтворюваним: є маршрут ескалації, типові дії за класами загроз і матеріал для розбору після закриття.

Підсумок — не «ще один інструмент», а передбачуваний контур: зрозумілий час до виявлення, контрольований шум, відоме покриття і відпрацьований порядок дій при інциденті.

Способи розгортання та збору подій

Wazuh налаштування починається з вибору архітектури розгортання, і цей вибір визначає, які події взагалі потраплять у кореляцію.

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

Універсальної відповіді немає: схема диктується тим, які системи в контурі та наскільки глибоко потрібно бачити те, що відбувається всередині них.

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

Мережевий збір, навпаки, не вимагає нічого ставити на вузли: трафік знімається з дзеркального порту або точки агрегації та розбирається на боці колектора. Це зручно для сегментів, куди агент не поставити — мережеве обладнання, промислові контролери, чужі підмережі.

Гібрид закриває змішані контури, але вимагає акуратної нормалізації: події з різних джерел повинні потрапляти в загальну схему полів, інакше кореляційні правила працюють вхолосту.

На практиці схему обирають за кожним сегментом окремо, а не на всю інфраструктуру загалом. Починаємо з інвентаризації джерел подій: що вже віддає журнали, що доступне лише по мережі, де взагалі немає телеметрії.

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

Етапи впровадження: від аудиту до передачі в експлуатацію

Впровадження починаємо з обстеження: збираємо перелік джерел подій — сервери, мережеві пристрої, застосунки, хмарні сервіси, — фіксуємо, які журнали вже пишуться і в якому форматі, де вони губляться під час перезапуску.

На виході — карта покриття: які вузли видно, які ні, і що дасть найбільший приріст виявлення першими.

1. Аудит інфраструктури. Інвентаризація вузлів і джерел, оцінка навантаження на збір подій, перевірка, що критичні журнали не вимкнені й зберігаються достатньо довго для розбору інцидентів.
2. Проєктування схеми. Визначаємо топологію: де стоять збирачі, як події доходять до аналітичного вузла, як розділяємо потоки за критичністю. Заздалегідь плануємо відмовостійкість — втрата вузла не повинна залишати нас без видимості.
3. Налаштування правил. Пишемо й адаптуємо правила кореляції під реальні сценарії: підозрілий вхід, ескалація привілеїв, зміна критичних конфігурацій. Кожне правило тестуємо на хибні спрацювання — шум в оповіщеннях знецінює систему швидше, ніж пропуск.
4. Перевірка сценаріїв. Проганяємо контрольовані імітації атак і аномалій, дивимося, чи спрацювало правило, чи дійшло оповіщення до чергового, чи вистачає контексту для рішення. Ітеративно підкручуємо пороги.
5. Передача в експлуатацію. Оформлюємо регламенти реагування, навчаємо чергову зміну, налаштовуємо маршрутизацію оповіщень. Передаємо документацію й залишаємося на зв'язку на період супроводу.

Така послідовність дає передбачуваний результат: на момент запуску команда розуміє, що бачить система, як на це реагувати і куди дивитися під час розбору. Обговоримо ваше завдання — повернемося з оцінкою та планом за етапами.

Правила кореляції та пріоритизація сигналів

Правила кореляції в Wazuh — це шар, який перетворює потік сирих подій на обмежений набір інцидентів.

Базовий движок розбирає логи за декодерами, зіставляє з сигнатурами та присвоює рівень критичності; завдання інженера — налаштувати правила так, щоб спрацювання відображали реальну загрозу, а не активність сканерів і штатних завдань. Без цієї роботи черга алертів зростає швидше, ніж аналітик встигає її розбирати.

Відсікання шуму до пріоритизації

Першим кроком прибираємо хибні спрацювання на джерелі: виключаємо довірені підмережі, службові облікові записи, планові завдання та відомі сканери вразливостей.

Далі групуємо пов'язані події в одне правило — наприклад, серія невдалих входів із подальшим успішним логіном з тієї самої адреси дає один інцидент замість десятків рядків. Так черга скорочується в рази, а значущі події не тонуть у фоні.

Рівні та маршрутизація сигналів

Пріоритизація будується на рівнях критичності та порогах: низькі рівні йдуть в архів для ретроспективи, середні — у чергу на розбір, високі — на негайне оповіщення чергового.

Пороги підбираємо за частотою спрацювань на реальному трафіку, а не «на око»: правило, яке спрацьовує сотні разів на добу, марне незалежно від рівня. Для кожного сценарію фіксуємо умову ескалації та відповідального.

Перевірка правил на живому потоці

Налаштовані правила проганяємо на історичних логах і контрольованих сценаріях — імітуємо підозрілий вхід, зміну привілеїв, звернення до чутливого ресурсу. Дивимося, чи спрацювало правило, на якому рівні, чи не породило дублів.

Підсумок налаштування — передбачувана черга, де кожна подія має зрозумілу причину спрацювання та власника.

Що замовник отримує після впровадження

Впровадження закінчується не запущеним сервером, а комплектом, за яким систему можна експлуатувати, передати іншій команді та пройти перевірку. Усе, що ми налаштовуємо, фіксується в артефактах: конфігурації, схеми, політики доступу, регламенти реагування та документація.

• Конфігурації — файли правил і декодерів, налаштування збору логів із серверів, мережевого обладнання та застосунків, параметри зберігання й ротації подій. Усе в системі контролю версій, щоб зміна правил проходила рев'ю, а не правилася руками на проді.
• Схеми інфраструктури — потік даних від джерела до сховища подій: де стоять агенти, що збирається напряму, як влаштовані сегменти та точки відмови. Схема знімає половину питань під час підключення нового вузла.
• Політики доступу — ролі та права для аналітиків, чергової зміни й підрядників, розподіл зон відповідальності, порядок надання та відкликання доступів. Окремо фіксуємо, хто і на якій підставі бачить чутливі події.
• Регламенти реагування — за кожним класом спрацювань: що вважається інцидентом, кому надходить повідомлення, за який час, хто ухвалює рішення і як закривається запис. Правила узгоджені з вашою службою, а не написані «для галочки».
• Документація — інструкція з експлуатації, порядок оновлення правил, чек-ліст підключення нового джерела, опис типових збоїв і дій чергового.
• Звіт про приймання — які сценарії атак перевірені, як система на них відреагувала, які правила дають хибні спрацювання і що з цим зроблено.

Комплект залишається у вас: команда може розвивати систему сама або передати її іншому підряднику без відновлення логіки з пам'яті. Опишіть задачу — повернемося з оцінкою та планом.

Чим відрізняється налаштування Wazuh від типового впровадження SIEM

Wazuh — це відкрита платформа для виявлення загроз, моніторингу цілісності файлів і контролю безпеки, побудована навколо агентів на кінцевих вузлах.

На відміну від класичних SIEM, які насамперед збирають і корелюють події з мережевих пристроїв і застосунків, Wazuh від початку ставить агент на сам хост — сервер, робочу станцію, контейнер — і звідти знімає телеметрію: зміни файлів, підозрілі процеси, спроби підвищення привілеїв, стан конфігурацій.

Це змінює логіку впровадження: ви не просто налаштовуєте приймання логів, а розгортаєте керовану агентську мережу з централізованими політиками.

Класичний SIEM сильний у кореляції подій із різнорідних джерел і побудові аналітики за великим потоком даних, але потребує окремого агента для кожного типу джерела і часто залишає хостововий рівень осторонь.

Wazuh закриває саме цей шар: вбудовані модулі перевірки цілісності, сканування вразливостей і виявлення вторгнень працюють з коробки, без придбання додаткових ліцензій на кожен вузол.

Тому вибір між підходами — це питання про те, що для вас критичніше: глибина видимості на кінцевих точках чи широта охоплення мережевої інфраструктури.

Специфіка налаштування Wazuh проявляється в кількох речах. Правила виявлення описуються декларативно і успадковуються між групами агентів, тому одна політика застосовується до сотні серверів без ручного редагування на кожному.

Порогові значення та винятки налаштовуються на рівні правил, а не розмазуються по конфігурації кожного вузла.

Нарешті, Wazuh добре поєднується з класичним SIEM: агенти збирають хостові події, а платформа передає їх далі в загальний контур кореляції — так ви отримуєте і глибину, і широту.

Це важливо, коли інфраструктура розподілена, частина вузлів перебуває поза периметром, а штат безпеки обмежений. Тоді агентська модель із централізованими політиками дає передбачуване покриття без роздування команди.

Якщо ж основне завдання — кореляція мережевих подій і відповідність вимогам регулятора щодо журналювання, класичний SIEM залишається базою, а Wazuh доповнює її хостовим шаром.

Кейс: скорочення часу виявлення в розподіленій мережі

Що було до

Розподілена мережа: кілька майданчиків, десятки сервісів, частина трафіку йде між сегментами. Логи збиралися по серверах — кожен у свій файл, зі своїм форматом часу. Розбір інциденту починався з питання «а де взагалі дивитися».

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

Середній час від події до підтвердженої гіпотези тримався на рівні 6-8 годин.

Частина атак — перебір паролів за сервісними обліковими записами, горизонтальне переміщення між вузлами — не виявлялася взагалі: поодинокі події не виглядали підозріло, а кореляції між ними ніхто не рахував.

Що змінили

Розгорнули Wazuh як єдиний шар збору та кореляції: агенти на вузлах, централізований індекс, нормалізація часу та полів із різнорідних джерел. Далі — правила виявлення під нашу топологію, а не типовий набір з коробки.

• Кореляція за кількома подіями: серія невдалих входів, потім успішний — спрацьовує як один інцидент, а не як десять записів у лозі.
• Окремі правила на горизонтальне переміщення: аномальні підключення між сегментами, які в нормі не спілкуються напряму.
• Контроль цілісності файлів на критичних вузлах — зміна конфігурації або підміна бінарника дає сигнал одразу.
• Пріоритизація за критичністю вузла: алерт з периметра і алерт з тестового стенда не змішуються в одну чергу.

Що стало

Час виявлення скоротився з 6-8 годин до 15-40 хвилин — переважно завдяки тому, що кореляція йде на стороні системи, а не в голові чергового.

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

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

Часті технічні сумніви щодо налаштування Wazuh

Сумніви зазвичай однакові: чи приживеться агент на наявних серверах, чи не з'їсть він ресурси продакшену, чи не потоне команда у спрацьовуваннях і що буде з оновленнями. Нижче — як ці питання закриваються на практиці, без обіцянок «поставимо і запрацює».

Яким буде навантаження на сервери та мережу?

Агент тримає буфер на диску й надсилає події пакетами, тому піки не б'ють по процесору. На типовому вузлі споживання — одиниці відсотків, але точну цифру дає лише замір на вашому профілі навантаження: ми знімаємо метрики до і після на пілотній групі.

Мережу обмежуємо стисненням і розкладом надсилання, а на слабких каналах ставимо проміжний вузол-агрегатор.

Чи не потонемо ми в хибних спрацьовуваннях?

Базовий набір правил шумить — це нормально для старту. Перші тижні йдуть на налаштування: вимикаємо нерелевантні правила, додаємо списки виключень за вашими сервісами, знижуємо пріоритет відомих адміністративних дій.

Мета — не «нуль спрацьовувань», а передбачуваний потік, де кожна подія вимагає дії. Поріг чутливості підбираємо за вашим середовищем, а не за замовчуванням.

Що з оновленнями та відкатом?

Правила й конфігурація зберігаються в системі контролю версій, тому будь-яку зміну можна відкотити. Оновлення ставимо спочатку на тестовий контур, перевіряємо на копії трафіку, потім розгортаємо на продакшен.

Версії агентів і сервера тримаємо сумісними, а перед великим оновленням знімаємо знімок стану — повернення займає хвилини, а не години розбору.

Якщо щось із цього викликає питання щодо вашого середовища — опишіть задачу, повернемося з оцінкою та планом.

Обговоримо ваше завдання щодо виявлення загроз

Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен мінімум вхідних даних про вашу інфраструктуру. Збираємо їх в одній розмові: які джерела подій уже є, де вони зберігаються, хто відповідає за доступи. За цими даними будуємо план робіт і називаємо терміни — без попереднього аудиту «на око».

Що допомагає нам швидко оцінити обсяг і не вигадувати зайвого:

• Перелік джерел подій: сервери та робочі станції, мережеве обладнання, хмарні сервіси, застосунки — що з цього вже віддає журнали, а що поки ні.
• Поточний стан: чи є збір журналів, куди вони пишуться, як довго зберігаються, хто і як їх сьогодні переглядає.
• Схема мережі та сегментація: де проходять межі, які вузли критичні, чи є ізольовані контури.
• Вимоги до виявлення: які класи загроз у пріоритеті — вхід за підозрілими обліковими записами, зміни привілеїв, аномалії на серверах, витоки даних.
• Обмеження щодо доступів і регламентів: що можна ставити на вузли, які політики безпеки діють, хто погоджує зміни.
• Відповідальні з вашого боку: хто прийме систему, хто буде розбирати спрацювання після запуску.

Підхід до проєкту простий: спочатку закриваємо видимість — підключаємо джерела та налаштовуємо збір, потім правила виявлення під ваші сценарії, потім перевіряємо, що спрацювання надходять і розбираються.

Wazuh налаштування тут іде не «за мануалом», а під вашу картину загроз: набір правил і пріоритети залежать від того, що для вас справді критично.

Опишіть завдання у вільній формі — які системи потрібно покрити і що турбує зараз. Повернемося з оцінкою термінів, складом робіт і планом за етапами.