Ossec – Log Analysis and Monitoring– HIDS parte 7
Fala galera! Dando continuidade a nossa série de posts sobre o ossec, hoje vamos ver um pouco mais sobre a parte de análise e monitoramento de logs. Essa é uma das funcionalidades chaves dele, em outras palavras é o coração da ferramenta. Essa funcionalidade é extremamente personalizável, ela te permite fazer de tudo um pouco, mas tudo isso vai depender da necessidade e do cenário de cada um 😉
A análise do log (ou inspeção de logs) é feita pelos processos logcollector e analysisd. O primeiro coleta os eventos e o segundo analisa (decodifica, filtra e classifica) os mesmos. Tudo isso é feito em tempo real, então, assim que um evento for escrito, o ossec os processará. Ele pode ler eventos de arquivos de log internos, do log de eventos do Windows e também recebê-los diretamente através de um syslog remoto.
Dentro do ossec, chamamos a análise de log de LIDS, ou log-based intrusion detection system. O objetivo é detectar ataques, uso incomuns ou erros do sistema usando os logs. Os LIDS são os processos ou técnicas usadas para detectar ataques em uma rede específica ou sistemas usando logs como a principal fonte de informação. Também é muito útil para detectar abusos de software, violações de políticas e outras formas de atividades inadequadas.
Os logs são monitorados em tempo real e os eventos são analisados no lado do server. No agente o uso de CPU e memória são muito pequenos, pois ele só precisa ler e encaminhar os eventos para o servidor, já no servidor o consumo vai depender do número de eventos por segundo. Para ambientes que precisam estar em compliance com o PCI, a ferramenta ajudará diretamente com a sessão 10 do PCI. Em relação há falsos positivos, eles podem ser eliminados utilizado regras locais. Existem dois tipos principais de monitorar logs com o ossec, um deles é através de arquivos, o outro é através de processos.
Monitoramento de processos
Dentro do ossec tudo é tratado como se fosse um registro de log e analisado adequadamente com as regras. No entanto, algumas informações não estão disponíveis nos arquivos de log, mas ainda é preciso monitora-las. Para resolver essa lacuna, foi adicionado a capacidade de monitorar a saída de comandos e tratar a saída desses comandos exatamente como se fossem arquivos de log.
Por exemplo, para monitorar o tamanho de espaço de disco livre basta inserir a entrada abaixo no arquivo de configuração do ossec (/var/ossec/etc/ossec.conf) ao invés de ter que salvar a saída do comando em um arquivo.
<localfile>
<log_format>command</log_format>
<command>df -h</command>
</localfile>Como já existe uma regra para espaço de disco, caso alguma partição atinja 100% de uso iremos ver o seguinte alerta:
** Alert 1257451341.28290: mail - ossec,low_diskspace,
2009 Nov 05 16:02:21 (home-ubuntu) 192.168.0.0->df -h
Rule: 531 (level 7) -> "Partition usage reached 100% (disk space monitor)."
Src IP: (none)
User: (none)
ossec: output: 'df -h': /dev/sdb1 24G 12G 11G 100% /var/backupVamos para outro exemplo, na verdade um exemplo bem besta, pois já temos outras regras que fazem isso e muito mais, mas para fins didáticos é bem interessante, vamos monitorar um usuário específico que logue no ssh, caso positivo iremos receber um alerta. Adicione a entrada abaixo no ossec.conf:
<localfile>
<log_format>command</log_format>
<command>ps aux | grep ssh</command>
</localfile>Agora iremos precisar criar uma regra para que o alerta seja gerado, essa é a primeira vez que estamos criando uma regra desde que iniciamos a série de posts sobre o hids ossec, como o intuito desse post é analise e monitoramento de logs, não vou entrar muitos em detalhes na explicação da regra , iremos ter um post específico para criação de regras em breve 😉
Adicione a entrada abaixo no arquivo de regras locais (/var/ossec/rules/local_rules.xml):
<rule id="200001" level="7">
<if_sid>530</if_sid>
<match>ossec: output: 'ps aux | grep ssh': </match>
<regex>ricardo</regex>
<description>Ricardo is logged via ssh</description>
</rule>Na primeira linha temos o ID da regra, na segunda linha temos uma instrução que diz que essa regra só será lida se a regra com id 530 for trigada, já na terceira linha temos a identificação do comando informado ossec.conf (ps aux | grep ssh), na quarta linha temos a condição propriamente dita, no meu caso se existir a palavra “ricardo” na saída do comando a regra irá gerar um alerta, por último temos a descrição da regra que aparecerá no alerta.
Depois de reiniciar o ossec, basta olhar o arquivo de log de alertas que iremos ver um alerta como exibido abaixo, mas lógico, se não houver nenhum usuário ricardo logado no ssh, nenhum alerta será gerado, altere o regex para o ambiente de vocês.
** Alert 1501210722.3373: mail - local,syslog,2017 Jul 27 23:58:42 OssecServer->ps aux | grep sshRule: 200001 (level 7) -> 'Ricardo is logged via ssh'ossec: output: 'ps aux | grep ssh':root 1205 0.0 0.2 10004 4980 ? Ss Jul23 0:00 /usr/sbin/sshd -Droot 1423 0.0 0.2 13176 6112 ? Ss Jul23 0:01 sshd: ricardo [priv]ricardo 1502 0.0 0.1 13312 3280 ? S Jul23 0:02 sshd: ricardo@pts/0root 2502 0.0 0.0 2368 564 ? S 23:58 0:00 sh -c ps aux | grep sshroot 2504 0.0 0.0 5424 816 ? R 23:58 0:00 grep ssh
No caso do Windows podemos ainda monitorar um registro específico, vamos ver agora um exemplo de monitoramento de USB. Adicione a entrada abaixo no ossec.conf dos agentes Windows ou mesmo no agent.conf:
<localfile>
<log_format>full_command</log_format>
<command>reg QUERY HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR</command>
</localfile>Em seguida precisamos criar uma regra para essa nova configuração, crie a regra abaixo no local rules:
<rule id="140125" level="7"> <if_sid>530</if_sid> <match>ossec: output: 'reg QUERY</match> <check_diff /> <description>New USB device connected</description></rule>
Caso alguém plugue um pendrive ou algum dispositivo USB no agente Windows iremos receber um alerta como mostrado abaixo:
** Alert 1268687754.35062: mail - local,syslog,2010 Mar 15 18:15:54 (xx-netbook) any->reg QUERY HKLMSYSTEMCurrentControlSetEnumUSBSTORRule: 140125 (level 7) -> 'New USB device connected'Src IP: (none)User: (none)ossec: output: 'reg QUERY HKLMSYSTEMCurrentControlSetEnumUSBSTOR':! REG.EXE VERSION 3.0HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORHKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_&Prod_USB_Flash_Memory&Rev_5.00HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Generic&Prod_Flash_Disk&Rev_8.0HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Hitachi&Prod_HTS543225L9A300&Rev_HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_LEXAR&Prod_JD_FIREFLY&Rev_1100HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_SAMSUNG&Prod_HM160JC&Rev_0000HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Sony&Prod_DSC&Rev_1.00HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_TomTom&Prod_ONE_XXL_IQ_RtsHKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_USB_2.0&Prod_USB_Flash_Drive&Rev_0.00Previous output:ossec: output: 'reg QUERY HKLMSYSTEMCurrentControlSetEnumUSBSTOR':! REG.EXE VERSION 3.0HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORHKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_&Prod_USB_Flash_Memory&Rev_5.00HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Generic&Prod_Flash_Disk&Rev_8.07HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Hitachi&Prod_HTS543225L9A300&Rev_HKEY_LOCAL_ACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_SAMSUNG&Prod_HM160JC&Rev_0000HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Sony&Prod_DSC&Rev_1.00HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_TomTom&Prod_ONE_XXL_IQ_RtsHKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_USB_2.0&Prod_USB_Flash_Drive&Rev_0.00
Monitoramento de arquivos
O ossec tem um processo chamado ‘ossec-logcollector’ que monitora arquivos de log configurados no ossec em busca de novos eventos. Quando novas mensagens de log chegam, o log-collector encaminha esses logs para outro processo para ser analisado ou os transporta para o ossec server.
Para adicionar um arquivo de log especifico no Linux basta adicionar a entrada abaixo no arquivo ossec.conf ou no agent.conf:
<localfile>
<location>/var/log/messages</location>
<log_format>syslog</log_format>
</localfile>A tag <log_format> tem várias opções de log, a mais comumente utilizada é o ‘syslog’, ele é usado para arquivos de texto planos que possuem uma linha única para cada entrada de log. Para conhecer os demais tipos de logs suportados acesse o manual do ossec.
No caso de sistemas Windows não é muito diferente, para monitorar um log do Windows Event por exemplo basta adicionar a entrada abaixo no ossec.conf ou agent.conf, observe que o “log_format” é o “eventlog”:
<localfile>
<location>Security</location>
<log_format>eventlog</log_format>
</localfile>Opções de configuração no ossec
Aqui iremos listar as principais opções de configuração disponíveis no “localfile”.
location
Especifica a localização do arquivo de log a ser lido, permite que wildcards sejam utilizados como file.log-%Y-%m-%d. Adicionalmente, múltiplos arquivos podem ser especificados com uma só entrada, basta utilizar asterisco, como em <location>/var/log/*.log</location>.
log_format
Especifica o formato do log que será lido, essa entrada aceita diversos formatos, os mais utilizados são os seguintes atributos:
- syslog – Arquivos de texto plano com uma entrada por linha.
- snort-full – Formato full do output do Snort.
- eventlog – É usado para os logs do Microsoft Windows eventlog.
- eventchannel – Permite que o ossec monitore o “Windows eventlogs” padrão e logs “Application and Services” mais recentes.
- full_command – Esse formato é a saída do comando configurado na tag “command”, ele será tratado como um linha de log única, diferente do “command” que é tratado linha por linha separadamente.
command
O comando a ser executado pelo ossec.
check_diff
A saída de um evento será armazenada em uma base de dados interna para ser comparada com a saída futura dos mesmos eventos, se a saída futura for diferente da anterior um novo alerta será gerado.
Esses são as principais opções de configuração do monitoramento de arquivos e processos, caso você queira ver a lista completa basta acessar o manual do ossec aqui.
Bem pessoal é isso ai, espero que tenham curtido. Em breve irei postar outros artigos da série 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
