Teniendo que auditar un activo, durante la fase de reconocimiento quise hacer un escaneo de todos los puertos, del 1 al 65535, para que no hubiera nada raro que no debiera estar accesible. Como esto llevaría un tiempo que no me apetecía invertir, recordé el artículo de mi compañero José Luis sobre la optimización de Nmap. Ya sabéis, básicamente lancé un ping para calcular el RTT mínimo y medio y utilicé esos valores para definir los parámetros --initial-rtt-timout y --max-rtt-timeout.

mbelda@pc:~$ ping -c4 192.168.XXX.XXX
PING 192.168.XXX.XXX (192.168.XXX.XXX) 56(84) bytes of data.
64 bytes from 192.168.XXX.XXX: icmp_req=1 ttl=58 time=7.88 ms
64 bytes from 192.168.XXX.XXX: icmp_req=2 ttl=58 time=2.55 ms
64 bytes from 192.168.XXX.XXX: icmp_req=3 ttl=58 time=2.97 ms
64 bytes from 192.168.XXX.XXX: icmp_req=4 ttl=58 time=3.16 ms 

--- 192.168.XXX.XXX ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.553/4.146/7.886/2.171 ms
mbelda@pc:~$ nmap -PN -T4 -p1-65535 --max-retries 1 --min-parallelism 70 \
     --initial-rtt-timeout 5 192.168.XXX.XXX 

[...]

Una de las principales funciones de un SOC es la Gestión de Incidentes de Seguridad. Este servicio comprende la notificación de incidentes a los afectados así como a los responsables de la red atacante, en la mayoría de los casos. Aunque pueda parecer que es algo poco importante, considero que es una de las fases más cruciales en la gestión de incidentes, ya que debe transmitir claramente a la persona interesada los hechos ocurridos, la importancia del problema y la solución del mismo.

Parece un mal endémico del personal técnico el no tener una buena capacidad de redacción y síntesis; podemos hablar sobre multitud de conceptos técnicos, utilizando una infinitud de palabras en inglés pero parece que no seamos capaces de sintentizar y trasladar a un lenguaje más coloquial un incidente de seguridad que hayamos detectado.

El pasado 7 de diciembre, ENISA publicó un informe con los resultados de una encuesta realizada a diferentes CERTs y otros organismos de ámbito europeo —y alguno extra-comunitario— traducido al castellano como “Detección proactiva de Incidentes de Seguridad”. Esta entrada viene a resumir las conclusiones más importantes que he extraído de este informe según mi valoración.

Dicho informe tiene como finalidad recoger e identificar los distintos métodos que utilizan los CERTs de ámbito europeo para la detección de incidentes de seguridad en las redes de las que son responsables y cómo, a partir de esta información, mejorar los métodos utilizados por otros CERTs para detectar estos incidentes de forma proactiva; se trata una manera de aunar esfuerzos. La definición del término proactivo, en contraposición a reactivo, se refiere en este caso al descubrimiento de actividades maliciosas a través de procesos internos antes de que sean detectados por los propios afectados. Esto último sería en el caso de un incidente notificado a través de un formulario por parte de los afectados o terceros.

La entomología es la ciencia que estudia los insectos. En este artículo vamos a tomar el rol de un entomólogo y pasaremos a analizar los “insectos” que haya capturado nuestra planta dionaea, para ver si descubrimos algún espécimen nuevo. Y hasta aquí, cualquier similitud con esta ciencia.

En realidad, voy a contar el uso de wireshark para analizar un ataque recibido por nuestra sonda que está ejecutando dionaea y explicar cómo ver las pruebas, así como también algunas cosas más del funcionamiento de este interesante honeypot del que ya hemos hablado en alguna que otra ocasión. Adelanto que la captura del tráfico se hizo con tcpdump porque, aunque sabemos que dionaea se guarda el ejecutable que descarga, queríamos capturar todo el ataque, no sólo el ejecutable en cuestión.

Desde finales del mes pasado, estamos detectando en nuestros Sistemas de Detección de Intrusos un aumento en los ataques dirigidos al puerto 3389 (servicio de Terminal Service). Se pensó que este aumento podía ser debido a una vulnerabilidad no conocida de este servicio, pero analizando el tráfico capturado, pudimos comprobar que se trataba de intentos de acceso utilizando el mismo usuario y un grupo de contraseñas débiles fijas.

Investigamos un poco y vimos que este aumento podría ser debido a un nuevo virus identificado como Morto. Se trata de un gusano que se propaga por la red aprovechándose de contraseñas débiles conocidas configuradas en los sistemas.

La entrada anterior era tan sólo una introducción a esta interesante herramienta, pero no mucho más extensa de lo que cuentan en la página principal del proyecto. La idea original de este artículo que he tenido que dividir era, además de presentarla, mostrar algunas curiosidades de las que podemos sacar bastante jugo y que paso a comentar a continuación.

Colaborando con la causa

Como comenté en el artículo anterior, uno de los puntos más interesantes de Dionaea es el envío de las muestras de malware a servicios de terceros para su análisis. Pero esto no es lo realmente interesante, no nos interesa saber de qué especimen se trata en concreto, ya que hemos comentado que se presupone que todo archivo descargado será malware -salvo que queramos analizarlo en un laboratorio y averiguar cómo funciona-. Lo más interesante es que alguna de las muestras que enviamos no haya sido detectada previamente y no exista firma en los motores de antivirus. Es decir, sea una nueva variante no detectada hasta el momento.

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.

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.

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.

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”.