Recientemente tuvo lugar una nueva edición de “Respuestas SIC”, unas jornadas que periódicamente organiza la revista SIC y a las que tuve la oportunidad de asistir.

Esta edición tenía como título: “Protección de vanguardia ante APTs y DDoS: Nuevos ataques, mejores defensas” y tuvo tres bloques. En el primero, un especialista en protección de la información (Juan Miguel Velasco López-Urda) ofreció una charla sobre su visión ante la defensa frente a APTs. En el segundo bloque, siete fabricantes de seguridad TI (Check Point, Corero, Fortinet, HP, Stonesoft, Symantec y Trend Micro) explicaron sus orientaciones en materia de protección frente a APTs y DDoS. El tercer bloque contó con la participación del Centro Criptológico Nacional representado por su subdirector General Adjunto, Luis Jiménez Muñoz, y dos organizaciones privadas: Arsys (Olof Sandstrom Herrera, Director de operaciones y seguridad) y Telefónica Digital (Santiago Perez) y consistió en una mesa redonda en la cual se trató la visión de los usuarios/centros de competencia al respecto de los temas tratados (APTs y DDos) además de hablar sobre los escenarios actuales, limitaciones y necesidades futuras.

A continuación, en esta y sucesivas entradas realizaré una breve crónica de la jornada.

BLOQUE 1: Protección ante APTs y DDoS. Situación presente.

Juan Miguel Velasco López-Urda
Consultor Estrátegico de Seguridad y Cloud para Grandes Corporaciones

Juan Miguel comenzó mencionando, entre otros, que en 2014 se prevé que habrá más dispositivos conectados que habitantes en la Tierra (fuente: Gartner) —hizo hincapié en la tendencia en auge BYOD y en que ésto crea un perímetro que no se puede cerrar— y que actualmente los ciberataques según el World Economic Forum se encuentran en 4º lugar como potenciales riesgos globales en cuanto a probabilidad que puedan afectarnos (por detrás del aumento de emisiones de gases de efecto invernadero).

Definió las APTs (Advanced Persistent Threats) como una categoría de cibercrimen dirigido contra objetivos empresariales y gubernamentales cuya máxima es “atacar de manera lenta y silenciosa” y que son un tipo de servicio demandado por competidores, cazarrecompensas, gobiernos, servicios de inteligencia, etc.

Asemejó sus técnicas con técnicas de estrategia militar y mencionó Stuxnet, Aurora, Flame, Shady RAT, GhostNet, Night Dragon, Nitro, y la última ‘saltada a la palestra’ cuya misión es la búsqueda y robo de ficheros Autocad, Medre (creo que así se ha bautizado). Habló incluso de APTs para PC de usuarios con objetivo el robo de identidad.

Describió como fases por las que se pasa cuando se descubre una APT en un organismo las siguientes: Denial, Shock, Attribution & Retribution, Investigation & Discovery, Realization y Resolution. Según Juan Miguel, en España nos quedamos en las tres primeras fases (‘esto no me puede pasar a mi’,’estado de shock’,’echar las culpas’), y es algo que hay que cambiar.

Como principal vía de entrada para una APT habló del phishing dirigido y del BYOD como nueva puerta de entrada (además de otras puertas de entrada como fallos en el perímetro externo: Firewall, VPN Server, Proxy, aplicaciones web vulnerables, navegación web, perímetro interno: ingeniería social, USBs, …etc) y citó algunos precios reales de lo que costaría planear una campaña de APT:

• RAT: Gratuito.
• Servicio de phishing dirigido : Setup de 2000$, coste mensual de 2000 $.
• Dos 0-day: 40.000 $.
• Rent-a-hacker: unos 20.000 $ al mes.

Habló de los ataques de DDoS como método de distracción para llevar otros ataques más sofisticados y los caracterizó como ataques universales (te puede pasar donde sea, a quien sea y cuando sea), baratos, eficientes, impunes (gracias al anonimato que dan las botnets), de gran impacto, reiteradamente posibles y menospreciados.

Ante cómo defenderse frente a una APT comentó que los elementos tradicionales y de defensa han de ser desplegados, monitorizados en tiempo real y recopilados todos los logs para su análisis y almacenamiento. Al menos hay que tener todos los Proxy Logs, Authentication Logs, IDS alerts, HIDS logs, Firewall logs, Full content traffic captures, Netflow, aplicaciones (datos y errores) y auditoría con activación proactiva.

Algunas conclusiones extraídas de esta interesante charla del señor Velasco fueron las siguientes.

1) Frente a defensa de APTs:

• Diseñar el perímetro (Firewalls, IPS, WAF, habló del cloud como protagonista como tercer perímetro y de la necesidad de monitorizarlo y auditarlo de manera periódica. Éste debe ser una extensión de nuestro perímetro exterior asumiendo nuestra política y reglas).
• Implementar contramedidas antiDDoS (implementando un modelo híbrido cloud).
• Implantar protección email (Antispam, email firewall).
• Análisis de código Web y politicas de diseño Web y código.
• Monitorizar toda la información que entra y sale.
• Restringir el acceso a BYOD.
• Segmentar la red y el acceso a los usuarios.

2) Sobre la situación actual respecto a APTs y DDoS, destacó que:

• Cada día aparece nuevo malware, nuevos 0-day, nuevas vulnerabilidades… y nuevas APT aprovechándose de ello. Por otro lado los ataques DDoS son favorecidos por la proliferación de las botnets, y además comienzan a tener un ‘toque de sofisticación’ puesto que ya no son volumétricos, sino que también son dirigidos.
• El perímetro comienza a perder los límites establecidos por el exceso de tráfico no catalogado, la heterogeneidad de las aplicaciones, la necesidad de que el usuario sea capaz de conectarse desde cualquier parte y a través de cualquier dispositivo. Por tanto se ha de redimensionar de manera adecuada este perímetro y sobre todo incluir monitorización en el mismo y correlación continua y gestionada. Además, los servicios en la nube podrían ayudarnos como una evolución de nuestro perímetro.
• La incorporación de tecnologías antiDDoS, la simulación de entornos con SandBox virtuales y los analizadores de tráfico dinámicos no basados en firmas ayudarían en la ‘lucha’ contra las APTs y los DDoS.

En la tanda de preguntas resaltar la opinión de una persona que afirmó que es imposible parar BYOD; se trata de una tendencia imparable y que hay que elegir bien la tecnología y buscar un equilibrio. Otra persona comentó que a veces dudaba de si las vulnerabilidades las anunciaban los mismos que nos venden ‘la solución’: los fabricantes.

En definitiva, el bloque 1 de las jornadas, de la mano de Juan Miguel Velasco, aportó una visión muy clara sobre la situación presente ante las nuevas, avanzadas y persistentes amenazas que están presentes en el panorama actual. En la próxima entrada acabaré la crónica de esta jornada, con el bloque 2 y 3. Mientras, os lanzo una de las interesantes preguntas que surgieron a lo largo del día:

¿Creéis que los fabricantes de herramientas TIC están orientando de manera adecuada sus desarrollos con fines de seguridad y protección frente a las nuevas amenazas que se nos están viniendo encima?

[Sobre la autora]

Recientemente ha sido publicada Nmap 6 tras tres años de trabajo. Una de las mejoras más importantes ha sido la incorporación de nuevas opciones para Web Scanning aumentando de 6 a 54 el número de scripts NSE para el análisis de servidores Web. Algunos de esos nuevos scripts son los siguientes:

• http-title: determina el título de la página por defecto de cualquier servidor web detectado durante el escaneo, información que puede ser muy valiosa. Veamos un ejemplo de funcionamiento (las pruebas las he realizado con owaspbwa):

  nmap -sV --script=http-title 172.16.94.129
  PORT     STATE SERVICE     VERSION
  22/tcp   open  ssh         OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0)
  80/tcp   open  http        Apache httpd 2.2.14 ((Ubuntu) mod_mono/2.4.3 
  PHP/5.3.2-1ubuntu4.5 with Suhosin-Patch mod_python/3.3.1 Python/2.6.5 
  mod_perl/2.0.4 Perl/v5.10.1)
  |_http-title: OWASP Broken Web Applications
  139/tcp  open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
  143/tcp  open  imap        Courier Imapd (released 2008)
  445/tcp  open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
  5001/tcp open  ovm-manager Oracle OVM Manager
  8080/tcp open  http        Apache Tomcat/Coyote JSP engine 1.1
  |_http-title: Apache Tomcat/6.0.24 - Error report
  

[Read more…]

El ICS-CERT ha publicado recientemente una serie de recomendaciones muy básicas sobre cómo mitigar una ciberintrusión dirigida, sobre todo, a entornos industriales e infraestructuras críticas, y aplicable tanto a redes empresariales como a sistemas de control. Aunque estas recomendaciones no entran en detalle en cada una de las acciones que se deben realizar, si que conviene tenerlas en cuenta, ya que proporcionan una serie de buenas pautas a seguir, importantes dentro de la seguridad en un entorno industrial.

• Prevención de movimientos laterales: cuando descubrimos que hay un equipo comprometido en nuestra red, nuestra principal preocupación debería ser minimizar los movimientos laterales a través de la red. Es decir, no tiene sentido ir desinfectando equipo por equipo comprometido conforme se vayan detectando si la infección no ha sido contenida, ya que ésta seguirá expandiéndose. Es esencial que se identifique cuanto antes el grado de intrusión y en qué áreas de la red están los equipos comprometidos para aislarlos. Los movimientos laterales pueden ser identificados por diversas herramientas y técnicas como IPS, IDS, analizando los logs de firewalls, proxys, DNS o realizando capturas de paquetes.

[Read more…]

En esta entrada trataremos otra vez de cómo sacarle provecho a Nessus, en concreto vamos a comentar brevemente algunas de las mejoras que trae su nueva versión, Nessus 5 y algunas de sus posibles aplicaciones.

La instalación y configuración ahora es mucho más sencilla y puede realizarse a través de un panel de administración vía Web. Además han incluido una nueva clasificación para la criticidad de las vulnerabilidades, ahora las engloban en Info, Low, Medium, High y Critical. Hay diferentes novedades pero la que personalmente me ha llamado más la atención es la incorporación de nuevos filtros tanto para la creación de Informes (Reports) como de Políticas de escaneo (Policies).

Por ejemplo a la hora de crear una nueva política podemos seleccionar solo aquellos plugins para los que haya exploit en el Framework Metasploit, para ello deshabilitamos todos los plugins, creamos nuestros filtros exigiendo que cumpla lo que deseamos, los guardamos y al ir seleccionando las familias de plugins que queramos solo se habilitarán aquellos que cumplan con las opciones de filtrado:

[Read more…]

Tal día como hoy, hace 5 años arrancaba con una entrada de Manolo Benet (y con mucha ilusión) Security Art Work. En aquella entrada, Manolo se hacía eco de una noticia en la que se contaba que japoneses y coreanos comenzaban a abordar el tema de la seguridad dentro de la robótica y dejaba entrever con esto la necesidad y la importancia de incorporar la seguridad en diversos sectores en su concepto más amplio.

Manolo no iba mal encaminado, ya que en estos últimos 5 años se ha incrementado de manera considerable el riesgo asociado a ciberataques contra sectores de la sociedad que hasta no hace mucho no eran considerados como susceptibles de ser ciberatacados. Un claro ejemplo pueden ser los sistemas informáticos en los que se apoyan las llamadas Infraestructuras Críticas. Cada vez se este tema va suscitando mas interés dado a su importancia y así ,.remontándonos 5 años atrás comienzan a circular por Internet diferentes publicaciones que describen vulnerabilidades en entornos SCADA, desde aquel vídeo “Aurora vulnerability” en 2007 en el que se sabotea un generador hasta un ciberataque del que da constancia la CIA y por el que varias ciudades sufren una pérdida de electricidad pasando por los conocidos Stuxnet (en 2010) y Duqu (2011), malware avanzado diseñado específicamente para atacar infraestructuras críticas (Información extraída del Informe Protección de Infraestructuras críticas 2011 que recientemente publicamos).

En esta primera entrada también nos hacíamos eco de la creación del CCN-CERT, como tercer CERT nacional (sumándose así al CERT de la UPC y al de Red Iris) para proteger a las administraciones públicas de los ataques informáticos. Tan sólo dos meses después comenzaba la creación de CERT autonómicos en España con la puesta en marcha de CSIRT-cv. Mucho ha llovido desde entonces en estos últimos 5 años en materia de seguridad en las administraciones públicas y así surge como hito interesante la obligatoriedad de la adaptación al Esquema Nacional de Seguridad por parte de todas las administraciones públicas con objeto de aplicar una política de seguridad que conlleve una protección adecuada de los sistemas de información.

Han sido 5 años muy intensos en lo que a seguridad concierne, y desde Security Art Work hemos intentado poner nuestro granito de arena compartiendo con vosotros casi diariamente nuestro conocimiento, bien sea a través de artículos técnicos, sobre seguridad legal o sobre seguridad en el desarrollo así como opiniones personales o desarrollo de herramientas u otras noticias interesantes. Pero lo que enriquece a un blog no es solo la cantidad de artículos que en él se publique, lo que de verdad enriquece a un blog sois vosotros, nuestros lectores (habituales o esporádicos), cuando sentís que os estamos aportando conocimiento en cada uno de las entradas que leéis y a vosotros os queremos dar las gracias en este quinto aniversario.

No quiero hablar ni de estadísticas, ni de números de lectores, ni de cuantos nos seguís en Twitter ni del premio que nos dieron :p. Solo comentar que cada día sois más los que nos leéis, los que nos hacéis llegar vuestras opiniones, los que aportáis conocimiento a cada post con comentarios y eso hace que todos aprendamos de todos y el conocimiento se extienda. Y todo ello nos hace estar más ilusionados con Security Art Work.

He partido de la primera entrada que se publicó en este blog y quería acabar con un Típico Tópico (como dice nuestro compañero Toni Villalón) dentro de la Seguridad, haciendo referencia a una frase de “El arte de la guerra” de Sun Tzu (fantástico libro) pero dado que no consigo meter ninguna ni con calzador :D acabaré citando mejor una frase de Manolo mucho más sencilla de introducir en este post: “Hola, buenos días y bienvenidos”.

Tras casi dos meses de respuestas, hoy miércoles toca cambiar la encuesta del blog, y lo hacemos con un tema, el del cloud, que ya no sabe uno si está de moda, si está demodé, o si simplemente es que va lentamente atravesando la curva Hype Cycle de Gartner (el autor de la imagen es Jeremy Kemp):

[Read more…]

Recordemos rápidamente el post anterior que Security Art Work publicó sobre Razorback: es un proyecto de código abierto actualmente en desarrollo por el equipo VRT de Sourcefire, cuyos objetivos son básicamente proporcionar un marco de trabajo unificado para la gestión de incidentes de manera avanzada en el que poder analizar tráfico, detectar ataques, generar alertas, correlarlas y guardar toda la información en una misma base datos. Con todo esto dispondríamos de una información muy valiosa de cara a detectar tendencias de ataques (entre otras cosas) y así poder prevenirnos.

Conocíamos la teoría, y sabíamos que potencialmente podría ser muy versátil gracias a su diseño modular, que lo hace escalable y personalizable (comentábamos que estaba formado por Nuggets que podemos crear nosotros mismos) pero hasta que no lo hemos probado no hemos visto qué era capaz de hacer.

La instalación del entorno no es rápida, sin embargo, disponemos de una máquina virtual con todo ya montado, ideal para probar de una manera cómoda el funcionamiento. Tiene instalados los siguientes nuggets: Yara, OfficeCat, ClamAV, Archive Inflate, Scripting, File Inject, Snort, Virus Total (se activa si le proporcionamos una API key) y el PDF Dissector ( solo se activa bajo licencia) y está montada sobre FreeBSD.

Una vez levantada la VM puedes acceder a la interfaz de administración (o de gestión como yo le he llamado, véase la siguiente imagen) desde http://:8080 :

Desde este panel de administración podemos gestionar fácilmente todo el sistema, desde la creación de usuarios, conexiones de red, creación de nuevas interfaces, control de los servicios, estado de los nuggets, ver qué procesos se están ejecutando, comprobar el estado de nuestra CPU, tráfico a través de las interfaces, etc. Por ejemplo, en la siguiente imagen vemos como desde el panel de administración comprobamos que nuggets tenemos funcionando:

También podemos comprobar los servicios:

En el puerto 80 podemos acceder a la interfaz de usuario, en la cual podemos consultar los eventos generados o subir ficheros para que los analice directamente (“Submit Data Block“). A continuación se muestra una imagen de dicha interfaz en la que mostramos el campo Status, para comprobar el estado general del sistema:

Se ha probado por ejemplo a pasarle un fichero comprimido que contenía un ejecutable malicioso y en los eventos generados se puede ver el análisis que se le hace tanto al fichero comprimido como a cada fichero contenido en él alertándonos en que fichero se alojaba el malware.

Para las pruebas que se hicieron, se configuró una nueva interfaz de red en la VM (que se llamó monitorización —ver primera imagen de este post—) de modo que Snort (nuestro nugget collector) monitorizara todo el tráfico que llegara por esa interfaz. Una vez hecho ésto, para probar el funcionamiento se le pasaron varios pcap con malware que se cogieron de este repositorio. Comentar que se hizo con Tcpreplay:

/usr/local/bin/tcpreplay --intf1=em1 file.pcap

De esta forma se inyecta por la interfaz em1 (mi interfaz de monitorización) un fichero file.pcap.

Así, una vez enviado tráfico sobre la interfaz de monitorización puedo observar en la interfaz de usuario, en Events, todas las alertas que me genera ese tráfico, aquí una imagen (cortada porque era un gran listado de eventos):

En la imagen anterior vemos tres eventos a modo de ejemplo, en los dos primeros nos muestra que se han generado alertas (5ª columna). Desplegando, en este mismo panel, los metadatos asociados al evento que tenemos seleccionando nos da la siguiente información:

Pinchando directamente en las alertas generadas nos muestra lo siguiente:

Desplegando la sección de Malware Names, nos saca un listado (incompleto porque se ha acortado para que se viera mejor) de nombres de este tipo de malware:

En líneas generales este sería el funcionamiento básico de Razorback.

Por supuesto está aún en “pañales” y probablemente se le pueda sacar mucho más partido en un futuro del que se ha mostrado en este post, pero nos da una idea de lo que es capaz de hacer y cómo manejarnos a través de los paneles de gestión que incorpora. Tras las breve toma de contacto que se ha tenido con este Framework diríamos que algunas ventajas a tener en cuenta serían que es apropiado para detectar en tiempo real incidentes contra usuarios finales, puedes crear tus propios nuggets, parece interesante para detectar 0-day, detección de tendencias de ataques, interesante a la hora de hacer un análisis forense a un pcap, las interfaces son muy intuitivas… Por otro lado, sus principales inconvenientes serían que está en desarrollo, parece generar falsos positivos y es complicado de montar.

Hace unos días se publicaba en The Honeynet Project una entrada que hablaba sobre una serie de nuevos plugins para Wireshark desarrollados en el Google Summer of Code (GSoC) de este año.

Uno de esos plugins, WireShnork, permite aplicar las reglas de Snort al tráfico de red capturado por Wireshark y añade un nuevo filtro para que se pueda seleccionar aquellos paquetes que hacen saltar una regla que tengamos definida en Snort. Parece muy interesante, sobre todo a la hora de hacer un análisis forense ya que cuando el tamaño de la captura a analizar contiene miles de paquetes se hace inmanejable y es necesario filtrar por lo más relevante.

Por ahora WireShnork (y el resto de nuevos plugins del GSoC) solo está para Wireshark 1.7 (Development Release) y, tal y como indican en la entrada de The Honey Project, se pueden descargar vía GIT:

$ git clone git://git.honeynet.org/wireshark.git

Tras descargarlos se habrá creado un nuevo directorio:“wireshark”, con los plugins y un script llamado get-wireshark.sh. Para probarlo es necesario tener también Snort instalado (para las pruebas que hice usé Snort 2.9.1.2). Una vez se tiene Snort funcionando, Wireshark 1.7 instalado, y los nuevos plugins compilados ya se puede probar el funcionamiento de WireShnork.

Al arrancar la primera vez Wireshark salta un aviso indicando que no se encuentran los ficheros de configuración de Snort, así que se debe indicar la ruta a snort.conf en Edit-> Preferences -> Protocols-> Wireshnork tal y como se muestra en la siguiente figura:

Para realizar las pruebas con WireShrork pasé un pcap descargado del repositorio de pcap públicos que nos ofrece Sourceforge. Concretamente utilicé una captura de una máquina infectada por el gusano W32/Sdbot.

En el cuadro de texto disponible para realizar los filtrados, añadimos “snort” y aplicamos dicha regla de filtrado. Esto seleccionará solo aquellos paquetes que hayan hecho “match” con las reglas de Snort que estén activas, tal y como se ve en la siguiente figura:

Se puede filtrar también por el SID de la regla del snort, Message, etc:

Por ejemplo, filtrando por un SID concreto mostraría solamente aquellos paquetes que hicieran saltar la regla de Snort con dicho SID como se puede ver a continuación:

Resulta de gran utilidad para ahorrar tiempo al analizar, desde el punto de vista forense, una captura de tráfico de gran tamaño.

Otro plugin del paquete del GSoC que también parece muy interesante para Wireshark es WireViz, éste nos muestra gráficamente con GraphViz las interconexiones de tráfico que se indiquen. En el menú Statistics de Wireshark, si se lanza WireViz se muestra una cuadro en el se puede elegir como queremos que se dibuje el gráfico, filtrando por ip, tcp, eth,udp, ivpv6 o el diseño que queremos aplicarle a dicho gráfico:

Si filtramos por ip y con la opción twopi para que pinte un diseño radial, el gráfico quedaría de la siguiente forma:

Pinchando en cada nodo se puede aplicar un filtrado en el propio Wireshark:

Se puede también personalizar nuestro gráfico aplicando diferentes formas y colores y filtrando según protocolo por ejemplo:

Se puede afinar más los resultados usando la barra de filtrado, de manera que es posible, por ejemplo, seleccionar únicamente por las interconexiones que hacen saltar las reglas de Snort, tal y como se ha comentado para WireShnork:

Para finalizar, os dejo un video muy ilustrativo de cómo usar WireViz y comentaros que, como dicen en The Honeynet Project , cualquier feedback acerca de estos nuevos plugins será bien recibido.

Recientemente comentábamos entre los compañeros cómo han disminuido, en general, los ataques dirigidos a servidores, aumentando especialmente, por contra, los ataques al usuario. Dichos ataques están siendo cada vez más sofisticados ya que intentan explotar vulnerabilidades muy avanzadas a nivel de cliente, sobretodo a la hora de procesar ficheros “complejos”, como DOC o PDF.

Con ello, nos encontramos ante la dificultad de realizar una detección en tiempo real de ataques dirigidos a usuarios, ya que los sistemas inline deberían simular diversos escritorios para poder detectarlos, con diferentes navegadores y sistemas operativos; por ejemplo, añadiendo el hecho de que una inspección en profundidad de cada uno de los ficheros consume mucho tiempo de proceso.

Uno de mis compañeros, Josemi (archivo de autor, @J0SM1 ), nos habló de Razorback, un proyecto que aún está en fase de desarrollo pero que precisamente tiene por objetivo proporcionar un entorno de trabajo que se adecúe justo a lo que comentaba anteriormente: al panorama cambiante de amenazas en el que nos encontramos, y que nos permita gestionar de manera avanzada incidentes en tiempo real. Decidí profundizar más acerca de éste proyecto, y como me pareció interesante, en esta entrada entraré un poco en éste, en una posterior entrada comentaré acerca de la instalación y mostraré un ejemplo práctico de su funcionamiento.

Razorback es un proyecto de código abierto que está desarrollando el equipo VRT de Sourcefire y que pretende ofrecer un único framework de gestión avanzada de incidentes, escalable y extensible enfocado sobre todo a la detección de malware, especialmente de exploits 0-day.

Básicamente, está diseñado para ser un “marco de distribución” (dispatching framework), ya que distribuye los datos que va monitorizando hacia herramientas de análisis y detección de amenazas que realizan una inspección más en profundidad de esos datos, y todo esto manteniendo una gran base de datos forense en la que se almacena toda la información procesada. Al combinar diversas herramientas bajo un mismo marco de trabajo y punto de vista se acelera la creación de las contramedidas al respecto de esas amenazas, y disponer de toda esa información en una misma base de datos es muy útil de cara a detectar tendencias de ataques, y así prevenirlas, obtener informes sobre malware, o buscar por firmas de ataques en dicha base de datos.

Este framework está formado por una serie de elementos principales que trabajan por separado pero retroalimentándose de información los unos de los otros, como vemos en la siguiente imagen:

• Dispatcher: elemento principal de nuestro framework, ya que se encarga de gestionar todas las comunicaciones entre el resto de elementos.
• Base de datos que almacena información sobre cada evento, metadatos, información de la configuración, etc.
• Nuggets: diversas herramientas que nos van a proporcionar diversas funcionalidades según el tipo que sean:
  • Collection Nugget: se encargan de capturar datos de la red y contactar con el Dispatcher para evaluar si esos datos ya han sido tratados:
    • Snort
  • Detection Nugget: analizan los datos que vienen desde los elementos de Collection Nugget. Contactan con el Dispatcher para indicarle si se genera cualquier tipo de alerta. Podemos encontrar:
    • PDF Dissector
    • JavaScript Analyzer
    • Shellcode Analyzer
    • Office Cat Nugget
    • SWF Nugget
    • ClamAV
  • Output Nugget: Reciben alertas desde el Dispatcher. Pueden enviar datos a otros sistemas, como por ejemplo a una interfaz de Maltego.
  • Intelligence Nugget: no generan alertas por sí mismos, sino que generan datos que podrían ser usados a posteriori para correlar eventos o analizar tendencias de ataques.
  • Correlation Nugget: interactúan directamente con la base de datos. Se encargan de proporcionar información sobre datos de tendencias, o hosts críticos, por ejemplo. Nos podrían ayudar a trazar, por ejemplo, un ataque a través de la red.
  • Defense update Nugget: ponen en marcha la actualización de diferentes dispositivos a petición del Dispatcher.
  • Workstation Nugget: interfaz donde se puede gestionar el resto de nuggets, consultar los eventos, alertas, etc.

El funcionamiento a grandes rasgos es el siguiente: Razorback monitoriza cierto tipo de tráfico (HTTP, Web o correo electrónico SMTP) y va enviando a diferentes nuggets datos replicados, con el fin de analizarlos en busca de vulnerabilidades 0-day o posibles códigos de explotación, registrándolo todo en la base de datos.

Básicamente estamos hablando de que al Dispatcher le llega un fichero, y escoge a qué nugget le tiene que enviar dicho fichero para que lo analice. Si por ejemplo un fichero embebe otro de diferente tipo, el fichero embebido se le devuelve al Dispatcher para que lo vuelva a redirigir al nugget apropiado. En la siguiente imagen se muestra un ejemplo del funcionamiento:

Los desarrolladores invitan a los usuarios a crear sus propios nuggets ya que en teoría es fácil integrarlos en el funcionamiento, y a probar la herramienta para hacer crecer este proyecto. Para la siguiente entrada os quiero hablar sobre la instalación de Razorbarck (que os adelanto que es un infierno) y mostraros un ejemplo práctico de su funcionamiento y cómo ver y manejar la información que nos ofrece.

Si os interesa el proyecto, no dudéis en visitar su página (http://sourceforge.net/apps/trac/razorbacktm/) y echarle un vistazo a esta presentación de Razorback en la Defcon del año pasado (y siguientes vídeos).

Una de las características que ofrece la versión ProfessionalFeed (la de pago, vamos: $1200 al año cada licencia) de Nessus —entre otras— es la posibilidad de realizar auditorías de cumplimiento a sistemas Unix y Windows, aplicaciones o bases de datos SQL basadas en estándares ya predefinidos.

Así pues, podremos realizar auditorías de cumplimiento basándonos en las recomendaciones CERT, guías de buenas prácticas CIS o NSA, requerimientos de configuración PCI , e incluso Bandolier (proyecto de Digital Bond) proporciona políticas de cumplimiento (a través de ficheros .audit de los cuales hablaremos a continuación) para auditar sistemas SCADA, DCS y otras aplicaciones de sistemas de control industrial, entre otros.

El cumplimiento o no cumplimiento de dichas recomendaciones viene predefinido por los ya mencionados ficheros de extensión .audit que ofrece Tenable a través de su centro de soporte. Podemos descargarnos diversos ficheros .audit que nos definan por ejemplo políticas de auditorías desarrolladas por Tenable para auditar sistemas Windows, Linux, HP-UX, Solaris y AIX para comprobar el cumplimiento de unos requerimientos de configuración mínimos establecidos según el estándar PCI, políticas de cumplimiento basadas en las mejores prácticas según Cisco para la configuración de sus dispositivos o incluso políticas de auditoría que analizan la presencia de contenido “sensible” en los sistemas a auditar (contenido para adultos, información corporativa confidencial, números de tarjetas de crédito, etc.) por citar algunos ejemplos.

Por ejemplo si queremos auditar un dispositivo Cisco según las propias recomendaciones sobre buenas prácticas de Cisco usaríamos el fichero .audit correspondiente. Veamos una posible puesta en escena. El primer paso es crearnos nuestra política:

Descargamos el fichero .audit correspondiente del centro de soporte. En este caso a modo de ejemplo usaremos Cumplimiento_Cisco_Level_2.audit: fichero que implementa las recomendaciones de configuración de nivel 2 según el CIS Cisco IOS Benchmark v2.4.0. En la descripción del fichero .audit además indica que es necesario que toda la familia de plugins de Cisco esté habilitada, así que no debemos olvidarnos de habilitar el plugin correspondiente a Cisco dentro de la familia de plugins del cumplimiento de las políticas:

A continuación en Preferencias cargamos el fichero .audit que hemos descargado previamente seleccionando el plugin ‘Cisco IOS Compliance Checks’; como vemos permite incluir hasta cinco ficheros .audit de política de Cisco que permiten verificar si dispositivo con Cisco IOS está configurado conforme a los estándares de seguridad indicados en las políticas cargadas:

De este modo tan simple, ya tendríamos la política creada para auditar nuestro dispositivo y ver si cumple con las recomendaciones que el proveedor nos da.

Si nuestra empresa dispone de su propia política de seguridad en cuanto a configuraciones de servidores por ejemplo podemos editar nuestro propio fichero .audit para realizar la auditoría de cumplimiento de acuerdo a nuestra propia política. Asimismo, en el centro de soporte de Nessus se proporcionan también diversas Tools (i2a, c2a, p2a) para generar nuestros propios ficheros .audit a partir de otros ficheros. Así, por ejemplo podemos generar ficheros .audit a partir de ficheros .inf de Windows. por citar un ejemplo. Para aquellos interesados, Tenable proporciona información al respecto de la creación de ficheros .audit en su centro de soporte e invita a que los usuarios interesados visiten los foros de discusión del producto.

Por propia experiencia y para acabar, los ficheros .audit ayudan con el cumplimiento de estándares, o al menos dan una idea bastante aproximada de cuál es la situación al respecto, sin embargo creo que como con cualquier herramienta automatizada, es recomendable a posteriori realizar una verificación de los resultados.