Emilio José Mira Alfaro
emial@alumni.uv.es
13 de Enero de 2002
Un Sistema de Detección de Intrusos o IDS (Intrusion Detection System) es una herramienta de seguridad encargada de monitorizar los eventos que ocurren en un sistema informático en busca de intentos de intrusión.
Definimos intento de intrusión como cualquier intento de comprometer la confidencialidad, integridad o disponibilidad de un sistema informático, o de eludir los mecanismos de seguridad de éste.
Las intrusiones se pueden producir de varias formas:
La detección de intrusiones permite a las organizaciones proteger sus sistemas de las amenazas que aparecen al incrementar la conectividad entre las redes. Los ataques de DoS (denegación de servicio) en febrero de 2000 ante Amazon.com y E-Bay entre otras, revelaron la necesidad de herramientas efectivas para la detección de intrusos, especialmente en empresas on-line públicas y de comercio electrónico.
Se estima que el 85% de los ataques que se producen en una red vienen desde dentro. El resto son ataques externos en forma de ataques DoS o intentos de penetración en la infraestructura de la red. Los IDS han ganado aceptación como una adición necesaria para toda infraestructura de seguridad de la organización. Hay varias razones para adquirir y usar un IDS:
Al incrementar la posibilidad de descubrir y castigar a los atacantes, el comportamiento de algunos cambiará de forma que muchos ataques no llegarán a producirse. Esto también puede jugar en nuestra contra, puesto que la presencia de un sistema de seguridad sofisticado puede hacer crecer la curiosidad del atacante por ver qué es eso que tanto intentamos proteger.
Los atacantes pueden conseguir accesos no autorizados a muchos sistemas cuando vulnerabilidades conocidas no son corregidas. Esta corrección no siempre es posible, ya sea por problemas de tiempo por parte del administrador o simplemente por un fallo de configuración. Aunque un IDS NO puede detectar cuando un atacante en un sistema ha tenido éxito explotando un fallo no corregido, sí que podríamos avisar al administrador para que llevara a cabo inmediatamente un backup del sistema y evitar así que se pierda información valiosa.
Cuando un individuo ataca un sistema, lo hace típicamente en fases predecibles. En la primera fase, un atacante hace pruebas y examina el sistema o red en busca de un punto de entrada óptimo. En sistemas o redes que no disponen de un IDS, el atacante es libre de examinar el sistema con un riesgo mínimo de ser detectado. Esto le facilita la búsqueda de un punto débil en nuestra red.
La misma red con un IDS monitorizando sus operaciones le presenta una mayor dificultad. Aunque el atacante puede examinar la red, el IDS observará estas acciones, las identificará como sospechosas, podrá activamente bloquear el acceso del atacante al sistema objetivo y avisará al personal de seguridad de lo ocurrido para que tome las acciones pertinentes.
Cuando se hace un presupuesto para la gestión de seguridad de la red, es necesario conocer cual es el riesgo de la organización a posibles amenazas, la probabilidad de ser atacada o si incluso está siendo atacada.
Un IDS nos puede ayudar a conocer la amenaza desde fuera y dentro de la organización, ayudándonos a hacer decisiones a cerca de los recursos de seguridad que deberemos emplear en nuestra red.
Incluso cuando los IDSs no son capaces de bloquear ataques, pueden recoger información detallada y relevante sobre éstos. Esta información puede, bajo ciertas circunstancias, ser utilizada como pruebas en actuaciones legales. También se puede usar esta información para detectar fallos en la configuración de seguridad o en la política de seguridad de la organización.
Existen varias propuestas sobra la arquitectura de los IDSs, pero ninguna de ellas se usa mayoritariamente. Esto provoca que los productos de los fabricantes que trabajan con distinta arquitectura puedan difícilmente interoperar entre sí.
El Marco de Detección de Intrusos Común fue un primer intento de estandarización de la arquitectura de un IDS. No logró su aceptación como estándar, pero estableció un modelo y un vocabulario para discutir sobre las intrusiones. Mucha gente que trabajó en el esfuerzo original está fuertemente involucrada en los esfuerzos del Grupo de Trabajo de Detección de Intrusos (Intrusion Detection Working Group, IDWG) del Internet Engineering Task Force (IETF).
Los cuatro tipos básicos de componentes de un IDS que contempla el CIDF son los siguientes:
Estos componentes necesitan un lenguaje para comunicarse. Aparece entonces CISL (Common Intrusion Specification Language). Los diseñadores de CISL pensaron que este lenguaje debería ser capaz al menos de transmitir los siguientes tipos de información:
A diferencia de CIDF/CISL, el CERT australiano desarrolló un sistema de trabajo sencillo que permitía que se analizara y se agregara un informe en una base de datos con tan solo un par de líneas de Perl. La forma de una detección podría ser la siguiente:
Source: 216.36.45.84
Ports: tcp 111
Incident type: Network_scan
re-distribute: yes
timezone: GMT + 1300
reply: no
Time: Web 15 Mar 2000 at 14:01 (UTC)Este sistema tiene una alta interoperabilidad y es muy sencillo de construir y analizar. El problema es que los analistas a menudo necesitan un gran nivel de detalle (una fidelidad alta) acerca del evento (por ejemplo, para análisis forense), y en este modelo, toda esa información se perdería.
Por su parte, el IETF ha creado un grupo de trabajo llamado IDWG para conseguir la interoperabilidad de diferentes sistemas de IDS estandarizando el formato y semántica de los mensajes que se intercambiarán en dispositivos de diversos fabricantes
En estos momentos existen tres borradores esperando a ser aceptados como RFC (http://www.ietf.org/ids.by.wg/idwg.html).
Existen varias clasificaciones posibles de los IDSs dependiendo de la característica en la que nos fijemos. Las veremos a continuación:
Existen varias fuentes por las que un IDS puede tomar eventos. Algunos IDSs analizan paquetes de red, capturados del backbone de la red o de segmentos LAN, mientras que otros IDSs analizan eventos generados por los sistemas operativos o software de aplicación en busca de señales de intrusión.
IDSs basados en red (NIDS)
La mayor parte de los sistemas de detección de intrusos están basados en red. Estos IDSs detectan ataques capturando y analizando paquetes de red. Escuchando en un segmento de red, un NIDS puede monitorizar el trafico de red que afecta a múltiples hosts que están conectados a ese segmento de red, protegiendo así a estos hosts.
Los IDSs basados en red a menudo están formados por un conjunto de sensores localizados en varios puntos de la red. Estos sensores monitorizan el trafico de la red, realizando análisis local de este trafico e informando ataques a la consola de gestión. Como los sensores están limitados a ejecutar el IDS, pueden ser mas fácilmente asegurados ante ataques. Muchos de estos sensores son diseñados para correr en modo oculto, de tal forma que sea más difícil para un atacante determinar su presencia y localización.
Ventajas:
Desventajas:
Los HIDS fueron el primer tipo de IDSs desarrollados e implementados. Operan sobre la información recogida desde dentro de una computadora, como pueda ser los ficheros de auditoría del sistema operativo. Esto permite que el IDS analice las actividades que se producen con una gran precisión, determinando exactamente qué procesos y usuarios están involucrados en un ataque particular dentro del sistema operativo. A diferencia de los NIDSs, los HIDSs pueden ver el resultado de un intento de ataque, al igual que pueden acceder directamente y monitorizar los ficheros de datos y procesos del sistema atacado.
Ventajas:
Desventajas:
Hay dos acercamientos al análisis de eventos para la detección de ataques: detección de abusos y detección de anomalías. La detección de abusos es la técnica usada por la mayoría de sistemas comerciales. La detección de anomalías, en la que el análisis busca patrones anormales de actividad, ha sido y continua siendo objeto de investigación. La detección de anomalías es usada de forma limitada por un pequeño número de IDSs.
Los detectores de abusos analizan la actividad del sistema buscando eventos que coincidan con un patrón predefinido o firma que describe un ataque conocido.
Ventajas:
Desventajas:
La detección de anomalías se centra en identificar comportamientos inusuales en un host o una red. Funcionan asumiendo que los ataques son diferentes a la actividad normal. Los detectores de anomalías construyen perfiles representando el comportamiento normal de los usuarios, hosts o conexiones de red. Estos perfiles son construidos de datos históricos recogidos durante el periodo normal de operación. Los detectores recogen los datos de los eventos y usan una variedad de medidas para determinar cuando la actividad monitorizada se desavía de la actividad normal.
Las medidas y técnicas usadas en la detección de anomalías incluyen:
Ventajas:
Desventajas:
Una vez se ha producido un análisis de los eventos y hemos detectado un ataque, el IDS reacciona. Las repuestas las podemos agrupar en dos tipos: pasivas y activas. Las pasivas envían informes a humanos para que sean éstos los encargados de tomar acciones al respecto. Las activas lanzan automáticamente respuestas a dichos ataques.
Las respuestas activas son acciones automáticas que se toman cuando ciertos tipos de intrusiones son detectados. Podemos estableces dos categorías distintas:
En este tipo de respuestas se notifica al analista, al usuario del sistema atacado o a algún CERT de lo sucedido. También es posible avisar al administrador del sitio desde el cual se produjo el ataque avisándole de lo ocurrido, pero es posible que el atacante monitorice el correo electrónico de esa organización o que haya usado una IP falsa para su ataque.
La decisión de donde localizar el IDS es algo que se debería hacer antes que cualquier otra cosa. De esta decisión dependerá tanto el equipo que usemos, como el software IDS o la base de datos.
Existen principalmente tres zonas en las que podríamos poner un IDS, tal y como muestra la siguiente figura:
Veamos las características que presenta cada una de estas zonas:
En el caso de tener un IDS escuchando tráfico interno (por ejemplo, colocado entre una VLAN y su router), las falsas alarmas vendrán provocadas en su mayor parte por máquinas internas al acceder a los servidores de nuestra red, por servidores nuestros (DNS sobre todo) y escaneadores de red, por lo que habrá que configurar el IDS para que no sea muy sensible.
¿Qué ocurre ahora si nuestra organización es un ISP?. Es posible que el trafico a la entrada de este ISP sea demasiado grande como para ser técnicamente imposible instalar un único IDS que lo analice todo. Para estos casos es necesario un sistema de detección de intrusos que pueda separar los sensores de la estación de análisis. Una posible solución podría ser la de instalar un sensor en cada uno de los nodos que conectan físicamente con las organizaciones a las que da servicio el ISP, y que estos sensores envíen las alertas generadas a la estación de análisis (ver figura 3).
Esta transmisión debe realizarse de forma segura (y esto quiere decir 'encriptada') y a intervalos regulares, puesto que si el sensor avisa de la alerta nada más ésta se ha producido, un atacante podría monitorizar el tráfico que genera el sensor hacia la estación de análisis y deducir si un ataque ha sido detectado por el sensor o no.
Es un IDS en tiempo real desarrollado por Marty Roesch y disponible bajo GPL. Se puede ejecutar en máquinas UNIX y Windows. Es el número uno en sistemas de detección de intrusos en este momento[1]. Dispone actualmente de 1.200 filtros y de multitud de aplicaciones para el análisis de sus alertas.
En Snort no es posible separar el componente de análisis y los sensores en máquinas distintas. Sí que es posible ejecutar Snort atendiendo a varios interfaces a la vez (cada uno podría estar monitorizando lugares distintos dentro de una red), puesto que se basa en la librería pcap1, pero esto no permite ningún reparto de carga en el proceso de análisis. Es más, ni aun disponiendo de una máquina multiprocesador es posible (en estos momentos) hacer balanceo de carga por CPU. Esto es así porque la opción de compilación multihilo de Snort está todavía en fase de pruebas y no es muy estable, lo que obliga a ejecutar Snort como un proceso monolítico.
Para conocer su funcionamiento y configuración se puede consultar el excelente manual en www.snort.org/docs/SnortUsersManual.pdf
Fue desarrollado como respuesta a los falsos positivos de un IDS anterior, NID. La idea era construir una interfaz rápida que funcionara bien en una DMZ caliente (una DMZ que sufre mucho ataques). La interfaz permitiría al analista evaluar gran cantidad de información de red y decidir de qué eventos informar.
No es en tiempo real. Los diseñadores de Shadow sabían que no iban a estar disponibles para vigilar el sistema de detección de intrusos 7 días a las semana, 24 horas al día. Shadow almacena el tráfico de red en una base de datos y se ejecuta por la noche. Los resultados esperan a que el analista llegue a la mañana siguiente.
Al no ser en tiempo real, es inviable que Shadow analice el contenido de los paquetes, por lo que tan solo se centra en las cabeceras. Esto le hace incapaz de ser útil para análisis forense.
RealSecure es el sistema de detección de intrusos comercial desplegado de forma más generalizada.
Está dividido en dos partes: directores, que se utilizan para tareas administrativas y operativas, y sensores, que son los generadores de eventos. Están disponibles los sensores basados en red y basados en host. Tienen versiones para UNIX y para Windows NT/2000, pero la consola sólo se ejecuta en NT/2000. Tener un sensor y una estación de análisis separados es un arquitectura óptima.
RealSecure utiliza normativas para definir eventos de interés. Estas normativas se configuran en el director de análisis y se descargan desde los sensores. El sensor la toma y la utiliza en la detección de eventos. Si la consola está funcionando los eventos se toman en tiempo real.
Como back-end, RealSecure utiliza una base de datos de Microsoft Access
NetRanger (de Cisco Systems), es un ejemplo de IDS con capacidad de equipo 'R'. Cisco lo llama 'componente de seguridad dinámico'. Podemos configurar el sistema para detectar, informar y responder automáticamente a eventos de interés. Las capacidades de alerta pueden ser beeps, ventanas desplegadas, alertas de busca o e-mails. La respuesta automática incluye la capacidad de reiniciar conexiones o reconfigurar enrutadores.
Los componentes del sistema incluyen sensores, una estación de análisis y equipos R. Estos componentes se comunican mediante un protocolo patentado.
El sensor está diseñado para revisar registros de sistema de routers Cisco (syslogs), además de los datos de paquetes en bruto de la red. Es el sensor IDS disponible comercialmente más competente[1]. Soporta reensamblaje de paquetes, por lo que los ataques que colocan una parte de la cadena en un fragmento y la segunda parte en un segundo fragmento, seguirán siendo detectados. Esta característica de importancia crítica no está disponible en todos los sistemas de detección de intrusos.
Podemos encontrar sensores basados en Pentium, plataformas en rack para líneas de alta velocidad o módulos IDS para Catalyst 6000. El director es un software tanto para UNIX como para Windows.
Ventajas
Como caso práctico veremos la implantación de un NIDS dentro de la Universidad de Valencia, obtendremos algunas alertas y las analizaremos en busca de posibles ataques.
El sistema a utilizar sera un potente PC Linux con dos interfaces Fast Ethernet. Una de estas interfaces la utilizaremos para monitorización y la otra para gestión remota del IDS.
El software empleado sera Snort por ser el más ampliamente utilizado en las organizaciones. También usaremos una base de datos relacional que actuará como back-end del sistema, MySQL, la cual nos permitirá hacer búsquedas complejas de las alertas del Snort. Es posible configurar Snort para otras bases de datos como Oracle o PostgreSQL, pero la elección de MySQL vino dada por la suposición de que la base de datos no tendría muchas entradas, tan solo las provocadas por ataques y algunas falsas alarmas. (MySQL ofrece un mejor rendimiento que PostgreSQL para BBDD pequeñas).
El NIDS se encuentra custodiando la VLAN de farmacia ( VLAN B en la figura 4). Al ser un IDS interno, las falsas alarmas van a ser más numerosas, puesto que el tráfico interno es mayor y más variado que el tráfico de la red con el exterior. Por lo tanto, la modificación de los filtros que vienen por defecto con el software IDS sera en ocasiones necesaria.
El IDS tiene configuradas dos interfaces, la de monitorización y la de gestión. La de monitorización se encuentra en modo promiscuo, lo cual le permitirá escuchar todo el trafico que salga y entre de la VLAN B. No es necesario darle una dirección IP, de esta forma nuestro IDS sera invisible (no contestará a consultas ARP).
La parte sombreada dentro de la elipse es un añadido que hubo que hacer para colocar el IDS en ese lugar. Las VLANs que se encuentran en otros edificios están unidas al conmutador principal por medio de enlaces Gigabit Ethernet de fibra óptica. En ese conmutador principal es posible hacer copia del tráfico de uno o varios interfaces sobre otro cualquiera. De esta forma, podría haber sido posible volcar todo el trafico del interfaz de la VLAN B al interfaz donde se encuentra conectado el interfaz de monitorización del IDS. El problema es que esta interfaz es Fast Ethernet, y el conmutador no permite hacer este volcado de un interfaz GE a otro FE. La solución fue la que aparece en la figura.
Lo que sucede ahora es que estamos limitando la velocidad de 1Gbps FD que tenia antes la VLAN B hacia el exterior a 100Mbps HD, pero ahora nos aseguramos de que el interfaz de monitorización del IDS no va a perder nada de tráfico
La interfaz de gestión se encuentra en la VLAN de servidores y se utilizará para gestión remota del equipo. Para esto es necesario darle una dirección IP válida, lo cual hace ahora que nuestro IDS sea visible. Además, al no disponer de un firewall en la Universidad de Valencia, somos incapaces de controlar desde donde se puede acceder a él desde el exterior. Esto hace que las medidas de seguridad que tengamos que adoptar sean severas, puesto que una intrusión en el propio IDS no solo nos deja indefensos para detectar posibles ataques a nuestra red, sino que le da al intruso una copia de todo el trafico que circula por ella.
Otra posible localización de nuestro IDS sería a la entrada de la Universidad, como se muestra en la siguiente figura.
Esta sería una zona de alto riesgo que, como se vio en el apartado 1.5, provocaría muchas falsas alarmas si la sensibilidad del IDS fuese alta.
Para esta configuración necesitariamos una tarjeta ATM en el IDS y reconfigurar el conmutador ATM de la UV para hacer multipunto los dos circuitos virtuales que hay entre el router de RedIRIS y el de la UV.
Los ejemplos que veremos a continuación son casos reales de alarmas generadas por el IDS monitorizando la VLAN de farmacia. Los filtros del Snort han sido modificados para que ignoren los eventos producidos por escaneadores de red, servidores Web, proxy-cache Web y DNS. Algunas reglas también han sido eliminadas al provocar demasiados falsos positivos ('SCAN Proxy attempt', 'BAD TRAFFIC bad frag bits', 'ICMP Destination Unreachable (Port Unreachable)', 'ICMP Echo Replay (Undefined Code!)'). Por supuesto, antes de eliminar una regla hay que comprobar que la causa de que genere tantas alarmas está justificada.
Existen multitud de entornos gráficos para la visualización de las alertas generadas por Snort, entre los más destacados ACID, IDScenter, Snort Report y Snort Monitor, todos disponibles en la web de Snort [11]. Estos entornos funcionan con PHP, así que se hace necesaria la instalación de un servidor web dentro del IDS, lo cual le da más carga y le resta seguridad. Para evitar esto, la forma en la que accederemos a las alertas generadas por Snort almacenadas en MySQL será por medio de unos scripts en Perl. Estos scripts nos permiten obtener información de una forma más flexible y rápida que los bonitos pero costosos programas PHP.
El script principal es ranking, que nos muestra para cada alerta lo siguiente:
COUNT SIG_ID NUM_SRC NUM_DST SIG_NAME (REF)
------------------------------------------------
585889 17660 981 301 WEB-IIS cmd.exe access
222337 1 130 44 RPC portmap request rstatd (arachnids 10)
77690 12926 4 5 NETBIOS nimda .eml (url www.datafellows.com/v-descs/nimda.shtml)
68499 17661 1025 316 WEB-IIS CodeRed v2 root.exe access
65128 17666 9 4 WEB-IIS multiple decode attempt (cve CAN-2001-0333)
62721 17665 50 10 WEB-IIS scripts access
57057 17662 939 261 WEB-FRONTPAGE /_vti_bin/ access
51818 17689 1 1 EXPLOIT ssh CRC32 overflow NOOP (bugtraq 2347)
34651 44 351 221 MISC Large ICMP Packet (arachnids 246)
16720 275 47 47 INFO msn chat access
4297 131 124 191 SHELLCODE x86 NOOP (arachnids 181)
4114 17672 1 1 NETBIOS nimda .nws (url www.datafellows.com/v-descs/nimda.shtml)
4080 1054 18 27 INFO Possible IRC Access
2807 320 60 17 RPC portmap request mountd (arachnids 13)
1923 4646 162 12 spp_stream4: STEALTH ACTIVITY (Vecna scan) detection
1782 259 206 61 INFO FTP anonymous FTP
966 12 157 2 WEB-MISC count.cgi access (bugtraq 550) (cve CVE-1999-0021)
712 108 55 2 SMTP RCPT TO overflow (cve CAN-2001-0260) (bugtraq 2283)
604 1048 55 12 EXPLOIT ssh CRC32 overflow filler (bugtraq 2347)
543 716 21 28 SCAN nmap TCP (arachnids 28)
380 17686 3 269 spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection
341 1950 26 77 FTP Bad login
309 58 9 60 TELNET Bad Login
254 28 10 160 INFO Napster Client Data
187 200 5 43 Virus - Possible scr Worm
168 306 43 102 DNS named version attempt (arachnids 278)
164 119 34 50 SHELLCODE x86 setuid 0 (arachnids 436)
142 11823 24 11 SHELLCODE x86 unicode NOOP
55 330 4 40 Virus - Possible pif Worm
45 2169 3 3 BAD TRAFFIC same SRC/DST
41 3852 7 1 DNS zone transfer (arachnids 212)
33 4687 4 5 spp_stream4: STEALTH ACTIVITY (FIN scan) detection
30 10670 1 17 Virus - Possible NAVIDAD Worm
26 167 11 1 TCP SYN received
16 8204 3 7 TELNET Bad Login
16 329 3 5 Virus - Possible MyRomeo Worm
16 3981 2 4 Virus - Possible PrettyPark Trojan (MCAFEE 10175)
15 3087 9 7 BAD TRAFFIC udp port 0 traffic
14 667 8 5 spp_stream4: STEALTH ACTIVITY (NULL scan) detection
14 5507 3 11 RPC EXPLOIT statdx (arachnids 442)
14 17687 2 7 FTP CWD / - possible warez site
14 5931 6 4 BAD TRAFFIC tcp port 0 traffic
13 17674 1 1 MISC Tiny Fragments
12 6114 8 4 SCAN FIN (arachnids 27)
12 331 10 8 SHELLCODE x86 setgid 0 (arachnids 284)
9 17659 5 4 spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection
8 17658 4 3 spp_stream4: NMAP FINGERPRINT (stateful) detection
8 17673 7 4 WEB-MISC apache DOS attempt
8 1436 2 2 INFO Napster Client Data
6 5503 2 6 FTP EXPLOIT format string (arachnids 453)
3 17726 1 1 WEB-CGI finger access (arachnids 221) (cve CVE-1999-0612)
3 17695 1 1 EXPLOIT ssh CRC32 overflow (bugtraq 2347) (cve CVE-2001-0144)
3 17677 3 3 SCAN nmap fingerprint attempt (arachnids 05)
3 17685 2 2 ATTACK RESPONSES id check returned root
2 1998 1 1 PORN free XXX
2 17667 2 2 SCAN XMAS (arachnids 144)
2 7979 2 2 SCAN NULL (arachnids 4)
2 3653 1 1 DOS Winnuke attack (bugtraq 2010) (cve CVE-1999-0153)
2 17700 1 1 RSERVICES rsh root (arachnids 389)
1 4292 1 1 Virus - Possible NAIL Worm (MCAFEE 10109)
1 17716 1 1 WEB-MISC BigBrother access
1 17698 1 1 FTP CWD ...
1 17761 1 1 WEB-ATTACKS cc command attempt
1 17693 1 1 SCAN ident version (arachnids 303)
1 17691 1 1 SCAN NMAP XMAS (arachnids 30)
1 17707 1 1 WEB-MISC cat%20 access (cve CVE-1999-0039) (bugtraq 374)
1 17765 1 1 spp_stream4: STEALTH ACTIVITY (Full XMAS scan) detection
Para ver por qué se han producido las alertas es de gran ayuda echar un vistazo a la regla que la define dentro de Snort (ficheros de configuración *.rules). No haremos un análisis detallado de cada alarma, tan solo veremos algunas:
Esta regla salta cuando en el contenido de una sesión TCP aparece la cadena cmd.exe y el destino es un puerto 80.
Snort también nos permite configurarlo de forma que este tipo de reglas (WEB-IIS) solo salten cuando el destino sea uno de nuestros servidores web, por medio de una variable $HTTP_SEVERS que habremos rellenado con todos nuestros servidores web. Esto ralentizará menos el IDS puesto que la regla está más acotada (cuantos menos grados de libertad tenga una regla, más rápida se ejecutará). El problema es que en una organización no siempre es posible llevar la cuenta de todas las máquinas que hay como servidores web (por ejemplo, muchos usuarios instalan en su PC de escritorio Windows 2000 Server sin saber que el IIS estará activo por defecto), por lo que el mejor valor para $HTTP_SERVERS es ANY.
El encontrar cmd.exe en una conexión TCP dirigida al puerto 80 de un servidor web suele significar que el gusano nimda está intentando colarse en ese servidor. El gusano solo compromete sistemas que ejecutan IIS 4.0 e IIS 5.0 en los sistemas operativos Windows NT y Windows 2000.
El gusano envía su código como un requerimiento HTTP. El requerimiento HTTP ejecuta un exploit sobre una vulnerabilidad conocida del IIS, lo cual permite que el gusano se ejecute en el sistema víctima, depositando 3 archivos:
132.248.XXX.XXX - - [18/Sep/2001:10:16:47 -0400] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 287 "-" "-"
132.248.XXX.XXX - - [18/Sep/2001:10:16:48 -0400] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 285 "-" "-"
132.248.XXX.XXX - - [18/Sep/2001:10:16:48 -0400] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 295 "-" "-"
132.248.XXX.XXX - - [18/Sep/2001:10:16:49 -0400] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 295 "-" "-"
132.248.XXX.XXX - - [18/Sep/2001:10:16:49 -0400] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 309 "-" "-"
132.248.XXX.XXX - - [18/Sep/2001:10:16:50 -0400] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 326 "-" "-"
132.248.XXX.XXX - - [18/Sep/2001:10:16:50 -0400] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
El que esta alarma haya saltado casi 600,000 veces significa que este virus está aun muy vivo en nuestra red y/o en Internet. Veamos con el comando shsig los 10 primeros orígenes y destinos de estos ataques:
## WEB-IIS cmd.exe access ## 17660 ##
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN SRC
-----------------------------------------------
280996 415694 698 2001-12-27 00:57:14 2002-01-08 16:35:53 pericles.adeit.uv.es
164308 237721 1083 2001-12-22 04:24:27 2001-12-25 22:25:24 212.146.128.223
53263 76123 417 2001-12-19 10:05:53 2001-12-21 10:38:05 auladeit40.adeit.uv.es
22781 29592 181 2001-12-19 12:49:53 2002-01-07 21:41:03 contab21.admeco.uv.es
19661 25454 147 2002-01-07 15:58:16 2002-01-08 13:10:59 tornasol.electron.uv.es
11957 15948 185 2001-12-19 10:23:22 2002-01-07 09:11:05 galadriel.fbiolo.uv.es
9569 12109 129 2002-01-07 14:53:13 2002-01-09 12:16:22 servuniversia.dise.uv.es
3482 5342 0 2001-12-28 03:23:33 2001-12-28 03:26:22 147.46.67.224
1863 2208 232 2001-12-24 12:52:37 2002-01-08 20:34:13 visionarc.irobot.uv.es
442 526 2 2001-12-20 14:11:15 2001-12-26 07:14:32 c2.sll.se
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN DST
-----------------------------------------------
324331 10 529371 2001-12-19 10:31:01 2002-01-11 04:50:49 vpnserver.ci.uv.es
9285 4659 10924 2001-12-19 10:10:16 2002-01-12 16:58:21 capone.informat.uv.es
6617 9612 7699 2001-12-19 10:32:10 2002-01-12 06:07:18 catafar4b1.ci.uv.es
6063 9944 7074 2001-12-19 10:27:53 2002-01-11 16:31:26 catafar2a.ci.uv.es
5917 9635 6881 2001-12-19 11:21:48 2002-01-11 04:47:18 catafar4a.ci.uv.es
5585 120 6822 2001-12-19 10:54:00 2002-01-09 11:10:53 suelos.bioveg.uv.es
5421 9979 6319 2001-12-19 10:10:46 2002-01-11 04:47:19 catafar4a1.ci.uv.es
5374 895 6381 2001-12-19 10:22:14 2002-01-10 17:09:26 teruca.informat.uv.es
5331 280 59125 2001-12-19 10:44:46 2002-01-12 11:43:04 tapec.informat.uv.es
5320 24221 6220 2001-12-19 10:15:44 2002-01-09 13:10:51 nexus.informat.uv.es
La mayoría de estos orígenes (recordamos que solo aparecen listados los 10 primero) pertenecen a nuestra red, y serán casi con toda seguridad debidos a que el gusano ha infectado esas máquinas.
Es ahora cuando se podrían poner en marcha los dos mecanismos de respuesta vistos en la introducción:
Esta es una alarma provocada por una cadena hexadecimal (90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90) sobre el puerto 22 de una conexión TCP que apareció en un programa liberado en Internet que explotaba una vulnerabilidad en un servidor SSH. Esta ha sido la firma elegida para detectar un ataque de este tipo.
## EXPLOIT ssh CRC32 overflow NOOP ## 17689 ##
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN SRC
-----------------------------------------------
51818 51818 0 2001-12-31 13:38:04 2001-12-31 13:58:42 remote02.sn.com
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN DST
-----------------------------------------------
51818 281 59150 2001-12-31 13:38:04 2001-12-31 13:58:42 tapec.informat.uv.es
Una vez ejecutado shsig, vemos que no tiene mucho sentido este comportamiento tratándose de un exploit. Normalmente, el atacante lanzará el exploit un par de veces para ver si tiene éxito, y de ser así entrará como root. En caso contrario, lo intentaría con otra máquina que escuche en ese puerto.
Lo que puede estar ocurriendo es que, al tratarse de una comunicación encriptada, esta cadena aparezca en dicha comunicación, y el IDS de un falso positivo pensando que ha detectado un ataque.
Aunque esto no es ningún ataque, dada la política de seguridad de la organización este tipo de actividades puede que no estén permitidas [5].
Es muy posible que esta regla de muchos falsos positivos, pero algunas veces también acertará y nos pondrá en la pista de algún ataque.
Esta regla busca el código hexadecimal correspondiente a la llamada al sistema 'setuid 0' en una arquitectura x86, esto es 'b017 cd80'. Esta llamada es ejecutada normalmente por los shellcodes de la mayoría de los exploits, pero su firma es demasiado corta como para asegurar que cada vez que la encontremos en una conexión TCP sea debido a un intento de penetración en un sistema, por lo que provocará muchas falsas alarmas.
Además, al ser un IDS interno que monitoriza una VLAN, podremos tener ataques incluso desde los servidores proxy, como vemos a continuación:
## SHELLCODE x86 setuid 0 ## 119 ##
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN SRC
-----------------------------------------------
75 8521 738 2001-12-03 12:14:03 2002-01-08 20:40:01 proxy2.ci.uv.es
50 10173 32928 2001-12-03 17:27:14 2002-01-07 09:36:32 proxy1.ci.uv.es
2 16 17 2002-01-09 16:43:58 2002-01-09 16:43:58 vicky.irobot.uv.es
2 2 0 2002-01-10 11:17:36 2002-01-10 11:17:39 dsl170.boi.micron.net
2 2208 232 2001-12-17 12:03:12 2001-12-17 12:09:01 visionarc.irobot.uv.es
2 2 0 2002-01-09 13:08:59 2002-01-09 13:09:03 h24-65-99-127.ed.shawcable.net
1 1 0 2001-12-18 12:42:59 2001-12-18 12:42:59 pD951E322.dip.t-dialin.net
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN DST
-----------------------------------------------
29 1544 1425 2001-12-03 13:48:22 2002-01-09 13:09:03 chusta.ffarma.uv.es
15 998 3099 2001-12-03 13:52:43 2002-01-09 13:28:39 bigelnota.farmatec.uv.es
15 92 3121 2001-12-03 14:42:03 2001-12-12 14:53:11 eulogiov.microb.uv.es
15 950 792 2001-12-03 17:27:14 2002-01-10 11:17:39 adrfarma2.ffarma.uv.es
11 176 85 2001-12-03 19:22:50 2001-12-20 17:00:44 jurasic.farmac.uv.es
6 0 95 2001-12-03 12:14:03 2001-12-12 21:07:57 vgcasabo.farmatec.uv.es
6 7283 2199 2001-12-14 20:49:30 2002-01-12 03:31:13 linea900.farmatec.uv.es
6 284 1466 2001-12-03 18:25:44 2001-12-21 07:03:11 tcrom.farmatec.uv.es
4 179 577 2001-12-03 13:52:09 2001-12-27 11:46:15 secfarma.farmac.uv.es
4 69 134 2001-12-14 15:43:39 2001-12-14 15:49:19 godzilla.ffarma.uv.es
Pero también vemos que hay otras IPs de fuera que han hecho saltar la alarma, podemos prestarle más atención a esas. Por ejemplo, vamos a fijarnos en h24-65-99-127.ed.shawcable.net
Con el comando shsigip podemos concentrarnos en una firma y una IP. Obtenemos lo siguiente:
## SHELLCODE x86 setuid 0 ## 119 ##
SOURCE
---------
2002-01-09 13:08:59 h24-65-99-127.ed.shawcable.net -> chusta.ffarma.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1500 ID:48966 Flags:0x0 Offset:0 TTL:111 Proto:6 Cksum:10860
[TCP] SPort:1214, DPort:1097 Seq:113522033 Ack:113078 Offset:5 Res:0 Flags:0x10 Win:8437 Cksum:35362 Urp:0 Res:0
2002-01-09 13:09:03 h24-65-99-127.ed.shawcable.net -> chusta.ffarma.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1500 ID:24647 Flags:0x0 Offset:0 TTL:111 Proto:6 Cksum:35179
[TCP] SPort:1214, DPort:1097 Seq:113522033 Ack:113078 Offset:5 Res:0 Flags:0x10 Win:8437 Cksum:35362 Urp:0 Res:0
Podemos ver la fecha, la hora, y el tipo de paquete que se envió. Era un segmento TCP desde el puerto 1214 dirigido al 1097. No parece que hayan servidores importantes en este último puerto, así que puede tratarse de un falso positivo.
Las transferencias de zona solo deberían tener como origen servidores DNS secundarios. Cuando aparece una transferencia de zona iniciada desde fuera de la organización, es muy probable que alguien esté reuniendo información para llevar a cabo un ataque sobre nuestra red.
En este caso, qfgate.quifis.uv.es es un servidor DNS secundario de la UV que está mal configurado y acepta peticiones de transferencia de zona hacia máquinas que no son DNS de la UV.
## DNS zone transfer ## 3852 ##
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN SRC
-----------------------------------------------
25 2775 8658 2001-12-21 09:34:58 2001-12-21 09:48:10 slabii.informat.uv.es
4 4 0 2001-12-11 12:51:37 2001-12-27 16:04:24 hostcount.ripe.net
2 8 2 2001-12-05 00:48:23 2001-12-05 00:48:23 194.85.9.53
2 2 0 2001-12-20 11:11:54 2001-12-20 11:11:54 acfpp06.acfp.upv.es
2 2 0 2001-12-29 01:03:35 2001-12-29 01:03:35 ineco.nic.es
2 2 0 2002-01-02 18:26:57 2002-01-02 18:26:57 twmaine-208-5-183-250.twmaine.com
2 2 0 2002-01-12 07:20:45 2002-01-12 07:20:45 ariston.netcraft.com
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN DST
-----------------------------------------------
43 2389 174130 2001-12-05 00:48:23 2002-01-12 07:20:45 qfgate.quifis.uv.es
Lo que podríamos hacer ahora es, con el comando shsip, ver si alguna de estas IPs ha estado involucrada en otros ataques. Al mirar sobre 194.85.9.53 obtenemos lo siguiente:
SOURCE
NUM SIG_ID SIG_NAME
------------
5 5503 FTP EXPLOIT format string
2001-12-08 08:11:48 194.85.9.53 -> apotkpr.ffarma.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:64 ID:2978 Flags:0 Offset:0 TTL:47 Proto:6 Cksum:54106
[TCP] SPort:3086, DPort:21 Seq:2147483647 Ack:2147483647 Offset:5 Res:0 Flags:0x18 Win:32120 Cksum:63768 Urp:0 Res:0
2001-12-08 09:33:37 194.85.9.53 -> aficio2.informat.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:76 ID:38242 Flags:0 Offset:0 TTL:47 Proto:6 Cksum:17912
[TCP] SPort:2184, DPort:21 Seq:618981048 Ack:2110736262 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:36706 Urp:0 Res:0
2001-12-08 09:34:25 194.85.9.53 -> nexus.informat.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:76 ID:38628 Flags:0 Offset:0 TTL:47 Proto:6 Cksum:17462
[TCP] SPort:2254, DPort:21 Seq:669818701 Ack:1998022812 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:7593 Urp:0 Res:0
2001-12-08 09:34:58 194.85.9.53 -> teruca.informat.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:76 ID:38828 Flags:0 Offset:0 TTL:47 Proto:6 Cksum:17216
[TCP] SPort:2304, DPort:21 Seq:697739214 Ack:2147483647 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:14328 Urp:0 Res:0
2001-12-08 11:37:09 194.85.9.53 -> capone.informat.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:76 ID:12685 Flags:0 Offset:0 TTL:47 Proto:6 Cksum:43730
[TCP] SPort:4158, DPort:21 Seq:2147483647 Ack:2147483647 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:30413 Urp:0 Res:0
2 3852 DNS zone transfer
2001-12-05 00:48:23 194.85.9.53 -> qfgate.quifis.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:75 ID:52910 Flags:0 Offset:0 TTL:47 Proto:6 Cksum:41847
[TCP] SPort:3657, DPort:53 Seq:2147483647 Ack:1718339697 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:52791 Urp:0 Res:0
2001-12-05 00:48:23 194.85.9.53 -> qfgate.quifis.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:75 ID:52910 Flags:0 Offset:0 TTL:46 Proto:6 Cksum:42103
[TCP] SPort:3657, DPort:53 Seq:2147483647 Ack:1718339697 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:52791 Urp:0 Res:0
1 44 MISC Large ICMP Packet
2001-12-08 09:34:08 194.85.9.53 -> flop.informat.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:1500 ID:38478 Flags:0 Offset:0 TTL:238 Proto:1 Cksum:49236
[ICMP] Type:0, Code:0 Cksum:34386 ID:39612 Seq:57072
DESTINATION
NUM SIG_ID SIG_NAME
------------
2 1950 FTP Bad login
2001-12-08 09:33:45 wooster.informat.uv.es -> 194.85.9.53
[IP] Ver:4 HLen:5 Tos:16 Len:74 ID:55970 Flags:0 Offset:0 TTL:64 Proto:6 Cksum:61379
[TCP] SPort:21, DPort:2191 Seq:1424374098 Ack:623887842 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:11079 Urp:0 Res:0
2001-12-08 09:34:19 tapec.informat.uv.es -> 194.85.9.53
[IP] Ver:4 HLen:5 Tos:16 Len:74 ID:65510 Flags:0 Offset:0 TTL:64 Proto:6 Cksum:51802
[TCP] SPort:21, DPort:2232 Seq:991799545 Ack:652061349 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:33904 Urp:0 Res:0
Esta IP se ha hecho con la lista de IPs-nombres de la UV desde un DNS secundario, y a los 3 días ha lanzado exploits FTP sobre algunas máquinas. También ha intentado entrar en algunos servidores FTP con un login incorrecto.
No podemos saber si los ataques exploit tuvieron éxito, por lo que deberíamos informar al administrador de estas máquinas de que hubo un intento de penetrar en ellas.
Si tenemos curiosidad, podriamos tratar de averiguar de donde es esta IP, aunque debemos saber que el atacante puede estar manipulando su IP origen. Para ello, podemos consultar las BBDD Whois existentes, que son las siguientes:
inetnum: 194.85.8.0 - 194.85.9.255
netname: SIOBC
descr: Shemyakin-Ovchinnikov Institute of Bioorganic Chemistry
descr: Russian Academy of Sciences
descr: Moscow
country: RU
admin-c: IVM11-RIPE
tech-c: DEN2-RIPE
rev-srv: wowa.siobc.ras.ru
rev-srv: nss.ras.ru
status: ASSIGNED PI
notify: noc@nc.ras.ru
notify: root@wowa.siobc.ras.ru
mnt-by: AS3058-MNT
changed: eugene@nc.ras.ru 20010103
source: RIPE
Existen herramientas gráficas que nos permiten ver la ruta geográfica que atravesamos para llegar a una IP destino. Un ejemplo puede ser VisualRoute, de Visualware (www.visualware.com/visualroute/index.html). Probamos esta aplicación para la IP 194.85.9.53 y obtenemos lo siguiente:
Vemos que como punto inicial en España aparece 'El Puerto de Santa Maria'. Esto es así porque el Applet en Java que se descarga en nuestro navegador está configurado para que el punto de origen sea éste, puesto que el servidor VisualRoute al que hemos accedido se encuentra ahí.
Después de haber detectado el ataque y haber obtenido información del atacante, podríamos dar cuenta de lo ocurrido a nuestro CERT. En el caso de la UV avisariamos a IRIS-CERT (de RedIRIS), miembro del FIRST (Forum of Incident Response and Security Teams, www.first.org) desde 1997.
Sobre qué hacer cuando detectamos una ataque existen obras completas. Ver [8]
rpc.statd es un servidor RPC que implementa el protocolo NSM (Network Status Monitor). Se utiliza para monitorizar clientes y servidores NFS. En versiones antiguas este servidor tiene una vulnerabilidad que puede ser explotada remotamente. Veamos las alarmas que ha generado el IDS con respecto a esta firma:
## RPC EXPLOIT statdx ## 5507 ##
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN SRC
------------------------------------
7 22 0 2001-12-08 08:39:45 2001-12-08 08:42:01 61.182.50.241
6 20 0 2001-12-26 07:53:22 2001-12-26 07:53:40 caetano.empresa.net
1 7 0 2001-12-26 09:27:31 2001-12-26 09:27:31 65.107.106.51
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN DST
------------------------------------
2 365 340 2001-12-08 08:39:48 2001-12-26 07:53:26 bugs.informat.uv.es
2 39 45 2001-12-08 08:39:45 2001-12-26 07:53:22 iris.quiorg.uv.es
2 2389 174287 2001-12-08 08:41:12 2001-12-08 08:41:12 qfgate.quifis.uv.es
1 6 33 2001-12-26 09:27:31 2001-12-26 09:27:31 crean.red.uv.es
1 0 22 2001-12-26 07:53:40 2001-12-26 07:53:40 wild.red.uv.es
1 84 4647 2001-12-26 07:53:27 2001-12-26 07:53:27 marvin.informat.uv.es
1 1326 5619 2001-12-26 07:53:27 2001-12-26 07:53:27 taz.informat.uv.es
1 44 7158 2001-12-26 07:53:27 2001-12-26 07:53:27 tro.informat.uv.es
1 4199 22 2001-12-08 08:39:50 2001-12-08 08:39:50 crac.informat.uv.es
1 0 13 2001-12-08 08:42:00 2001-12-08 08:42:00 hussey.red.uv.es
La IP 61.182.50.241 ha generado 7 alarmas en un periodo de algo más de 2 minutos y aparece como origen de 22 alarmas en total. Vamos a ver estas alarmas con un poco más de detalle:
SOURCE
NUM SIG_ID SIG_NAME
------------
14 1 RPC portmap request rstatd
7 5507 RPC EXPLOIT statdx
1 44 MISC Large ICMP Packet
DESTINATION
NUM SIG_ID SIG_NAME
------------
Vemos como además de lanzar exploits, ha emitido peticiones al servidor rpc.statd, seguramente para comprobar si se encontraba activo. Veamos con más detalle estas alarmas y nos fijaremos en las IPs atacadas y en el orden temporal de los ataques:
SOURCE
NUM SIG_ID SIG_NAME
------------
14 1 RPC portmap request rstatd
2001-12-08 08:39:44 61.182.50.241 -> iris.quiorg.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:21911 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:10116
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:47 61.182.50.241 -> slabii.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:22917 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:8114
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:48 61.182.50.241 -> sdisco.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:22942 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:8088
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:48 61.182.50.241 -> bugs.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:22950 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:8065
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:49 61.182.50.241 -> slopez.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:22965 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:8049
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:49 61.182.50.241 -> bunny.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:22968 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:8044
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:49 61.182.50.241 -> crac.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:22971 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:7833
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:41:12 61.182.50.241 -> qfgate.quifis.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:54632 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:14765
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:41:12 61.182.50.241 -> qfgate.quifis.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:54632 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:14765
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:41:22 61.182.50.241 -> neron.ci.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:57704 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:9185
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:41:22 61.182.50.241 -> neron.ci.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:57704 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:9185
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:42:00 61.182.50.241 -> hussey.red.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:7566 Flags:0 Offset:0 TTL:44 Proto:17 Cksum:46393
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:42:01 61.182.50.241 -> macklin.red.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:7578 Flags:0 Offset:0 TTL:44 Proto:17 Cksum:46148
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:42:23 61.182.50.241 -> efcanon.ecofin.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:84 ID:15554 Flags:0 Offset:0 TTL:44 Proto:17 Cksum:30839
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
7 5507 RPC EXPLOIT statdx
2001-12-08 08:39:45 61.182.50.241 -> iris.quiorg.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1104 ID:21912 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:9095
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:48 61.182.50.241 -> bugs.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1104 ID:22962 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:7033
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:39:50 61.182.50.241 -> crac.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1104 ID:22973 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:6811
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:41:12 61.182.50.241 -> qfgate.quifis.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1104 ID:54670 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:13707
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:41:12 61.182.50.241 -> qfgate.quifis.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1104 ID:54670 Flags:0 Offset:0 TTL:45 Proto:17 Cksum:13707
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:42:00 61.182.50.241 -> hussey.red.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1104 ID:7569 Flags:0 Offset:0 TTL:44 Proto:17 Cksum:45370
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
2001-12-08 08:42:01 61.182.50.241 -> macklin.red.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1104 ID:7581 Flags:0 Offset:0 TTL:44 Proto:17 Cksum:45125
[UDP] Sport:0 Dport:0 Len:0 Cksum:0
1 44 MISC Large ICMP Packet
2001-12-08 08:39:47 61.182.50.241 -> flop.informat.uv.es
[IP] Ver:4 HLen:5 Tos:0 Len:1500 ID:22928 Flags:0 Offset:0 TTL:236 Proto:1 Cksum:23062
[ICMP] Type:0, Code:0 Cksum:34386 ID:39612 Seq:57072
Efectivamente se han producido ataques a máquinas que estaban ejecutando este servidor RPC. Vemos como antes de ejecutar el exploit, se ha comprobado que la IP objetivo estaba ejecutando el rpc.statd. También vemos que esto ha sido ejecutado de forma automática (mediante un script, por ejemplo), puesto que la temporización entre los ataques es a veces de 1 segundo y entre las consultas a veces menor.
Es posible que este ataque compruebe primero que la estación tiene servicios RPC corriendo, y de ser así pase entonces a buscar el rpc.statd. Esa puede ser la causa por la que el tiempo transcurrido entre consultas sea un poco desigual.
A modo de curiosidad vemos que esta IP pertenece a algún lugar de China:
Es posible que el mismo programa que uso la IP 61.182.50.241 fuese usado también por caetano.empresa.net y por 65.107.106.51, puesto que los patrones de alerta son los mismos:
DESTINATION
NUM SIG_ID SIG_NAME
------------
caetano.empresa.net
SOURCE
NUM SIG_ID SIG_NAME
------------
13 1 RPC portmap request rstatd
6 5507 RPC EXPLOIT statdx
1 44 MISC Large ICMP Packet
DESTINATION
NUM SIG_ID SIG_NAME
------------
SOURCE
NUM SIG_ID SIG_NAME
------------
5 1 RPC portmap request rstatd
1 44 MISC Large ICMP Packet
1 5507 RPC EXPLOIT statdx
DESTINATION
NUM SIG_ID SIG_NAME
------------
Este ataque lo habiamos visto antes, pero lo derivamos de una petición de transferencia de zona a un DNS secundario de nuestra red. Buscando de forma más general en esta firma encontramos dos IPs, la de Rusia y otra nueva, la 134.208.23.118:
FTP EXPLOIT format string ## 5503 ##
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN SRC
-----------------------------------------------
5 8 2 2001-12-08 08:11:48 2001-12-08 11:37:09 194.85.9.53
1 3 0 2002-01-04 11:22:35 2002-01-04 11:22:35 134.208.23.118
COUNT TOT_SRC TOT_DST TIME_INI TIME_FIN DST
-----------------------------------------------
1 2329 10 2001-12-08 08:11:48 2001-12-08 08:11:48 apotkpr.ffarma.uv.es
1 19 5255 2001-12-08 09:33:37 2001-12-08 09:33:37 aficio2.informat.uv.es
1 24221 6222 2001-12-08 09:34:25 2001-12-08 09:34:25 nexus.informat.uv.es
1 895 6382 2001-12-08 09:34:58 2001-12-08 09:34:58 teruca.informat.uv.es
1 4659 11059 2001-12-08 11:37:09 2001-12-08 11:37:09 capone.informat.uv.es
1 27 1038 2002-01-04 11:22:35 2002-01-04 11:22:35 luciano.informat.uv.es
Esta nueva IP aparece una sola vez dentro de esta firma, pero en total aparece 3 veces como origen de ataques. Miremos en que ataques está involucrada:
SOURCE
NUM SIG_ID SIG_NAME
------------
2 44 MISC Large ICMP Packet
2002-01-04 11:22:26 134.208.23.118 -> dmcm.farmac.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:1500 ID:55161 Flags:0 Offset:0 TTL:235 Proto:1 Cksum:46188
[ICMP] Type:0, Code:0 Cksum:34386 ID:39612 Seq:57072
2002-01-04 11:22:32 134.208.23.118 -> flop.informat.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:1500 ID:58015 Flags:0 Offset:0 TTL:235 Proto:1 Cksum:42055
[ICMP] Type:0, Code:0 Cksum:34386 ID:39612 Seq:57072
1 5503 FTP EXPLOIT format string
2002-01-04 11:22:35 134.208.23.118 -> luciano.informat.uv.es
[IP] Ver:4 HLen:5 Tos:32 Len:76 ID:58038 Flags:0 Offset:0 TTL:44 Proto:6 Cksum:10465
[TCP] SPort:2865, DPort:21 Seq:2147483647 Ack:975696626 Offset:8 Res:0 Flags:0x18 Win:32120 Cksum:15047 Urp:0 Res:0
DESTINATION
NUM SIG_ID SIG_NAME
------------
Las dos primeras alertas vienen dadas por reglas que detectan paquetes sospechosos, como por ejemplo un paquete ICMP de mas de 800 bytes de carga útil. No está muy claro a qué se deben estos paquetes y deberían ser objeto de un estudio posterior, puesto que son paquetes ICMP Echo reply que van de 134.208.23.118 hacia la IP atacada. Vemos también que aparecen varios segundos antes del ataque exploit al servidor FTP.
De nuevo, utilizamos VisualRoute para ver de donde proviene el ataque y vemos que viene de Taiwan:
Para finalizar el caso práctico veremos algunos intentos de recogida de información, que aunque en sí no son ataques, sí que son pruebas que indican que alguien está curioseando en nuestra red no sabemos con qué intenciones.
Muchos escaneadores de puertos (nmap por excelencia - www.insecure.org/nmap/) utilizan técnicas muy variadas para intentar pasar desapercibidos ante firewalls o IDSs. Las técnicas más utilizadas son las siguientes:
Vemos como Snort (y en particular su preprocesador de flujo TCP spp_stream4), es capaz de detectar estos intentos de recogida de información.
Los IDSs son cada vez más necesarios conforme aumenta el número de incidentes en Internet. Son de gran ayuda para los administradores de una red, trabajando en conjunto con otras herramientas de seguridad, como los firewalls y analizadores de red. La información que dan nos ayuda a determinar los abusos que se producen en la red, su naturaleza y sus fuentes. No sorprende que las ventas de IDSs sigan subiendo y puedan llegar al millón de euros en los próximos dos años.
Tanto si un IDS usa detección de firmas o detección de anomalías, si usa métodos de reacción activos o pasivos, cae en una de estas dos categorías: basado en red (NIDS) o basado en host (HIDS), cada uno con sus ventajas e inconvenientes. Como solución general, es conveniente tener uno (o varios colocados adecuadamente) NIDS a la entrada y HIDS en los servidores principales (web, correo, FTP, ...).
Pero la forma de atacar no es, generalmente, la de atacar a los servidores más importantes de nuestra red, sino que consiste en hacer un barrido de nuestra red para ver qué máquinas están corriendo un servicio para el cual los atacantes tienen un exploit. Este barrido se puede evitar mediante un firewall. Así, tan solo tendriamos que preocuparnos de los hosts accesibles desde fuera y correr en ellos un IDS, aunque, como hemos visto, esto puede degradar su rendimiento.
En cualquier caso, se hace necesario redactar la política de seguridad de la organización. Esta política, entre otras cosas, dictará al firewall lo que debe dejar pasar y lo que no, y le dirá al IDS de qué nos tiene que avisar.
El proceso de análisis es costoso y dedicado. El IDS guarda las huellas dejadas por los intrusos en sus ataques y somos nosotros los que debemos buscarlas e interpretarlas. Para ello, cualquier herramienta sera de gran ayuda: BBDD relacionales, entornos gráficos y automatizados, etc.
Por último, recordar que un IDS no sabe si el ataque ha tenido éxito o no. Se hacen necesarios métodos de respuesta automáticos o manuales para avisar a los administradores de los sistemas atacados de lo que ha ocurrido.
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.47)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir5252tdyPmz/lyx_tmpbuf5252fD6NGb/IDS.tex
The translation was initiated by on 2002-03-03