Conoce a tu enemigo:
Estadísticas
Analizando
el pasado ... prediciendo el futuro
Traducción del
texto: Know your enemy (Statistics), disponible en
Honeynet Project
http://www.honeynet.org/
Última modificación: 31 enero, 2003
Licencia de la traducción
Se da permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia Libre de Documentación GNU, versión 1.2 o cualquier versión posterior publicada por la Free Software Foundation (Fundación para el Software Libre); este documento no tiene secciones invariantes, textos de portada ni de contraportada. Se incluye una copia de dicha licencia en la sección titulada "Licencia de Documentación Libre GNU".
Durante los últimos años,
el Honeynet Project ha ido recopilando y archivando información sobre la
comunidad blackhat. Hemos intentado, tan bien como
hemos podido, hacer logs y capturar cada intento,
ataque, exploit que se han hecho contra nuestro
Honeynet. Estos datos intactos tienen un potencial de gran valor. Decidimos
compartir estos datos con la comunidad de seguridad y demostrar su importancia.
Nos centraremos en dos áreas. Primero, intentaremos demostrar lo activa que la
comunidad blackhat puede llegar a ser. No estás seguro, sin importar quién seas.
Nuestro objetivo es alertarte sobre este hecho. Segundo, probaremos el concepto
de la Detección Temprana y la Predicción. Mediante la identificación de
tendencias y métodos, puede ser posible predecir un ataque y reaccionar, días
antes de que ocurra. Probaremos esta teoría utilizando los datos recogidos por
el Honeynet Project.
Los Datos Recogidos
El Honeynet Project mantiene ocho redes IP altamente
controladas y estrechamente monitorizadas. Hemos recogido y archivado todos los
ataques a esta red durante un período de once meses, concretamente desde abril
de 2000 hasta febrero de 2001. Esta Honeynet consistió en ocho direcciones IP,
proporcionadas por una conexión RDSI simple de un PSI local. Este tipo de
conexión es la misma que utilizan muchos usuarios en sus hogares y pequeñas
empresas. De hecho, el Honeynet se ubicó en el dormitorio de uno de los
miembros del proyecto. Durante aquel período de tiempo, normalmente existían de
uno a tres sistemas dentro del Honeynet. Esos honeypots
ejecutaban uno de los siguientes sistemas operativos; Solaris
Sparc, WinNT, Win98, y Red Hat Linux.
La
red Honeynet, la
red utilizada para la captura de datos, es una red básica de sistemas
operativos comunes, tales como Red Hat Linux o Windows NT, con una configuración por defecto. No
se hizo ningún intento por difundir la presencia del Honeynet, ni para atraer a
los atacantes. Teóricamente, este sitio debería ver muy poca actividad, ya que
no publicamos ningún servicio ni sistema. No obstante, hubo ataques, y
frecuentes.
Los falsos negativos son
otro reto que encaran la mayoría de las organizaciones. Los falsos negativos
tienen lugar cuando no se detectan ataques reales o actividades no autorizadas.
La mayoría de las organizaciones tienen mecanismos para detectar ataques, tales
como Sistemas de Detección de Intrusiones, logs de Cortafuegos, logs de
Sistema, y monitorización de procesos. El propósito de estas herramientas es el
de detectar actividades sospechosas o no autorizadas. No obstante, hay dos
desafíos principales que conducen a los falsos negativos, la sobrecarga de
datos y las nuevas amenazas. La sobrecarga de datos ocurre cuando las
organizaciones capturan tal cantidad de datos, que no todos pueden ser
revisados, así que hay ataques que no se ven. Por ejemplo, muchas
organizaciones registran Gigabytes de actividad del cortafuegos o del sistema. Es extremadamente difícil
repasar toda esa información e identificar un comportamiento sospechoso. El
segundo desafío son los nuevos ataques, amenazas de las que las organizaciones
o el software de seguridad no están enterados. ¿Si el ataque es desconocido,
cómo puede ser detectado? El Honeynet reduce los falsos negativos (la
desaparición de ataques) capturando absolutamente todo lo que entra y sale del
Honeynet. Recuerda, hay poca o ninguna actividad de producción dentro de un
Honeynet. Esto significa que toda la actividad que se captura es probablemente
sospechosa. Incluso si perdemos el ataque inicial, todavía tenemos capturada la
actividad. Por ejemplo, un honeypot ha sido
comprometido dos veces sin que los administradores del Honeynet hayan sido
alertados en tiempo real. No detectamos el ataque con éxito hasta que los honeypots iniciaron las conexiones salientes. Una vez fueron
detectados estos intentos, revisamos toda la actividad capturada, identificamos
el ataque, cómo tuvo éxito, y por qué no lo vimos. Para propósitos de
investigación, la ayuda de Honeynets reduce falsos
negativos.
El valor de los datos que
vas a revisar radica en que tanto los falsos negativos como los falsos
positivos han sido dramáticamente reducidos. Ten presente, que los resultados
que discutimos abajo son específicos de nuestra red; esto no significa que tu
organización experimente los mismos patrones de tráfico o comportamiento. Hemos
utilizado estos datos recogidos para demostrar la naturaleza de determinados blackhats, y el potencial de la Detección Temprana y la
Predicción.
Analizar el Pasado
Durante la investigación de la comunidad blackhat, el
Honeynet Project se asombró de lo activa que puede llegar a ser la comunidad blackhat. Los resultados asustan. Debajo hay alguna de las
estadísticas que hemos identificado a partir de los datos que recogimos durante
el período de once meses. El propósito de estas figuras es demostrar el
comportamiento activo de la comunidad blackhat. Ten
presente que estas estadísticas representan a una red casera de poco valor que
ni fue anunciada ni usada para atraer blackhats.
Organizaciones más grandes con más publicidad o valor, muy probablemente son
sondeadas y atacadas en números mucho mayores.
Análisis posterior al
ataque:
·
Entre
abril y diciembre de 2000, siete instalaciones por defecto de servidores Red Hat 6.2 fueron atacados a los tres días de estar conectados
a Internet. Según esto, estimamos la esperanza de vida de una instalación por
defecto de un servidor Red Hat 6.2 en menos de 72
horas. La última vez que procuramos confirmar esto, el sistema fue comprometido
en menos de ocho horas. El tiempo récord para comprometer un sistema fue de 15
minutos. Esto significa que el sistema fue escaneado,
sondeado, y explotado durante los 15 minutos que llevaba conectado a Internet.
Casualmente, este fue el primer honeypot que
instalamos, en marzo de 1999.
·
Un
equipo Windows98 fue instalado el 31 de octubre de 2000, con la opción de
compartir activada, la misma configuración que se puede encontrar en muchos
hogares y organizaciones. El honeypot fue
comprometido en menos de veinticuatro horas. En los tres días siguientes fue
comprometido con éxito otras cuatro veces. Esto hace un total de cinco ataques
con éxito en menos días.
·
En mayo de 2000, el primer mes completo que archivamos las alarmas del Detector
de Intrusiones Snort, el Honeynet registró 157 alarmas. En
febrero de 2001, el Honeynet registró 1.398 alarmas del Snort,
mostrando un crecimiento de más del 890%. Este aumento pudo verse afectado por
modificaciones en el fichero de configuración del IDS Snort.
Sin embargo, también se aprecia un incremento de la actividad en los registros
del Cortafuegos. En mayo de 2000, el primer mes completo que archivamos las
alarmas del cortafuegos, el cortafuegos del Honeynet
registró 103 escaneos únicos (sin contar NetBios). En febrero de 2001, el Honeynet registró 206 escaneos únicos (sin contar NetBios).
Esto representa un incremento del 100%. Estas cifras indican que la actividad blackhat ha continuado creciendo, muy probablemente como
resultado de la aparición de herramientas de escaneo
más agresivas y automáticas, y su creciente disponibilidad.
·
Durante
un período de treinta días (20 de sep - 20 de oct de 2000), el Honeynet recibió
524 escaneos ÚNICOS de Netbios,
a una media de 17 escaneos únicos de NetBios cada día.
·
En el mes de febrero de 2001, un total de 27 exploits X86 fueron lanzados contra el Honeynet. X86
significa que estos ataques fueron diseñados para sistemas de arquitectura Intel. De estos, 8 fueron lanzados contra un sistema Solaris Sparc. Estos exploits no funcionan contra un sistema Sparc,
ya que la arquitectura del sistema no es compatible. Esto indica que algunos blackhats no se molestan en comprobar el sistema operativo
o la versión del servicio que estás ejecutando. Algunos blackhats
han pensado su proceso de escaneo para buscar
simplemente un servicio específico. Si encuentran el servicio, lanzan el exploit sin ni siquiera comprobar primero si el sistema es
vulnerable, o si es el sistema correcto. Esta aproximación activa permite a los
blackhats escanear y
explotar más sistemas en menos tiempo.
·
Desde
abril de 2000 hasta hoy, los métodos de reconocimiento más populares, además
del escaneo general, fueron solicitudes de versión de
DNS, seguido por solicitudes a los servicios RPC.
·
El
ataque más popular fue el desbordamiento asociado al rpc.statd
para sistemas Intel.
·
El
método más popular de escaneo detectado fue el escaneo SYN-FIN para buscar en un rango entero de IP
puertos específicos (a menudo en orden secuencial). Esto refleja la táctica de
concentrarse en una sola vulnerabilidad, y de escanear
tantos sistemas como sea posible para encontrarla. Muchos blackhats
usan sólo una herramienta o un exploit que sepan cómo
utilizar, o sea el más efectivo.
Predecir el Futuro
Una de las áreas
que el Honeynet se propone investigar es la
Detección Temprana y la Predicción.
Es nuestro intento por dar más valor a los datos que el Honeynet recoge
prediciendo ataques futuros. Esta teoría no es nueva y la persiguen importantes
organizaciones. Esperamos que esta investigación beneficie a estas y otras
organizaciones. Antes de explicar nuestra metodología, quisiéramos indicar que
nuestra investigación todavía está en su infancia, y requiere más análisis.
Ahora, vamos a calificar
esa declaración:
·
Estamos
hablando de un sólo Honeynet, que ofrece la perspectiva de un sólo sensor, y trabaja con muy pocos datos. La metodología
explicada debajo será pronto probada en un entorno empresarial, con múltiples Honeynets distribuidos alrededor del mundo.
·
No
hemos intentado separar alertas del mismo atacante, simplemente por el excesivo
uso del spoofing.
·
Trabajamos
actualmente bajo la suposición de que una máquina primero es sondeada y después
de esto atacada. Por supuesto, los dos eventos que tendemos a ver pueden en
realidad no estar relacionados en absoluto, ser mera coincidencia. No obstante,
realizamos el análisis siguiente bajo la premisa de que un atacante podría,
como mínimo, reunir datos antes del ataque, y entonces comprobar de nuevo justo
antes del ataque si el puerto seguía abierto... que es lo que vimos.
En un esfuerzo por predecir
tendencias, dos miembros del Honeynet Project tomaron dos acercamientos
distintos. Sin embargo, sus resultados fueron similares, casi todos los ataques
se podían detectar dos o tres días antes de que ocurrieran.
Detección temprana
utilizando Controles de Proceso Estadístico (SPC):
El
primero era un análisis estadístico muy simple, similar a la metodología de control
de procesos estadísticos utilizada en entornos industriales para medir defectos
en ajustes de fábricas. Este método, aunque muy sencillo, demostró ser
extremadamente eficaz a corto plazo (tres días o menos), avisando de ataques
inminentes contra el Honeynet. El proceso básico funciona de la siguiente
manera:
·
Analizamos registros del snort
desde abril de 2000 hasta enero de 2001.
·
Para cada una de las diez primeras reglas de la
lista del snort publicadas, calculamos el número de
veces que cada regla era publicada cada día.
·
Después, calculamos el promedio móvil de tres días
(3DMA) de cada regla publicada, y dibujamos en un gráfico de control el número de
publicaciones de cada regla en cada día, y el del 3DMA.
·
Los límites de control fueron calculados obteniendo
la desviación estándar del promedio sobre el período, y multiplicando 2 veces
(límites de control 2-sigma).
·
Cuando el 3DMA estuviera por encima del límite de
control 2-sigma, o si notáramos una ejecución (3 o más incrementos sin
decrementos), era considerada como alerta.
Todos los cálculos se realizaron sin
aviso previo de intentos o ataques con éxito. Sólo después de haber calculado
la carta de control, eran dibujados los intentos y ataques con éxito en la
línea de tiempo. Todos los datos están disponibles en el sitio de Honeynet. He
aquí algunos de nuestros hallazgos:
1.
El Honeynet registró ocho ataques de
exploit con éxito entre el 9 de abril de 2000 y el 31
de diciembre de 2000. Durante esta franja de tiempo, todos los ataques excepto
uno tenían alarmas previas utilizando la metodología descrita arriba.
2.
Para toda la línea de tiempo, y cada
ataque conocido, los 3DMAs por encima de los límites
de control dieron 3 días de aviso para todo intento de ataque en todas las
ocasiones excepto una, que nos dio 7 días de aviso. Técnicas simples de control
de proceso estadístico revelaron un mínimo de 3 días de advertencia para cada ataque.
Aquí hay algunos ejemplos específicos:
o
RPC: La
actividad del RPC fue seguida durante 180 días (el día 1 empieza el 1 de abril
de 2000). Entre los días 61 y 68, el 3DMA mostró una ejecución, o un movimiento
ascendente en la carta, indicando una actividad anormal. El día 68, se apreció un
intento de acceso usando el rpc.statd. De nuevo, el día
153, y 170, se notó una anormal cantidad de actividad en el puerto 111, seguida
de una intrusión con éxito en el día 177, utilizando un desbordamiento del rpc.statd. Debajo hay una representación gráfica de este
modelo, el eje X son los días del ejemplo, el eje Y es la frecuencia.
o
DNS/named: Los días 81-85 mostraron una actividad inusual por
encima de los límites de control, con solicitudes al servicio named. El día 85, el servicio named
fue atacado con éxito.
Validación mediante análisis de regresión y ARIMA:
La metodología del segundo se
utilizó para validar los resultados del primero. Sentimos que podría ser un
ejercicio útil echar un vistazo a la relación entre las violaciones de las
reglas del RPC del snort y el número de días hasta
que el sistema era comprometido. Mientras un modelo de series de tiempo más
apropiado estaba en marcha, se podía hacer una aproximación rápida y preliminar utilizando
un modelo de regresión predictiva analizando la
frecuencia del número de violaciones de las reglas de rpc
en los días antes de que el sistema fuera comprometido.
La figura 1 debajo revela
el número de días predicho hasta que el sistema es comprometido con el rpc.statd de este modelo. El eje horizontal representa la
fecha, en días durante el tiempo de la muestra, desde 1-180. Los picos hacia
abajo antes de el compromiso ocurrieron en el día 68.
De nuevo, se aprecian tres “picos amenaza” negativos cerca del final del
gráfico antes de que el sistema fuera comprometido por el mismo ataque rpc en el día 177. Aún no hemos confirmado qué representan los
picos positivos, un análisis preliminar sugiere que son “momentos tranquilos” o
períodos de relativa seguridad.
Aunque se debería advertir
que existen algunos problemas estadísticos con el modelo - incluyendo una importante
estadística de Durbin-Watson
que sugiere que hay algunas auto correlaciones serias que
necesitan ser eliminadas del modelo - el examen preliminar sugiere que hay métodos
para alertar de un inminente ataque varios días antes de que tenga lugar. Un análisis
de series de tiempo más sofisticado de estos datos en conjunción con otros
datos podría ser lo más útil para el soporte en el futuro de la idea de la detección
temprana.
Examinando Características de Señales de un Pre-Ataque
usando un modelo ARIMA
Otra área de investigación
es discernir entre las características de ciertos tipos de ataques y sondeos.
Este segundo ejemplo viene de uno de los Equipos de Honeynet “Escaneo del Mes”. El gráfico debajo representa el número de
escaneo de puertos durante 30 días. Una de las
preguntas que nos gustaría contestar es, "cuál es el período de tiempo típico
en el que un ataque, sondeos posteriores o un cese de actividad pueden ser
observados" para varios comportamientos de sondeo y pre-ataque.
En este caso, un modelo simple de series de tiempo ARIMA (Auto Regresión
Integrada con Promedios Móviles) fue ajustado a los datos. ARIMA es un modelo básico
utilizado en análisis de series de tiempo para observar los datos recogidos
durante un período de tiempo. El gráfico debajo demuestra la frecuencia de escaneos del mes de noviembre.
Los
resultados del modelo ARIMA aparecen en la tabla debajo. Esta tabla sugiere que
una sesión de escaneo de puertos puede llevar hasta
tres días antes que termine y otra fase de pre-ataque,
el ataque o un cese de “hostilidades” ocurra. También sugiere que los 3 días de
promedio móvil propuesto por nuestro equipo de estadísticos puede ser demasiado
grande, y un promedio móvil de 2 días puede describir mejor al menos este tipo
de ataque.
Para ambos
análisis se debe apuntar que fueron dirigidos por un conjunto muy limitado y
pequeño de datos. Sin embargo, esto indica
que análisis de grupos mayores de datos podrían en realidad producir resultados
no tan triviales para ayudar a encontrar modelos estadísticos que pudieran
crear “alertas de amenaza” de ataques previos al ataque en sí. Para probar más adelante
estas teorías, nos proponemos desarrollar lo siguiente:
- Necesitamos adquirir más y
mejores datos para tener una buena idea de los patrones y las relaciones
- Más variables, añadir otros
tipos de capturas del snort nos ayudará a
comprender mejor los procesos que ocurren.
- Técnicas de análisis diferentes
como el Análisis Histórico de Eventos.
Animamos a la comunidad de
seguridad a probar y desarrollar estas teorías y a realizar sus propios análisis
estadísticos. Estamos especialmente interesados en cualquier otro tipo de análisis
o en encontrar gente que pueda encontrarlos. Lo que hemos presentado aquí no es
un análisis exhaustivo, más bien una investigación preliminar. Enlazados abajo
están los datos recogidos y usados por el Honeynet Project. Estos datos
representan once meses de datos, recogidos desde abril de 2000 hasta febrero de
2001. honeynet_data.tar.gz
Conclusión
Durante once meses el Honeynet Project ha procurado recoger todos los sondeos,
ataques y exploits enviados contra él. Estos datos
fueron luego analizados con dos finalidades. La primera era demostrar lo activa
que la comunidad blackhat puede ser. Las cifras
demuestran las amenazas hostiles que todos afrontamos. Recuerda, el Honeynet utilizado
para recoger esta información no tenía sistemas de producción de valor, ni fue
publicado ni usado para atraer atacantes. Si tu organización tiene algún valor,
o si ha sido publicada de cualquier forma, estás expuesto a una amenaza aún
mayor. La segunda era comprobar la teoría de la Detección Temprana y la Predicción. Creemos que hay la predicción de
ataques tiene un gran potencial. Las Honeynets no son
de ninguna manera el único método para recoger dichos datos, no obstante tienen
la ventaja de reducir tanto falsos positivos como falsos negativos. Armados con
la recolección de datos y análisis estadísticos, es posible que las organizaciones
estén más preparadas contra la comunidad blackhat.
