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:
- Debian and Ubuntu
- Red Hat and Fedora
- Red Hat Enterprise Linux 5
- VMWare ESX 3.0 and 3.5
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_controlAgora 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) - defaultr: (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.logVocê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->rootcheckRule: 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->rootcheckRule: 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->rootcheckRule: 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 -LUma 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, Facebook, G+ e seguir o Guia do Ti no Twitter. Compartilhem e comentem esse artigo, isso é muito importante para divulgação do nosso trabalho.
- Metasploit Framework de cabo a rabo – Parte 6 - 4 de junho de 2018
- Metasploit Framework de cabo a rabo – Parte 5 - 28 de maio de 2018
- CEH – Scanning Networks – Parte 2 - 24 de maio de 2018
