fuente: dragonjar
LA RED DEL HACKING ÉTICO
Maltego parte I
De acuerdo a su sitio web, las invenciones Paterva son únicas en cuanto a la manipulación y manejo de software. Paterva está encabezado por ROELOF TEMMINGH, quien está liderando un liviano y letal equipo de talentosos desarrolladores de software. El 6 de mayo de 2008, ellos publicaron una nueva versión de la herramienta denominada MALTEGO.
MALTEGO es una aplicación forense de código abierto, la cual permite la minería y obtención de datos e información, así como la representación de dicha información en una forma significativa. Complementada con sus librerías gráficas, le permite identificar la relación entre claves de información e identificar previamente las relaciones desconocidas entre ellas. Es una herramienta que se debe tener en el campo de la inteligencia, seguridad y aplicaciones forenses.
El relato de CHRIS GATES en el CHICAGO CONS 2008, titulada “NUEVA ESCUELA DE OBTENCIÓN DE INFORMACIÓN”, se refirió a muchas herramientas y técnicas. Una de las herramientas que él introdujo a la audiencia fue MALTEGOv2, la cual es la primera de la serie de 2 partes presentadas en ésta nueva herramienta con una introducción básica a MALTEGO seguida paso a paso por el tutorial de reconocimiento. La parte II, se enfocará en la enumeración de la estructura con MALTEGO.
Qué es MALTEGO?
Es una herramienta para la obtención de información que le permitirá visualizar las relaciones. MALTEGO le permite enumerar la información referente a la red y al dominio, como:
• Nombres de dominio
• Información WHOIS
• Nombres DNS
• Bloques de red
• Direcciones IP
MALTEGO también le permitirá enumerar la información de personas como:
• Dirección de correo electrónico asociada con un nombre de persona
• Sitios web asociados con un nombre de persona
• Números telefónicos asociados con un nombre de persona
• Grupos sociales que están asociados con un nombre de persona
• Compañías y organizaciones asociadas con un nombre de persona
MALTEGO también le permitirá:
• Hacer una verificación simple de las direcciones de correo electrónico
• Búsqueda de blogs y referencias por frases
• Identificar vínculos entrantes para sitios web
• Extraer metadatos desde archivos y fuentes de dominios
lunes, septiembre 20, 2010
martes, septiembre 14, 2010
Instalación OSSIM
Fuente: http://itfreekzone.blogspot.com
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:
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:
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:
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:
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):
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:
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 '' (config file '/etc/nagios3/conf.d/ossim-configs/hostgroup-services/port_445_Servers.cfg', starting on line 1)".
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:
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:
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:
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.
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.
OSSIM
Se trata de una distribucción linux que lleva multiples herramientas de monitorización de seguridad para una red. Se accede a la misma mediante un interface web y data de un servidor donde corren las aplicaciones y agentes para los pcs que forman la red dependiendo de la arquitectura y sistema operativo. http://www.alienvault.com/community.php?section=WhatisES
OSSIM ofrece detección de anomalias de red, analisis forense, analisis de vulnerabilidades, detección de intrusiones, etc .... gracias a herramientas tales como snort, nessus, OSSEC, nmap, spof, etc ...
Desde este blog http://itfreekzone.blogspot.com hemos sacado un pequeño manual que muestra por encima esta potente herramienta única y de software libre:
Hace tiempo en la empresa deseamos instalar un servidor de monitoreo, y por suerte el último mes volvieron realidad mi sueño (si me contento con poco...). Ya tenía en mente cómo sería la máquina para monitorear, tendría un GNU/Linux (tal vez debian o CentOS), y herramientas como ntop, Nessus y snort, pero no mucho más. Pero la cosa cambió cuando Javi me recomendó utilizar la distribución AlienVault OSSIM (Open Source Security Information Management). Esta distribución esta diseñada pensando en el monitoreo, e incluye todas aplicaciones libres destinadas a tal fin, ya configuradas y listas para usar.
La distribución lleva el nombre de la herramienta OSSIM, la cual se encarga de juntar los resultados retornados por las diferentes aplicaciones y mostrarlos en una interfaz Web única, desde donde el administrador puede observar todo lo que sucede en la red.
Si bien la instalación es muy simple y todo sale funcionando en cuestión de minutos, es necesario conocer las aplicaciones que corren de fondo para así entender los resultados retornados, y configurar el sistema para visualizar la información que nos interesa. Esta customización la vengo haciendo hace algunos días, y a partir de ella aprendí para qué sirve cada herramienta.
Como la funcionalidad de OSSIM se basa en las herramientas que corren por detrás, haré un mini-review de cada una. El review lo dividiré en partes porque son varias herramientas y muchas tienen varios componentes por lo que harían el artículo demasiado extenso. En esta primera parte hablaré de OSSIM en sí y de dos de los IDSs que trae, en las próximas examinaré el resto de las herramientas.
OSSIM
Como dije anteriormente, esta herramienta, desarrollada por la gente de AlienVault, se encarga de recolectar los datos entregados por las diferentes aplicaciones de monitoreo y mostrarlos a través de una interfaz Web. Realmente me sorprendió el nivel de integración que tiene OSSIM con el resto de las herramientas (que describiré abajo), logrando abstraer al administrador de lo que sucede de fondo. En lugar de tener que mirar por separado miles de logs, la interfaz Web junta todos los datos en un solo lugar y permite así tener vistas detalladas de cada aspecto de las redes, hosts, servidores, etc.
OSSIM se divide en tres programas: ossim-server, ossim-framework y ossim-agent. Además utiliza una base de datos para almacenar los eventos y la información necesaria para plugins.
- ossim-server: este programa es un demonio que se ejecuta en background y se conecta con la base de datos para obtener/ingresar datos desde los agentes y el framework. El propósito principal de este programa es:
- ossim-framework: es otro demonio que ejecuta tareas misceláneas, no realizables por los agentes, servers o el front-end. Este accede tanto a la base de datos de conocimiento del OSSIM, como a la BD de eventos. El propósito principal de este programa es:
- ossim-agent: se instala un agente en cada máquina que deseamos utilizar como monitor (llamadas sensores). Los agentes se encargan de recolectar todos los datos enviados por los diferentes dispositivos conectados a la red, estandarizar estos datos para que OSSIM pueda entenderlos, y luego enviarlos al servidor.
Pueden leer más en la documentación oficial sobre agentes.
Dados los tres programas anteriores, la arquitectura de OSSIM se divide en 4 elementos:
1. Sensores
2. Servidor de Administración
3. Base de Datos
4. Frontend
En la configuración default, los sensores se encargan de realizar las tareas de IDS, Vulnerability Scanner, detección de anormalidades, monitoreo de red, recolección de datos de routers, firewalls, e incluso pueden funcionar como firewall. Los sensores se encargan de enviar toda la información al servidor de administración, luego de haberla estandarizado.
Por su parte, el servidor de administración contiene el framework y el servidor OSSIM. Este servidor se encarga de recolectar la información de todos los sensores y normalizar, priorizar, coleccionar eventos, así como realizar análisis de riesgo. Además se encarga de realizar backups, inventarios on-line, y ejecución de escaneos.
La base de datos almacena eventos e información útil para la administración del sistema.
El frontend, como ya mencioné, es una aplicación web donde se puede visualizar todo lo que sucede.
La magia utilizada para estandarizar los datos recolectados de los diferentes programas, se realiza a través de plugins. Cada herramienta que se utiliza, debe tener su correspondiente plugin en OSSIM.
Existen dos tipos de plugins:
- Detectores: encargados de leer los logs creados por las diferentes herramientas y estandarizarlos para que el Agente pueda enviarlos al servidor. Ejemplos típicos de plugins detectores son snort, p0f, arpwatch, pads, etc.
- Monitores: reciben pedidos del servidor OSSIM y los envían a la herramienta correspondiente, obtienen la respuesta y le avisan al servidor si la herramienta acepta lo que se le pide. Ejemplos de monitores son el nmap y tcptrack.
Como ven, OSSIM es un sistema bastante complejo. En la documentación oficial pueden encontrar cómo crear plugins propios, así como también cómo crear políticas para generar alertas y acciones. Realmente vale la pena estudiarlo y utilizarlo.
Snort
Snort es uno de los IDSs utilizados por OSSIM. Por si todavía no conocen este tipo de herramientas, IDS significa Intrusion Detection System, o sistema de detección de intrusos. Los IDSs utilizan distintas técnicas de análisis para alertar al administrador en caso de ver acciones sospechosas. Snort en particular es un NIDS (N de Network) que se encarga de analizar el tráfico de red, inspeccionando el contenido de los paquetes para disparar alertas, o incluso, realizar algún tipo de acción cuando detecta trafico sospechoso. Snort es el IDS más utilizado mundialmente, y es probablemente el más completo de su tipo.
Como bien dice en el FAQ oficial, snort realiza análisis de protocolo, búsqueda/matching de contenido, y puede detectar una gran variedad de ataques y pruebas, como buffer overflows, escaneo sigiloso (stealth) de ports, ataques CGI, intentos de fingerprint de SOs, pruebas SMB, y mucho más.
La idea es simple (implementarla no lo es tanto), Snort sniffea la red y a través de un conjunto de reglas decide si el tráfico es sospechoso. Las reglas contienen la información que debería contener un paquete para considerarlo sospechoso, como ser la IP origen, el port origen, la IP destino, el port destino y el contenido del paquete. En las reglas se pueden utilizar expresiones regulares y se debe incluir un mensaje que describa qué es lo que detecta.
Además del motor de detección, Snort provee preprocesadores. Los preprocesadores permiten a los usuarios y programadores extender la funcionalidad de Snort. El código de los preprocesadores se ejecuta antes del motor de detección, pero después de que el paquete fue decodificado.
Snort es muy flexible y permite al usuario crear sus propias reglas y preprocesadores. Las reglas se almacenan en path/snort/rules/ y tienen una sintaxis simple, los preprocesadores requieren programación. Un artículo interesante para revisar es el de O'Reilly Write Your Own Snort Rules . Por supuesto, la mejor referencia de Snort es la guía de usuario proporcionada por Sourcefire (la empresa detrás de Snort).
OSSEC
Otro de los IDSs provistos por OSSIM, en este caso, un HIDS (H de Host). Un sistema de detección de intrusos basado en el Host se encarga de analizar los datos del host y detectar a través de ellos si el host está siendo víctima de algún ataque. OSSEC realiza esta tarea analizando logs, checkeando integridad, monitoreando la registry de Windows, detectando rootkits, y generando y respondiendo en tiempo real.
Los IDSs basados en análisis de logs son llamados LIDS (L de Log), porque detectan errores (o ataques) usando logs como su fuente de información primaria.
OSSEC (desarrollado por Trend Micro) está formado por un administrador (manager) central de monitoreo, que recibe información desde agentes, syslog, bases de datos y dispositivos sin agentes (agentless).
El manager almacena las bases de datos del chequeo de integridad de archivos, los logs, los eventos, y las entradas de auditoría del sistema. Todas las reglas, decodificadores y configuraciones importantes se almacenan en el manager.
Los agentes son pequeños programas que se instalan en los sistemas que deseamos monitorear, estos coleccionan información en tiempo real y se la envían al manager para ser analizada.
En los sistemas donde no se puede instalar agentes (Agentless), OSSEC puede realizar monitoreo de integridad de archivos.
OSSEC corre en la mayoría de los sistemas (Windows, Linux, OpenBSD/FreeBSD, y MacOS), y el análisis lo realiza a través de reglas escritas en lenguaje XML. Al igual que Snort, estas reglas son relativamente simples de escribir y se basan en la búsqueda de patrones (se pueden usar expresiones regulares) en los archivos analizados. También se pueden crear reglas compiladas, escritas en lenguaje C.
Como se habrán dado cuenta, OSSEC es una herramienta muy potente. Pueden aprender más de OSSEC leyendo el FAQ de la página, donde encontrarán varios tutoriales.
Como lo prometí, heme aquí escribiendo la segunda parte del review del OSSIM. Para el que no haya leído la primera parte, puede encontrarla aquí.
Para repasar un poco las cosas, recordemos que OSSIM es una herramienta que agrupa los resultados de muchas herramientas para mostrarlos de forma uniforme al pobre encargado de monitorear la red. La lista de herramientas que se ejecutan de fondo es grande y en la primer parte repasé, además de OSSIM, los IDSs Snort y OSSEC. En esta entrega veremos un poco más sobre herramientas de monitoreo y escaneo de red. Arranquemos nomas con el repaso.
Osiris
Continuando con la seguidilla de IDSs del artículo anterior, OSSIM también trae Osiris, un HIDS centrado en el monitoreo de integridad del host. Este se utiliza para monitorear cambios en una red de hosts a través del tiempo y reportando estos cambios al administrador(es).
Actualmente, el monitoreo incluye cambios en el filesystem. Osiris toma snapshots periódicos del filesystem y los almacena en una base de datos. Estas bases de datos, así como las configuraciones y los logs, son almacenados en un host de administración central. Cuando se detectan cambios, Osiris loguea estos eventos en el log del sistema y opcionalmente envía un e-mail al administrador.
Además de los archivos, Osiris también monitorea listas de usuarios, listas de grupos, y módulos del kernel o extensiones.
La arquitectura de Osiris está basada en tres componentes:
- consola de administración (osirisimd): debe estar instalada en un host confiable porque es a donde se almacena la información sobre los hosts administrados, incluyendo configuraciones, logs, y bases de datos.
- un agente de escaneo (osirisd): proceso que se ejecuta en cada host monitoreado. Es el responsable de escanear el filesystem local y enviar los datos al host administrador.
- aplicación de administración CLI (osiris): la utiliza el administrador para administrar los detalles de los hosts escaneados. Se comunica directamente con la consola de administración.
osiris <==> osirismd <==> osirisd
Pueden leer más sobre Osiris en su handbook.
Nessus
Pasamos de la detección pasiva a la activa por un momento. Nessus es un programa de escaneo de vulnerabilidades. Su función es escanear los hosts que el usuario desea, detectando primero los ports que tienen abiertos y luego enviando una batería de test para comprobar qué hosts son vulnerables. A partir de los resultados obtenidos, Nessus arma un detallado informe con las vulnerabilidades de cada host, describiendo cada vulnerabilidad, el nivel de riesgo que representa y las posibles formas de mitigarla.
Esta herramienta ahorra horas de pruebas al auditor de red (el sueño del pentester), y permite que personas sin tanto conocimiento sobre exploits pueda conocer los problemas en la red y las soluciones.
Nessus es una herramienta muy completa y flexible, permitiendo agregar tests (plugins) de vulnerabilidades, los cuales deben ser escritos en NASL (Nessus Attack Scripting Language), un lenguaje de scripting optimizado para interacción de red personalizada. Además es posible realizar auditoría de passwords y verificar el nivel de parches aplicados en Windows si el usuario provee las credenciales necesarias.
El reporte generado por Nessus se puede exportar en varios formatos como texto plano, XML, HTML y LaTeX, además del formato propio de Nessus.
En sistemas Unix Nessus está compuesto por un demonio nessusd encargado de realizar es escaneo, y un cliente que controla el escaneo y muestra los resultados. La versión Windows, en cambio, es un solo ejecutable que contiene todo.
Realmente esta herramienta es extremadamente útil, no sólo porque realiza un escaneo automatizado excelente (cubre una amplísima variedad de pruebas), generando reportes bien descriptivos, sino también porque es muy fácil de utilizar. La primera vez que corrí Nessus quedé muy sorprendido por su capacidad, no he conocido otra herramienta que realice un escaneo automatizado tan bueno. Generalmente los escaneos automatizados cubren algunos aspectos, pero fallan en detectar muchas vulnerabilidades, dejando la mayor parte del trabajo a la persona que realiza la auditoría.
Penosamente Nessus dejó de ser libre en 2005. La compañía detrás de Nessus (Tenable Network Security) cerró el código en su versión 3 y ahora venden los plugins. Por suerte todavía mantienen un conjunto de plugins gratuitos pero que sólo pueden utilizarse en casa o en empresas sin fines de lucro (ver Nessus FAQ). Si quieren utilizar Nessus en entornos con fines de lucro, deben comprar la versión profesional.
Por ello la gente de Alien Vault (empresa detrás de OSSIM) creó su propio conjunto de plugins gratuitos y licenciados bajo la GPLv2.
OpenVAS
Además de Nessus, OSSIM incluye OpenVAS (OpenSource Vulnerability Assessment Scanner), el fork libre de Nessus, creado a partir del motor en Nessus 2 (que era libre). Se entiende a partir de esto que OpenVAS funciona igual a Nessus y persigue el mismo propósito, escanear en busca de vulnerabilidades.
Esta herramienta tiene algunas limitaciones y no llega a ser Nessus, pero el trabajo detrás es interesante, porque además se pueden utilizar los plugins libres de Nessus.
Nagios
OK llegamos a una de mis favoritas. Sin dudas Nagios es una de las herramientas más interesantes para el monitoreo de redes, aunque también una de las más complejas para customizar y mantener. Como bien dicen en el manual oficial "Relax - it's going to take some time".
Nagios es de las herramientas más complejas, pero permite a un administrador tener una visión central del estado de los hosts de la red. A través del monitoreo de hosts, Nagios puede enviar alertas en caso de fallas. La descripción de la funcionalidad es simple, monitorear hosts y alertar en caso de fallas. Además posee un front-end web desde donde se puede observar el estado de la red.
Nagios se basa en un demonio central que recibe datos de plugins y los almacena en una base de datos. La configuración de todo el sistema se realiza a través de archivos de texto. Nagios no incluye mecanismos de chequeo de estado de hosts y servicios, deja este trabajo a los plugins. Simplemente se limita a ejecutar los plugins, recibir los resultados, procesar los resultados y ejecutar las acciones necesarias.
Lo bueno del sistema de plugins es que abstraen a Nagios del chequeo en sí, logrando que sea extremadamente flexible y extensible, abarcando varias plataformas. Los plugins pueden ser scripts o ejecutables que se pueden ejecutar desde la línea de comandos.
Si bien todo el monitoreo se puede realizar desde una sola máquina, algunos plugins requieren que se instale un agente monitor en la máquina que deseamos monitorear. Ejemplo de este caso es cuando deseamos monitorear el uso de CPU, memoria, disco, de alguna máquina en particular. El agente monitor se comunica con el server Nagios para enviar la información necesaria.
Actualmente existen plugins para monitorear varios dispositivos y servicios incluyendo:
* HTTP, POP3, IMAP, FTP, SSH, DHCP
* Carga de CPU, Uso de Disco, Uso de Memoria, Usuarios Actuales
* Unix/Linux, Windows, y servidores Netware
* Routers y Switches
Alertar sobre fallas es la principal función de Nagios, pero éste también es capaz de ejecutar event handlers. Los event handlers, al igual que los plugins, son comandos del sistema (ejecutables o scripts), y tratan de arreglar el problema antes de notificarlo. Entre los usos se incluye:
* Reiniciar un servicio que falló
* Ingresar un ticket de problema en un sistema helpdesk
* Loguear información del evento en una base de datos
* Reboot del sistema (hay que tener mucho cuidado con este)
Como dije anteriormente, Nagios es muy muy completo. La configuración no es simple, pero está muy bien documentada. Lleva un tiempo hasta que logramos que nos alerte lo que deseamos, o tomar las acciones necesarias. Al principio puede resultar bastante molesto la cantidad de alertas arrojadas, pero gracias a la configuración de umbrales, y a la inteligencia para detectar flip-flos (cuando un servicio/host cae y se levanta muchas veces en un intervalo corto de tiempo) es posible lograr el funcionamiento deseado.
Para esta tercer entrega dejé las herramientas que realizan su trabajo pasivamente, sin interferir en el funcionamiento normal de la red. Estas herramientas trabajan observando el tráfico de la red y generando estadísticas o alertas según lo que observan. También hablaré sobre una excelente herramienta que permite mantener un inventario en tiempo real de los dispositivos de la red.
NFSen
NFSen o Netflow Sensor, es un front-end web para las herramientas de flujo de red nfdump. A través de este front-end podemos ver gráficos de flujos, paquetes y Bytes usando RRD (Bases de datos Round Robin). Además es posible setear alertas e incluso programar plugins propios para procesar el flujo de red.
En cuanto al manejo de los gráficos NFSen es bastante flexible, permitiendo seleccionar intervalos de tiempos, tipo de gráficos (lineares, logarítmicos, etc), ver resumen estadístico, crear filtros, etc. Se pueden crear perfiles donde el usuario puede customizar lo que desea ver, con qué colores, en qué intervalo.
Como NFSen funciona sobre la base de NFDUMP, describiré un poco de qué trata esta última.
NFDUMP es un conjunto de herramientas encargadas de recolectar y procesar flujos de datos en la red que funcionan por línea de comandos. Las herramientas que componen NFDUMP son:
- nfcapd: el demonio que captura el flujo de red. Lee datos de la red y los almacena en archivos, los cuales va rotando automáticamente cada n minutos.
- nfdump: vendría a ser el dump de los datos almacenados por nfcapd. Esta herramienta sirve como visualizador de los datos almacenados por nfcapd. La sintaxis es similar a la de tcpdump, y puede crear varias estadísticas del tipo "top N" basado en flujos de datos IP, ports, etc.
- nfprofile: otro que lee los datos almacenados por nfcapd. Estos datos se pasan a través de un conjunto de filtros y los datos filtrados se almacenan en nuevos archivos.
- nfreplay: simplemente hace forward de los datos almacenados por nfcapd hacia otros hosts.
- nfclean: permite borrar los datos viejos.
- ft2nfdump: permite convertir datos de herramientas de flujo desde archivos o de la stdin al formato nfdump.
NFDUMP entonces permite analizar el flujo de datos en la red del pasado y hacer un seguimiento de patrones de tráfico interesantes continuamente.
Ntop
Otra gran herramienta que permite ver el uso de la red. Ntop lleva su nombre por la analogía con el comando top de Unix que muestra el uso de la memoria, CPU, etc, de los procesos.
Ntop, al igual que nfdump, lee los datos de la red, los almacena en archivos y a partir de ellos genera gráficas visualizables a través de una interfaz Web (port 3000 por defecto). Ntop es mucho más completo que nfdump, porque no solo distingue entre tráfico udp, tcp, icmp, etc, sino que también distingue protocolos de la capa aplicación, como ser HTTP, SNMP, SSH, DNS, etc.
La variedad de gráficas que Ntop es capaz de generar hacen que el administrador tenga una excelente visión de lo que sucede en la red. Se pueden generar gráficas por host, e incluso distingue que servidores ejecuta un dado host.
No hay mejor resumen de lo que se puede hacer con Ntop que el que nos da su autor en la página:
Pads
Pads cuyo significado es Passive Asset Detection System (Sistema de Detección Pasiva de Activos) es un sniffer que a través de signatures detecta activos. Los activos pueden ser dispositivos o servicios ejecutándose en la red. La idea detrás de PADS (como comenta su autor en la página oficial) es ser un nmap que funcione de forma pasiva, esto es, sin enviar un solo paquete a la red.
El funcionamiento es simple, Pads sniffea la red y a través de signatures va detectando servicios y hosts que existen en ésta, y loguea lo que detecta. De esta forma se puede hacer un mapeo de la red sin generar tráfico. Claro está que este tipo de detección es menos precisa que un escaneo activo como el de nmap, pero es muy útil cuando este último no es una opción viable.
P0f
Passive OS Fingerprinting (p0f) es otra herramienta de detección pasiva que permite obtener el fingerprint de Sistemas Operativos sin enviar un solo paquete a la red. Esta herramienta permite hacer un mapeo host->SO de los hosts que existen en la red, sin que estos se enteren. El funcionamiento es similar al de escaners activos como nmap, revisando TTL, TCP Windows size, DF (don't fragment), TOS (Type of Service), etc, de los paquetes que llegan a la máquina.
Arpwatch
Herramienta simple pero muy útil a la hora de detectar intrusos. Arpwatch observa las MACs que existen en la red, y mantiene un archivo con su IP asociada, el timestamp de la última vez que se vió en la red, y genera notificaciones en caso de haber cambios. De esta forma, es posible detectar si una IP asociada a una dada MAC ahora está asociada a otra MAC. En una red donde las máquinas suelen conservar su IP por largos períodos de tiempo (o estar fijas), el uso de una IP por otra máquina (con su dada MAC) es una situación sospechosa.
Esta herramienta permite por ejemplo detectar ataques Man in the Middle, suplantación de proxies, servers DNS, HTTP, etc.
Tcptrack
Conocido como el 'top' (por el comando Unix) de las conexiones TCP, Tcptrack es un sniffer que muestra información sobre las conexiones TCP que ve en una dada interfaz. Al igual que las herramientas anteriores, ésta funciona de forma pasiva, observando conexiones TCP y siguiendo el rastro del estado, mostrando la lista de conexiones de forma similar al comando top de Unix.
OCS-NG
Luego de hablar sobre herramientas de detección de intrusos, vulnerabilidades y monitoreo de la red, nos encontramos con OCS Inventory NG (Open Computer and Software Inventory Next Generation) que nos permite mantener un inventario actualizado en tiempo real de los dispositivos existentes en la red.
OCS-NG cuenta con 4 componentes principales:
- servidor de base de datos: que almacena la información del inventario (puede ser MySQL 4.1 o posterior),
- servidor de comunicación: maneja la comunicación HTTP/S entre la base de datos y los agentes (Apache 1.x, 2.x),
- servidor de despliegue: almacena la información de los paquetes a desplegar (requiere HTTPS),
- consola de administración: front-end web que permite al administrador realizar consultas a la base de datos (Apache 1.x, 2.x y PHP 4.1 o superior).
El funcionamiento se basa en instalar un agente en cada host que se desea inventariar, y mantener un servidor (o repartido en varios servidores) la base de datos con el manejador de los datos enviados por los agentes. Cada agente envía los datos del inventario de la máquina a través de HTTP/S al servidor de comunicación, utilizando archivos XML comprimidos con Zlib. Luego un administrador puede revisar su inventario a través de la interfaz Web.
OCS soporta la mayoría de los sistemas operativos, incluyendo GNU/Linux, Windows, Mac, Solaris, AIX, y *BSD.
Si bien no tuve la oportunidad de probar esta herramienta (viene instalada por defecto en OSSIM, pero no desplegué agentes), a partir de los screenshots se puede observar que es muy completa, mostrando información de discos, sistema de archivos, CPU, memoria, dispositivos, controladores, etc. Una herramienta muy interesante, para tener en cuenta.
OSSIM ofrece detección de anomalias de red, analisis forense, analisis de vulnerabilidades, detección de intrusiones, etc .... gracias a herramientas tales como snort, nessus, OSSEC, nmap, spof, etc ...
Desde este blog http://itfreekzone.blogspot.com hemos sacado un pequeño manual que muestra por encima esta potente herramienta única y de software libre:
Hace tiempo en la empresa deseamos instalar un servidor de monitoreo, y por suerte el último mes volvieron realidad mi sueño (si me contento con poco...). Ya tenía en mente cómo sería la máquina para monitorear, tendría un GNU/Linux (tal vez debian o CentOS), y herramientas como ntop, Nessus y snort, pero no mucho más. Pero la cosa cambió cuando Javi me recomendó utilizar la distribución AlienVault OSSIM (Open Source Security Information Management). Esta distribución esta diseñada pensando en el monitoreo, e incluye todas aplicaciones libres destinadas a tal fin, ya configuradas y listas para usar.
La distribución lleva el nombre de la herramienta OSSIM, la cual se encarga de juntar los resultados retornados por las diferentes aplicaciones y mostrarlos en una interfaz Web única, desde donde el administrador puede observar todo lo que sucede en la red.
Si bien la instalación es muy simple y todo sale funcionando en cuestión de minutos, es necesario conocer las aplicaciones que corren de fondo para así entender los resultados retornados, y configurar el sistema para visualizar la información que nos interesa. Esta customización la vengo haciendo hace algunos días, y a partir de ella aprendí para qué sirve cada herramienta.
Como la funcionalidad de OSSIM se basa en las herramientas que corren por detrás, haré un mini-review de cada una. El review lo dividiré en partes porque son varias herramientas y muchas tienen varios componentes por lo que harían el artículo demasiado extenso. En esta primera parte hablaré de OSSIM en sí y de dos de los IDSs que trae, en las próximas examinaré el resto de las herramientas.
OSSIM
Como dije anteriormente, esta herramienta, desarrollada por la gente de AlienVault, se encarga de recolectar los datos entregados por las diferentes aplicaciones de monitoreo y mostrarlos a través de una interfaz Web. Realmente me sorprendió el nivel de integración que tiene OSSIM con el resto de las herramientas (que describiré abajo), logrando abstraer al administrador de lo que sucede de fondo. En lugar de tener que mirar por separado miles de logs, la interfaz Web junta todos los datos en un solo lugar y permite así tener vistas detalladas de cada aspecto de las redes, hosts, servidores, etc.
OSSIM se divide en tres programas: ossim-server, ossim-framework y ossim-agent. Además utiliza una base de datos para almacenar los eventos y la información necesaria para plugins.
- ossim-server: este programa es un demonio que se ejecuta en background y se conecta con la base de datos para obtener/ingresar datos desde los agentes y el framework. El propósito principal de este programa es:
# recolectar datos de los agentes y otros servidoresPueden leer más en la documentación oficial sobre servidor.
# priorizar los eventos recibidos
# correlacionar los eventos recibidos de diferentes fuentes
# realizar la evaluación de riesgos y disparar alarmas
# almacenar eventos en la base de datos
# reenviar eventos o alarmas a otros servidores
- ossim-framework: es otro demonio que ejecuta tareas misceláneas, no realizables por los agentes, servers o el front-end. Este accede tanto a la base de datos de conocimiento del OSSIM, como a la BD de eventos. El propósito principal de este programa es:
# leer/escribir archivos del filesystem, evitando que el server web lo haga directamente.Pueden leer más en su documentación oficial sobre framework.
# ejecutar comandos externos.
# ejecutar en background tareas que requieran uso intensivo de CPU, para acelerar la visualización y el análisis.
- ossim-agent: se instala un agente en cada máquina que deseamos utilizar como monitor (llamadas sensores). Los agentes se encargan de recolectar todos los datos enviados por los diferentes dispositivos conectados a la red, estandarizar estos datos para que OSSIM pueda entenderlos, y luego enviarlos al servidor.
Pueden leer más en la documentación oficial sobre agentes.
Dados los tres programas anteriores, la arquitectura de OSSIM se divide en 4 elementos:
1. Sensores
2. Servidor de Administración
3. Base de Datos
4. Frontend
En la configuración default, los sensores se encargan de realizar las tareas de IDS, Vulnerability Scanner, detección de anormalidades, monitoreo de red, recolección de datos de routers, firewalls, e incluso pueden funcionar como firewall. Los sensores se encargan de enviar toda la información al servidor de administración, luego de haberla estandarizado.Por su parte, el servidor de administración contiene el framework y el servidor OSSIM. Este servidor se encarga de recolectar la información de todos los sensores y normalizar, priorizar, coleccionar eventos, así como realizar análisis de riesgo. Además se encarga de realizar backups, inventarios on-line, y ejecución de escaneos.
La base de datos almacena eventos e información útil para la administración del sistema.
El frontend, como ya mencioné, es una aplicación web donde se puede visualizar todo lo que sucede.
La magia utilizada para estandarizar los datos recolectados de los diferentes programas, se realiza a través de plugins. Cada herramienta que se utiliza, debe tener su correspondiente plugin en OSSIM.
Existen dos tipos de plugins:
- Detectores: encargados de leer los logs creados por las diferentes herramientas y estandarizarlos para que el Agente pueda enviarlos al servidor. Ejemplos típicos de plugins detectores son snort, p0f, arpwatch, pads, etc.
- Monitores: reciben pedidos del servidor OSSIM y los envían a la herramienta correspondiente, obtienen la respuesta y le avisan al servidor si la herramienta acepta lo que se le pide. Ejemplos de monitores son el nmap y tcptrack.
Como ven, OSSIM es un sistema bastante complejo. En la documentación oficial pueden encontrar cómo crear plugins propios, así como también cómo crear políticas para generar alertas y acciones. Realmente vale la pena estudiarlo y utilizarlo.
Snort
Snort es uno de los IDSs utilizados por OSSIM. Por si todavía no conocen este tipo de herramientas, IDS significa Intrusion Detection System, o sistema de detección de intrusos. Los IDSs utilizan distintas técnicas de análisis para alertar al administrador en caso de ver acciones sospechosas. Snort en particular es un NIDS (N de Network) que se encarga de analizar el tráfico de red, inspeccionando el contenido de los paquetes para disparar alertas, o incluso, realizar algún tipo de acción cuando detecta trafico sospechoso. Snort es el IDS más utilizado mundialmente, y es probablemente el más completo de su tipo.
Como bien dice en el FAQ oficial, snort realiza análisis de protocolo, búsqueda/matching de contenido, y puede detectar una gran variedad de ataques y pruebas, como buffer overflows, escaneo sigiloso (stealth) de ports, ataques CGI, intentos de fingerprint de SOs, pruebas SMB, y mucho más.
La idea es simple (implementarla no lo es tanto), Snort sniffea la red y a través de un conjunto de reglas decide si el tráfico es sospechoso. Las reglas contienen la información que debería contener un paquete para considerarlo sospechoso, como ser la IP origen, el port origen, la IP destino, el port destino y el contenido del paquete. En las reglas se pueden utilizar expresiones regulares y se debe incluir un mensaje que describa qué es lo que detecta.
Además del motor de detección, Snort provee preprocesadores. Los preprocesadores permiten a los usuarios y programadores extender la funcionalidad de Snort. El código de los preprocesadores se ejecuta antes del motor de detección, pero después de que el paquete fue decodificado.
Snort es muy flexible y permite al usuario crear sus propias reglas y preprocesadores. Las reglas se almacenan en path/snort/rules/ y tienen una sintaxis simple, los preprocesadores requieren programación. Un artículo interesante para revisar es el de O'Reilly Write Your Own Snort Rules . Por supuesto, la mejor referencia de Snort es la guía de usuario proporcionada por Sourcefire (la empresa detrás de Snort).
OSSEC
Otro de los IDSs provistos por OSSIM, en este caso, un HIDS (H de Host). Un sistema de detección de intrusos basado en el Host se encarga de analizar los datos del host y detectar a través de ellos si el host está siendo víctima de algún ataque. OSSEC realiza esta tarea analizando logs, checkeando integridad, monitoreando la registry de Windows, detectando rootkits, y generando y respondiendo en tiempo real.
Los IDSs basados en análisis de logs son llamados LIDS (L de Log), porque detectan errores (o ataques) usando logs como su fuente de información primaria.
OSSEC (desarrollado por Trend Micro) está formado por un administrador (manager) central de monitoreo, que recibe información desde agentes, syslog, bases de datos y dispositivos sin agentes (agentless).
El manager almacena las bases de datos del chequeo de integridad de archivos, los logs, los eventos, y las entradas de auditoría del sistema. Todas las reglas, decodificadores y configuraciones importantes se almacenan en el manager.
Los agentes son pequeños programas que se instalan en los sistemas que deseamos monitorear, estos coleccionan información en tiempo real y se la envían al manager para ser analizada.
En los sistemas donde no se puede instalar agentes (Agentless), OSSEC puede realizar monitoreo de integridad de archivos.
OSSEC corre en la mayoría de los sistemas (Windows, Linux, OpenBSD/FreeBSD, y MacOS), y el análisis lo realiza a través de reglas escritas en lenguaje XML. Al igual que Snort, estas reglas son relativamente simples de escribir y se basan en la búsqueda de patrones (se pueden usar expresiones regulares) en los archivos analizados. También se pueden crear reglas compiladas, escritas en lenguaje C.
Como se habrán dado cuenta, OSSEC es una herramienta muy potente. Pueden aprender más de OSSEC leyendo el FAQ de la página, donde encontrarán varios tutoriales.
Como lo prometí, heme aquí escribiendo la segunda parte del review del OSSIM. Para el que no haya leído la primera parte, puede encontrarla aquí.
Para repasar un poco las cosas, recordemos que OSSIM es una herramienta que agrupa los resultados de muchas herramientas para mostrarlos de forma uniforme al pobre encargado de monitorear la red. La lista de herramientas que se ejecutan de fondo es grande y en la primer parte repasé, además de OSSIM, los IDSs Snort y OSSEC. En esta entrega veremos un poco más sobre herramientas de monitoreo y escaneo de red. Arranquemos nomas con el repaso.
Osiris
Continuando con la seguidilla de IDSs del artículo anterior, OSSIM también trae Osiris, un HIDS centrado en el monitoreo de integridad del host. Este se utiliza para monitorear cambios en una red de hosts a través del tiempo y reportando estos cambios al administrador(es).Actualmente, el monitoreo incluye cambios en el filesystem. Osiris toma snapshots periódicos del filesystem y los almacena en una base de datos. Estas bases de datos, así como las configuraciones y los logs, son almacenados en un host de administración central. Cuando se detectan cambios, Osiris loguea estos eventos en el log del sistema y opcionalmente envía un e-mail al administrador.
Además de los archivos, Osiris también monitorea listas de usuarios, listas de grupos, y módulos del kernel o extensiones.
La arquitectura de Osiris está basada en tres componentes:
- consola de administración (osirisimd): debe estar instalada en un host confiable porque es a donde se almacena la información sobre los hosts administrados, incluyendo configuraciones, logs, y bases de datos.
- un agente de escaneo (osirisd): proceso que se ejecuta en cada host monitoreado. Es el responsable de escanear el filesystem local y enviar los datos al host administrador.
- aplicación de administración CLI (osiris): la utiliza el administrador para administrar los detalles de los hosts escaneados. Se comunica directamente con la consola de administración.
osiris <==> osirismd <==> osirisd
Pueden leer más sobre Osiris en su handbook.
Nessus
Pasamos de la detección pasiva a la activa por un momento. Nessus es un programa de escaneo de vulnerabilidades. Su función es escanear los hosts que el usuario desea, detectando primero los ports que tienen abiertos y luego enviando una batería de test para comprobar qué hosts son vulnerables. A partir de los resultados obtenidos, Nessus arma un detallado informe con las vulnerabilidades de cada host, describiendo cada vulnerabilidad, el nivel de riesgo que representa y las posibles formas de mitigarla.Esta herramienta ahorra horas de pruebas al auditor de red (el sueño del pentester), y permite que personas sin tanto conocimiento sobre exploits pueda conocer los problemas en la red y las soluciones.
Nessus es una herramienta muy completa y flexible, permitiendo agregar tests (plugins) de vulnerabilidades, los cuales deben ser escritos en NASL (Nessus Attack Scripting Language), un lenguaje de scripting optimizado para interacción de red personalizada. Además es posible realizar auditoría de passwords y verificar el nivel de parches aplicados en Windows si el usuario provee las credenciales necesarias.
El reporte generado por Nessus se puede exportar en varios formatos como texto plano, XML, HTML y LaTeX, además del formato propio de Nessus.
En sistemas Unix Nessus está compuesto por un demonio nessusd encargado de realizar es escaneo, y un cliente que controla el escaneo y muestra los resultados. La versión Windows, en cambio, es un solo ejecutable que contiene todo.
Realmente esta herramienta es extremadamente útil, no sólo porque realiza un escaneo automatizado excelente (cubre una amplísima variedad de pruebas), generando reportes bien descriptivos, sino también porque es muy fácil de utilizar. La primera vez que corrí Nessus quedé muy sorprendido por su capacidad, no he conocido otra herramienta que realice un escaneo automatizado tan bueno. Generalmente los escaneos automatizados cubren algunos aspectos, pero fallan en detectar muchas vulnerabilidades, dejando la mayor parte del trabajo a la persona que realiza la auditoría.
Penosamente Nessus dejó de ser libre en 2005. La compañía detrás de Nessus (Tenable Network Security) cerró el código en su versión 3 y ahora venden los plugins. Por suerte todavía mantienen un conjunto de plugins gratuitos pero que sólo pueden utilizarse en casa o en empresas sin fines de lucro (ver Nessus FAQ). Si quieren utilizar Nessus en entornos con fines de lucro, deben comprar la versión profesional.
Por ello la gente de Alien Vault (empresa detrás de OSSIM) creó su propio conjunto de plugins gratuitos y licenciados bajo la GPLv2.
OpenVAS
Además de Nessus, OSSIM incluye OpenVAS (OpenSource Vulnerability Assessment Scanner), el fork libre de Nessus, creado a partir del motor en Nessus 2 (que era libre). Se entiende a partir de esto que OpenVAS funciona igual a Nessus y persigue el mismo propósito, escanear en busca de vulnerabilidades.Esta herramienta tiene algunas limitaciones y no llega a ser Nessus, pero el trabajo detrás es interesante, porque además se pueden utilizar los plugins libres de Nessus.
Nagios
OK llegamos a una de mis favoritas. Sin dudas Nagios es una de las herramientas más interesantes para el monitoreo de redes, aunque también una de las más complejas para customizar y mantener. Como bien dicen en el manual oficial "Relax - it's going to take some time".Nagios es de las herramientas más complejas, pero permite a un administrador tener una visión central del estado de los hosts de la red. A través del monitoreo de hosts, Nagios puede enviar alertas en caso de fallas. La descripción de la funcionalidad es simple, monitorear hosts y alertar en caso de fallas. Además posee un front-end web desde donde se puede observar el estado de la red.
Nagios se basa en un demonio central que recibe datos de plugins y los almacena en una base de datos. La configuración de todo el sistema se realiza a través de archivos de texto. Nagios no incluye mecanismos de chequeo de estado de hosts y servicios, deja este trabajo a los plugins. Simplemente se limita a ejecutar los plugins, recibir los resultados, procesar los resultados y ejecutar las acciones necesarias.
Lo bueno del sistema de plugins es que abstraen a Nagios del chequeo en sí, logrando que sea extremadamente flexible y extensible, abarcando varias plataformas. Los plugins pueden ser scripts o ejecutables que se pueden ejecutar desde la línea de comandos.
Si bien todo el monitoreo se puede realizar desde una sola máquina, algunos plugins requieren que se instale un agente monitor en la máquina que deseamos monitorear. Ejemplo de este caso es cuando deseamos monitorear el uso de CPU, memoria, disco, de alguna máquina en particular. El agente monitor se comunica con el server Nagios para enviar la información necesaria.
Actualmente existen plugins para monitorear varios dispositivos y servicios incluyendo:
* HTTP, POP3, IMAP, FTP, SSH, DHCP
* Carga de CPU, Uso de Disco, Uso de Memoria, Usuarios Actuales
* Unix/Linux, Windows, y servidores Netware
* Routers y Switches
Alertar sobre fallas es la principal función de Nagios, pero éste también es capaz de ejecutar event handlers. Los event handlers, al igual que los plugins, son comandos del sistema (ejecutables o scripts), y tratan de arreglar el problema antes de notificarlo. Entre los usos se incluye:
* Reiniciar un servicio que falló
* Ingresar un ticket de problema en un sistema helpdesk
* Loguear información del evento en una base de datos
* Reboot del sistema (hay que tener mucho cuidado con este)
Como dije anteriormente, Nagios es muy muy completo. La configuración no es simple, pero está muy bien documentada. Lleva un tiempo hasta que logramos que nos alerte lo que deseamos, o tomar las acciones necesarias. Al principio puede resultar bastante molesto la cantidad de alertas arrojadas, pero gracias a la configuración de umbrales, y a la inteligencia para detectar flip-flos (cuando un servicio/host cae y se levanta muchas veces en un intervalo corto de tiempo) es posible lograr el funcionamiento deseado.
Para esta tercer entrega dejé las herramientas que realizan su trabajo pasivamente, sin interferir en el funcionamiento normal de la red. Estas herramientas trabajan observando el tráfico de la red y generando estadísticas o alertas según lo que observan. También hablaré sobre una excelente herramienta que permite mantener un inventario en tiempo real de los dispositivos de la red.
NFSen
NFSen o Netflow Sensor, es un front-end web para las herramientas de flujo de red nfdump. A través de este front-end podemos ver gráficos de flujos, paquetes y Bytes usando RRD (Bases de datos Round Robin). Además es posible setear alertas e incluso programar plugins propios para procesar el flujo de red.
En cuanto al manejo de los gráficos NFSen es bastante flexible, permitiendo seleccionar intervalos de tiempos, tipo de gráficos (lineares, logarítmicos, etc), ver resumen estadístico, crear filtros, etc. Se pueden crear perfiles donde el usuario puede customizar lo que desea ver, con qué colores, en qué intervalo.
Como NFSen funciona sobre la base de NFDUMP, describiré un poco de qué trata esta última.
NFDUMP es un conjunto de herramientas encargadas de recolectar y procesar flujos de datos en la red que funcionan por línea de comandos. Las herramientas que componen NFDUMP son:
- nfcapd: el demonio que captura el flujo de red. Lee datos de la red y los almacena en archivos, los cuales va rotando automáticamente cada n minutos.
- nfdump: vendría a ser el dump de los datos almacenados por nfcapd. Esta herramienta sirve como visualizador de los datos almacenados por nfcapd. La sintaxis es similar a la de tcpdump, y puede crear varias estadísticas del tipo "top N" basado en flujos de datos IP, ports, etc.
- nfprofile: otro que lee los datos almacenados por nfcapd. Estos datos se pasan a través de un conjunto de filtros y los datos filtrados se almacenan en nuevos archivos.
- nfreplay: simplemente hace forward de los datos almacenados por nfcapd hacia otros hosts.
- nfclean: permite borrar los datos viejos.
- ft2nfdump: permite convertir datos de herramientas de flujo desde archivos o de la stdin al formato nfdump.
NFDUMP entonces permite analizar el flujo de datos en la red del pasado y hacer un seguimiento de patrones de tráfico interesantes continuamente.Ntop
Otra gran herramienta que permite ver el uso de la red. Ntop lleva su nombre por la analogía con el comando top de Unix que muestra el uso de la memoria, CPU, etc, de los procesos.Ntop, al igual que nfdump, lee los datos de la red, los almacena en archivos y a partir de ellos genera gráficas visualizables a través de una interfaz Web (port 3000 por defecto). Ntop es mucho más completo que nfdump, porque no solo distingue entre tráfico udp, tcp, icmp, etc, sino que también distingue protocolos de la capa aplicación, como ser HTTP, SNMP, SSH, DNS, etc.
La variedad de gráficas que Ntop es capaz de generar hacen que el administrador tenga una excelente visión de lo que sucede en la red. Se pueden generar gráficas por host, e incluso distingue que servidores ejecuta un dado host.
No hay mejor resumen de lo que se puede hacer con Ntop que el que nos da su autor en la página:
* Ordenar el tráfico de red de acuerdo a varios protocolosPueden aprender más sobre ntop en los documentos recomendados en la página oficial.
* Mostrar el tráfico de red ordenado de acuerdo a varios criterios
* Mostrar estadísticas del tráfico
* Almacenar en disco estadísticas del tráfico en formato RRD (Round Robin Database)
* Identificar la identidad (e.g. direcciones de e-mail) de computadoras de usuarios
* Identificar pasivamente (i.e. sin enviar paquetes de prueba) el Sistema Operativo de los hosts
* Mostrar la distribución del tráfico IP entre varios protocolos
* Analizar el tráfico IP y ordenarlo de acuerdo a la fuente/destino
* Mostrar la matriz del tráfico IP de la subred (quién está hablando con quién)
* Reportar el uso del protocolo IP ordenado por tipo de protocolo
* Actuar como recolector de flujo de red para los flujos generados por routers (e.g.Cisco) y Juniper o switches (e.g. Foundry Networks)
* Producir estadísticas del tráfico tipo RMON
Pads
Pads cuyo significado es Passive Asset Detection System (Sistema de Detección Pasiva de Activos) es un sniffer que a través de signatures detecta activos. Los activos pueden ser dispositivos o servicios ejecutándose en la red. La idea detrás de PADS (como comenta su autor en la página oficial) es ser un nmap que funcione de forma pasiva, esto es, sin enviar un solo paquete a la red.
El funcionamiento es simple, Pads sniffea la red y a través de signatures va detectando servicios y hosts que existen en ésta, y loguea lo que detecta. De esta forma se puede hacer un mapeo de la red sin generar tráfico. Claro está que este tipo de detección es menos precisa que un escaneo activo como el de nmap, pero es muy útil cuando este último no es una opción viable.
P0f
Passive OS Fingerprinting (p0f) es otra herramienta de detección pasiva que permite obtener el fingerprint de Sistemas Operativos sin enviar un solo paquete a la red. Esta herramienta permite hacer un mapeo host->SO de los hosts que existen en la red, sin que estos se enteren. El funcionamiento es similar al de escaners activos como nmap, revisando TTL, TCP Windows size, DF (don't fragment), TOS (Type of Service), etc, de los paquetes que llegan a la máquina.
Arpwatch
Herramienta simple pero muy útil a la hora de detectar intrusos. Arpwatch observa las MACs que existen en la red, y mantiene un archivo con su IP asociada, el timestamp de la última vez que se vió en la red, y genera notificaciones en caso de haber cambios. De esta forma, es posible detectar si una IP asociada a una dada MAC ahora está asociada a otra MAC. En una red donde las máquinas suelen conservar su IP por largos períodos de tiempo (o estar fijas), el uso de una IP por otra máquina (con su dada MAC) es una situación sospechosa.
Esta herramienta permite por ejemplo detectar ataques Man in the Middle, suplantación de proxies, servers DNS, HTTP, etc.
Tcptrack
Conocido como el 'top' (por el comando Unix) de las conexiones TCP, Tcptrack es un sniffer que muestra información sobre las conexiones TCP que ve en una dada interfaz. Al igual que las herramientas anteriores, ésta funciona de forma pasiva, observando conexiones TCP y siguiendo el rastro del estado, mostrando la lista de conexiones de forma similar al comando top de Unix.
OCS-NG
Luego de hablar sobre herramientas de detección de intrusos, vulnerabilidades y monitoreo de la red, nos encontramos con OCS Inventory NG (Open Computer and Software Inventory Next Generation) que nos permite mantener un inventario actualizado en tiempo real de los dispositivos existentes en la red.OCS-NG cuenta con 4 componentes principales:
- servidor de base de datos: que almacena la información del inventario (puede ser MySQL 4.1 o posterior),
- servidor de comunicación: maneja la comunicación HTTP/S entre la base de datos y los agentes (Apache 1.x, 2.x),
- servidor de despliegue: almacena la información de los paquetes a desplegar (requiere HTTPS),
- consola de administración: front-end web que permite al administrador realizar consultas a la base de datos (Apache 1.x, 2.x y PHP 4.1 o superior).
El funcionamiento se basa en instalar un agente en cada host que se desea inventariar, y mantener un servidor (o repartido en varios servidores) la base de datos con el manejador de los datos enviados por los agentes. Cada agente envía los datos del inventario de la máquina a través de HTTP/S al servidor de comunicación, utilizando archivos XML comprimidos con Zlib. Luego un administrador puede revisar su inventario a través de la interfaz Web.OCS soporta la mayoría de los sistemas operativos, incluyendo GNU/Linux, Windows, Mac, Solaris, AIX, y *BSD.
Si bien no tuve la oportunidad de probar esta herramienta (viene instalada por defecto en OSSIM, pero no desplegué agentes), a partir de los screenshots se puede observar que es muy completa, mostrando información de discos, sistema de archivos, CPU, memoria, dispositivos, controladores, etc. Una herramienta muy interesante, para tener en cuenta.
sábado, septiembre 04, 2010
Repositorio de herramientas de pentesting
Repositorio: http://pentester.fr/resources/tools/pentest/
Gestor de descargas de herramientas de seguridad (windows): http://sourceforge.net/projects/ssdownloader/files/
Gestor de descargas de herramientas de seguridad (windows): http://sourceforge.net/projects/ssdownloader/files/
Suscribirse a:
Entradas (Atom)