May 4 2011

El huevo del cuco

chmeee

One flew east,
one flew west,
one flew over the cucko’s nest

Fantástica presentación de Bejtlich sobre lo que puede aprenderse del clásico libro ‘The cucko’s egg“.

En este libro, su autor, Cliff Stoll, cuenta como descubrió una trama de espionaje que robaba información de sistemas de los Estados Unidos.

En la presentación Bejtlich recoge las enseñanzas sobre monitorización y respuesta a incidentes que extrae tras leer el libro, animadas con capturas de una representación teatral (casi documental) que hicieron para televisión en la que actúan los propios implicados.

Tuve la oportunidad de leer este libro allá por el 2001 pero finalmente no lo hice :( . Y aunque siempre me he arrepentido, ahora me arrepiento más.

¿Qué puede aprenderse de este libro? Os incluyo la enumeración de Bejtlich traducida, aunque sólo sea para que se me quede mejor:

Lecciones sobre monitorización y análisis

  • “Dotarse de visibilidad” con una aplicación de contabilidad local
  • No dependas de una única “fuente de verdad”
  • El registro centralizado de actividad es una solución contra los intrusos que borran los logs locales
  • La monitorización pasiva de todo el tráfico captura todos los detalles sin alertar al intruso
  • Documenta el análisis en un libro de bitácora
  • Preguntas clave: ¿alcance de la intrusión, profundidad de la intrusión?
  • Monitorizar usando material abandonado es mejor que nada
  • Escritura de herramientas a medida para monitorizar y alertar
  • A alguien le importa: análisis por una persona que se tomó la intrusión de forma personal

Lecciones sobre la naturaleza de la intrusión

  • El intruso aprovecha credenciales débiles para acceder
  • El intruso utiliza una vulnerabilidad local para escalar privilegios
  • El intruso se aprovecha de relaciones de confianza
  • El intruso se aprovecha de configuraciones inseguras por defecto del fabricante
  • El intruso se aprovecha de la monocultura de sistemas (¡Unix de los ’80!)
  • Había información sensible accesible desde la red normal, por ejemplo, equipamiento de tratamiento de cáncer
  • Los propietarios de los sistemas le decían a Stoll repetidamente que una intrusión era “¡imposible — nuestros sistemas son seguros!
  • ¿Recuperación desde una imagen, re-construcción o desde backup?
  • La notificación externa es el método más común de detección

Lecciones sobre las verdades duraderas

  • De las 80 víctimas sólo dos se dieron cuenta (LBNL y NSA)
  • Las agencias del estado piden información pero dan poca
  • La comunicación de información sobre la intrusión compromete las operaciones de seguridad
  • Los intrusos desafían las suposiciones de los propietarios de la red
  • ¿Cuándo monitorizar al intruso y cuándo contenerlo?
  • ¿Cuánto cuesta la información robada? ¿Cuál es el coste del incidente?
  • Diversas técnicas de análisis proporcionan mejores resultados
  • No se puede confiar en que los sistemas se defiendan solos o que informen sobre su estado de seguridad
  • Los intrusos pueden ser creativos y persistentes

Por último, no os perdáis esta TED Talk de Cliff sobre… sobre… bueno, mejor que lo véais. Y no le toméis a mal el comentario “I find compurter security frankly to be kind of boring” :) .


Mar 27 2011

Ceguera tecnológica

chmeee

“¿No te has dado cuenta al pasar por la terraza de que la noche estaba seca y fría? ¿No sabes lo que eso significa? No lo sabes, claro. Pues eso quiere decir que ahora están brillando las estrellas con todo su esplendor, y que los videntes gozan de la maravilla de su presencia. Esos mundos lejanísimos están ahí (Se ha acercado al ventanal y toca los cristales.) tras los cristales, al alcance de nuestra vista…, ¡si la tuviéramos!” — En la ardiente oscuridad. Antonio Buero Vallejo

Ciego. Así es como me siento cuando no sé qué es lo que está pasando en los sistemas de información y en las redes de comunicación. Toda es información está ahí, “al alcance de nuestra vista…, ¡si la tuviéramos!“.

El problema es que, actualmente, en muchas organizaciones no hay medios implantados para  conocer qué pasando en nuestra infraestructura. Algunas de las razones para no tener medios implantados son:

  • No se han configurado registros de actividad
  • No se han centralizado registros de actividad
  • Se supone que la cantidad de almacenamiento requerido es alta
  • Se supone que no hay recursos suficientes para analizar los registros
  • No se sabe qué buscar en los registros de actividad
  • No se sabe qué hacer con los registros de actividad

Como todo en la vida, uno de los principales problemas es intentar saberlo todo antes de siquiera empezar. Está claro que es un problema difícil que hay que ir resolviendo poco a poco e ir adaptando a las necesidades y limitaciones de cada uno.

Como punto de partida, lo mejor es empezar a centralizar aquellos eventos que puedan ser de interés inmediato, por ejemplo, accesos o errores. e ir viendo qué está ocurriendo. Posteriormente, ampliarlo en función de las necesidades que vayan surgiendo.

La ventaja de ir conociendo, al menos, algunos datos de lo que pasa en los sistemas o redes es que provoca dudas y preguntas que nos llevan a investigar y, por ende, adquirir un conocimiento mucho más completo de nuestra infraestructura.

Y ése es el segundo aspecto de la ceguera: no conocemos nuestra infraestructura. Pensad si sabríais responder a las siguientes preguntas:

  • ¿Qué software requiere mi infraestructura?
  • ¿Qué tráfico es el mínimo necesario?
  • ¿Qué puertos debo tener abiertos?
  • ¿Qué cambios ha habido recientemente?
  • ¿Qué procesos automáticos se ejecutan periódicamente?

Y eso sin considerar otros aspectos como información, aplicaciones, ficheros, copias, replicaciones, etc.

Algunas herramientas interesantes contra la ceguera (no pretende ser muy completa) son las siguientes:

Registros/eventos

  • OSSEC: un HIDS muy completo y, además, software libre.
  • Splunk: el favorito de los niños, el Google de tus logs y mucho más. Puedes usar una versión limitada gratis.
  • Sentinel: recientemente han anunciado una versión limitada también gratuita.
  • Loggly: para los atrevidos que no les importe mandar los logs a la nube.
  • LogstashGraylog2: dos aplicaciones de centralización de logs en software libre de reciente aparición.

Red/tráfico

  • Snort: el archiconocido IDS de red en software libre.
  • Snorby: un entorno web moderno para snort.
  • Ntop: el clásico entorno web de monitorización de tráfico.
  • Nfsen: para monitorización de tráfico con netflow.

Infraestructura

  • Nmap: best… scanner… ever.
  • OneCMDB: una aplicación de ‘inventario’ que, aunque parece muy potente, a mí no me acaba de convencer, pero tampoco es que haya encontrado nada mejor.
  • OCSInventory: tampoco es que me fascine porque es algo viejuno, pero si el objetivo es conocer el hardware y software instalado, puede ser la mejor solución.

Dejo fuera otro tipo de herramientas tipo Nagios que es bastante más común encontrar en cualquier organización.

Y vosotros… ¿también os sentís ciegos? ¿Qué herramientas conocéis/usáis? En cualquier caso, recordad que el objetivo último es conocer para mejorar la seguridad.

Estas herramientas sólo sirven para obtener información y no son, en ningún caso, sustitutos de los humanos. Recordad que solas no hacen nada, hay que usarlas.

Aparte de analizar los datos de herramientas diariamente, conviene buscar los medios para obtener un conjunto de datos de forma periódica que nos ayuden a entender nuestra infraestructura.

El SANS publicó hace mucho la lista de los ‘Top 5 essential log reports‘ donde se indicaban los ‘informes’ a generar periódicamente extraídos de logs y otros datos de los sistemas.

Recientemente, Chuvakin ha hecho una propuesta para los ‘Top 7 essential log reports‘ que os recomiendo que miréis y penséis si sois capaces de obtenerla con los medios actuales y si os sería de utilidad.

Por cierto que acabo de ver que Chuvakin tiene en su blog una lista de herramientas de análisis de logs que acaba de actualizar. Echadle un ojo.