Откриване на проникване в Linux: Ръководство за auditd, AIDE и Wazuh (2026)

Защо откриването на проникване е критично през 2026 г.

Защитната стена е заключената входна врата. SSH укрепването е здравата ключалка. Но какво правите, когато някой вече е вътре — или още по-лошо, когато дори не подозирате, че е влязъл? Ето тук на сцената излизат системите за откриване на проникване (Intrusion Detection Systems, IDS) и мониторингът на целостта на файловете.

Честно казано, цифрите за 2025 г. са доста притеснителни. Linux ядрото натрупа 5530 CVE уязвимости — ръст от 28% спрямо предходната година. Това са средно по 8–9 нови уязвимости всеки ден, само за ядрото, без да броим потребителското пространство и библиотеките. Рансъмуер групи като Qilin, Kraken и RansomHub са експлоатирали ядрени уязвимости срещу над 700 организации в 62 държави. А атаките тип brute-force представляват цели 89% от всички регистрирани поведения на крайни точки под Linux.

В предишните ни ръководства разгледахме укрепването на защитната стена с nftables и модерната SSH конфигурация с пост-квантова криптография. Тези мерки са безспорно критични за намаляване на повърхността на атака. Но нито една защита не е абсолютна — рано или късно нещо ще се промъкне. Нуждаете се от система, която да открие нарушителя, когато (не ако) периметърът бъде пробит.

В това ръководство ще изградим трислойна система за откриване на проникване, базирана на три мощни и допълващи се инструмента:

• auditd — вграденият в Linux одитен фреймуърк за проследяване на системни повиквания и достъп до файлове на ниво ядро
• AIDE — инструмент за мониторинг на целостта на файловете, който открива неоторизирани промени в критични системни файлове
• Wazuh — централизирана SIEM/XDR платформа с отворен код, която агрегира, корелира и визуализира данните от всички източници

Всички примери са тествани на Ubuntu 24.04 LTS и RHEL 9 с последните стабилни версии на инструментите към февруари 2026 г.

1. Linux Audit Framework (auditd) — одит на ниво ядро

Linux Audit Framework е вграден механизъм в ядрото, който записва свързани със сигурността събития — системни повиквания, достъп до файлове, мрежова активност, промени в потребителски акаунти и привилегировани операции. Може да го мислите като „черната кутия" на вашия Linux сървър. Той е първата линия на системата за откриване на проникване, защото работи на най-ниското възможно ниво — директно в ядрото.

1.1. Инсталация и начална конфигурация

На повечето корпоративни дистрибуции (RHEL, CentOS, AlmaLinux) auditd е предварително инсталиран. На Debian/Ubuntu обаче трябва да го инсталирате ръчно:

# Debian / Ubuntu
sudo apt update && sudo apt install auditd audispd-plugins

# RHEL / Fedora / AlmaLinux
sudo dnf install audit audit-libs

# Активиране и стартиране
sudo systemctl enable auditd
sudo systemctl start auditd

# Проверка на състоянието
sudo systemctl status auditd

Основната конфигурация на демона се намира в /etc/audit/auditd.conf. Ето ключовите параметри, които си заслужава да настроите от самото начало:

# /etc/audit/auditd.conf — Укрепена конфигурация

# Максимален размер на лог файла (в MB)
max_log_file = 50

# Действие при достигане на максималния размер
max_log_file_action = ROTATE

# Брой ротирани лог файлове
num_logs = 10

# Действие при запълване на дисковото пространство
space_left_action = EMAIL
space_left = 75

# Действие при критично ниско пространство
admin_space_left_action = HALT
admin_space_left = 50

# Размер на буфера (увеличете за натоварени системи)
buffer_size = 8192

# Режим при грешка — 2 означава паника на ядрото (за критични системи)
# 1 означава продължаване с отпечатване на предупреждение
failure_mode = 1

# Формат на логовете
log_format = ENRICHED

Параметърът log_format = ENRICHED заслужава специално внимание — той добавя информация за потребителски имена и имена на групи директно в логовете. На практика това ви спестява доста главоболия при последващия анализ, защото не се налага ръчно да правите справки за UID/GID стойности.

1.2. Писане на правила за одит

Правилата за одит определят какво точно ще бъде записвано. Те се съхраняват в /etc/audit/rules.d/ и се зареждат с augenrules --load. Нека създадем набор от правила, организирани по категории.

Мониторинг на критични системни файлове:

# /etc/audit/rules.d/10-critical-files.rules

# Мониторинг на файлове за удостоверяване
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/gshadow -p wa -k identity_changes
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation

# Мониторинг на SSH конфигурация
-w /etc/ssh/sshd_config -p wa -k sshd_config_change
-w /etc/ssh/ssh_config -p wa -k ssh_config_change
-w /root/.ssh/ -p wa -k root_ssh_keys

# Мониторинг на PAM конфигурация
-w /etc/pam.d/ -p wa -k pam_changes
-w /etc/security/ -p wa -k security_config

# Мониторинг на cron задачи
-w /etc/crontab -p wa -k cron_changes
-w /etc/cron.d/ -p wa -k cron_changes
-w /var/spool/cron/ -p wa -k cron_changes

Мониторинг на привилегировани операции:

# /etc/audit/rules.d/20-privileged-ops.rules

# Записване на всички изпълнения на команди от root
-a always,exit -F arch=b64 -F euid=0 -S execve -k root_commands
-a always,exit -F arch=b32 -F euid=0 -S execve -k root_commands

# Мониторинг на промени в мрежовата конфигурация
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k network_changes
-w /etc/hosts -p wa -k network_changes
-w /etc/sysconfig/network -p wa -k network_changes
-w /etc/network/ -p wa -k network_changes

# Мониторинг на зареждане на ядрени модули
-w /sbin/insmod -p x -k kernel_modules
-w /sbin/rmmod -p x -k kernel_modules
-w /sbin/modprobe -p x -k kernel_modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k kernel_modules

Правила за откриване на Living Off the Land (LOTL) атаки:

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

# /etc/audit/rules.d/30-lotl-detection.rules

# Подозрително използване на инструменти за разузнаване
-w /usr/bin/wget -p x -k data_exfiltration
-w /usr/bin/curl -p x -k data_exfiltration
-w /usr/bin/nc -p x -k data_exfiltration
-w /usr/bin/ncat -p x -k data_exfiltration
-w /usr/bin/base64 -p x -k data_encoding
-w /usr/bin/xxd -p x -k data_encoding

# Мониторинг на мрежови инструменти за сканиране
-w /usr/bin/nmap -p x -k recon_tools
-w /usr/bin/tcpdump -p x -k packet_capture
-w /usr/sbin/tcpdump -p x -k packet_capture

# Мониторинг на компилатори (неочаквана компилация на сървър)
-w /usr/bin/gcc -p x -k compiler_usage
-w /usr/bin/cc -p x -k compiler_usage
-w /usr/bin/make -p x -k compiler_usage

Защита на самите одитни правила:

# /etc/audit/rules.d/99-finalize.rules

# Мониторинг на промени в auditd конфигурацията
-w /etc/audit/ -p wa -k audit_config_change
-w /etc/audisp/ -p wa -k audit_config_change

# Направете правилата неизменяеми (изисква рестарт за промяна)
-e 2

Параметърът -e 2 е може би най-важната част тук: той прави одитните правила неизменяеми до следващото рестартиране на системата. Дори root потребител не може да ги промени без рестарт — което значително затруднява атакуващите, опитващи се да заличат следите си. Малко драстична мярка на пръв поглед, но си заслужава.

След създаване на правилата, заредете ги:

# Зареждане на правилата
sudo augenrules --load

# Проверка на активните правила
sudo auditctl -l

# Проверка на статуса
sudo auditctl -s

1.3. Анализ на одитни записи с ausearch и aureport

Генерирането на логове е безполезно без ефективен начин за анализ. Логове, които никой не чете, просто заемат дисково пространство. Linux Audit Framework включва два мощни инструмента за тази цел:

# Търсене на промени в /etc/passwd за последните 24 часа
sudo ausearch -k identity_changes -ts today

# Търсене на неуспешни опити за вход
sudo ausearch -m USER_LOGIN --success no -ts this-week

# Търсене на изпълнени команди от конкретен потребител
sudo ausearch -ua 1001 -sc execve -ts recent

# Генериране на обобщен отчет за удостоверяване
sudo aureport -au --summary

# Отчет за изпълними файлове
sudo aureport -x --summary

# Отчет за неуспешни събития
sudo aureport --failed --summary

# Подробен отчет за промени в ключови файлове
sudo aureport -k --summary

Ето един практичен съвет от моя опит: създайте скрипт за ежедневен отчет. Спестява наистина много време при рутинния преглед и помага да не пропуснете нещо важно:

#!/bin/bash
# /usr/local/bin/daily-audit-report.sh

REPORT_DATE=$(date -d "yesterday" +%m/%d/%Y)
REPORT_FILE="/var/log/audit/daily-report-$(date +%Y%m%d).txt"

echo "=== Дневен одитен отчет за ${REPORT_DATE} ===" > "$REPORT_FILE"
echo "" >> "$REPORT_FILE"

echo "--- Обобщение на неуспешни събития ---" >> "$REPORT_FILE"
aureport --failed --summary -ts "$REPORT_DATE" >> "$REPORT_FILE" 2>&1

echo "" >> "$REPORT_FILE"
echo "--- Промени в удостоверяване ---" >> "$REPORT_FILE"
aureport -au -ts "$REPORT_DATE" >> "$REPORT_FILE" 2>&1

echo "" >> "$REPORT_FILE"
echo "--- Промени в критични файлове ---" >> "$REPORT_FILE"
ausearch -k identity_changes -k privilege_escalation -k sshd_config_change \
  -ts "$REPORT_DATE" --format text >> "$REPORT_FILE" 2>&1

echo "" >> "$REPORT_FILE"
echo "--- LOTL активност ---" >> "$REPORT_FILE"
ausearch -k data_exfiltration -k recon_tools -k compiler_usage \
  -ts "$REPORT_DATE" --format text >> "$REPORT_FILE" 2>&1

echo "Отчетът е записан в $REPORT_FILE"

1.4. Производителност и оптимизация

Нека бъдем реалисти — активната одитна конфигурация идва на цена. Може да увеличи натоварването на процесора с приблизително 10–15% на продуктивни системи. За да минимизирате въздействието:

• Използвайте ключове (-k) за всяко правило — това значително ускорява търсенето с ausearch
• Избягвайте прекалено широки правила за execve — ограничете ги до конкретни потребители или UID-та
• Добавете правила за потискане на известна легитимна активност (например автоматизирани системни процеси, които не ви интересуват)
• Уверете се, че /var/log/audit/ разполага с достатъчно дисково пространство — пълен диск и спрял auditd е най-лошият сценарий

2. AIDE — мониторинг на целостта на файловете

Докато auditd записва кой е направил какво и кога, AIDE (Advanced Intrusion Detection Environment) отговаря на съвсем различен въпрос: променени ли са критичните файлове от последната известна добра конфигурация?

Принципът е прост. AIDE създава база данни с хеш стойности и атрибути на файлове, и при последващи проверки сравнява текущото състояние с тази базова линия. Ако нещо не съвпада — знаете, че имате проблем.

2.1. Инсталация и инициализация

# Debian / Ubuntu
sudo apt update && sudo apt install aide

# RHEL / Fedora / AlmaLinux
sudo dnf install aide

# Инициализация на базата данни
# Това може да отнеме няколко минути в зависимост от обема данни
sudo aideinit

# На RHEL/Fedora:
sudo aide --init

# Преместване на новата база данни на активна позиция
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Инициализацията създава моментна снимка на всички наблюдавани файлове и директории. Тази снимка служи като еталон за бъдещи сравнения — нещо като „златен образ" на файловата ви система.

2.2. Конфигурация на aide.conf

Конфигурационният файл се намира в /etc/aide/aide.conf (Debian/Ubuntu) или /etc/aide.conf (RHEL). Нека изградим укрепена конфигурация стъпка по стъпка:

# /etc/aide/aide.conf — Укрепена конфигурация

# Дефиниране на групи от проверки
# NORMAL — стандартна проверка за повечето файлове
NORMAL = p+i+n+u+g+s+m+c+sha256

# PERMS — само разрешения и собственост
PERMS = p+i+u+g

# LOG — за лог файлове (очаква се да растат)
LOG = p+u+g+i+n+S

# CONTENT_EX — съдържание плюс разширени атрибути
CONTENT_EX = sha256+ftype+p+u+g+n+i+l+xattrs

# Директории за мониторинг
/boot/ CONTENT_EX
/bin/ CONTENT_EX
/sbin/ CONTENT_EX
/lib/ CONTENT_EX
/lib64/ CONTENT_EX
/usr/bin/ CONTENT_EX
/usr/sbin/ CONTENT_EX
/usr/lib/ CONTENT_EX

# Конфигурационни файлове
/etc/ NORMAL

# Ядрени модули
/lib/modules/ CONTENT_EX

# Директории, които да бъдат изключени
!/var/log/
!/var/spool/
!/var/cache/
!/var/tmp/
!/tmp/
!/run/
!/proc/
!/sys/
!/dev/

# Изключване на AIDE собствените файлове
!/var/lib/aide/
!/etc/aide/

# Мониторинг на crontab файлове
/var/spool/cron/ NORMAL
/etc/crontab NORMAL
/etc/cron.d/ NORMAL
/etc/cron.daily/ NORMAL
/etc/cron.weekly/ NORMAL
/etc/cron.monthly/ NORMAL

Няколко важни бележки за конфигурацията:

• sha256 е препоръчителният хеш алгоритъм — по-бърз е от sha512, а за целите на мониторинга на целостта предоставя напълно достатъчна сигурност
• xattrs проверява разширените атрибути на файловете, включително SELinux контекстите — нещо, което лесно може да се пропусне
• Изключването на /var/log/ и подобни динамични директории е задължително, иначе всяка проверка ще генерира буквално хиляди фалшиви позитиви
• Параметърът S (главно S) проверява само дали размерът расте, без да сравнява точната стойност — идеален е за лог файлове, които по дефиниция постоянно растат

2.3. Автоматизация на проверките с cron

Ръчните проверки са непрактични за продуктивна среда. Нека настроим автоматизирана проверка, която ще ви изпраща известие само когато нещо не е наред:

# Създаване на скрипт за автоматизирана AIDE проверка
sudo tee /usr/local/bin/aide-check.sh > /dev/null << 'SCRIPT'
#!/bin/bash
# Автоматизирана AIDE проверка с известяване

AIDE_LOG="/var/log/aide/aide-check-$(date +%Y%m%d-%H%M).log"
ADMIN_EMAIL="[email protected]"
HOSTNAME=$(hostname -f)

# Изпълнение на проверката
/usr/bin/aide --check > "$AIDE_LOG" 2>&1
EXIT_CODE=$?

if [ $EXIT_CODE -ne 0 ]; then
    SUBJECT="[AIDE ALERT] Открити промени на ${HOSTNAME}"
    
    # Изпращане на имейл известие
    echo "AIDE откри промени в целостта на файловете на ${HOSTNAME}." |     mail -s "$SUBJECT" -A "$AIDE_LOG" "$ADMIN_EMAIL"
    
    # Записване в syslog за Wazuh
    logger -p security.warning -t aide       "AIDE integrity check failed with exit code $EXIT_CODE"
fi
SCRIPT

sudo chmod 700 /usr/local/bin/aide-check.sh

# Добавяне в crontab — ежедневно в 03:00
echo "0 3 * * * root /usr/local/bin/aide-check.sh" |   sudo tee /etc/cron.d/aide-check

2.4. Обновяване на базата данни след легитимни промени

Един от най-честите проблеми с AIDE (и честно казано, най-досадният) е управлението на фалшивите позитиви след легитимни системни обновления. Ето препоръчителния работен процес:

# 1. Прегледайте промените внимателно
sudo aide --check | less

# 2. Ако промените са легитимни (например след apt upgrade),
#    обновете базата данни
sudo aide --update

# 3. Заменете старата база данни с новата
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# 4. Проверете, че новата база данни работи
sudo aide --check

Важна препоръка за сигурност: Съхранявайте копие на AIDE базата данни на отделен, защитен носител — например монтиран само за четене NFS дял или дори външно USB устройство. Защо? Ако атакуващият компрометира системата и получи root достъп, той може да модифицира локалната AIDE база данни, за да скрие промените си. Офлайн копието ви дава надеждна точка за сравнение, на която наистина можете да се доверите.

3. Wazuh — централизирана SIEM/XDR платформа

auditd и AIDE са чудесни инструменти, но имат един общ недостатък — те работят изолирано на всяка отделна машина. В среда с десетки или стотици сървъри, ходенето от машина на машина и четенето на отделни логове просто не работи. Имате нужда от централизирана платформа, която да агрегира, корелира и визуализира данните от всички източници. Wazuh е точно това — платформа за сигурност с отворен код, която обединява XDR и SIEM възможности.

Към януари 2026 г. последната стабилна версия е Wazuh 4.14.2, която включва подобрена поддръжка на SCA политики, асинхронно презареждане на правилата и разширена съвместимост с нови операционни системи.

3.1. Архитектура и компоненти

Wazuh използва архитектура от типа hub-and-spoke (звезда), която се състои от четири основни компонента:

• Wazuh Manager (сървър) — централната точка за агрегация и корелация на събития. Получава данни от агентите, прилага правила за анализ и генерира известия
• Wazuh Indexer — базиран на OpenSearch, индексира и съхранява събитията за дългосрочен анализ и ретроспективни разследвания
• Wazuh Dashboard — уеб интерфейс за визуализация, управление на агенти и конфигуриране на правила
• Wazuh Agent — лек агент, инсталиран на всяка наблюдавана крайна точка, който събира логове, извършва проверки за целостта на файловете и изпълнява SCA политики

3.2. Инсталация на Wazuh

Wazuh предоставя автоматизиран инсталационен скрипт, който значително опростява целия процес. За централния сървър процедурата е доста праволинейна:

# Инсталация на Wazuh сървър (all-in-one)
# Изтегляне на инсталационния скрипт
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh

# Изпълнение на инсталацията
sudo bash wazuh-install.sh -a

# Скриптът ще инсталира:
# - Wazuh Manager
# - Wazuh Indexer (OpenSearch)
# - Wazuh Dashboard
# - Filebeat (за препращане на събития)

# След инсталацията ще получите потребителско име и парола
# за достъп до Dashboard

За инсталиране на агент на наблюдавана Linux машина:

# Debian / Ubuntu
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg \
  --import && chmod 644 /usr/share/keyrings/wazuh.gpg

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" | \
  tee /etc/apt/sources.list.d/wazuh.list

apt update && apt install wazuh-agent

# RHEL / Fedora
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
cat > /etc/yum.repos.d/wazuh.repo << EOF
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=Wazuh repository
baseurl=https://packages.wazuh.com/4.x/yum/
protect=1
EOF

dnf install wazuh-agent

След инсталацията конфигурирайте агента да се свързва с мениджъра:

# Редактиране на конфигурацията на агента
sudo nano /var/ossec/etc/ossec.conf

# Задайте адреса на Wazuh Manager
# 
#   
#     
WAZUH_MANAGER_IP
#   
# 

# Стартиране на агента
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

# Проверка на свързаността
sudo /var/ossec/bin/agent_control -i 000

3.3. Интеграция на Wazuh с auditd

Тук нещата стават наистина интересни. Wazuh може директно да обработва логовете на auditd, превръщайки суровите одитни записи в структурирани известия с приоритет, описание и препоръки. Тази интеграция е, по мое мнение, една от най-силните страни на цялата система.

Конфигурирайте агента да чете auditd логовете:

  
    audit
    /var/log/audit/audit.log
  

Wazuh вече включва готови правила за auditd събития в /var/ossec/ruleset/rules/0365-auditd_rules.xml. Но можете (и е препоръчително) да добавите собствени правила за по-прецизно детектиране:

  
  
    80700
    identity_changes
    Промяна в критичен файл за удостоверяване: $(audit.file.name)
    audit_identity,gdpr_IV_32.2,hipaa_164.312.b
  

  
  
    80700
    data_exfiltration
    Потенциална ексфилтрация на данни: $(audit.exe) изпълнен от $(audit.auid)
    audit_lotl,attack.exfiltration
  

  
  
    80700
    audit_config_change
    КРИТИЧНО: Опит за промяна на одитната конфигурация!
    audit_tampering
  

Нивата на критичност в Wazuh варират от 0 (без действие) до 16 (максимална критичност). За одитните правила препоръчвам следната скала:

• Ниво 5–7: Информационни събития (успешно удостоверяване, рутинни промени)
• Ниво 8–10: Важни събития, изискващи внимание (промени в ключови конфигурации)
• Ниво 11–13: Високоприоритетни известия (подозрителна активност, LOTL)
• Ниво 14–16: Критични инциденти (опит за манипулация на одит, ескалация на привилегии)

3.4. Wazuh File Integrity Monitoring (FIM)

Wazuh има вграден модул за мониторинг на целостта на файловете, който може да работи успоредно с AIDE или дори да го замени в определени сценарии. Считано от версия 4.12.0, FIM поддържа eBPF за значително по-ефективен мониторинг в реално време.

  
    
    21600

    
    /etc
    /usr/bin
    /usr/sbin
    /sbin
    /bin
    /boot

    
    /var/www

    
    /etc/mtab
    /etc/resolv.conf
    /etc/adjtime
    .log$|.tmp$

    
    /etc/cron.d
    /etc/sudoers.d
  

Параметърът whodata="yes" е изключително полезен — той използва auditd за проследяване на това кой точно е направил промяната, какъв процес е бил използван и кога точно се е случило. На практика, това обединява функционалността на auditd и FIM в единен поток от данни, което прави разследванията много по-лесни.

3.5. Активен отговор (Active Response)

Wazuh не само открива заплахи — той може и да реагира автоматично. Ето пример за конфигуриране на активен отговор при подозрителна активност:

  
    firewall-drop
    local
    100101
    3600
  

  
  
    firewall-drop
    local
    5712
    1800
  

Едно предупреждение: бъдете внимателни с активните отговори. Те могат да блокират легитимен трафик при фалшиви позитиви, а няма нищо по-неприятно от това да се заключите от собствения си сървър. Препоръчвам да започнете в режим на наблюдение и да активирате автоматичните блокировки едва след поне две-три седмици настройка и наблюдение.

4. Обединяване на системата: auditd + AIDE + Wazuh

И така, имаме три отделни инструмента. Но истинската стойност се проявява, когато работят заедно като интегрирана система. Нека разгледаме как данните протичат през всеки слой.

Поток на данните

1. auditd записва системни повиквания и достъп до файлове в реално време на ниво ядро. Всяко събитие включва кой, какво, кога и как
2. Wazuh Agent чете логовете на auditd, прилага декодери за парсиране на формата и препраща структурираните данни към Wazuh Manager
3. Wazuh FIM допълнително следи за промени в ключови файлове, като добавя информация за хеш стойности и атрибути
4. AIDE периодично (например ежедневно) сканира цялата файлова система и сравнява с базовата линия — резултатите също се изпращат към Wazuh чрез syslog
5. Wazuh Manager корелира събитията от всички източници и генерира приоритизирани известия
6. Wazuh Dashboard визуализира всичко в единен интерфейс с възможност за drill-down анализ

Интеграция на AIDE с Wazuh

За да интегрирате AIDE отчетите с Wazuh, конфигурирайте агента да обработва AIDE логовете:

  
    syslog
    /var/log/aide/aide.log
  

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

  
    syslog
    AIDE found differences
    AIDE откри промени в целостта на файловете
    aide,file_integrity
  

  
    100200
    AIDE откри множество промени в рамките на 24 часа — възможно нарушение!
    aide,file_integrity,attack
  

Пример за разследване на инцидент

Нека разгледаме един практически сценарий. Представете си, че Wazuh генерира известие за промяна в /usr/bin/. Ето как бихте подходили към разследването:

# 1. Проверка на Wazuh известието в Dashboard
# Ще видите: файл, потребител, процес, времева марка

# 2. Задълбочено проучване с auditd
sudo ausearch -f /usr/bin/suspicious_binary -ts today
# Показва: кой процес е записал файла, от кой потребител, с какъв PID

# 3. Проверка на целостта с AIDE
sudo aide --check | grep suspicious_binary
# Показва: промени в хеш стойност, размер, разрешения

# 4. Проверка на бинарния файл
file /usr/bin/suspicious_binary
sha256sum /usr/bin/suspicious_binary
strings /usr/bin/suspicious_binary | head -50

# 5. Проверка на мрежовите връзки на процеса
ss -tlnp | grep suspicious
lsof -i -P -n | grep suspicious

# 6. Проверка на дървото на процесите
pstree -p $(pgrep suspicious_binary)

5. Съответствие с CIS и STIG стандарти

Правилно конфигурираната система за откриване на проникване не е просто „хубаво е да имаш" — тя е конкретно изискване на множество стандарти за сигурност и съответствие. Ако работите в регулирана индустрия, тази секция е особено важна за вас.

CIS Benchmark изисквания

CIS (Center for Internet Security) препоръчва следните контроли, които нашата система покрива:

• CIS 4.1.x: Конфигуриране на auditd — запис на събития за модификация на дата и час, потребителски акаунти, мрежова среда, MAC политики, входове и излизания, промени в разрешенията
• CIS 4.1.17: Записване на изпълнението на привилегировани команди
• CIS 4.1.3: Осигуряване на неизменяемост на одитните правила (-e 2)
• CIS 1.3.x: Конфигуриране на AIDE за мониторинг на целостта на файловете

Wazuh SCA модул

Wazuh включва вграден модул за Security Configuration Assessment (SCA), който автоматично проверява съответствието с CIS Benchmark. Към версия 4.14.2 са налични SCA политики за:

• Ubuntu 22.04 LTS (CIS Benchmark v2.0.0)
• RHEL 9 и RHEL 10
• CentOS Stream 10
• AlmaLinux 10
• Fedora 41
• Distribution Independent Linux

# Проверка на SCA статуса чрез Wazuh API
curl -k -X GET "https://WAZUH_MANAGER:55000/sca/001" \
  -H "Authorization: Bearer $TOKEN"

# Или чрез командния ред на агента
sudo /var/ossec/bin/wazuh-control info

PCI DSS съответствие

За организации, обработващи данни за кредитни карти, нашата система покрива следните ключови PCI DSS изисквания:

• PCI DSS 10.2: Записване на одитни следи за достъп до компоненти на системата — покрито от auditd
• PCI DSS 10.5: Защита на одитните следи от модификация — покрито от -e 2 и централизирано препращане към Wazuh
• PCI DSS 11.5: Внедряване на механизъм за откриване на промени — покрито от AIDE и Wazuh FIM

6. Практически съвети за внедряване в продуктивна среда

Теорията е чудесна, но реалните внедрявания винаги носят своите изненади. Ето някои практически съвети, натрупани от реален опит:

Поетапно внедряване

Не се опитвайте да внедрите всичко наведнъж. Сериозно, не го правете. Ето един по-разумен подход:

1. Седмица 1–2: Инсталирайте auditd с базов набор от правила. Наблюдавайте обема на генерираните логове и нагласете правилата, за да намалите шума
2. Седмица 3–4: Добавете AIDE. Инициализирайте базата данни и пуснете няколко тестови проверки, за да разберете какво е „нормално" за вашата система
3. Седмица 5–6: Инсталирайте Wazuh Manager и интегрирайте агентите. Започнете с няколко тестови сървъра, преди да разширите към цялата инфраструктура
4. Седмица 7–8: Настройте правилата и известяванията. Калибрирайте праговете, за да постигнете баланс между обхват и фалшиви позитиви

Управление на дисковото пространство

# Проверка на дисковото пространство за одитни логове
df -h /var/log/audit/

# Настройка на автоматична ротация за AIDE логове
cat > /etc/logrotate.d/aide << 'EOF'
/var/log/aide/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
}
EOF

Автоматизация с Ansible

За среди с повече от шепа сървъри, автоматизацията не е лукс, а необходимост. Ето скелет на Ansible playbook за разгръщане на цялата одитна инфраструктура:

# deploy-ids.yml
---
- name: Deploy Intrusion Detection Stack
  hosts: linux_servers
  become: yes
  tasks:
    - name: Install auditd
      package:
        name: "{{ 'auditd' if ansible_os_family == 'Debian' else 'audit' }}"
        state: present

    - name: Deploy audit rules
      copy:
        src: "audit-rules/{{ item }}"
        dest: "/etc/audit/rules.d/{{ item }}"
        owner: root
        group: root
        mode: '0640'
      loop:
        - 10-critical-files.rules
        - 20-privileged-ops.rules
        - 30-lotl-detection.rules
        - 99-finalize.rules
      notify: Restart auditd

    - name: Install AIDE
      package:
        name: aide
        state: present

    - name: Deploy AIDE configuration
      template:
        src: aide.conf.j2
        dest: "{{ aide_conf_path }}"
      vars:
        aide_conf_path: "{{ '/etc/aide/aide.conf' if ansible_os_family == 'Debian' else '/etc/aide.conf' }}"

    - name: Install Wazuh Agent
      include_role:
        name: wazuh-agent

  handlers:
    - name: Restart auditd
      service:
        name: auditd
        state: restarted

Мониторинг на здравето на самата IDS

Малка ирония — трябва да наблюдавате дали самите инструменти за наблюдение работят правилно. Ето бърз скрипт за проверка:

# Проверка на статуса на всички компоненти
echo "=== auditd ==="
systemctl is-active auditd
auditctl -s | grep -E "enabled|failure|pid"

echo "=== Wazuh Agent ==="
systemctl is-active wazuh-agent
/var/ossec/bin/wazuh-control status

echo "=== AIDE последна проверка ==="
ls -la /var/log/aide/aide-check-*.log | tail -1

echo "=== Дисково пространство ==="
df -h /var/log/audit/ /var/log/aide/ /var/ossec/logs/

7. Заключение и следващи стъпки

Трислойната система за откриване на проникване, която изградихме — auditd за ниско-ниво одит на ядрото, AIDE за периодичен мониторинг на целостта на файловете и Wazuh за централизирана агрегация и корелация — дава солидна основа за защита в дълбочина.

Ключовите принципи, които приложихме:

• Защита в дълбочина: Множество припокриващи се слоеве на детекция — ако единият бъде заобиколен, останалите компенсират
• Неизменяемост на одита: Правилото -e 2 на auditd и централизираното препращане на логовете осигуряват, че атакуващият не може просто да заличи следите си
• Автоматизация: Ръчният мониторинг е неустойчив в дългосрочен план — cron задачи, Wazuh правила и Ansible осигуряват последователно покритие
• Съответствие: Конфигурацията покрива изискванията на CIS Benchmark, STIG и PCI DSS

В бъдещи ръководства ще разгледаме интеграция на мрежови IDS (Suricata) с Wazuh за пълна видимост върху мрежовия трафик, както и използване на eBPF и Falco за мониторинг на контейнеризирани работни натоварвания в Kubernetes среда.

И накрая, едно напомняне: откриването на проникване не е продукт, който инсталираш и забравяш. Това е непрекъснат процес. Инсталацията е само началото — истинската работа е в непрекъснатото настройване на правилата, разследване на известията и адаптиране към новите заплахи. Но с правилните инструменти и систематичен подход, вече сте значително по-подготвени от повечето организации.