Ossec – Entendendo o Rootcheck – HIDS parte 6

Fala galera! Dando continuidade a nossa série de posts sobre o ossec; hoje vamos ver mais uma funcionalidade que ele nos oferece, o Rootcheck. O Rootcheck basicamente é dividido em duas partes, a detecção de rootkits e policy monitor, iremos destrinchar bastante essas funcionalidades hoje, por isso esse post será um pouco longo, na verdade o mais longo até agora, mas bastante interessante também!

Rootkit Detection

O rootcheck será executado a cada X minutos (especificado pelo usuário  – por padrão a cada 2 horas) para detectar qualquer possível rootkit instalado, lógico que se instalarmos o ossec em um sistema já comprometido por um rootkit não vai adiantar muita coisa 🙂 Essa é uma ferramenta de prevenção e não de remediação. Combinado com a análise de log e o mecanismo de verificação de integridade, ele se torna uma solução de monitoramento muito poderosa, e o mais importante, totalmente open source! Algumas características do Rootcheck Detection são:

O ossec lê o arquivo rootkit_files.txt que contém um banco de dados de rootkits e arquivos comumente usados ​​por eles. O ossec usa as chamadas de sistemas stats, fopen e opendir em cada arquivo especificado porque alguns rootkits kernel-level escondem arquivos de algumas chamadas do sistema. Quanto mais chamadas de sistema forem utilizadas, melhor será a detecção. Este método é bem parecido com uma assinatura de anti-vírus que precisa ser atualizada constantemente. As chances de falsos positivos são pequenas, mas falsos negativos podem ser produzidos modificando os rootkits.

O ossec lê o arquivo rootkit_trojans.txt que contém um banco de dados de assinaturas de arquivos infectados por rootkits. Esta técnica de modificação de binários é comumente usada pela maioria dos rootkits populares. Este método de detecção não encontrará nenhum rootkit do nível do kernel ou nenhum rootkit desconhecido.

O ossec escaneia o diretório /dev em busca de anomalias. O /dev só deve ter arquivos de dispositivo e o script Makedev. Muitos rootkits usam o /dev para ocultar arquivos. Esta técnica pode detectar até mesmo rootkits não públicos.

Ele escaneia todo o sistema de arquivos procurando arquivos incomuns e problemas de permissão. Arquivos com o root como dono e com permissão de gravação para outros usuários são muito perigosos e a detecção de rootkit irá procurar por essas anomalias. Arquivos suid, diretórios e arquivos escondidos também serão inspecionados.

Adicionalmente, o ossec procura por processos ocultos. ele usa o getsid() e o kill() para verificar se algum pid está sendo usado ou não. Se o pid estiver sendo usado mas o “ps” não consegue ver, é uma indicação de rootkit kernel-level ou de uma versão modificada do “ps”. Ele também verifica se a saída de kill e getsid são as mesmas.

O ossec procura por portas escondidas usando o bind() para verificar todas as portas tcp e udp no sistema. Se ele não puder subir a porta (ela está sendo usada), mas o netstat não mostra isso, provavelmente um rootkit está instalado.

Concluindo, o ossec escaneia todas as interfaces no sistema e procura por aquelas com o modo “promisc” ativo. Se a interface estiver em modo promíscuo, a saída do “ifconfig” deve mostrar isso. Caso contrário, provavelmente um rootkit está instalado.

Policy Monitor

O monitor de políticas do ossec permite que você verifique se todos os seus sistemas estão em conformidade com um conjunto de políticas relativas às configurações e ao uso de aplicativos. Essas políticas são configuradas centralmente no servidor ossec e são enviadas para os agentes. Ele também verifica se um sistema está em conformidade com os padrões de segurança do CIS e com as diretrizes de proteção de segurança da VMware.

Os seguintes sistemas são testados para as diretrizes do CIS e VMware:

 

Exemplos de Configuração
<rootcheck>
  <system_audit>/db/my_system_audit.txt</system_audit>
  <system_audit>/db/my_debian_linux.txt</system_audit>
  <system_audit>/db/my_rhel_linux.txt</system_audit>
</rootcheck>
<rootcheck>
   <system_audit>/var/ossec/etc/shared/audit_test.txt</system_audit>
</rootcheck>
Laboratório

OBS: Eu coloquei a lista de opções de configuração do rootcheck no final do post para não ficar muito massante de início.

O binário que nos permite trabalhar com o rootcheck é o rootcheck_control, ele está localizado na pasta bin do ossec, com ele podemos gerenciar as bases de dados de política e auditoria:

# /var/ossec/bin/rootcheck_control

Agora vamos fazer alguns testes no nosso laboratório, a parte de rootkit detection é bem robusta e não tem muito o que a gente possa ficar alterando, a não ser que você queira desativar algum recurso, caso contrário o que poderíamos fazer a criar novas regras, mas vou deixar essa tarefa para equipe de desenvolvimento do ossec, rsrsrs!! Iremos nos limitar a brincar com as políticas e auditoria 🙂

Antes de começar a escrever as regras precisamos entender como é sintaxe delas, as regra são divididas basicamente entre título e expressão, abaixo segue um exemplo de uma regra que verifica se a versão 1 do protocolo ssh está habilitada:

[SSH - Protocol version 1 enabled ] [any] [http://www.ossec.net] 
f:/etc/ssh/sshd_config -> !r:^# && r:Protocol\.+1;

Olhando assim pode parecer complicado, mas não é não 🙂 Então vamos ver qual é a lógica dessa sintaxe,  basicamente existem três tipos de expressão, sendo “f:” para arquivos ou diretórios, “p:” para processos e “d:” para qualquer arquivo dentro de um diretório. Esses tipos ainda podem conter valores, sendo “=:” para igual, “r:” para regerex, “>:” para maior e “<:” para menor. Caso queira combinar esses valores, basta usar “&&”, o sinal de exclamação “!” significa a lógica inversa da regra. Abaixo segue um resumo:

f (for file or directory) 
p (process running) 
d (any file inside the directory) 
=: (for equal) - default 
r: (for ossec regexes) 
>: (for strcmp greater)
<: (for strcmp lower) 
&& (Multiple patterns)

Além da expressão temos o título como comentei acima, ele é dividido em três partes de couchettes, a primeira parte é o título/nome propriamente dito, a segunda parte é a condição de quantas expressões precisam dar macth para gerar o alerta e a última parte é a referência. Adicionalmente, podemos utilizar expressão regular para melhorar nossas regras, assim conseguimos criar regras de auditoria mais precisas e robustas:

\w -> A-Z, a-z, 0-9, '-', '@' characters 
\d -> 0-9 characters 
\s -> For spaces " " 
\t -> For tabs. 
\p -> ()*+,-.:;<=>?[]!"'#$%&|{} (punctuation characters) 
\W -> For anything not \w 
\D -> For anything not \d 
\S -> For anything not \s 
\. -> For anything
 
+ -> To match one or more times (eg \w+ or \d+) 
* -> To match zero or more times (eg \w* or \p*) 
^ -> To specify the beginning of the text. 
$ -> To specify the end of the text. 
| -> To create an "OR" between multiple patterns.

Agora que já temos nossa espécie de dicionário para entender as regras, vamos criar algumas. Iremos criar três regras inicialmente, uma para cada tipo de expressão. Crie um arquivo guiadoti.txt no diretório share do ossec server e altere as permissões dele, em seguida adicione as linhas abaixo nesse arquivo:

# touch /var/ossec/etc/shared/guiadoti.txt 
# chown ossec:ossec /var/ossec/etc/shared/guiadoti.txt
[Generic Linux - DNS Configuration Is Wrong] [any] [http://www.guiadoti.com] 
f:/etc/resolv.conf -> !r:^# && r:^nameserver\.+ && !r:8\.8\.8\.8; 

[Generic Linux - Daemon SSH Is Not Running] [any] [http://www.guiadoti.com] 
!p:r:sshd; 

[Generic Linux - Suspicious File Found] [any] [http://www.guiadoti.com] 
d:/etc/init.d -> ^.initd$;

Depois reinicie o ossec server para ele gerar um novo merged.mg e enviar para os agentes. Antes de prosseguir, vou explicar as regras acima, a primeira regra verifica o conteúdo do arquivo /etc/resolv.conf e vê se o dns utilizado é o 8.8.8.8, caso negativo ele alerta. A segunda regra verifica se o processo “sshd” está rodando, caso negativo ele alerta. A terceira regra verifica por um arquivo oculto “.initd” dentro do diretório /etc/init.d, caso positivo ele alerta (no nosso caso eu criei esse arquivo manualmente para os testes).

Depois de reiniciar o nosso agente “Agent_Linux” temos que aguardar ele terminar o processo de syscheck e rootcheck, para não acompanhar podemos olhar o arquivo de log do agent:

# tail -f /var/ossec/logss/ossec.log

Vocês irão ver as seguintes entrar por último no arquivo de log do agent, quando a última linha aparecer os alertas já devem ter sido enviados para o ossec server:

2017/07/08 03:37:24 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database). 
2017/07/08 03:37:24 ossec-syscheckd: INFO: Starting syscheck database (pre-scan). 
2017/07/08 03:44:52 ossec-syscheckd: INFO: Initializing real time file monitoring (not started). 
2017/07/08 03:44:52 ossec-syscheckd: INFO: Real time file monitoring started. 
2017/07/08 03:44:52 ossec-syscheckd: INFO: Finished creating syscheck database (pre-scan completed). 
2017/07/08 03:45:04 ossec-syscheckd: INFO: Ending syscheck scan (forwarding database). 
2017/07/08 03:45:24 rootcheck: INFO: Starting rootcheck scan.

Execute o comando abaixo no ossec server e veja se os alertas do nosso agente foram gerados, caso positivo, vocês devem ver algo parecido com isso:

** Alert 1499496326.12723: - ossec,rootcheck, 
2017 Jul 08 03:45:26 (Agent_Linux) any->rootcheck 
Rule: 516 (level 3) -> 'System Audit event.' 
System Audit: Generic Linux - DNS Configuration Is Wrong. File: /etc/resolv.conf. Reference: http://www.guiadoti.com .
** Alert 1499496326.12984: - ossec,rootcheck, 
2017 Jul 08 03:45:26 (Agent_Linux) any->rootcheck 
Rule: 516 (level 3) -> 'System Audit event.' 
System Audit: Generic Linux - Daemon SSH Is Not Running. Process: sshd. Reference: http://www.guiadoti.com .
** Alert 1499496326.13235: - ossec,rootcheck, 
2017 Jul 08 03:45:26 (Agent_Linux) any->rootcheck 
Rule: 516 (level 3) -> 'System Audit event.' 
System Audit: Generic Linux - Suspicious File Found. File: /etc/init.d/.initd. Reference: http://www.guiadoti.com .

Também podemos usar o comando abaixo para verificar os últimos alertas do nosso agente, no meu caso o ID no agente é 002:

# /var/ossec/bin/rootcheck_control -i 002 -L

Uma dica bem legal é utilizar os benchmark do CIS Security para criar os arquivos de policy audit no ossec, é um bom ponto de partida para poder contribuir com a comunidade, eu pretendo fazer isso depois que acabar com essa série de posts sobre o ossec, mas qualquer ajuda será muito bem vinda 🙂

Abaixo seguem algumas regras para sistemas Windows, onde focamos em monitorar chaves de registro. Como disse anteriormente, quando se fala de Windows eu prefiro criar os arquivos com regras e fazer toda configuração necessária manualmente, mas isso não é uma regra 😉

[Allow unencrypted traffic] [any] [CIS - Microsoft Windows Server 2012 R2 Benchmark v1.1.0 - Topic 18.7.67.2.2] 
r:HKLM\Software\Policies\Microsoft\Windows\WinRM\Service -> AllowUnencryptedTraffic -> 1;
 

[Disallow WinRM from storing RunAs credentials] [any] [CIS - Microsoft Windows Server 2012 R2 Benchmark v1.1.0 - Topic 18.7.67.2.3] 
r:HKLM\Software\Policies\Microsoft\Windows\WinRM\Service -> DisableRunAs -> 0; 


[Configure Automatic Updates] [any] [CIS - Microsoft Windows Server 2012 R2 Benchmark v1.1.0 - Topic 18.7.71.1] 
r:HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU -> NoAutoUpdate -> 1;
 

[Allow Basic authentication] [any] [CIS - Microsoft Windows Server 2012 R2 Benchmark v1.1.0 - Topic 18.7.67.2.1] 
r:HKLM\Software\Policies\Microsoft\Windows\WinRM\Service -> AllowBasic -> 1;
 

[Firewall state] [any] [CIS - Microsoft Windows Server 2012 R2 Benchmark v1.1.0 - Topic 9.2.1] 
r:HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile -> EnableFirewall -> 0;

Basta copiar as regras acima para o arquivo “win_audit_rcl.txt” do seu agente Windows w reiniciá-lo, depois disso é só olhar os alertas gerados 🙂

Opções de Configuração

Essas opções de configuração podem ser especificadas em ossec.conf de cada agente ou no agent.conf, exceto a opção auto_ignore e alert_new_file, que são opções do lado do servidor ossec. Se a opção ignore for especificada no manager, a configuração será global para todos os agentes.

base_directory

O diretório base que será anexado às seguintes opções:

  • rootkit_files
  • rootkit_trojans
  • windows_malware
  • windows_audit
  • windows_apps
  • systems_audit

Permitido: Caminho do diretório

Default: /var/ossec

rootkit_files

Esta opção pode ser usada para alterar a localização do banco de dados dos arquivos do rootkit.

Permitido: Um arquivo com as assinaturas de rootkit

Default: /etc/shared/rootkit_files.txt

rootkit_trojans

Esta opção pode ser usada para alterar a localização do banco de dados de trojans do rootkit.

Default: /etc/shared/rootkit_trojans.txt

Permitido: Um arquivo com as assinaturas dos trojans

windows_audit

system_audit

windows_apps

windows_malware

scanall

Avisa o rootcheck para verificar todo o sistema (pode levar a alguns falsos positivos).

Default: no

Permitido: yes/no

frequency

Frequência de que o rootcheck será executado (em segundos).

Defaults: 36000 (10 horas)

Permitido: Tempo (em segundos)

disabled

Desativa a execução do check-up.

Default: no

Permitido: yes/no

check_dev

Ativar ou desativar a verificação de arquivos no sistema de arquivos ‘/dev’

Default: yes

Permitido: yes/no

check_files

Ativar ou desativar a verificação com base nos arquivos do rootkit

Default: yes

Permitido: yes/no

check_if

Ativar ou desativar a verificação das interfaces de rede

Default: yes

Permitido: yes/no

check_pids

Ativar ou desativar a verificação de IDs de processo

Default: yes

Allowed: yes/no

check_ports

Ativar ou desativar a verificação de portas de rede.

Default: yes

Permitido: yes/no

check_sys

Ativar ou desativar a verificação do sistema de arquivos em busca de possíveis problemas

Default: yes

Permitido: yes/no

check_trojans

Ativar ou desativar a verificação de trojans.

Default: yes

Permitido: yes/no

check_unixaudit

Ativar ou desativar a verificação de problemas de Unix

Default: yes

Permitido: yes/no

check_winapps

Ativar ou desativar a verificação de aplicativos do Windows

Default: yes

Permitido: yes/no

check_winaudit

Ativar ou desativar a verificação de problemas do Windows

Default: 1

Permitido: 1/0

check_winmalware

Ativar ou desativar a verificação de malware no Windows

Default: yes

Permitido: yes/no

skip_nfs

Especifica se o rootcheck deve escanear sistemas de arquivos montados em rede. Funciona no Linux e no FreeBSD. Atualmente skip_nfs irá abortar verificações executadas contra CIFS ou montagens NFS.

Default: no

Permitido: yes/no

Bem pessoal é isso ai, espero que tenham curtido. Em breve irei postar outros artigos sobre o Ossec mostrando configurações mais avançadas. Não esqueçam de curtir nossas páginas nas redes sociais, FacebookG+ e seguir o Guia do Ti no Twitter. Compartilhem e comentem esse artigo, isso é muito importante para divulgação do nosso trabalho.

Siga me

Ricardo Galossi

É um apaixonado por segurança da informação, atua profissionalmente há mais de 7 anos na área de tecnologia da informação, onde é focado em análise de vulnerabilidades e testes de invasão.Criou o blog Guia do TI para compartilhar conhecimento, ajudar os mais novos, incentivar debates e manter a comunidade atualizada com as principais notícias da área de TI.
Ricardo Galossi
Siga me

Últimos posts por Ricardo Galossi (exibir todos)

Ricardo Galossi

É um apaixonado por segurança da informação, atua profissionalmente há mais de 7 anos na área de tecnologia da informação, onde é focado em análise de vulnerabilidades e testes de invasão. Criou o blog Guia do TI para compartilhar conhecimento, ajudar os mais novos, incentivar debates e manter a comunidade atualizada com as principais notícias da área de TI.

Deixe seu comentário