OSSIM: alertas arpwatch por mail que incluyan MAC origen y destino

Desde hace varias semanas vengo peleando con OSSIM y el plugin que utiliza para parsear logs de arpwatch. En el artículo anterior les conté cómo modifiqué el código de arpwatch para que reporte sólo el cambio de MAC de hosts específicos, y no todos los cambios de MACs. Ahora mi meta era hacer que OSSIM me envíe un mail cada vez que detecte el cambio de MAC de estos hosts.

El envío de este tipo de alertas por mail es muy simple y lo describiré luego. Primero veamos qué información brinda el plugin de arpwatch y entenderán por qué tuve que crear un nuevo plugin.

El plugin original (/etc/ossim/agent/plugins/arpwatch.cfg o /etc/ossim/agent/plugins/arpwatch_eth0.cfg) utiliza el tipo de evento host-mac-event, un tipo de evento que posee un conjunto fijo de atributos y no se pueden agregar, ni quitar, ni modificar, a menos que modifiquemos el código C del servidor OSSIM. Los atributos que brinda este tipo de evento, según la documentación oficial, son:

    host: IP del host que cambio su MAC
    mac: nueva dirección MAC en hexadecmal
    vendor: fabricante de la placa
    sensor
    interface
    date
    plugin_id: el ID del plugin, el cual es siemrpe 1512 (arpwatch)
    plugin_sid: sin importancia ya que el servidor OSSIM asignará el que corresponda
    log: contiene una copia del cambio de MAC
    userdata1: copia de la nueva dirección MAC nueva
    userdata2: copia del nombre fabricante

Si prestan atención, pueden ver que la MAC anterior sólo figura en el atributo log. Cuál es el problema? que el atributo log no se puede utilizar en las acciones (y presupongo que tampoco en las correlaciones, pero no puedo asegurarlo).
Entonces, si no se puede utilizar en las acciones, no es posible enviar mails que incluyan la MAC de origen en ellos, algo que, al menos para mi, es de mucha utilidad.
Supongan que arman una política que les envíe una alerta por mail cada vez que un host importante cambia su MAC. Con el plugin original sólo tendrían la nueva MAC y deberían ir a revisar la larga lista de eventos SIEM para encontrar cual era la MAC anterior y ver la diferencia.


Nuevo plugin para arpwatch

En fin. Para arreglar esto, definí un nuevo plugin para arpwatch, denominado arpwatch_new.cfg (oh si, muy original):

[DEFAULT]
plugin_id=51512

[arpwatch-changed-address]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$4}
mac={$2}
userdata1={$2}
userdata3={$3}
plugin_sid=2
regexp="arpwatch.*?: changed ethernet address (\IPV4) (\MAC) \((\MAC)\) (\S+)"
vendor=unknown

[arpwatch-flipflop]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$4}
mac={$2}
userdata1={$2}
userdata3={$3}
plugin_sid=2
regexp="arpwatch.*?: flip flop (\IPV4) (\MAC) \((\MAC)\) (\S+)"
vendor=unknown

[arpwatch-new-station]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$3}
mac={$2}
plugin_sid=1
regexp="arpwatch.*?: new station (\IPV4) (\MAC) (\S+)"
vendor=unknown

[arpwatch-reused-address]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$4}
mac={$2}
userdata1={$2}
userdata3={$3}
plugin_sid=2
regexp="arpwatch.*?: reused old ethernet address (\IPV4) (\MAC) \((\MAC)\) (\S+)"
vendor=unknown

[config]
create_file=true
enable=yes
interface=eth0
location=/var/log/ossim/arpwatch-new.log
process=/usr/sbin/arpwatch_eth0
restart=no
restart_interval=\_CFG(watchdog,restart_interval)
shutdown=killall %(process)s
source=log
start=yes
startup=%(process)s -d -d -i %(interface)s -f /var/lib/arpwatch/arp-eth0.dat -N >> %(location)s 2>&1 &
stop=yes
type=detector

Como verán, cambié el identificador a 51512 para no colisionar con el anterior (1512) y utilicé el tipo de evento genérico "event", que permite flexibilidad en los atributos a utilizar. Gracias a esto, ahora puedo ver la MAC origen en el atributo userdata3, mientras que la nueva MAC está en userdata1, como antes.
Para habilitar este nuevo plugin, hay que ingresarlo en las tablas plugin y plugin_sid de la base de datos OSSIM. Esto se hace a través del siguiente archivo sql (arpwatch_new.sql):

-- uncomment the following lines to delete old arpwatch plugin
-- DELETE FROM plugin WHERE id = "1512";
-- DELETE FROM plugin_sid WHERE plugin_id="1512";
-- delete old entries of this plugin
DELETE FROM plugin WHERE id = "51512";
DELETE FROM plugin_sid WHERE plugin_id = "51512";

INSERT INTO plugin (id, type, name, description) VALUES (51512, 1, 'arpwatch_new', 'Ethernet/FDDI station monitor daemon');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 1, NULL, NULL, 'arpwatch_new: Mac address New');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 2, NULL, NULL, 'arpwatch_new: Mac address Change');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 3, NULL, NULL, 'arpwatch_new: Mac address Deleted');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 4, NULL, NULL, 'arpwatch_new: Mac address Same');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 5, NULL, NULL, 'arpwatch_new: Mac address Event unknown');

Inluir esto en la base de datos es tan simple como ejectutar:
  cat arpwatch_new.sql | mysql -u root -p ossim

Luego deben modificar la configuración del agente OSSIM para que incluya este plugin, es decir, comentar la línea del plugin de arpwatch anterior y agregar el nuevo en el archivo /etc/ossim/agent/config.cfg, en la sección plugins:
  #arpwatch_eth0=/etc/ossim/agent/plugins/arpwatch_eth0.cfg
  arpwatch_new=/etc/ossim/agent/plugins/arpwatch_new.cfg

Finalmente reinicien los servicios de ossim server y agent:
  /etc/init.d/ossim-server restart
  /etc/init.d/ossim-agent restart
y verifiquen que se encuentre cargado en la  pestaña Collections de la interfaz web.


Reporte de cambios por mail

Con el nuevo plugin ya es posible crear una política que ejecute una acción que envíe mails. Las políticas y las acciones se pueden crear fácilmente desde la interfaz web. Para hacerlo, hay que dirigirse a la opción Intelligence -> Policy & Actions.

Primero crearemos la acción que ejecutará el envío de mail, para luego poder seleccionarla en la política. La acción se crea desde la pestaña Actions y dando al botón New. Una acción puede ser la creación de un ticket, o, como deseamos nosotros, el envío de un mail. Este tipo se elige en el desplegable Type. Es obligatorio colocar una descripción de la acción.
El resto de los campos son muy intuitivos, el originario del mail, el destinatario, el asunto y el mensaje. Se pueden utilizar palabras claves especiales tanto en el contenido como en el asunto del mail, las cuales OSSIM reemplazará por el valor correspondiente. En la parte superior de la acción estan los atributos elegibles, entre los que se cuenta con las IPs de orígen y destino, puertos, protocolos y varios campos más. Para el caso en cuestión, lo importante es que el reporte contenga la IP del host y las MACs anterior y nueva, las cuales se encuentran en los atributos userdata1 y userdata3, según lo definimos en el plugin.

La política se crea de forma bastante intuitiva, en la pestaña Policy, dando New y siguiendo los pasos. Los primeros pasos describen atributos que deben tener los paquetes para que esta política se aplique, como IPs orígen y destino, y Ports destino.
Uno de los pasos relevantes es la definición del "DS Groups", donde se elige el grupo de plugins a tener en cuenta a la hora de analizar los paquetes. OSSIM trae algunos grupos de plugins ya armados, pero para nuestro caso, hay que insertar uno nuevo, dandole al link "Insert new DS Group?". En este punto hay que ingresar un nombre y una descripción, acompañado por el plugin a utilizar, que se selecciona dando en el +

En el listado debería aparecer el nuevo plugin que creamos anteriormente con ID 51512. Una vez seleccionado es posible elegir que tipos de evento, del mencionado plugin, deben tenerse en cuenta. Es así como podemos reportar sólo eventos de cambio de MAC y no cuando se ve un host nuevo. El tipo de evento que nos interesa es el que tiene el identificador 2.
Cuando el grupo DS ya está ingresado, es posible seleccionarlo y continuar con la definición de la política.
El otro paso relevante es la elección de las consecuencias que tiene la política. Es decir, qué acción tomar cuando detectamos un evento que cumple con las características descriptas en la política. Para este caso, elegiremos la acción que creamos anteriormente, y además podríamos elevar la prioridad del evento a 5.


En fin

Con estos cambios ya es posible recibir por mail reportes de cambios de MACs en hosts importantes, que incluyan la MAC anterior y la nueva, gracias a la nueva definición del plugin y la política creada.


Referencias

- OSSIM Sensor - The Agent
- Creating a Custom OSSIM 3 policy