A análise dos rexistros realízase dentro de OSSEC a través dos procesos logcollector e analysisd. O primeiro é quen de recoller os eventos e o segundo analiza, descodifica, filtra e clasifica os eventos identificados polo primeiro.
Que se entende pola análise do rexistro? En OSSEC enténdese por análise de logs a LIDS, Log based Intrusion Detection, ou detección de intrusión baseada en logs e o seu obxectivo é detectar ataques, mal uso ou erros do sistema usando os rexistros.
A LIDS, en xeral, consiste nunha serie de procesos ou técnicas empregados para detectar ataques dentro dunha rede, sistema ou aplicación específicos e que utilizan os rexistros como a principal fonte de información. Tamén é moi útil para detectar o mal uso de software, as violacións de políticas e outras formas de actividades inadecuadas.

OSSEC realiza este procesado en tempo real, polo que toda vez que un log queda escrito no sistema, OSSEC o procesa e o incorpora á súa lóxica de procesado. OSSEC é compatible con eventos de arquivos de rexistro internos do rexistro de eventos de Windows e tamén de recibilos directamente mediante syslog remoto.

Os eventos procesados por OSSEC en tempo real son almacenados no manager mentres marca a política definida no mesmo e que é configurada polo usuario. Toda o procesado faise no mesmo manager polo que o custo computacional efectúase no mesmo manager.

A configuración das opcións son establecidas localmente no arquivo ossec.conf de cada axente ou o no arquivo compartido agent.conf. As opcións relacionadas están dentro do elemento <localfile>, pode ter as seguintes opcións.

As dúas opcións máis importantes son localfile e log_format. Estas definen a localización dos arquivos a procesar e o seu formato. OSSEC soporta moitos dos máis comúns formatos de log existentes dende syslog ata windows events, pasando por snort, mysql, apache, postgresql, iis, squid, etc.

Na mesma documentación de OSSEC podes atopar multitude de exemplos de configuración para cada cal dos formatos.

Mais, nun escenario real, non toda a información que queres supervisar está dispoñible nos arquivos de rexistro. Existen tamén información interesante de ser supervisada que non se escribe nos rexistros pero que seguro tamén desexaríamos comprobala. Para solucionar esa lagoa, OSSEC engade a capacidade de controlar a saída de comandos e tratar a saída deses comandos como se fosen os ficheiros de rexistro. Esto faise en OSSEC a través dun tipo de formato particular chamado command. Co formato command pódese usar OSSEC para interpretar a saída da execución dun comando como un arquivo de rexistro. En efecto, dentro de OSSEC trátase todo coma se fose un rexistro e analízase de forma similar a como se analizan os arquivos de rexistro. Con esta funcionalidade, somos quen de supervisar cousas como o espazo en disco, a conexión dun dispositivo USB no equipo, etc.

Enviando alertas en OSSEC

Se xa temos o noso servidor de OSSEC detectando eventos sospeitosos nos sistemas, o seguinte paso que nos interesará facer posiblemente sexa a notificación destes eventos a través de alertas. OSSEC inclúe varias formas de enviar alertas a outros sistemas ou aplicacións. Syslog, correo electrónico e envío de alertas a unha base de datos SQL son os métodos máis usuais. Estes métodos de saída envían só alertas e non datos de rexistro completos e, xa que os axentes non xeran alertas, estas opcións son só configurables nos servidores.

A saída de syslog permitirá a un xestor de OSSEC enviar as alertas de OSSEC a un ou máis servidores syslog. Neste exemplo, todas as alertas son enviadas a 192.168.4.1 e as alertas de nivel 10 e anteriores tamén se envían a 10.1.1.1:

<ossec_config>

<syslog_output>
<server>192.168.4.1</server>
</syslog_output>

<syslog_output>
<level>10</level>
<server>10.1.1.1</server>
</syslog_output>


</ossec_config>

Despois de que se realice este cambio, deberase activar o proceso client-syslog:

/var/ossec/bin/ossec-control enable client-syslog

E, finalmente, reiniciar os procesos OSSEC:

/var/ossec/bin/ossec-control restart

A partires deste punto deberiamos ver mensaxes do tipo Forwarding alerts via syslog to no log do servizo. Esto será o indicador de que está a funcionar o sistema de alertas a través de syslog.

Nunha configuración seria tamén será interesante o envío de notificacións a través de correo electrónico. Con OSSEC dispoñemos actualmente de tres tipos de alertas por correo electrónico: Notificacións únicas por alerta; notificacións granulares a calquera número de enderezos; e informes diarios a través de correo electrónico. A configuración do soporte de envío de alertas por correo trátase dunha opción de configuración global:

<ossec_config>
<global>
<email_notification>yes</email_notification>
<email_to>me@example.com</email_to>
<smtp_server>mx.example.com..</smtp_server>
<email_from>ossec@example.com</email_from>
</global>

<alerts>
<email_alert_level>10</email_alert_level>
</alerts>

Resposta activa aos eventos

Xa temos identificados os eventos, xa somos notificados dos sucesos anómalos do sistema mais queremos ir un paso máis aló. Queremos que o sistema sexa quen de actuar automaticamente fronte a un determinado tipo de eventos.

A función de resposta activa dentro de OSSEC outorga o mecanismo para executar aplicacións nun axente ou servidor en resposta a determinados disparadores. Estes disparadores poden ser alertas específicas, niveis de alerta ou grupos de regras.

Este sistema de resposta activa tamén é o que permite a un administrador de OSSEC iniciar unha comprobación do sistema ou reiniciar OSSEC nun axente remoto.

OSSEC por defecto vén con algúns scripts de resposta activa, pero se algunha vez ten que expandilos, OSSEC documenta o xeito de como facelo.

Para o caso de sistemas Unix a configuración de resposta activa está dividida en dúas partes. Na primeira configúranse os comandos que desexan executar. Na segunda, emparéllanse os comandos coas regras ou eventos que os disparan.

Como sempre, aprender a través de exemplos é máis sinxelo e rápido. Escribiremos aquí unhas simples configuracións de como se configuraría a execución de comandos.

Na sección de comandos créanse novos “comandos” para ser usados como respostas. Pódense ter nesta sección tantos comandos como se queira. Cada un debe estar dentro do seu propio elemento de tipo command:

<command>
<name>The name (A-Za-Z0-9)</name>
<executable>The command to execute (A-Za-z0-9.-)</executable>
<expect>Comma separated list of arguments (A-Za-z0-9)</expect>
<timeout_allowed>yes/no</timeout_allowed>
</command>


Na
sección de resposta activa, é onde se fará a asociación dos comandos a executar coas condicións que disparan estes eventos:

<active-response>
<disabled>Completely disables active response if “yes”</disabled>
<command>The name of any command already created</command>
<location>Location to execute the command</location>
<agent_id>ID of an agent (when using a defined agent)</agent_id>
<level>The lower level to execute it (0-9)</level>
<rules_id>Comma separated list of rules id (0-9)</rules_id>
<rules_group>Comma separated list of groups (A-Za-z0-9)</rules_group>
<timeout>Time to block</timeout>
</active-response>

Para configuras a resposta activa en Windows debemos empezar primeiro desactivando a resposta activa por defecto e activar a resposta activa en Windows. Para facelo, engada a seguinte configuración no arquivo ossec.conf do axente:

<active-response>

<disabled>no</disabled>

</active-response>

E xa como último paso, despois diso, configuraríase no manager o comando e cando executar a resposta. Engadindo o seguinte a ossec.conf habilitará as respostas das alertas arriba do nivel 6:

<command>

<name>win_nullroute</name>

<executable>route-null.cmd</executable>

<expect>srcip</expect>

<timeout_allowed>yes</timeout_allowed>

</command>

<active-response>

<command>win_nullroute</command>

<location>local</location>

<level>6</level>

<timeout>600</timeout>

</active-response>

Con isto rematamos polo día de hoxe. Seguimos a vindeira semana e o faremos cun último pero moi interesante artigo onde falaremos da configuración avanzada de OSSEC para a detección de intrusos usando cazadores de rootkits e máis vixiando modificacións de arquivos clave do sistema operativo.

Artigos anteriores

OSSEC: Sistema de detección de intrusos

OSSEC: Pasos de instalación

Pin It on Pinterest

Share This