OSSEC — классическая система обнаружения вторжений на хосте, которая до сих пор держится во многих инфраструктурах. Она следит за целостностью файлов, анализирует логи, проверяет подозрительные изменения и умеет реагировать на инциденты. Разберём установку менеджера и агента, настройку syscheck, разбор алертов и сопровождение без сюрпризов.

Место OSSEC среди HIDS

HIDS (Host-based Intrusion Detection System) работает не с сетевым трафиком, а с самим сервером: файлами, журналами, процессами и учётными записями. OSSEC объединяет несколько подсистем:

  • syscheck — контроль целостности файлов по контрольным суммам;
  • rootcheck — поиск признаков руткитов и подозрительных прав;
  • log analysis — разбор журналов по декодерам и правилам;
  • active response — автоматические действия, например блокировка адреса.

Проект развивается медленно: актуальная ветка 3.7.x вышла несколько лет назад, но правила и схема работы остаются стабильными. Если нужна более активная разработка, посмотрите на Wazuh — форк OSSEC с современным интерфейсом; конфигурация во многом совместима.

Архитектура

Есть три режима установки: local (всё на одной машине), manager (сервер сбора) и agent (контролируемый хост). Для небольшой инфраструктуры удобна связка «менеджер плюс агенты»: алерты собираются в одном месте, а на хостах остаётся минимум настроек.

Менеджер слушает порт 1514/TCP для агентов и 1515/TCP для регистрации. Оба порта должны быть доступны только из сети управления.

Установка из исходников

Готовых пакетов в основных репозиториях Debian и Ubuntu нет, поэтому чаще всего ставят из исходников. Скачайте архив и запустите интерактивный установщик:

wget -q https://github.com/ossec/ossec-hids/archive/refs/tags/3.7.0.tar.gz
tar xzf 3.7.0.tar.gz
cd ossec-hids-3.7.0
sudo ./install.sh

Установщик спросит язык, тип установки, каталог и параметры. Для менеджера выберите server, для хоста — agent и укажите адрес менеджера. Компиляция на современных ядрах обычно проходит без правок, но может потребоваться пакет build-essential и заголовки OpenSSL.

После установки запустите сервис и проверьте статус:

sudo /var/ossec/bin/ossec-control start
sudo /var/ossec/bin/ossec-control status

Для автозапуска добавьте unit-файл systemd или используйте скрипт из поставки. Проверьте, что процесс ossec-syscheckd действительно работает: именно он отвечает за контроль целостности.

Настройка syscheck

Основной файл — /var/ossec/etc/ossec.conf. Блок syscheck задаёт каталоги и частоту проверки:

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <directories check_all="yes" report_changes="yes">/etc,/usr/bin,/usr/sbin</directories>
  <ignore>/etc/mtab</ignore>
  <alert_new_files>yes</alert_new_files>
</syscheck>

Частота указана в секундах: 43200 — это раз в 12 часов. Для критичных каталогов можно включить режим реального времени:

<directories realtime="yes" check_all="yes">/etc/ssh</directories>

Учтите, что realtime опирается на inotify и не работает рекурсивно на огромных деревьях. Не добавляйте в контроль /var/log и /tmp целиком: получите шторм событий и лишнюю нагрузку. Исключения для часто меняющихся файлов обязательны.

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

Первый скан и проверка конфигурации

После запуска не ждите мгновенных алертов: первый проход syscheck только строит базу контрольных сумм. Если в логе /var/ossec/logs/ossec.log появились ошибки чтения каталогов, значит, процессу не хватает прав или в списке есть несуществующий путь. Проверьте, что каталоги указаны без пробелов вокруг запятых.

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

Анализ логов и правила

OSSEC читает журналы через блок localfile. Для системного журнала достаточно указать путь и формат. Правила лежат в /var/ossec/rules, декодеры — в /var/ossec/decoders. Свои правила добавляйте в local_rules.xml, чтобы не потерять их при обновлении.

Проверка нового правила выполняется утилитой ossec-logtest: она показывает, какой декодер сработал и какое правило совпало. Это быстрее, чем ждать реального события.

sudo /var/ossec/bin/ossec-logtest

Типичный алерт контроля целостности выглядит как правило 550 «Integrity checksum changed». Найти свежие срабатывания можно так:

sudo grep "Integrity checksum changed" /var/ossec/logs/alerts/alerts.log | tail -n 20

Агенты и их состояние

На менеджере список подключённых агентов показывает утилита agent_control. Она же позволяет перезапустить агент или запросить его состояние.

sudo /var/ossec/bin/agent_control -l

Если агент в статусе Disconnected, проверьте три вещи: доступность порта 1514, совпадение ключа в /var/ossec/etc/client.keys и время на хостах. Расхождение часов ломает корреляцию событий и затрудняет разбор инцидента.

Для проверки целостности на агенте используйте syscheck_control -l: команда покажет, какие файлы изменились с момента последнего сканирования.

Active response: осторожно

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

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <level>10</level>
  <timeout>600</timeout>
</active-response>

Обязательно оставьте доступ к серверу через отдельный канал или адрес вне блокировки. Проверьте, что правила фаервола не конфликтуют с OSSEC и не сбрасываются при перезагрузке.

Сопровождение

OSSEC не требует ежедневного внимания, но и «поставил и забыл» не работает. Раз в неделю просматривайте алерты высокого уровня, раз в месяц проверяйте, что агенты на связи, и обновляйте правила. Диск с логами имеет свойство заполняться: настройте ротацию alerts.log и ossec.log.

Храните конфигурацию в системе контроля версий. Тогда изменение, после которого пропали алерты, легко откатить и сравнить.

Итог

OSSEC — проверенный временем HIDS, который закрывает базовые задачи: контроль целостности, разбор журналов и первичную реакцию. Он нетребователен к ресурсам и понятен в настройке, хотя интерфейс и темп разработки выглядят устаревшими. Главное — аккуратно выбрать каталоги для syscheck, не включать агрессивную блокировку без тестов и следить за связью с агентами. Для защиты собственных серверов этого набора возможностей более чем достаточно.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте