En numerosas ocasiones hemos hablado en este blog de sistemas de decepción, normalmente conocidos como Honeynets ,que nos sirven para dos propósitos fundamentales. Por un lado, podemos “entretener” a alguien que esté tratando de entrar en nuestros sistemas, atacando unos sistemas que en realidad se tratan de un señuelo, mientras nosotros hemos sido advertidos del intento de intrusión y podemos actuar en consecuencia al identificar el atacante, su modus operandi, sus herramientas y objetivos. Por otro lado, nos puede servir para identificar nuevos tipos de ataque o vulnerabilidades desconocidas. De toda esta información extraída podemos crear firmas para los sistemas de detección/prevención de intrusiones que tengamos en nuestra infraestructura.

Uno de los proyectos open source más conocidos en este campo es The Honeynet Project. Este proyecto cuenta con numerosas soluciones que abarcan diferentes ámbitos en el estudio de nuevos ataques, entre otros. También cuenta con un programa de financiación para nuevos proyectos, pero sólo los más interesantes son aceptados y patrocinados por Google a través de su programa Google Summer of Code.

En esta entrada vamos a presentar uno de ellos realmente interesante y fácil de desplegar, el cual puede contribuir, no sólo a la protección de nuestros sistemas, sino también a un nivel global.

Se trata de Dionaea, una evolución del también conocido Nepenthes que fue abandonado en 2009. Dionaea, según mencionan en su página web, tiene el propósito de identificar malware, centrándose en detectar nuevos especímenes que circulan en la red. El sistema está desarrollado en C y Python y almacena la información en una base de datos SQLite.

Para que la descarga del malware y su posterior análisis sea posible, el sistema expone a la red una serie de servicios vulnerables a la espera de que éstos sean atacados, partiendo de la premisa de que toda petición recibida y todo código que se haya podido descargar es malicioso, ya que ninguno de estos servicios estan publicados o tienen uso alguno por ningún cliente. Los principales servicios que se ofrecen son: SMB, HTTP, FTP, TFTP, MSSQL y SIP.

Se trata de un sistema modular, compuesto por los siguientes elementos que describiremos muy brevemente:

Explotación: este módulo hace uso de libemu para tratar de averiguar qué trata de hacer el código y emularlo. Una vez ya sabe qué hace el payload y sus intenciones, cuenta con otros shellcodes que actúan como debería hacerlo el malware.
Shells: ofrece un terminal falso al atacante; incluso puede abrir una conexión a la espera de que se conecte el atacante o conectarse a él directamente.
URLDownloadToFile: obtiene el archivo mediante HTTP y después emula su ejecución.
Exec: executa el comando recibido usando WinExec.
Multi-stage payloads: realiza varias acciones de las anteriores.
Descargas: una vez ha identificado la ubicación del fichero que quiere que nos descarguemos, dionaea tratará de descargarlo mediante los módulos ftp, tftp o http con los que cuenta.
Envío: el código malicioso descargado puede enviarse a terceros para que sea analizado e incluso podemos obtener el resultado de los informes tras el análisis. Entre éstos podemos enviar a Anubis o VirusTotal, así como a servicios propios que tengamos desplegados en otro lugar.
Registro: módulo que resgistra los incidentes y ofrece una traza de todo lo ocurrido.

Toda la información que genera Dionaea sobre ataques, incidentes y muestras de virus, como hemos dicho anteriormente, se almacena en una base de datos SQLite. Sabemos las limitaciones que tiene esta base de datos pero puede sernos más que suficiente para nuestro propósito. Tan sólo comentar que, según los desarrolladores, se puede enviar la información a una base de datos Postgres o MySQL a través de un módulo que actúa como cliente XMPP, por lo que bastaría con montar un servidor XMPP quien escribirá en estas bases de datos, pero en mi opinión es una solución un poco enrebesada y SQLite es suficiente, aunque no estaría mal que desarrollaran un módulo que permita escribir directamente en éstas, como lo hace Snort, por ejemplo.

La instalación es bastante sencilla. Se deben instalar antes algunas dependencias pero no suelen dar problemas en la instalación/compilación y las instrucciones indicadas en la propia web de Dionaea dejan poco margen de error. Para iniciarlo, se recomienda ejecutarlo con un usuario con pocos privilegios, ya que es un servicio que está siendo atacado constantemente y debemos ser precavidos. Además, se puede ejecutar dentro de un ambiente chroot. Podemos lanzarlo con el siguiente comando:

# /opt/dionaea/bin/dionaea -l all,-debug -L ‘*’ -u nobody -g nogroup -r /opt/dionaea -w /opt/dionaea -D

Hasta aquí la primera entrega en la que quería presentar esta herramienta y describir algunos de los módulos que la componen. En la próxima entrada hablaremos más en profundidad de algunos módulos interesantes y cómo explotar la información recopilada por esta sensacional herramienta. Por último, hay que tener cuidado con los binarios descargados, ya que estamos tratando con archivos peligrosos.

La visualización de la información es tan importante como la información en sí misma. Demasiada información, sin la posibilidad de analizarla correctamente, no sirve de mucho. Por esto, quería dedicar esta entrada a mi chica unas herramientas que muestran, de una forma visualmente atractiva, alertas de seguridad generadas por Snort. No esperéis potentes interfaces gráficas haciendo data mining, agregando información, categorizándola, procesándola, correlándola y alertando de lo más importante que está ocurriendo en nuestra red. Para eso hay que recurrir a soluciones profesionales que conllevan un coste más o menos considerable.

En esta ocasión os voy a mostrar una herramienta de código libre que nos ofrece una interfaz visualmente atractiva, aprovechando la potencia de una herramienta del omnipresente Google. Esta herramienta se llama SnoGE y está desarrollada por Leon Ward, un ingeniero de seguridad que trabaja en Sourcefire, empresa que está detrás del proyecto Snort. Este script procesa las alertas generadas por Snort en formato Unified2 y genera un fichero KML. ¿Qué es un fichero KML? Para quien no lo sepa, se trata de un fichero XML especialmente diseñado por Google para representar objetos en su GoogleEarth. Y es ahí donde está la gracia del proyecto SnoGE: con un sencillo script escrito en Perl, es posible montar una interfaz gráfica muy atractiva que nos permite ver desde dónde nos están atacando; ideal para cuando vengan periodistas ávidos de ver ataques informáticos en tiempo real u otra fauna no técnica, al estilo de la película “Juegos de Guerra” o las diseñadas por Mark Coleran.

De acuerdo, admito que no se trata de una herramienta imprescindible en la gestión de incidentes o en la respuesta temprana ante ellos; esta herramienta únicamente muestra la alerta y el origen. No muestra agregaciones, ni criticidades, ni más información que pudiera ser útil a la hora de detectar un ataque potencialmente crítico a nuestra infraestructura. Pero visualmente es muy atractiva y puede mostrar las alertas en el momento en el que se producen.

SnoGE cuenta con dos modos principales de operación: uno estático y otro en tiempo real. El estático se ejecuta una única vez, leyendo de uno o varios archivos Unified2, mientras que en tiempo real se le indica el directorio donde se guardan las alertas de Snort para que las vaya analizando, de forma similar a Barnyard2.

Utilizando esta última opción, se le puede indicar el tiempo de refresco y el número de alertas a mostrar. Esto es importante ya que, si se cuenta con muchas alertas, se puede volver algo lento.

Una vez generado el archivo KML, sólo nos quedaría representarlo. La forma más impactante es abrir el fichero KML directamente con GoogleEarth o utilizar este visor, que permite insertarlo en una página web y visualizarlo instalando el plugin para GoogleEarth desde el navegador. De esta forma, se consiguen una interfaz 3D muy potente y atractiva. Algo similar a esto:

Otra opción más sencilla, la cual no requiere de complementos adicionales, es verla en 2D. Para verla en 2D sin necesidad de tener instalado GoogleEarth ni ningún plug-in, podemos utilizar las librerías de JavaScript geoxml.

En ambas opciones se debe indicar el tiempo de refresco de la página. El sistema, de forma conceptual, lo componen los siguientes elementos:

• El archivo Unified2, del que se leen las alertas.
• El fichero KML, resultante de la ejecución del script.
• El fichero del servidor, en caso de utilizar el refresco automático, que se encarga de leer el anterior según el tiempo indicado.
• El código HTML que contiene el módulo o el código JavaScript que representa el archivo KML.

Bueno, simplemente quería presentar estas dos opciones, fáciles de implantar, aunque la instalación no se aborde aquí por no extenderme. He seguido las indicaciones de los respectivos desarrolladores y no he tenido problemas para instalarlos. Aunque no haya demasiada información al respecto, la que se incluye en cada proyecto es más que suficiente. Resumiendo, SnoGE: una solución sencilla, barata y atractiva para mostrar los ataques recibidos a personas no técnicas.

Por lo demás, pasen muy buen fin de semana.

Hace un tiempo estaba charlando con una buena amiga que trabaja en una empresa del sector aeronáutico sobre la tecnología utilizada en comunicaciones, y me vino a la cabeza el tema de la seguridad en la aeronáutica y si se recurría a sistemas antiguos en caso de avería del principal. En ocasiones, trato de buscar similitudes entre la seguridad aplicada en otros campos y la de los sistemas de información, y el mundo de la aviación es, según dicen, uno de los más seguros.

Todos hemos visto numerosas películas de aviones o helicópteros en las que se va produciendo un fallo tras otro y la aeronave se ve precipitada irremediablemente al vacío, hasta que el “prota” consigue, de la forma más inverosímil, hacerlo aterrizar con soluciones al más puro estilo McGyver. Esto me llevó a preguntarle cuántos errores deben encadenarse para que se quede un helicóptero sin potencia. En concreto, cómo se planteaba el tema de la redundancia de los dispositivos básicos para que esto no ocurriera.

Esta amiga mía trabaja en una empresa de mantenimiento de helicópteros cuya oficina de diseño se encarga de la integración e instalación (entre otras cosas) de sistemas de comunicación y de navegación que les solicitan los clientes, siempre según la normativa de aviación civil (AESA) y las características o el uso al que va destinada la aeronave.

Pues como decía, curioso por las medidas de seguridad que se aplican en los helicópteros y poder encontrar semejanzas con el mundo de las TIC, estuvimos charlando sobre los elementos de seguridad con los que cuenta un helicóptero para la navegación y las comunicaciones. Su respuesta me dejó un tanto sorprendido. Me estuvo enumerando, un poco por encima, los equipos de navegación y comunicaciones que son obligatorios en cualquier aeronave.

En resumen, la mayoría de los helicópteros cuenta con el siguiente instrumental. Para las comunicaciones, dos radios VHF-COMM (que trabaja en la banda comprendida entre 118-137 Mhz, para comunicaciones de aviación civil) con sendas antenas, que se utiliza en comunicaciones a distancias cortas y medias entre aeronaves y tierra.

Para la navegación: dos sistemas VHF-NAV, que indican la posición con respecto a unas estaciones VOR o VOR/DME o realizar Instrumental Landing System (un sistema de asistencia al aterrizaje), que trabajan en la banda de 108-118 Mhz. También cada uno cuenta con su antena (VOR/LOC).

Otro sistema de navegación básico es el ADF (Automatic Direction Finder) (para que luego digan que en la informática utilizamos muchos acrónimos anglosajones), que indica la posición relativa respecto a una estación NDB.

Un sistema GPS (a 1.575 MHz) y un Localizador de Emergencia (ELT) que emite una señal radioeléctrica, en caso de producirse un fuerte impacto (2,3G) o una caída al agua, durante un máximo de 72 horas. Éste también puede activarse desde el panel de mando.

Cuenta con numerosos sistemas más que enumeramos para no alargar esta entrada: Marker Beacon, ATC Transponder, Radioaltímetro, Radar…

La mayoría de estos sistemas están redundados, unos pertenecen a la parte del piloto y los otros a la del copiloto, algo que es muy habitual en sistemas TIC que buscan alta disponibilidad. Al contrario de lo que yo pensaba, no cuentan con sistemas antiguos para casos de emergencia; conozco algunos casos en los que se cuenta con una línea de RDSI en caso de perder la comunicación principal con Internet (aunque sería insuficiente teniendo en cuenta el volumen de tráfico actual). Pero esto no fue lo que me llamó la atención. Lo que me resultó curioso es el sistema eléctrico del helicóptero. Os dejo una representación esquemática que he realizado del real.

Lo explico brevemente de la siguiente manera. Primero se observa que todos los elementos están duplicados, lo que aumenta muchísimo la disponibilidad. El sistema comienza por el generador, cada uno conectado a uno de los motores/rotores, que suministra corriente a todos los buses y a la batería (para que esté siempre cargada). Los dispositivos comentados anteriormente se conectan a diferentes buses, según la criticidad del mismo. Los relés permiten al piloto redirigir la corriente en caso de avería en alguno de los elementos intermedios hacia su instrumental, e incluso permiten desconectarlo todo y que sea alimentado por la batería (BATT). Poniéndonos en el peor de los casos, que ambos generadores fallen, el piloto podrá activar el relé de la batería y dispondrá de unos 30 minutos para aterrizar el helicóptero “tan pronto como sea posible” (as soon as posible, dice el manual de vuelo) en el primer lugar posible que encuentre”, y pedirá auxílio. Si no dispone de corriente para activar la radio (aunque siempre tiene que haber una radio conectada a la barra de batería, otra cosa es que se rompa en el aterrizaje), podría utilizar la radiobaliza de emergencia (ELT) que emite una señal fija de emergencia durante 72 horas.

La ventaja que vi de este planteamiento consiste en que, según determinadas circunstancias, se pueden activar o desactivar diferentes circuitos para solucionar determinados fallos en la circuitería o alargar la duración de la batería en caso de avería en los generadores.

Este concepto es el que quería exponer en este artículo y valorar la posibilidad de aplicar esta idea de los circuitos diferenciados que se activan o desactivan en caso de avería o fallo en el suministro eléctrico con el objetivo de alargar la duración del SAI. Todos tenemos claro que no todos los sistemas son igual de críticos, y más concretamente, no todos tienen una disponibilidad crítica. Por esto, me gusta esa idea de desplegar diferentes circuitos según la criticidad, de forma que se puedan apagar ordenadamente los sistemas según el tiempo estimado o real del corte eléctrico. Los sistemas informáticos no son iguales que un altímetro u otros instrumentos de medida, y necesitan ser apagados correctamente. Esto me lleva a pensar en un sistema de alimentación ininterrumpida que cuente con varias líneas. En caso de avería o fallo, se enviará una señal de apagado a las máquinas de forma secuencial, comenzando con los menos críticos, y así alargar la duración de la batería o la del generador (que no son ilimitados, como la gente cree).

Así, equipos que no son críticos como un sistema interno de inventario, por poner un ejemplo, podrían recibir la señal de apagado del SAI inmediatamente después de detectar un corte eléctrico. En el otro extremo, nos encontramos en el caso de sistemas que deben estar operativos sí o sí. Se debe configurar el sistema de forma que se alargue el periodo de actividad hasta el restablecimiento del suministro energético. Entre medias de estos casos nos encontraríamos con una variedad de situaciones que podrían configurarse según las necesidades de cada uno. Se me ocurre que se podría dejar funcionando aquellos sistemas básicos necesarios para el trabajo diario, ya que la actividad no puede pararse por un corte eléctrico; no obstante, si el corte se alargara demasiado y peligrara la disponibilidad de los sistemas críticos, se podría optar por apagar estas líneas a pesar de detenerse la actividad. Para eso se definen las prioridades y se planifican las contingencias…

Bueno, es una idea que se me ocurrió durante una charla. Desconozco si en el MundoReal (TM) ya se pone en práctica algo parecido o si en el mercado existen productos comerciales que ofrecen esto; pero de los numerosos lugares que he visitado, ninguno de ellos es así. La verdad es que deja todo mucho que desear, ya que se conecta a un único SAI, y evidentemente no todo es igual de importante. He visto monitores e impresoras conectadas sin justificación.

Dejo esta idea en el aire, quizá alguien con más conocimiento en sistemas pueda arrojar algo más de luz sobre este tema.

Ya hemos hablado anteriormente de Barnyard2, una herramienta para procesar ficheros Unified2 y que permite múltiples configuraciones de salida; la más utilizada, la escritura en Base de datos.

En este pequeño artículo hablaremos de otro uso que puede sernos de utilidad: la salida de ficheros en formato “pcap”. Este tipo de fichero puede ser procesado por otras aplicaciones, como el analizador de protocolos Wireshark —una potente herramienta gráfica que facilitan la vida de administradores de redes y técnicos de seguridad y cada vez ofrece una mayor cantidad de funciones—. En esta entrada vamos a ver un ejemplo de cómo podemos aprovechar esta opción para la conversión de un formato de archivo generado por Snort -del que también se ha hablado aquí- a otro que es capaz de trabajar con Wireshark para analizar esos paquetes “maliciosos”.

Vamos a recordar que Snort puede almacenar directamente la captura de tráfico en formato PCAP activando el siguiente módulo de salida:

output log_tcpdump: tcpdump.pcap

Pero, ¿qué ocurre si no tenemos configurada esa salida en el sistema, ya que repercute más en el rendimiento que el mencionado al principio, pero queremos realizar un análisis a posteriori? Vamos a ver cómo pasamos rápidamente de Unified2, a uno “pcap”. Lo más habitual es que Snort escriba directamente en una base de datos. A menudo, podemos querer analizar un conjunto de paquetes, pero el problema es que con BASE -un frontend basado en web para alertas de Snort- no permite descargar a la vez varios paquetes implicados en un mismo ataque por lo que la tarea se vuelve tediosa.

Vamos a utilizar Barnyard2 para leer este tipo de ficheros y configurarlo de forma que genere una captura de tráfico en formato “pcap”, teniendo como origen el pool donde se almacenan las alertas en local.

Para ello ejecutaremos la siguiente orden, poniendo especial atención a la selección del fichero de configuración, que en lugar de insertar los eventos en base de datos los convierta en un fichero “pcap” —especificándolo con la opción “-o”— con los siguientes parámetros:

/usr/local/barnyard2/bin/barnyard2 -c <conf_barnyard -pcap> -u snort -g snort 
-l <directorio_destino> -o <archivo_unified2>

Cabe destacar que el fichero de configuración debe tener descomentada la siguiente línea:

log_tcpdump: captura.pcap 
# el único parámetro que acepta es el nombre que se le dará al fichero,
# al que añadirá un timestamp

Una vez ejecutado esto, ya tenemos el fichero PCAP que podremos abrir y analizar con Wireshark.

Hay que tener en cuenta que al tratarse del registro de alertas de Snort, todos los paquetes habrán sido almacenados por coincidir con una regla de Snort, por lo que no tendremos la conversación completa. Para poder tener la traza completa, deberíamos tener un sistema que esté capturando todo el tráfico y guardándolo en formato PCAP, como podría ser tcpdump. Todo depende del volumen de tráfico y de la necesidad de tener esa captura. Dejo en el aire la posibilidad de montar ese sistema que tenga una ventana de registros de los días que se consideren necesarios para que, en caso de que nuestro IDS detectara alertas, podamos consultar para analizar el ataque en profundidad.

INTECO-CERT ha publicado un informe sobre “Análisis de tráfico con Wireshark” dirigido a administradores y técnicos de seguridad, que pretende ser una ayuda a la hora de analizar el tráfico de red para detectar problemas o ataques.

S2 Grupo, consciente de la importancia de la formación continua, recomienda esta guía en la que se describen brevemente algunos tipos de problemas o ataques con los que nos podemos encontrar en una red, y cómo mitigarlos. Incluye ejemplos prácticos y capturas de pantalla para facilitar la comprensión a aquellos que desconocen esta herramienta para analizar capturas de tráfico. Para aquellos que ya la conocen, siempre pueden descubrirnos algo que desconocíamos.

En la guía han colaborado, entre otros colaboradores, técnicos de CSIRT-cv, que con sus ejemplos y experiencia en este tipo de análisis, han aportado información para apoyar y facilitar las tareas de administración de redes.

Destacar por último que SecurityArtWork ha servido de referencia en algunos puntos de esta guía, por lo que nos honra e impulsa a seguir difundiendo artículos y opiniones sobre seguridad.

Terminamos con éste la serie de artículos sobre la implantación de un IDS en un entorno con una alta tasa de tráfico, donde veremos las soluciones que se han tomado para el problema de los paquetes descartados y la escritura en base de datos.

Según dejamos el tema en el artículo anterior, el problema parece residir en que Snort, hasta que no termina de escribir la alerta en la base de datos, no procesa el siguiente paquete. La escritura en base de datos se realiza mediante una conexión TCP que precisa del handshake y de la escritura del INSERT en la misma; es por esto que constituye un proceso muy lento. Para solucionarlo, vamos a tomar cuatro pequeñas medidas que reducirán considerablemente el tiempo que necesita Snort en generar una alerta:

Escritura en disco local de la alerta y uso del formato unified2. La escritura en local es mucho más rápida que la escritura en red y si utilizamos un formato binario que ocupa muy poco espacio, se tardará mucho menos tiempo en generar la alerta. El formato binario unified2 es una evolución del formato unified introducido en Snort v.2.8. Se trata de un formato extensible formado por una cabecera que define el tipo de registro y su longitud, y que permite guardar en un mismo fichero diversos tipos de eventos como, por ejemplo, alertas IPv6, estadísticas o información de escaneos.

[Read more…]

Después de una semana para dejar pensar a nuestros lectores, seguimos con el artículo sobre la implantación de un sistema IDS en un entorno con una tasa de tráfico muy elevada.

Nos habíamos quedado en un momento donde la tasa de tráfico era tan elevada que, aunque la tarjeta no estaba perdiendo tráfico, Snort no era capaz de procesar todos los paquetes. Teniendo en cuenta la carga de CPU en el sistema, y revisando la documentación de Snort donde se indica que esta aplicación no es multi-hilo, no quedaba otra opción que montar la granja; es decir, levantar varias instancias de Snort y repartir el tráfico para que cada una de ellas analizara una tasa menor. Suponíamos que íbamos a conseguir un buen resultado ya que sólo se estaba utilizando un único core al 100% mientras que el resto no se utilizaba.

Para conseguir esto se deben tener en cuenta varios aspectos para que no entren en conflicto diferentes instancias en un mismo sistema. En resumen, se deben crear filtros BPF para especificar el tráfico que procesará cada instancia, puede haber uno o varios archivos de configuración, debe especificarse un sufijo diferente para el pidfile de cada instancia, debe especificarse un identificador (id) en cada instancia a la hora de escribir en la base de datos y un directorio diferente para almacenar los logs.

[Read more…]

No, no estamos hablando de dejar esta vida ajetreada de las ciudades e irnos al campo a vivir y alimentarnos de lo que cultivamos y criamos. Tampoco hablamos de “invertir” nuestro tiempo libre en juegos de una determinada red social para aprender las labores del campo. Este post viene a explicar el proceso que hemos seguido para optimizar el rendimiento de un sistema de detección de intrusos (IDS) en redes con una tasa de tráfico alta.

Hace tiempo se nos propuso preparar para un cliente un sistema de detección de intrusos de alto rendimiento, capaz de procesar una gran cantidad de tráfico totalmente heterogéneo. Así que preparamos una máquina con muy buenas prestaciones para asegurarnos que, por hardware, no iba a ser; a saber, un procesador de 6 cores con 4 GB de memoria RAM, tarjetas Gigabit Ethernet y un sistema NAS para albergar toda la información generada en una red que, suponíamos, iba a ser muy complicada de manejar por la cantidad, la variedad y la naturaleza de su tráfico.

Se optó por una de las soluciones más extendidas en los sistemas de detección de intrusos de código abierto: Snort.

[Read more…]