Conoce a tu enemigo:
Identificación pasiva

Identificando máquinas remotas, sin que se enteren

Revisión de la traducción al castellano del texto: Know Your Enemy: Passive Fingerprinting Identifying remote hosts, without them knowing. Disponible en
Honeynet Project
http://www.honeynet.org/
Última modificación: 4 de marzo, 2002
 

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"

Uno de los desafíos de la seguridad de redes es aprender acerca de los malhechores. Para comprender las amenazas a tu red y protegerte mejor contra ellas, tienes que conocer a tu enemigo. La identificación pasiva es un método para saber más sobre el enemigo sin que se entere. Específicamente, se trata de determinar el sistema operativo y otras características de la máquina remota usando nada más que los paquetes capturados de un sniffer. Aunque no es 100% precisa, pueden obtenerse resultados sorprendentemente buenos con esta técnica. La gente de "subterrain.net" ha creado siphon, una herramienta pasiva de identificación de sistemas operativos y mapeo de redes y sistemas. Además, Michael Zalewski (el mejor de Polonia) y Bill Stearns mantienen p0f. Ambas herramientas demuestran la funcionalidad que explicaremos a continuación.

Identificación
Tradicionalmente, la identificación de sistemas de operación se ha hecho con herramientas activas, como queso o nmap. Esta herramientas operan bajo el principio que cada sistema operativo responde de forma distinta a una serie de paquetes mal formados. Todo lo que hay que hacer es crear una base de datos sobre como los diferentes sistemas responden a paquetes diversos. Luego, para determinar el sistema de operación de una máquina, se le envía una batería de paquetes mal formados, se ven las respuestas y se comparan con las de la base de datos. nmap, desarrollado por Fyodor, es la herramienta preferida al usar esta metodología. También ha escrito un documento detallado al respecto

La identificación pasiva sigue el mismo concepto pero con diferente implementación. La identificación pasiva se basa en ver paquetes capturados con sniffers provenientes del sistema remoto. En vez de probar activamente el sistema, todo lo que hay que hacer es guardar paquetes provenientes del mismo. Basándose en los paquetes capturados de un sniffer de dichos paquetes, se puede determinar el sistema de operación del sistema remoto. Igual que en el caso de la identificación activa, la pasiva se basa en el principio de que todas las pilas IP de todos sistema operativo tienen sus idiosincrasias. Analizando los paquetes capturados capturados e identificando dichas diferencias puedes determinar el sistema operativo de la máquina remota

Firmas
Hay 4 áreas del protocolo TCP que examinaremos para determinar el sistema operativo (aunque también hay otras que podrían usarse). Estas son:

Analizando estos factores en un paquete, puede determinarse el sistema de operación remoto que lo origino. No es 100% preciso, y funciona mejor con ciertos sistemas de operación. No hay ninguna firma individual que pueda identificar consistentemente el sistema de operación remoto, pero, si miramos varias firmas y combinamos la información, incrementamos la precisión. Un ejemplo para explicarlo más fácilmente. Abajo tenemos el registro de un sistema enviando un paquete. Este sistema nos envió un exploit al servicio mountd, así que queríamos saber más sobre el mismo. No queríamos hacerle finger o nmap, para no delatarnos, así que decidimos estudiar la información. La firma la capturamos usando snort, nuestra herramienta pasiva favorita.

04/20-21:41:48.129662 129.142.224.3:659 -> 172.16.1.107:604
TCP TTL:45 TOS:0x0 ID:56257
***F**A* Seq: 0x9DD90553
Ack: 0xE3C65D7 Win: 0x7D78

Basándonos en nuestros 4 criterios, identificamos las firmas siguientes:

Ahora, comparamos esta información con nuestra base de datos de firmas Primero examinaremos el valor del campo TTL usado por la máquina remota. Podemos ver que esta puesto en 45. Lo más probable es que pasase por 19 saltos antes de llegar a nosotros, por lo que el valor original seria 64. Basándonos en ese TTL, el paquete provendría de una máquina con Linux o FreeBSD (sin embargo, necesitamos más firmas en la base de datos). Este TTL lo podemos confirmar enviando un traceroute a la máquina remota. Si te preocupa que nos puedan detectar el traceroute, puedes hacer un traceroute que en vez de usar el TTL por defecto (30 saltos), use uno que se quede uno o dos saltos antes que el destino (opción -m). Por ejemplo, en este caso haríamos un traceroute a la máquina remota pero con solo 18 saltos (traceroute -m 18). Esto nos descubre el camino a la máquina (incluyendo su proveedor), sin llegar a tocarla. Para más información sobre los TTLs, revisa este documento de investigación sobre valores por defecto del campo TTL

Nuestro próximo paso es examinar el tamaño de la ventana (Window Size) del paquete. Hemos encontrado que este parámetro es otra herramienta efectiva, en particular el valor en uso y cuan frecuentemente cambia. La firma que vimos tenia como tamaño de ventana 0x7D78, un valor por defecto comúnmente usado por Linux. Además, Linux, FreeBSD y Solaris tienden a mantener el mismo valor de tamaño de ventana por sesión (como ocurrió en este caso). Sin embargo, los routers Cisco (al menos mi 2514) y sistemas con Windows NT cambian constantemente el valor del tamaño de la ventana. Hemos descubierto que el valor de este campo se mide con mayor precisión después del saludo a tres vías inicial (debido al "arranque lento" de TCP). Para mayor información sobre este campo, véase Stevens, "TCP/IP Illustrated, Volume 1", capítulo 20.

La mayoría de los sistemas de operativos activan el bit DF, así que este valor tiene una utilidad limitada. Sin embargo, hace que sea mas fácil identificar los pocos sistemas que no lo usan (como SCO o OpenBSD). Después de varias pruebas, creemos que el TOS también tiene una utilidad limitada. Parece basarse más en la sesión que en el sistema operativo; en otras palabras, no depende del sistema determinar el TOS, sino del protocolo en uso. Aunque definitivamente hay que examinarlo más a fondo. Por lo tanto, basándonos en la información recabada, especialmente en el TTL y el tamaño de la ventana, puedes compararla con la base de datos de firmas y determinar con cierto grado de confianza el sistema operativo (en este caso, Linux con núcleo 2.2.x).

Recuerda que, al igual que pasa con la identificación activa, la pasiva tiene sus limitaciones. En primer lugar, aquellas aplicaciones que construyen sus propios paquetes (nmap, hunt, nemesis, etc.) no van a tener las mismas firmas que el sistema operativo en que corran. En segundo lugar, es bastante fácil ajustar los valores de TTL, WS, DF o TOS en una máquina. Por ejemplo, para cambiar el valor por defecto del TTL:

Solaris: ndd -set /dev/ip ip_def_ttl 'number'
Linux: echo 'number' > /proc/sys/net/ipv4/ip_default_ttl
NT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Sin embargo, combinando una serie de diferentes paquetes y firmas, en este caso el TTL y el tamaño de ventana, se puede hacer una aproximación bastante fiable del sistema remoto.

Otras firmas y posibles usos.
No estamos limitados a las 4 firmas que hemos discutido hasta ahora. Hay otras áreas que podemos vigilar, como los números de secuencia inicial, números de identificación IP, opciones IP y TCP, etc. Por ejemplo, los routers Cisco tieneden a empezar los números de Identificación IP en 0, en vez de usar un número aleatorio. En cuanto a opciones TCP, la opción "Selective Acknowledgment" SackOK la usan con frecuencia Windows y Linux, mientras que no es común verla en FreeBSD o Solaris. Con la opción MSS (Maximum Segment Size, tamaño máximo de segmento), la mayoría de los sistemas de operación usan un valor de 1460, pero Novell frecuentemente utiliza 1369, y algunas variantes de FreeBSD, 512. También se pueden examinar los paquetes ICMP. Ofir Arkin, miembro de Honeynet, ha realizado una investigación exhaustiva sobre el uso de ICMP en la identificación de sistemas; véase su documento titulado "ICMP Usage in Scanning". Las firmas ICMP que comenta en su documento pueden usarse para la identificación pasiva de sistemas. Por ejemplo, la parte de datos de los paquetes ICMP REQUEST provenientes de sistemas Microsoft contiene el alfabeto, mientras que la mayoría de los sistemas Unix como Solaris o Linux tienen números y símbolos.

La identificación pasiva puede usarse para varios otros fines. Pueden usarla los "chicos malos" para identificar sistemas silenciosamente. Por ejemplo, para determinar el sistema operativo de una victima potencial, como un servidor Web, solo haría falta pedir una página al servidor, y luego analizar la captura de los paquetes. Con esto se elimina la necesidad de usar una herramienta activa que pueda ser detectada por sistemas de IDS. También puede usarse para identificar cortafuegos en modo proxy. Como estos tienen que reconstruir la conexión para sus clientes, puede identificarse dichos cortafuegos usando las firmas que hemos discutido anteriormente. Las organizaciones también pueden usar la identificación pasiva para detectar máquinas "ilegales", o sea, sistemas no autorizados a estar en su red. Por ejemplo una organización 100% basada en Microsoft o Sun podría usar esta técnica para detectar rápidamente máquinas Linux o FreeBSD "ilegales" que aparezcan misteriosamente en su red. La identificación pasiva también puede usarse para hacer un inventario rápido sobre los sistemas operativos en uso en una organización sin tocar ningún sistema ni afectar el rendimiento de la red. Te sorprendería la cantidad de organizaciones que no saben que sistemas tienen en su red interna. Para aquellos que llevan a cabo auditorias de seguridad, la identificación pasiva permite identificar rápidamente sistemas críticos (como mainframes Unisys). Al determinar sistemas operativos "ilegales" o "no autorizados", puede servir también como indicador de actividad maliciosa en la red.


Nosotros en El Proyecto hemos desarrollado una base de datos de prueba para demostrar los conceptos básicos de la identificación pasiva. La base de datos se creó probando una gama de sistemas usando los protocolos Telnet, FTP, HTTP y SSH. Esta base de datos no esta en desarrollo y sólo esta disponible como demostración. Si quieres contribuir al desarrollo de esta metodología, te recomendamos las herramientas de las que hemos hablado antes.

Conclusión
La identificación pasiva te da la capacidad para averiguar cosas sobre el enemigo sin alertarle. Aunque no hay ningún dato aislado que pueda identificar positivamente un sistema operativo, combinado varias firmas puedes hacer una buena aproximación del sistema remoto. Muchas gracias a las siguientes personas por su colaboración e ideas:

Craig Smith
Peter Grundl
Subterrain Siphon Project


The Honeynet Project