Агент Windows OSSEC не может синхронизировать конфигурацию

Последние несколько дней это раздражало, и мне еще предстоит выяснить причину.

В лаборатории я установил две виртуальные машины, OSSEC Server Appliance и клиент Windows 7 x64 Enterprise SP1.

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

Проблема возникает, когда я пытаюсь централизовать конфигурацию для "менеджера" или OSSEC Server Appliance.

[root@ossec etc]# md5sum /var/ossec/etc/shared/agent.conf
9cc4c937f4eae011ecbccf4468973133  /var/ossec/etc/shared/agent.conf
[root@ossec etc]# /var/ossec/bin/agent_control -i 004

OSSEC HIDS agent_control. Agent information:
   Agent ID:   004
   Agent Name: ABC
   IP address: 192.168.0.93
   Status:     Active

   Operating system:    Microsoft Windows 7 Enterprise Edition Professional ..
   Client version:      OSSEC HIDS v2.9.0 / cd66e10fca4cc1dc4c459a1f05f9b2d1
   Last keep alive:     Sat Oct  7 22:52:09 2017

   Syscheck last started  at: Sat Oct  7 21:35:12 2017
   Rootcheck last started at: Sat Oct  7 22:27:19 2017
[root@ossec etc]#

Не удивительно, что конфигурации не в той же версии.

То, что должно быть простым исправлением перезапуска устройства и агента Windows (и ожидания нескольких минут), оказывается, не так.

Прочитав документацию, я понял, что агент попытается объединить централизованную конфигурацию:

<agent_config name="ABC">
    <localfile>
        <location>/var/log/my.log2</location>
        <log_format>syslog2</log_format>
    </localfile>
</agent_config>


<agent_config os="Linux">
    <localfile>
        <location>/var/log/my.log2</location>
        <log_format>syslog</log_format>
    </localfile>
</agent_config>


<agent_config os="Windows">
 <!-- This is a test config -->

  <!-- One entry for each file/Event log to monitor. -->
  <localfile>
    <location>Application</location>
    <log_format>eventlog</log_format>
  </localfile>

  <!-- Additional contents are in here. -->

  <active-response>
    <disabled>no</disabled>
  </active-response>

</agent_config>

С одним в имеет локально. Вот конфигурация агента (ossec.conf):

<ossec_config>
  <active-response>
    <disabled>no</disabled>
  </active-response>
  <client>
        <server-ip>192.168.0.21</server-ip>
        <notify_time>120</notify_time>
        <time-reconnect>240</time-reconnect>
  </client>
</ossec_config>

и файл agent.conf в общей папке на агенте:

<agent_config>
    <localfile>
        <location>/var/log/my.log</location>
        <log_format>syslog</log_format>
    </localfile>
</agent_config>

Из журнала видно, что слияние не происходит, выполняется локальная копия:

2017/10/08 00:06:52 ossec-agentd: INFO: Trying to connect to server 192.168.0.21, port 1514.
2017/10/08 00:06:52 INFO: Connected to 192.168.0.21 at address 192.168.0.21:1514, port 1514
2017/10/08 00:06:52 ossec-agent: Starting syscheckd thread.
2017/10/08 00:06:52 ossec-syscheckd(1702): INFO: No directory provided for syscheck to monitor.
2017/10/08 00:06:52 ossec-syscheckd: WARN: Syscheck disabled.
2017/10/08 00:06:52 ossec-rootcheck: INFO: Started (pid: 2512).
2017/10/08 00:06:52 ossec-syscheckd: INFO: Started (pid: 2512).
2017/10/08 00:06:53 ossec-agentd(4102): INFO: Connected to server 192.168.0.21, port 1514.
2017/10/08 00:06:53 ossec-agent: INFO: System is Vista or newer (Microsoft Windows 7 Enterprise Edition Professional Service Pack 1 (Build 7601) - OSSEC HIDS v2.9.0).
2017/10/08 00:06:53 ossec-logcollector(1103): ERROR: Could not open file '/var/log/my.log' due to [(9)-(Bad file descriptor)].
2017/10/08 00:06:53 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/my.log'.

В конце концов, похоже, что агент / менеджер не может:

  • Соединитесь друг с другом.
  • Разобрать файлы конфигурации.
  • Отправляйте данные туда и обратно (сработавшие правила).
  • Проверьте, какую версию файла конфигурации он использует.
  • Конфигурации слияния (периодически я вижу файл агента merged.mg размером 0 КБ).

Не удалось установить параметр на устройстве / диспетчере или проблема в другом месте?

Источник

1 ответ

Решение

Так что, не имея успеха на security.stackexchange.comвопрос был перенесен сюда. Потратив на это несколько дополнительных дней, я нашел "решение".

Вы можете свести это к следующему: найти другое решение HIDS.

Я пришел к такому выводу, попробовав обширный список вещей:

  • Запустите OVA как есть, прямо с веб-сайта проекта (2.8.3)
  • Обновлен / обновлен OVA, представленный на веб-сайте проекта OSSEC.
  • Установил сервер / менеджер OSSEC на новой установке CentOS 7.
  • Установлен сервер с "Серверным графическим интерфейсом" и "Минимальной" установкой CentOS 7.
  • Пробовал обновлять клиентскую виртуальную машину Windows 7.
  • Использование других свежих виртуальных машин на базе Windows.
  • Измените порты, правила брандмауэра и статические IP-адреса.
  • Отключил брандмауэры как на сервере, так и на клиенте.
  • Увеличьте буфер UDP в клиенте Windows через реестр.
  • Отключен SELinux (разрешающий режим активен).
  • Проверено, что на сервере перечислены агенты и перезапущен для обнаружения изменений.
  • Установил сервер из источников RPM
  • Скомпилировано и установлено из исходного кода.
  • Пробовал агент Windows версии 2.9.0 и 2.9.2.

Чтобы получить разумную установку, которая хотя бы сработала (отчасти), я выполнил следующие шаги:

  1. Загрузите сервер с установочного носителя CentOS 7.
  2. Выберите минимальную установку
  3. Подключитесь к своей сети, лучше всего использовать статический IP.
  4. После установки войдите как root.
  5. Откройте брандмауэр firewall-cmd --permanent --zone=public --add-port=1514/udp
  6. Зафиксируйте изменения firewall-cmd --reload
  7. Установите некоторые дополнения yum install mysql-devel postgresql-devel gcc wget vim
  8. Получить исходный код wget https://github.com/ossec/ossec-hids/archive/2.9.2.tar.gz
  9. UnTar код tar -zxvf 2.9.2.tar.gz
  10. Зайдите в новый каталог cd ossec-hids-2.9.2
  11. Запустите установщик ./install.sh
  12. Выбрать server введите для установки.
  13. Теперь настройте, я по умолчанию на всех опциях, кроме установки электронной почты на нет.
  14. Настройте конфиг клиентов /var/ossec/bin/manage_agents
  15. Настройте новый централизованный файл конфигурации через vim /var/ossec/etc/shared/agent.conf
  16. Запустите сервер /var/ossec/bin/ossec-control start
  17. Установите клиент Windows с последней версией (2.9.2).

Что было здорово, проведя часы и часы, так это то, что вся моя работа была потрачена впустую. Я нашел, как настроить клиент Windows для отладки уровня 2, и обнаружил сообщение:

2017/10/20 02:13:40 ossec-agentd: Failed md5 for: shared/merged.mg -- deleting.

Оказывается, что на "нормальном" уровне журнала не выдается предупреждение о том, что критическое слияние конфигурации не удалось (серьезно!?).

Я был еще более впечатлен тем фактом, что серверу не удалось получить хэш md5 конфигурации клиента после перезапуска сервера и клиента (попытка с 2 по 14).

За один запуск с OVA (попытка № 1) сервер смог получить клиентский md5 конфигурации, но он не соответствовал серверному. Вы можете увидеть это в моем первоначальном вопросе. Я думаю, что md5 от агента был отправлен, потому что я добавил некоторые дополнительные файлы в каталог conf на агенте (главным образом agent.conf).

В чистом раздражении я обратился к Интернету и нашел обсуждение группы Google для OSSEC. После прочтения всей цепочки сообщений стало очевидно, что в OSSEC есть серьезный недостаток:

Как я уже говорил ранее, IMHO, проблема затрагивает агентов Windows и UNIX, но чаще встречается в Windows, потому что буфер по умолчанию короче. У нас была проблема с агентом Windows в частной сети VirtualBox: общий файл не поступил. С включенной отладкой мы увидели сообщение:

ossec-agent: Failed md5 for: merged.mg -- deleting.

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

Части общего файла могут быть потеряны из-за протокола UDP, а также любого другого события агента или управляющего сообщения. На самом деле использование TCP кажется хорошим решением этой проблемы. Мы внедрили TCP-связь в Wazuh год назад с версии 1.1, и мы достигли некоторых преимуществ:

No event losing. Communication is reliable for events, control messages and Active response requests.
Agents detect that a manager is down immediately, so they are able to "lock" the transmission in order to prevent events from being dropped.

Агенты с TCP-соединением работают должным образом во многих системах, использующих Linux, Windows, OpenBSD, macOS, AIX и т. Д.

Это не то, что я ожидал прочитать. Больше всего меня беспокоит тот факт, что инфраструктура OSSEC может быть разрушена просто из-за потери пакетов. Еще более тревожно то, что при нормальном уровне журнала сбой при объединении конфигурации даже не обнаруживается.

Хотя я тестировал только агенты Windows, я не сомневаюсь, что агенты Linux работают. Возможно, в будущем OSSEC перейдет на TCP-соединения, но сейчас OSSEC не хватает критически важной части функциональности.

tldr; К чему это приводит (по крайней мере, на мой взгляд) плохое тестирование программного обеспечения / обеспечение качества. Я узнал из обсуждений в Группе Google, что UDP-соединения вызывают проблемы, и существует ограниченная проверка передачи данных. Из-за повреждения конфигурации менеджера в пути, клиент отказывается объединить его. Это, кажется, происходит только на клиентах Windows.

Источник
Другие вопросы по тегам