Последние несколько дней это раздражало, и мне еще предстоит выяснить основную причину.
В лабораторной работе я установил два виртуальных машины, 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'.
В конце концов, похоже, что агент / менеджер не может:
Не удалось ли мне установить параметр на прибор / менеджер, или проблема в другом?
Итак, после неудачной попытки на security.stackexchange.com
вопрос был перенесен сюда. Потратив на это несколько дополнительных дней, я нашел «решение».
Вы можете свести это к следующему: найти другое решение HIDS.
Я пришел к такому выводу, попробовав обширный список вещей:
Чтобы получить разумную установку , которая, по крайней мере, сработала (отчасти), я выполнил следующие шаги:
firewall-cmd --permanent --zone = public --add- port = 1514 / udp
firewall-cmd --reload
yum install mysql-devel postgresql-devel gcc wget vim
wget https://github.com/ossec/ossec-hids/archive/2.9.2.tar.gz
tar -zxvf 2.9.2.tar.gz
cd ossec-hids-2.9.2
./ install.sh
сервер
для установки. / var / ossec / bin / manage_agents
vim / var / ossec / etc / shared / agent. conf
/ var / ossec / bin / ossec-control start
Что было здорово, после нескольких часов работы , было то, что вся моя работа была потрачена зря. Я нашел, как настроить клиент 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: Ошибка md5 для: merged.mg - удаление.
Итак, мы провели этот тест: мы изменили исходный код, чтобы предотвратить распространение файла был удален, хотя он был поврежден, и сравнил полученные файл с исходным: некоторые фрагменты файла действительно были потеряны, это не была проблема с окончанием строки.
Общие фрагменты файлов могут быть потеряны из-за протокола UDP, а также из-за любых другое событие агента или управляющее сообщение. На самом деле использование TCP кажется хорошее решение этой проблемы. Мы реализовали TCP-связь в Wazuh год назад из версии 1.1, и мы достигли некоторых преимуществ:
Нет проигрышей в событиях. Связь надежна для событий, управляющих сообщений и запросов активного ответа. Агенты немедленно обнаруживают, что менеджер не работает, поэтому они могут «заблокировать» передачу, чтобы предотвратить сброс событий.
Агенты с TCP-соединением работают правильно во многих системах, использующих Linux, Windows, OpenBSD, macOS, AIX и т.д.
Это не то, что я ожидал прочитать . Больше всего меня беспокоит тот факт, что инфраструктура OSSEC может выйти из строя просто из-за потери пакетов. Еще более тревожно то, что на нормальном уровне журнала невозможность объединения конфигурации даже не отображается.
Хотя я тестировал только агентов Windows, я не сомневаюсь, что агенты Linux работают. Возможно, в будущем OSSEC перейдет на TCP-соединения, но на данный момент OSSEC не хватает критически важной функциональности.
tldr; Все сводится (по крайней мере, на мой взгляд) к плохому тестированию / контролю качества программного обеспечения. Я узнал из обсуждений в группе Google UDP-соединения вызывают проблемы, а проверка передачи данных ограничена. Из-за повреждения конфигурации диспетчера при передаче клиент отказывается объединить ее. Это происходит только на клиентах Windows.