Después de hacer una introducción a esta interesante herramienta de monitoreo, y ya teniendo en mente los programas que utiliza y qué función desempeña cada uno, podemos comenzar a instalar y configurar el sistema. Para el que se perdió las entregas anteriores, pueden leer el completo review que hice de OSSIM en los siguientes links: Parte I, Parte II, y Parte III.
Si bien la instalación es tan simple como la de cualquier otra distribución, la configuración no lo es tanto. Todo va a depender de la red que estamos monitoreando y de las funciones que deseamos utilizar.
En este artículo voy a plantear la configuración que realicé en el sistema de mi empresa, pero puede que no se adapte a toda red. La realidad es que no existe una receta mágica, y uno se va dando cuenta de lo que necesita alertar y lo que desea obviar una vez que tiene el sistema sniffeando.
Lo que planteo a continuación es una lista de pasos de configuración que realicé, a partir de la observación y la lectura de muchos manuales/artículos/tutoriales. Hace más de dos meses que utilizo OSSIM y todavía queda mucho por aprender. La idea es tener un sistema seguro, que alerte sólo lo que necesitamos.
El artículo inicial lo escribí hace más de un mes, pero como era extremadamente extenso y muchos temas se podían tratar por separado, decidí partirlo en varios artículos genéricos, como el uso de NTP, la activación de HTTPS, la configuración de Snort, las modificaciones a Oinkmaster y las actualizaciones automáticas. En este artículo haré referencia a ellos en el caso que la explicación lo requiera.
Configurar switch para monitorear
Para poder monitorear, primero tenemos que ser capaces de recibir el tráfico que nos interesa. En redes switcheadas, si todo va bien, sólo veremos el tráfico dirigido a la máquina conectada, y el tráfico broadcast. Esto por supuesto no nos sirve si queremos monitorear varios servidores o la red completa.
Por suerte los switchs vienen preparados para realizar monitoreo. No se de otras marcas, pero los Cisco ofrecen dirigir el tráfico de otros ports a un dado port. Es decir, es posible enviar al port donde está conectada nuestra máquina monitor todo el tráfico de otros ports.
Los comandos a ejecutar para realizar esta tarea son muy simples. Debemos definir una sesión de monitoreo, y asignar los ports fuentes y el port destino (nuestra máquina monitor).
Suponiendo que tenemos nuestra máquina monitor en el port GigabitEthernet 0/1, y que deseamos monitorear los ports Gi0/4, Gi0/5 y Fa1/7, los comandos a ejecutar serían:
switch(config)# monitor session 1 destination interface G0/1Listo, ya podemos monitorear =)
switch(config)# monitor session 1 source interface Gi0/4, Gi0/5
switch(config)# monitor session 1 source interface Fa1/7
Instalando OSSIM
OK, el paso más simple será descargar e instalar OSSIM en la máquina destinada a monitoreo.
La descarga la pueden realizar en la sección download de la página de alienvault. La primer decisión que deberán tomar es si instalar la versión de 32 o la de 64 bits. Mi recomendación es que si tienen un procesador de 64bits, instalen la versión de 64bits. Esta versión aprovechará mejor los recursos, y a pesar de la creencia general, las distribuciones de 64bits no ocasionan problemas. Yo utilizo debian de 64bits hace más de 3 años, y no he tenido ningún inconveniente.
El requerimiento de hardware dependerá de la cantidad de hosts a monitorear, y las herramientas de monitoreo que activen. La gente de alienvault recomienda tener una máquina con un mínimo de 2GB de RAM, y por supuesto, una placa de red de 1 Gbit. No hacen ninguna referencia al procesador o al disco, pero por mi experiencia recomendaría como mínimo un Core 2 Duo o un Athlon X2 de 2GHz, y 500GB de disco (realmente se generan muuuuchos logs). Si bien con 2GB de RAM, y desactivando algunos monitoreos, el sistema puede sobrevivir, les recomiendo que se gasten en tener 4GB, así utilizan menos swap y aceleran el sistema.
Los pasos de la instalación son tan simples como el de cualquier distribución basada en debian. Igualmente pueden encontrar una guía en la misma página de OSSIM.
Pasos iniciales
Una vez terminada la instalación, se encuentran con que el sistema inicia en modo consola. Si bien pueden instalar algún entorno gráfico, no creo que valga la pena, simplemente sobrecargarán al ya sobrecargado sistema (a menos que tengan un server con recursos de sobra). Además el sistema funciona completamente por Web, solamente la configuración inicial requerirá que utilicen la consola.
Como bien dije, las herramientas más importantes se visualizan por Web. Por un lado tienen el OSSIM, y por otro Ntop. Si bien Ntop está (al igual que el resto de las herramientas), embebido en las secciones del OSSIM, pueden accederlo directamente a través del port 3000. Ntop no corre sobre apache, sino que ejecuta su propio servidor Web. Les recomiendo que utilicen esta interfaz porque Ntop trae muchísima información que no es desplegada dentro de OSSIM.
Para el resto de la configuración no necesitan estar sentados frente a la máquina monitor, sino que pueden accederlo remotamente a través de SSH, el cual ya viene instalado y funcionando. Claro está que les recomiendo tener siempre un teclado y monitor a mano, porque cuando configuremos el firewall, puede que perdamos la conexión remota =P
Configurar el firewall
OSSIM por defecto trae una configuración de iptables que nos permite acceder a los servicios más importantes (SSL, HTTP y HTTPS), pero obviamente al no conocer de antemano las IPs que tienen permitido el acceso, utiliza una política permisiva que debemos cambiar.
El script que inicia/detiene/reinicia el firewall es /etc/init.d/ossim-firewall. En este script encontrarán que OSSIM realiza un restore de las reglas ubicadas en /etc/ossim_firewall, así que debemos tocar este último archivo.
En ossim_firewall encontrarán, como les anticipé, que las políticas default son ACCEPT. Antes de cambiar esto, debemos modificar las reglas que nos permiten acceso, porque sino, perderemos la conexión (a quién no le ha pasado alguna vez =)).
Para cada servicio utilizado, debemos agregar las IPs desde las que se lo puede acceder. En nuestro caso, remotamente solo accederemos a través de SSH, HTTP, HTTPS, y Ntop, mientras que permitiremos a MySQL que acceda localmente.
Suponiendo que la IP de la máquina monitor es 192.168.1.30 y que permitimos el acceso desde la IP 192.168.1.2, las reglas deberían quedar como las siguientes:
# permitimos sshAhora que ya sabemos lo que vamos a permitir, rechacemos todo el resto. Para ello, modificamos las políticas default, cambiando las líneas
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
# aceptamos que MySQL se conecte localmente
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -s 127.0.0.1 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -s 192.168.1.30 -j ACCEPT
# permitimos HTTP
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
# permitimos HTTPS
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
# permitimos Ntop
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 3000 -j ACCEPT
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
por
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
Habilitar NTP
Si tenemos una red de mediana a grande, probablemente tengamos configurado algún servidor NTP (sobre todo si están en un entorno Windows Active Directory).
Tal como anticipé en la introducción, hace uno días publiqué cómo configurar el sistema como cliente NTP en el artículo Configurar NTP en GNU/Linux. Se aplica exactamente lo mismo en OSSIM.
Habilitando HTTPS
En la instalación default, OSSIM no provee seguridad para acceder a su interfaz Web, simplemente transmite los datos a través de HTTP. Absolutamente todo fluye a través de HTTP, incluso las credenciales de acceso al server. Por ello, el primer paso a realizar es activar HTTPS.
Al igual que en el caso de NTP, hace un tiempo publiqué un artículo que explica cómo habilitar HTTPS en Apache y sobre cómo forzar el uso de SSL. Me remito entonces a tal artículo porque se aplica lo mismo en este caso: Activar HTTPS en Apache + Forzar SSL.
Deshabilitar servicios
Si bien todas las herramientas tiene su utilidad, puede que no necesitemos todas, y si no las necesitamos, es mejor desactivarlas para que no consuman valiosos recursos.
En mi caso, encontré que las herramientas que detectan servicios en la red no eran necesarias, debido a que conozco los dispositivos que se encuentran conectados, y el gasto de recursos que suponían no valía la pena. Por esto, desactivé las herramientas pads y p0f.
Pads me resultó llamativo por el consumo de CPU. Estando pads activado, la utilización de CPU estaba siempre al 100%, con pads encabezando la lista con alrededor de un 97% de utilización. Realmente este alto consumo no justificaba una funcionalidad que puedo realizar con nmap.
P0f no consume tantos recursos pero si genera muchos logs del tipo "se encontró que una máquina tiene el mismo sistema operativo que antes", es decir, mensajes totalmente inútiles que llenan logs y fastidian la vida de la persona que los lee.
A su vez, dado que el administrador de dominio de la red ya cuenta con otras herramientas para monitorear los hosts, también deshabilité el Nagios.
Para desactivar herramientas, primero eliminamos los links desde los diferentes rc* para que no se inicien cada vez que arrancamos el sistema:
# update-rc.d pads removeTambién necesitamos eliminar los servicios de la lista de servicios levantados por OSSIM. Esto lo hacemos comentando las líneas correspondientes en /etc/ossim/agent/config.cfg, en la sección [plugins]:
# update-rc.d nagios3 remove
#p0f_eth0=/etc/ossim/agent/plugins/p0f_eth0.cfgLa anécdota con este último paso es que si no lo realizamos, cada vez que matamos un servicio, OSSIM lo vuelve a revivir! (servicio Highlander como suele llamarlo Javi).
#pads_eth0=/etc/ossim/agent/plugins/pads_eth0.cfg
Ahora sí, estando seguros de que nadie revivirá los servicios, los detendremos con su correspondiente script en /etc/init.d, o bien ejecutamos un kill:
# /etc/init.d/pads stop
# /etc/init.d/nagios3 stop
# killall p0f_eth0
Mantener el sistema actualizado
Algo que es extremadamente importante es mantener el sistema actualizado. Esto permite mantener el sistema seguro, parchando vulnerabilidades.
Tal como les expliqué en el artículo Actualizaciones automáticas de seguridad en GNU/Linux, realizar actualizaciones automáticas pueden provocar inestabilidad y por ello es recomendable aplicar automáticamente sólo actualizaciones de seguridad. En el artículo citado les comento cómo hacer esto con la herramienta unattended upgrades.
Además de las actualizaciones de seguridad, también necesitamos mantener actualizadas las reglas de nuestro snort. Los temas relacionados a la configuración de snort los traté en el artículo Customizando Snort (). Particularmente el tema de actualizar reglas lo pueden encontrar rápidamente en la sección "Mantener Snort actualizado" de dicho artículo.
Cuando se actualizan las reglas de snort, si queremos que OSSIM las detecte debemos ejecutar un script en perl que mapea reglas con entradas en la base de datos del OSSIM (ver Install Oinkmaster and update snort rules):
perl /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules/Esto lógicamente hay que ejecutarlo cada vez que se agregan/actualizan/eliminan reglas, es decir, cada vez que Oinkmaster hace su trabajo. Por ello podemos agregar una entrada en cron que cada día actualice la base de atos:
# rebuild the sid database of ossimSi leen el artículo sobre snort, encontrarán que ya había creado un script para cron que ejecute tareas relacionadas a la actualización de reglas, así que tranquilamente pueden la línea anterior a dicho script.
perl /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules/ 2>&1 | logger -t ossim-snort
Acceso a la interfaz Web OSSIM
Cuando utilicen por primera vez la interfaz Web de OSSIM, se encontrarán con que les pide credenciales que ustedes nunca crearon. Pues bien, esta información la pueden encontrar rápidamente en la guía de OSSIM, pero para ahorrarles el trabajo les comento que las credenciales default son admin:admin.
Cuando se logueen por primera vez usando las credenciales anteriores el sistema les pedirá que cambien el password.
Administración de ntop
Luego de instalar OSSIM, ntop ya se encuentra en funcionamiento y podemos ver las estadísticas que arma a partir de los paquetes observados. Pero si quieren ingresar a la sección "Admin", no van a poder porque requiere un password que nunca asignamos. El password lo podemos asignar desde la consola ejecutando el comando:
# ntop -AEn particular, necesité acceder a las preferencias de la sección Admin para setear el path al programa dot, el cual se encarga de graficar la conexión entre nodos. El gráfico lo pueden ver en "IP -> Local -> Network Traffic Map", eso si, si logran entender algo, es un milagro =P
Corregir Nagios
Si decidieron utilizar Nagios, se van a encontrar con un problema. No investigué demasiado, pero alguno de los programas que descubren hosts, los va agregando automáticamente a Nagios para poder realizar el seguimiento. El problema está en que no realiza correctamente la configuración, porque los agrega en un archivo pero no crea la definición del host.
Por ejemplo, el programa descubre un host que escucha en el port 445, entonces agrega el host a hostgroup-services/port_445_Servers.cfg. Ese archivo define grupos de host que escuchan en el port 445. Hasta aca todo bien. Pero como no crea una definición para el host, cuando Nagios intenta leer la configuración, arroja un error del estilo "Error: Could not find any host matching '
Para que Nagios vuelva a funcionar debemos, o bien quitar de port_445_Servers.cfg la IP del host, o bien crear una definición para el Host. Las definiciones de Hosts están agrupadas en /etc/nagios3/conf.d/ossim-configs/hosts/. Pueden agarrar algún archivo de host ya configurado como base, copiarlo y cambiar la IP. El formato de los archivos que definen hosts es:
define host{
host_name
address
use generic-host
}Deberán generar uno de estos archivos por cada host que tengan en la red. También pueden agregar varias definiciones en un mismo archivo, lo de separarlos es por seguir el funcionamiento de OSSIM.Desactivar alertas molestas
Como menciono al principio del artículo, OSSIM funciona bien apenas lo instalamos, pero es necesario customizarlo para que nos alerte lo que necesitamos. Las configuraciones default nunca son buenas, y este no es un caso especial. Apenas conecten la máquina a la red para monitorear, van a notar una montaña de alertas con falsos positivos. En mi caso, en dos días monitoreando 8 servidores el log creció 40GB! así no hay disco que aguante. Lo bueno es que uno puede reconocer rápidamente cuáles son los falsos positivos más recurrentes y desactivarlos.
Recuerden que en OSSIM se muestran las alertas de todas las herramientas que corren por debajo, como ser snort, OSSEC, p0f, pads, arpwatch, etc. Por supuesto que el que genera la mayor cantidad de alertas es snort. El segundo en generar alertas molestas es OSSEC. Por ello voy a tratar estas dos herramientas en particular.
Configurar snort
Snort es probablemente la herramienta más importante dentro de OSSIM, pero también la más compleja. Con ella perdi la mayor cantidad de tiempo, monitoreando alertas, buscando y aprendiendo lo que reportaban y desactivando lo que no necesito.
En el artículo Customizando Snort traté todos los temas relacionados a esta herramienta, incluída la desactivación de alertas y la configuración de preprocesadores. Me remito entonces a tal artículo.
Lo único que deben tener en cuenta al leer el artículo es que OSSIM genera un archivo de configuración por cada interfaz de red que utilicemos para monitorear. Por ejemplo, si deseamos monitorear con la interfaz eth0, OSSIM genera y utiliza el archivo de configuración /etc/snort/snort.eth0.conf en lugar del clásico snort.conf. A su vez, como explico también en el artículo de snort, los paquetes snort de debian utilizan las variables configuradas en snort.debian.conf, que en OSSIM están en archivos dependientes de la interfaz (tomando como ejemplo eth0, el archivo se llamará snort.debian.eth0.conf).
Algo que también me llamó la atención es el hecho de tener dos binarios para el snort. Por un lado tenemos el común "snort", y por otro uno llamado "snort_eth0". En el caso de tener más placas de red, tal vez OSSIM habría creado un tercer binario llamado snort_eth1, pero no pude encontrar información al respecto, así que no puedo asegurarlo. No descubrí diferencias entre los binarios snort y snort_eth0, incluso calculé los hashes md5 y dan igual... si alguien tiene idea de cuál es el sentido de tener dos binarios, agradeceré comentarios. La teoría de Javi es que esta distinción entre nombres es para que cuando se listan procesos (por ejemplo usando top), uno pueda ver rápidamente en qué interfaz está escuchando cada proceso de snort.
Personalizar alertas en OSSEC
OSSEC se mostró incordioso con los errores en los logs. Básicamente OSSEC busca expresiones regulares en los logs y cuando detecta patrones extraños, los reporta. También posee otras funcionalidades, pero ésta es la que más se utiliza por default en OSSIM.
Luego de observar un rato los alertas en OSSIM, descubrimos rápidamente el error "Unknown problem somewhere in the system" por destacarse en cantidad de apariciones. Este error para nada descriptivo lo arroja OSSEC cuando detecta la presencia de palabras como error, failure, failed, en los logs, y no existe alguna regla que entienda el error. Esto es, una regla detecta la palabra error, si no existe otra regla que detecte un patrón conocido en esa línea, se arroja el error "Unknown problem somewhere in the system" porque no sabe con qué está lidiando, sólo sabe que es un error.
En el caso de mi monitor, encontré que había muchos errores del tipo "Error reading channel stat information. Missing key" en syslog, y por ello saltaba la alerta. La regla que dispara esta alerta está ubicada en /var/ossec/rules/syslog_rules.xml y tiene el siguiente formato:
donde $BAD_WORDS es "core_dumped|failure|error|attack|bad |illegal |denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted". Como no me interesa llenar mi pantalla de monitoreo con este tipo de errores, decidí crear una regla que se abstenga de reportar.$BAD_WORDS alert_by_email Unknown problem somewhere in the system.
Escribir reglas para OSSEC es relativamente sencillo, posee un poderoso motor de expresiones regulares, así que podemos crear reglas complejas. El formato es XML, así que cualquiera puede adaptarse rápidamente.
Al igual que snort, poseemos un archivo donde agregar reglas definidas por nosotros, el cual es /var/ossec/rules/local_rules.xml.
La regla que definiré no reportará el error si la expresión regular coincide con el error "Error reading channel stat information. Missing key" y el programa que la reporta es nfsen:
Como observan, el nuevo id es diferente al original. De esta forma, primero matchea la primer regla, pero como hay una regla que dice no alertar estos casos, entonces no lo hace.
1002
^nfsen
Error reading channel stat information. Missing key \s+
no_email_alert
Pueden leer más sobre customizar reglas OSSEC en Why does ossec send me so many emails?. Me resultó interesante la frase que citan en el mismo: "To keep ossec useful and yourself sane you need to do some tunning to keep the signal to noise ratio high" =)
Para aprender más sobre OSSEC, vean el FAQ donde pueden encontrar mucha ayuda.
No hay comentarios:
Publicar un comentario