Киберзащита за малкия бизнес (част 4): Wazuh — SIEM за откриване на атаки

Това е четвъртата част от ръководството ни за киберзащита на малкия и среден бизнес. В предишните три части изградихме защита: защитен рутер (IPS/IDS/blacklist), защитен сървър (fail2ban, харднат стек) и частен облак Nextcloud с валиден сертификат. Сега идва нещо също толкова важно, но често пренебрегвано:

Не можеш да защитиш това, което не виждаш.

Защитите от предишните части работят денонощно — но как разбираш кога някой е опитал да влезе, кога е подменен файл, или че сървърът ти има непачната уязвимост? За това служи Wazuh — безплатна, отворена платформа, която превръща разпръснатите логове в ясни, подредени сигнали за сигурност. Всички адреси и имена в примерите са генерализирани.

Какво е Wazuh

Wazuh е open-source платформа за сигурност от тип SIEM (Security Information and Event Management) и XDR (Extended Detection and Response). На прост език: тя събира на едно място събитията по сигурността от всичките ти устройства, анализира ги по правила и те предупреждава, когато нещо изглежда нередно.

Важно е да се разбере какво Wazuh не е: това не е инструмент за графики на трафика и натоварването (за това има други решения — тях ще разгледаме в пета част). Wazuh гледа към сигурността: опити за пробив, промени по файлове, уязвимости, спазване на добрите практики. Двете се допълват.

Какво умее накратко:

• Анализ на логове от много източници, с корелация (свързва отделни събития в една атака).
• File Integrity Monitoring (FIM) — следи кои файлове се променят и кога.
• Откриване на уязвимости — сверява инсталирания софтуер срещу база с известни CVE.
• Security Configuration Assessment (SCA) — одит на системата спрямо стандарти за сигурност (CIS).
• Откриване на прониквания и (по желание) активен отговор — автоматично блокиране на атакуващ адрес.

Как работи Wazuh

Wazuh се състои от няколко компонента, които работят заедно:

Потокът на данните е прост: агент → manager (декодиране + правила) → indexer (съхранение) → dashboard (визуализация). Всяко правило има ниво от 0 до 16 — колкото по-високо, толкова по-важно е събитието.

А устройства без агент? (рутерът)

На мрежово оборудване като MikroTik рутер не можеш да инсталираш агент. За тях Wazuh ползва agentless подход през syslog — рутерът праща логовете си по мрежата към manager-а. Така събитията от рутера (логини, IPS банове) се събират на същото място като тези от сървъра. Към това ще се върнем в конфигурацията.

Какво трябва да следим

Един SIEM е толкова полезен, колкото са добре подбрани нещата, които следи. За типичен малък и среден бизнес ето кое носи най-голяма стойност:

• Неуспешни логини и brute-force — повтарящи се опити за вход (SSH, уеб панели, поща, рутер). Първият сигнал за насочена атака.
• Промени по важни файлове (FIM) — неочаквана промяна в системни конфигурации или в кода на уебсайта почти винаги означава компрометиране (напр. инжектиран web shell). На споделени папки FIM улавя и масово криптиране (ransomware).
• Уязвимости (CVE) — кой инсталиран софтуер има известни пробиви и трябва да се обнови.
• Спазване на добрите практики (SCA) — автоматичен одит дали системата е настроена сигурно (спрямо CIS бенчмарковете).
• Привилегировани действия — използване на sudo/root, създаване на нови потребители, промени в правата.
• Събития от мрежата — логини към рутера и задействания на неговата защита (IPS банове), на едно място с останалото.

Целта не е да гледаш всичко — а да изведеш значимото и да заглушиш шума. Точно затова в края ще напишем и собствени правила.

Инсталация

Ще ползваме официалния „all-in-one“ инсталатор, който слага manager, indexer и dashboard на една машина. За малък бизнес (няколко сървъра + рутер) това е напълно достатъчно. Изискване: 64-битова система, препоръчително 4+ ядра и 8+ GB RAM (indexer-ът обича паметта).

Бележка за сигурността: в идеалния случай Wazuh server-ът стои на отделна машина, не на тази, която наблюдава — ако наблюдаваната машина бъде превзета, наблюдателят трябва да остане независим. За по-малки бюджети е приемливо да е на същия сървър, стига да си наясно с компромиса.

Сваляме и стартираме асистента. Един важен детайл: ако на сървъра вече има уеб сървър (както в нашия случай — Nextcloud на порт 443), Wazuh dashboard ще се сблъска с него, защото и той по подразбиране иска 443. Решението е чисто — задаваме друг порт с -p:

curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash ./wazuh-install.sh -a -p 8443

Така dashboard-ът тръгва на порт 8443 и не пипа порт 443 на съществуващия сайт. Инсталаторът сам генерира сертификати и пароли — в края извежда адреса и паролата за admin. Запишете ги.

Уловка от практиката: на новите версии на Ubuntu системната услуга needrestart може да „замрази“ инсталацията по средата (изчаква интерактивен отговор, който никога не идва). Ако ви се случи, направете я неинтерактивна предварително: в /etc/needrestart/needrestart.conf задайте $nrconf{restart} = 'a'; и пуснете инсталатора пак. Друга добра практика — vulnerability detection работи най-гладко на поддържана LTS версия (напр. Ubuntu 22.04/24.04).

След няколко минути проверяваме, че всичко е вдигнато:

systemctl status wazuh-indexer wazuh-manager wazuh-dashboard
# и че dashboard-ът отговаря на новия порт:
curl -k -I https://localhost:8443

Конфигурация

1. Валиден сертификат и ограничен достъп

По подразбиране dashboard-ът е със самоподписан сертификат — браузърът ще се оплаква. Понеже вече имаме валиден Let’s Encrypt сертификат за домейна (от трета част), просто насочваме dashboard-а към него в /etc/wazuh-dashboard/opensearch_dashboards.yml:

server.ssl.certificate: "/etc/wazuh-dashboard/certs/le-fullchain.pem"
server.ssl.key:         "/etc/wazuh-dashboard/certs/le-privkey.pem"

(копираме файловете на сертификата с права за потребителя wazuh-dashboard и добавяме deploy-hook за автоматичното им подновяване).

Никога не отваряйте SIEM-а към целия интернет. Ако ви трябва достъп отдалечено, ограничете го само до доверената си мрежа. На рутера правим port-forward за 8443, но само от нашата администраторска мрежа:

/ip firewall nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=8443 \
    in-interface=ether1 src-address=198.51.100.0/24 \
    to-addresses=192.168.1.100 to-ports=8443 \
    comment="wazuh dashboard (само mgmt)"

Така dashboard-ът е достъпен от офиса/администраторската мрежа, но за всички останали в интернет той просто не съществува.

2. Сървърът да наблюдава себе си

Понеже manager-ът върви на същата машина, той я наблюдава директно. Допълваме наблюдението с най-ценното за един уеб сървър — FIM върху кода на сайта (за да хванем инжектиран web shell) и събиране на специфичните логове. Добавяме отделен блок в /etc/wazuh-manager/ossec.conf (Wazuh слива няколко такива блока):

<ossec_config>
  <syscheck>
    <directories check_all="yes" realtime="yes">/var/www/nextcloud</directories>
    <nodiff>/var/www/nextcloud/config/config.php</nodiff>
  </syscheck>

  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/apache2/*error*.log</location>
  </localfile>
  <localfile>
    <log_format>json</log_format>
    <location>/path/to/nextcloud-data/nextcloud.log</location>
  </localfile>
</ossec_config>

С realtime="yes" промяна в кода се засича мигновено. Логините към операционната система (SSH, sudo) и към fail2ban се събират автоматично през journald, така че за тях няма какво да настройваме.

3. Рутерът (agentless през syslog)

Първо казваме на manager-а да слуша за syslog само от рутера. Нов блок в конфигурацията:

<ossec_config>
  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>
    <allowed-ips>192.168.1.1</allowed-ips>
  </remote>
</ossec_config>

После на MikroTik рутера добавяме действие „изпращай към syslog“ и правила кои събития да праща (логини, грешки, и нашите IPS банове от първа част):

/system logging action
add name=wazuh target=remote remote=192.168.1.100 remote-port=514 \
    src-address=192.168.1.1
/system logging add topics=account  action=wazuh
/system logging add topics=error    action=wazuh
/system logging add topics=critical action=wazuh
/system logging add topics=firewall action=wazuh

Целият трафик остава във вътрешната мрежа — нищо не се излага навън.

4. Собствени декодери и правила за рутера

Тук идва силата на Wazuh. По подразбиране той няма готови правила за MikroTik, така че суровите редове влизат неразпознати. Пишем собствен декодер, който разбира формата на RouterOS, и правила, които вдигат смислени сигнали. Пример за извличане на данните от логин и от IPS бан (в /etc/wazuh-manager/etc/decoders/local_decoder.xml):

<decoder name="mikrotik">
  <prematch type="pcre2">^(system|firewall|script|account),</prematch>
</decoder>

<decoder name="mikrotik-login">
  <parent>mikrotik</parent>
  <prematch>logged in from</prematch>
  <regex type="pcre2">user (\S+) logged in from (\S+) via (\w+)</regex>
  <order>dstuser, srcip, protocol</order>
</decoder>

И правилата (в local_rules.xml), които превръщат това в четими сигнали с подходящо ниво:

<group name="mikrotik,">
  <rule id="100100" level="0">
    <decoded_as>mikrotik</decoded_as>
    <description>MikroTik RouterOS event.</description>
  </rule>

  <rule id="100101" level="3">
    <if_sid>100100</if_sid>
    <match>logged in from</match>
    <description>MikroTik: user $(dstuser) logged in from $(srcip)</description>
  </rule>

  <rule id="100104" level="10">
    <if_sid>100100</if_sid>
    <match>IPS-BAN-</match>
    <description>MikroTik IPS: банван нападател $(srcip)</description>
    <group>ids,</group>
  </rule>
</group>

Преди да рестартираме, винаги тестваме правилата без риск с вградения инструмент:

echo "system,info,account user admin logged in from 198.51.100.9 via ssh" \
  | /var/ossec/bin/wazuh-logtest

Ако излезе нашето правило (id: 100101) с попълнени полета — готово. Сега вместо неразбираем ред, в dashboard-а виждаме чисто: „MikroTik: user admin logged in from 198.51.100.9“. Можем дори да добавим правило, което при няколко неуспешни логина от един и същ адрес за кратко време вдига сигнал за brute-force.

5. fail2ban и Wazuh заедно

Важно: Wazuh не заменя fail2ban от предишните части. Двете се допълват — fail2ban е „мускулът“ (мигновено блокира на място), а Wazuh е „очите и паметта“ (вижда цялата картина, свързва събитията, пази история и алармира). Заедно дават и реакция, и видимост.

Какво виждаме накрая

След като всичко е настроено, dashboard-ът показва на едно място: сигналите за сигурност по ниво на важност, картата на събитията, промените по файлове (FIM), резултата от одита за сигурност (SCA) и събитията от рутера. Един поглед сутрин е достатъчен, за да знаеш как е минала нощта.

Заключение

С Wazuh затворихме кръга: вече не само се защитаваме, а и виждаме какво се случва — опити за пробив, промени по файлове, уязвимости, събития от рутера, всичко на едно място и с разбираеми сигнали. Това е и сериозна стъпка към съответствие с NIS2/GDPR, които изискват именно журналиране, откриване и реакция на инциденти.

Остава последната тема от серията — мониторинг на инфраструктурата: натоварване, дисково пространство, мрежов трафик, наличност на услугите в реално време. На това ще посветим петата част. До скоро.

Тази серия е част от усилията ни сериозната киберзащита да стане достъпна за българския малък и среден бизнес.