OSSEC Windows Agent Falha ao Sincronizar Configuração

Question

Isto provou ser um aborrecimento nos últimos dias, e eu ainda tenho que descobrir a causa raiz.

Em um laboratório, configurei duas máquinas virtuais, um OSSEC Server Appliance e um cliente Windows 7 x64 Enterprise SP1.

Ambos parecem funcionar bem quando fazem suas próprias coisas . Se eu tiver um arquivo de configuração extenso no cliente Windows, o agente o lerá e fará o que for necessário.

A questão surge quando tento centralizar a configuração no "gerenciador" ou no 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]# 

Para surpresa, as configurações não são da mesma versão.

O que deve ser uma solução fácil para reiniciar o appliance e o agente do Windows (e aguardar alguns minutos) não é o caso.

Ao ler a documentação, cheguei à conclusão de que o agente tentará mesclar a configuração centralizada:

<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>

Com o um em localmente. Aqui está a configuração do agente (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>

e o arquivo agent.conf na pasta compartilhada no agente:

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

Eu posso ver no log, que a fusão não está ocorrendo, ele está executando a cópia local:

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'.

No final, não parece ser um caso de o agente / gerente não poder:

• Conecte-se um ao outro.
• Analise os arquivos de configuração.
• Enviar dados para frente e para trás (regras acionadas).
• Verifique qual versão do arquivo de configuração está sendo usada.
• Mesclar configurações (vejo um arquivo mesclado.mg periodicamente de 0 KB no agente).

Eu deixei de definir uma opção no dispositivo / gerenciador ou o problema está em outro lugar?

    

Answer 1

Então, depois de não ter sucesso em security.stackexchange.com , a questão foi migrada aqui. Passando alguns dias extras nisso, encontrei a "solução".

Você pode resumir para: encontrar outra solução HIDS.

Cheguei a essa conclusão depois de tentar uma lista extensa de coisas:

• Execute o OVA como está, diretamente no site do projeto (2.8.3)
• Atualizado / atualizado o OVA fornecido no site do projeto OSSEC.
• Instalado o servidor / gerenciador OSSEC em uma nova instalação do CentOS 7.
• Instalou o servidor com as instalações "Server GUI" e "Minimal" do CentOS 7.
• Tentei atualizar a VM do cliente do Windows 7.
• Usando outras VMs novas baseadas no Windows.
• Alterar portas, regras de firewall e endereços IP estáticos.
• Desativou os firewalls no servidor e no cliente.
• Aumente o buffer UDP no cliente Windows por meio do registro.
• SELinux desativado (modo permissivo ativo).
• Verificado, havia agentes listados no servidor e reiniciados para detectar alterações.
• Instalou o servidor a partir das fontes de RPM
• Compilado e instalado a partir do código-fonte.
• Versão do agente do Windows 2.9.0 e 2.9.2.

Para conseguir uma instalação razoável, , que pelo menos funcionou (um pouco), segui estes passos:

1. Servidor de inicialização para mídia de instalação do CentOS 7.
2. Escolha uma instalação mínima
3. Conecte-se à sua rede, um IP estático é o melhor.
4. Após a instalação, efetue login como root.
5. Abra o firewall para cima firewall-cmd --permanent --zone=public --add-port=1514/udp
6. Confirme as alterações firewall-cmd --reload
7. Instale alguns extras yum install mysql-devel postgresql-devel gcc wget vim
8. Pegue o código-fonte wget https://github.com/ossec/ossec-hids/archive/2.9.2.tar.gz
9. Desmarcar o código tar -zxvf 2.9.2.tar.gz
10. Ir para o novo diretório cd ossec-hids-2.9.2
11. Execute o instalador ./install.sh
12. Escolha o tipo server para a instalação.
13. Agora configure, padronizei todas as opções além de configurar o email como não.
14. Configure a configuração dos clientes /var/ossec/bin/manage_agents
15. Configure o novo arquivo de configuração centralizado via vim /var/ossec/etc/shared/agent.conf
16. Iniciar o servidor /var/ossec/bin/ossec-control start
17. Instale o Windows Client com a versão mais recente (2.9.2).

O que foi ótimo, depois de passar horas e horas, foi que todo o meu trabalho foi desperdiçado. Descobri como configurar o cliente Windows para depurar o nível 2 e descobri a mensagem:

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

Acontece que não há nenhum aviso lançado no nível de log "normal" que uma mesclagem crítica de configuração falhou (seriamente!?).

Fiquei ainda mais impressionado com o fato de o servidor não conseguir recuperar o hash md5 da configuração do cliente após reiniciar o servidor e o cliente (tentativa de # 2 a # 14).

Em uma execução com o OVA (tentativa # 1), o servidor conseguiu capturar o md5 do cliente da configuração, mas não correspondeu ao do servidor. Você pode ver isso na minha pergunta original. Eu acho que o md5 do agente foi enviado porque eu adicionei alguns arquivos adicionais ao diretório conf no agente (principalmente agent.conf).

Em aborrecimento, liguei-me à Internet e encontrei a discussão do Grupo do Google para o OSSEC. Depois de ler toda a cadeia de mensagens, ficou bastante aparente há uma falha grave no OSSEC :

As I said before IMHO the issue affects to Windows and UNIX agents but it's more common in Windows because the default buffer is shorter. We had this problem with a Windows agent on a private VirtualBox network: the shared file didn't arrive. With debugging enabled, we saw the message:

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

So we did this test: we modified the source code to prevent file from being deleted although it was corrupted, and compared the received file with the original one: some chunks of the file were indeed lost, it was not a line ending issue.

Shared file chunks may be lost due to the UDP protocol, as well as any other agent event or control message. In fact using TCP seems to be a good solution for this problem. We implemented TCP communication in Wazuh a year ago from version 1.1 and we reached some advantages:

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.

Agents with TCP connection are working properly in many systems using Linux, Windows, OpenBSD, macOS, AIX, etc.

Isto não é o que eu esperava ler . O que mais me preocupa é o fato de que uma infra-estrutura OSSEC poderia ser derrubada simplesmente pela perda de pacotes. É ainda mais preocupante que, no nível de log normal, a falha em mesclar a configuração nem apareça.

Embora eu tenha testado apenas agentes Windows, não tenho dúvidas de que os agentes Linux funcionam. Talvez no futuro o OSSEC se mova para conexões TCP, mas por enquanto, o OSSEC não possui uma funcionalidade crítica .

tldr; O que se resume a (pelo menos na minha opinião) é o mau teste de software / garantia de qualidade. Descobri a partir das discussões do Grupo do Google As conexões UDP causam problemas e há uma verificação limitada das transmissões de dados. Devido à corrupção da configuração do gerenciador em trânsito, o cliente se recusa a mesclá-lo. Isso parece acontecer apenas em clientes Windows.