PDF de programación - Un enfoque práctico para engañar la detección remota de SO de Nmap

Un enfoque práctico para engañar la

detección remota de SO de Nmap

David Barroso Berrueta
http://voodoo.somoslopeor.com

[email protected]

Copyright © 2003 David Barroso Berrueta. Palencia (Spain)

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".

La detección remota de SO es está haciendo cada vez más popular, no sólo para los auditores de redes,
sino también para cualquier atacante. Ya que Nmap es cada vez más popular como la herramienta
utilizada para adivinar qué SO está corriendo en un sistema remota, están surgiendo algunas
herramientas de seguridad para engañanar a Nmap en su propósito de la detección de SO. Este artículo
describe diferentes métodos para engañar a Nmap y comportarse como cualquier otro sistema operativo
elegido, así como demostraciones de cómo se realiza.

1. Introducción

El propósito de este artículo es intentar enumerar y describir brevemente todas las aplicaciones y técnicas
desarrolladas para engañar la detección remota de SO de Nmap, pero en cualquier caso, la seguridad por
oscuridad no es ninguna buena solución; puede ser una buena medida de seguridad, pero por favor, ten en cuenta
que es más importante tener un entorno verdaderamente seguro (parches, firewalls, ids, ...) que intentar esconder
tu SO.

Saber que Sistema Operativo está corriendo en un sistema remoto puede ser muy valioso tanto para los auditores
de redes como para cualquier atacante. Supón que encuentran un puerto abierto en su (aprobada o no)
penetración; saber el SO hace que encontrar y ejecutar un exploit contra ese servicio sea más fácil, ya que a
menudo los exploitsson para versiones específicas de SO, y un exploit para Sendmail sobre HP-UX no
funcionará para Sendmail sobre AIX, o para ser más exactos, un exploit para AIX 4.3.3 puede no funcionar en
un sistema corriendo 4.3.3 con los últimos parches de mantenimiento aplicados. Fyodor (autor de Nmap) ha
escrito un detallado artículo (http://www.insecure.org/nmap/nmap-fingerprinting-article.html) sobre la detección
remota de SO, describiendo algunos métodos diferentes de detectar con éxito el SO remoto, desde los métodos
más básicos, hasta los más complejos.

1

Engañando la detección remota de SO

Al principio, adivinar el SO remoto se hacía mirando el banner de un servicio específico. Por ejemplo, un típico
banner de telnet o ftp siempre era mostrado a todo el mundo, diciendo que SO estaba siendo ejecutado; o si el
banner había sido quitado o cambiado, se podían ejecutar algunos comandos para conocer el SO (recuerda el
SYST en el FTP). Otros métodos básicos para conocer el SO pueden ser buscar entradas HINFO en el servidor
DNS, o intentar conseguir información usando snmp (un montón de dispositivos tienen habilitado por defecto el
acceso snmp usando la cadena ’public’). Incluso buscar anuncios de trabajo publicados en Internet, buscar en su
basura manuales de SO, o hacer uso de la ingeniería social son métodos válidos de intentar averiguar el SO
remoto.

Después, se desarrollaron algunas soluciones más avanzadas, aprovechándose de que cada fabricante de SO tiene
una pila TCP/IP distinta. La idea es mandar algunos paquetes ’creados’ al sistema remoto y esperar su respuesta.
Esos paquetes son paquetes ’malvados’, construidos con opciones TCP poco comunes u opciones ’imposibles’.
Cada SO tiene su propia pila TCP/IP, no existe una implementación común para todos los SO, y este hecho
permite crear una clasificación de los SO y versiones de acuerdo a sus respuestas. De esta forma es como
funcionan las herramientas de detección remota de SO; algunas de ellas usando el protocolo TCP/IP, y otras
usando el protocolo ICMP.

Hay un artículo sobre’Defeating TCP/IP Stack Fingerprinting
(http://www.usenix.org/publications/library/proceedings/sec2000/smart.html)’ que describe en un modo teórico
el diseño y la implementación de un programa de recogida de implementaciones de pilas TCP/IP. Ese artículo
describe cómo y porqué puedes vencer a la detección de SO, por lo que no voy hablar mucho sobre ello; por lo
tanto, me centraré en la soluciones que podemos usar y están disponibles.

2. Razones para ocultar tu SO al mundo

Quizás te estas preguntando porqué quieres perder tu valioso tiempo cambiando tu kernel de Linux para ocultar
tu verdadero SO a los usuarios ’malvados’ de Nmap. Puede que las siguientes razones te convezcan:

• Al revelar tu SO hace que encontrar y ejecutar con éxito un exploit contra cualquiera de tus dispositivos sea

más fácil.

• Tener un SO no parcheado o una versíon antigua no es muy conveniente para el prestigio de tu compañia.
Imagina que tu compañia es un banco y algunos usuarios se dan cuenta de que tienes varias máquinas sin
parchear. No creo que confíen más en ti. Además, este tipo de ’malas’ noticias siempre salen a la luz pública.

• El conocer el SO que tienes puede llegar a ser más peligroso, porque la gente puede adivinar que aplicaciones

estás ejecutando en ese SO (inferencia de datos). Por ejemplo, si tu sistema es MS Windows, y estás
ejecutando un base de datos, es muy probable que estés ejecutando MS-SQL.

• Puede llegar a ser conveniente para otras compañias de programas, ya que te pueden ofrecer un nuevo entorno

de SO (ya que saben lo que tienes).

• Y finalmente, privacidad; nadie necesita saber los sistemas que estás ejecutando.

3. Nmap

Nmap (http://www.insecure.org) es una de estas herramientas. Manda siete paquetes TCP/IP (llamados tests) y
espera la respuesta. Los resultados se comparan en una base de datos de resultados conocidos (fichero de firmas
de SO). Esta base de datos es un fichero de texto que contiene el resultado respondido (firma) de cada SO

2

Engañando la detección remota de SO

conocido. Así, si la respuesta coincide con alguna de las entradas de la base de datos, podemos adivinar que el
SO remoto es el mismo que el de la base de datos. Algunos paquetes Nmap se mandan a un puerto abierto y otros
a un puerto cerrado; dependiendo de los resultados, se averigua el SO remoto. Una entrada de ejemplo puede ser:

/* Comentario sobre el SO. Sí, queremos ser una consola Sega Dreamcast */

Fingerprint Sega Dreamcast

/* Predicibilidad del ISN; TD: dependiente del tiempo */
TSeq(Class=TD%gcd= < 780%SI= < 14)

/* Resultado del Test 1: paquete SYN con algunas opciones a un puerto abierto. Obtenemos
un SYN+ACK, reconocimiento seq +1, tamaño de ventanta 0x1d4c, bit no fragmentar
no activado, y sólo el MSS devuelto */
T1(DF=N%W=1D4C%ACK=S++%Flags=AS%Ops=M)

/* Resultado del Test 2: paquete Null con
algunas opciones a un puerto abierto. Obtenemos un ACK+RST, reconocimiento seq,
tamaño de ventana 0x0, bit no fragmentar no activado */
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

/* Resultado del Test 3: SYN, FIN, URG, PSH con opciones a un puerto abierto.
Obtenemos un SYN+ACK, reconocimiento seq +1, tamaño de ventana 0x1d4c, el
bit no fragmentar no activado, y sólo devuelve el MSS */
T3(Resp=Y%DF=N%W=1D4C%ACK=S++%Flags=AS%Ops=M)

/* Resultado del Test 4: paquete ACK a un puerto abierto. Obtenemos un RST,
reconocimiento seq, tamaño de ventana 0x0, bit de no fragmentar no activado */
T4(DF=N%W=0%ACK=S%Flags=R%Ops=)

/* Resultado del Test 5: paquete SYN con opciones a un puerto cerrado. Obtenemos
un ACK+RST, reconocimiento seq, tamaño de ventana 0x0, bit de no fragmentar no
activado */
T5(DF=N%W=0%ACK=S%Flags=AR%Ops=)

/* Resultado del Test 6: ACK con opciones a un puerto cerrado. Obtenemos un RST,
reconocimiento seq, tamaño de ventana 0x0, bit no fragmentar no activado */
T6(DF=N%W=0%ACK=S%Flags=R%Ops=)

/* Resultado del Test 7: FIN, PSH, URG con opciones a un puerto cerrado. Obtenemos
un ACK+RST, reconocimiento seq+1, tamaño de ventana 0x0, bit no fragmentar no
activado */
T7(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

/* Resultado de Port unreachable. No hay respuesta */
PU(Resp=N)

Así que, si queremos engañar a Nmap y decir al atacante que estamos corriendo un sistema operativo diferente,
sólo necesitamos engañar las respuestas a los tests de Nmap. La solución que voy a describir es sólo válida para
engañar Nmap pero no a todas las herramientas de detección remota de SO. En la Conclusión otras herramientas
serán mencionadas, así como algunas recomendaciones para el auditor de sistemas y/o el atacante.

3

4. Soluciones de Linux

Engañando la detección remota de SO

Los métodos para engañar la detección remota de SO de Nmap están escritos como módulos del kernel, o al
menos, como parches al kernel de Linux. La razón es que si el objetivo es cambiar el comportamiento de la pila
TCP/IP, necesitamos hacerlo en la capa del kernel.

Se van a describir tres módulos del kernel, todos ellos independientes del árbol del kernel de Linux; tienes que
descargarlos y parchear tu kernel para añadirlos. El primero requiere que tengas netfilter activado en tu kernel
(que pienso que es necesario si quieres empezar a tener un sistema seguro), pero los otros dos no lo necesitan.

4.1. IP Personality

El primero, y probablemente, mejor opción es IP Personality (http://ippersonality.sourceforge.net/). Es un
módulo de netfilter (por lo tanto, sólo disponible para kernels 2.4) que permite cambiar el comportamiento de la
pila IP, pudiendo tener múltiples personalidades dependiendo de los parámetros que le especifiques en una regla
de iptables. De hecho, podemos cambiar las siguientes opciones:

• Número de Secuencia Inicial TCP (ISN)

• Tamaño inicial de ventana TCP

• Opciones TCP (sus tipos, valores y orden en el paquete)

•

•

•

IP números de ID

respuestas a algunos paquetes TCP ’anómalos’

respuestas a algunos paquetes UDP

Un resumen general de IP Personality es que podemos cambiar la forma de responder a algunos paquetes, y
podemos especificar qué paqu