Nota de la traduccion en al Español:
Primero que nada, una traduccion de un documento es mucho muy dificil, ya
que muchos terminos son dificiles de interpretar de un idioma a otro. Hay
que notar que el idioma al que se tradujo este documento es Español
Mexicano, de Baja California Norte (por si tienen algunas dudas de los
modismos o chistes idiomaticos).
Otro detalle son los acentos. Como es altamente tedioso hacer algo como
eso, no lo hice. Si alguien lo quiere hacer por mi, o tiene algun comentario
o mejora para este articulo, favor de contactarme a mabs&at&hotmail.com
Esta traduccion se hizo por parrafos, por enunciados completos, asi que
si tienen alguna duda de que significa algun termino, consultar la
version en Ingles, parrafo por parrafo, enunciado por enunciado y veran
los terminos originales que intente traducir.
Aqui hay algunas de la palabras que fueron dificiles de traducir y
mas bien se "interpretaron".
fingerprinting: Esto se refiere a identificacion por medio de huellas digitales
o de los dedos. Lo interprete como identificacion la mayor parte
de las veces.
fingerprint: la "huella" digital en si.
snapshot: imagen de algo en un instante determinado. La traduje como imagen.
puede tambien ser una "vista" o panorama.
crash: se dice de cuando un programa deja de funcionar de manera anormal. Aqui
lo interprete como "deternerse".
download: bajar de la red.
host: maquina, anfitrion, computadora que a la que se puede hacer una conexion.
release: version por lo regular lo suficientemente estable como para que
la use el publico en general. Traducido como programa algunas veces.
banner: anuncio a gran escala de algo, generalmente un letrero que indica
algun tipo de informacion. Traducido como "letrero".
SO: sistema operativo.
owned, own: dicese algunas veces del hecho de tener privilegios de root, o
ganarlos. Se interpreta como "comer el mandado", "caminar".
scratch space: generalment un espacio temporal para escribir y borrar cosas
que no tienen importancia o mientras se genera una idea.
se tradujo como "espacio para rayar".
checksum: suma de control. No se si alguien lo maneje asi o si la mayoria
de la gente en computacion lo use como checksum.
dropped: cuando un paquete de datos se deja de transmitir por una red
ya sea por que se le acabo su tiempo de vida o alguna otra causa.
Lo traduje como "soltado" en la mayoria de los casos.
lame: gacho, malo, en este caso lo interprete como "maleta".
Deteccion Remota de SO via Reconocimiento de Pila TCP/IP
por Fyodor <fyodor@insecure.org> (insecure.org)
Escrito: Octubre 18, 1998
Ultima Modificacion: Abril 10, 1999
[French Translation by Arhuman <arhuman&at&francemel.com>]
[Portuguese Translation by Frank Ned <frank&at&absoluta.org>]
[Italian Translation by Rige <rigel&at&penguinpowered.com>]
[Russian Translation by Alex Volkov <alex&at&nmap.ru>]
[Spanish Translation by Marco Barbosa <mabs&at&hotmail.com>]
Este documento puede ser distribuido libremente. La copia mas reciente debe estar
disponible en http://nmap.org/nmap-fingerprinting-article.html
RESUMEN
Este documento discute como obtener informacion valiosa sobre una maquina
consultando su pila de TCP/IP. Primero presento algunos de los metodos
"clasicos" para determinar el SO de una maquina, que no requieren
identificacion de la pila. Despues describo las herramientas actuales
mas novedosas para identificacion de pila. Despues viene una descripcion
de muchas tecnicas para hacer hacer que la maquina remota gotee informacion
sobre si misma. Finalmente, detallo mi (nmap) implantacion de esto, seguido
de una imagen obtenido de nmap que nos dice que SO estan corriendo
en muchos sitios populares de Internet.
RAZONES
Pienso que la utilidad de determinar que SO esta corriendo un sistema es
bastante obvia, asi que hare esta seccion corta. Una de los ejemplos mas
fuertes de esta utilidad es que muchos hoyos de seguridad son dependientes
de la version del SO. Digamos que estas haciendo una prueba de penetracion
y encuentras el puerto 53 abierto. Si esta es una version vulnerable del
Bind, solo tienes una oportunidad de explotarlo ya que un intento fallido
detendra el demonio. Con un buen identificador de TCP/IP, rapidamente
sabras que esta maquina esta corriendo "Solaris 2.51" o "Linux 2.0.35" y
puedes ajustar to codigo shell de acuerdo a esto.
Una posibilidad aun peor, es alguien que desee escanear 500,000 maquinas
con anticipacion para ver que SO's estan corriendo y que puertos estan
abiertos. Despues cuando alguien publica (digamos) un hoyo para root en el
demonio comsat de Sun, nuestro pequeño cracker podria hacer un
grep a su lista para obtener "UDP/512" y "Solaris 2.6" e inmediatamente
tiene paginas y paginas de maquinas root-ables. Debe notarse que esto
es comportamiento de un MOCOSO SCRIPT. No se ha demostrado ninguna habilidad
y nadie se impresionara por que haya encontrado algun .edu vulnerable que no
haya parchado el hoyo a tiempo. Ademas, la gente estara aun menos
impresionada si se utiliza su recien encontrado acceso para desacrar el
sitio-web del departamento con un monumento anunciando lo cabron que
es y lo estupidos que deben ser los administradores del sistema.
Otro uso posible es para ingenieria social. Digamos que estas escaneando
tu compañia objetivo y nmap reporta un 'Datavoice TxPORT PRISM
3000 T1 CSU/DSU 6.22/2.06'. El hacker puede llamar como 'Soporte de
Datavoice' y discutir algunos asuntos sobre su PRISM 3000. "Vamos a
anunciar un hoyo de seguridad pronto, pero primero queremos que todos
nuestros clientes actuales instalen el parche -- se lo acabo de enviar
por correo..." Algunos administradores ingenuos podrian asumir que solo
un ingeniero autorizado de Datavoice podria sabar tanto de su CSU/DSU.
Otro uso potencial para esta capacidad es evaluacion de compañias
con las que podria hacer negocios. Despues de seleccionar un ISP,
escanealos para ver que equipo usan. Esos tratos de "$99/año" no suena
tan buenos cuando se entera que tienen enrutadores chafas y ofrecen
servicios PPP de una bola de cajas Windows.
TECNICAS CLASICAS
La identificacion de pila resuelve el problema de identificar un SO de
manera unica. Yo pienso que esta tecnica tiene el mayor futuro, pero hay
en la actualidad muchas otras soluciones. Tristemente, esta es aun una
de mas efectivas de estas tecnicas:
playground~> telnet hpux.u-aizu.ac.jp
Trying 163.143.103.12 ...
Connected to hpux.u-aizu.ac.jp.
Escape character is '^]'.
HP-UX hpux B.10.01 A 9000/715 (ttyp2)
login:
No vale la pena pasar por todo el procedimiento de indentificacion
si la maquina anunciara despreocupadamente al mundo exactamente que es
lo que esta corriendo! Tristemente, muchos vendedores envian sistemas
actuales con este tipo de letreros y muchos administradores
no los quitan. Solo porque hay otras maneras de averiguar que SO
se esta corriendo (como identificacion), no quiere decir que vamos
a anunciar nuestro SO y arquitectura a todo tarugo que trate de
conectarse.
El problema con depender de esta tecnica es que un numero creciente
de gente esta quitando los letreros, muchos systems no dan mucha
informacion, y es trivial que alguien "mienta" en sus letreros.
Sin embargo, lectura de letreros es todo lo que obtienes
si gastas $miles en el escaner ISS comercial. Baja nmap
o queso y ahorra tu dinero :).
Aun si quitas los banners, muchas aplicaciones felizmente regalaran
este tipo de informacion cuando se les pregunte. Por ejemplo veamos
a un servidor FTP:
payfonez> telnet ftp.netscape.com 21
Trying 207.200.74.26 ...
Connected to ftp.netscape.com.
Escape character is '^]'.
220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.
SYST
215 UNIX Type: L8 Version: SUNOS
Primero que nada, nos da detalles del sistema en su letrero por omision.
Despues si le damos el comando 'SYST', felizmente nos regresa aun mas
informacion.
Si soporta FTP anonimo, muchas veces podemos bajar /bin/ls u otros
binarios y determinar para que arquitectura fueron construidos.
Muchas otras aplicaciones tambien dan informacion gratis. Toma los
servidores web por ejemplo:
playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:'
Server: Microsoft-IIS/4.0
playground>
Hmmm ... me pregunto que SO estan corriendo esos maletas.
Otras tecnicas clasicas incluyen registros de informacion del anfitrion
DNS (raramente efectivos) y ingenieria social. Si la maquina esta
escuchando 161/udp (snmp), casi se te garantiza una bola de informacion
detallada usando 'snmpwalk' de la distribucion de herramientas de CMU SNMP
y el nombre comunitario 'public'.
PROGRAMAS DE IDENTIFICACION ACTUALES
Nmap no es el primer programa de reconocimiento de SO que usa identificacion
de TCP/IP. El spoofer para IRC sirc de Johan ha incluido tecnicas de
identificacion muy primitivas desde la version 3 (o anteriores). Intenta
colocar un anfitrion en las classes "Linux", "4.4BSD", "Win95", o
"Desconocido" usando una cuantas pruebas simples de banderas de TCP.
Otro programa asi es checkos, hecho publico en Enero
de este año por Shok en el numero 7 de Confidence Remains High.
Las tecnicas de identificacion son exactamente las mismas que las de
SIRC, y aun el codigo es identico en muchos lugares. Checkos ya era
disponible privadamenta por mucho tiempo antes de su puesta al publico, asi
que no tengo idea quien le copio codigo a quien. Pero ninguno parece
darle credito al otro. Algo que checkos agrega, es el chequeo de
letrero de telnet, que es util, pero tiene los problemas descritos
con anterioridad. [Actualizacion: Shok escribio para decir que no se
tenia la intencion de hacer checkos publico y por esto no se molesto
en darle credito a SIRC por algunas partes del codigo.]
Su1d tambien escribio un programa para checar SO's. El suyo se llama SS
y a partir de la version 3.11 puede identificar 12 diferentes tipos
de SO's. Yo soy un tanto parcial hacia este ya que le da credito a mi
nmap por unas partes del codigo interconexion :).
Despues, esta queso. Este programa es el mas nuevo y es una gran salto
hacia enfrente de los otros programas. No solo introducen un par de
pruebas novedosas, sino que fueron los primeros (que yo he visto) en
mover las "huellas" fuera de el codigo. Los
otros escaners incluyeron codigo como:
/* from ss */
if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) &&
(flagsthree & TH_ACK))
reportos(argv[2],argv[3],"Livingston Portmaster ComOS");
En su lugar, queso pone esto en un archivo de configuracion, que obviamente
es mejor para incrementar y hace que poner otro SO sea tan facil como
agregar unas cuantas lineas a un archivo de "huellas" .
Queso fue escrito for Savage, uno de los buenos tipos de Apostols.org .
Un problema con todos los programas descritos arriba es que estan muy
limitados en el numero de pruebas de identificacion que limita la
granularidad de las respuestas. Yo quiero saber mas que solo 'esta
maquina es OpenBSD, FreeBSD, NetBSD', yo deseo saber exactamente cual
de esas es asi como una idea de el numero de version de el programa.
De la misma manera, preferiria ver 'Solaris 2.6' que simplemente 'Solaris'.
Para obtener esta granularidad en las respuestas, yo trabaje en un
numero de tecnicas de identificacion que se describen en la siguiente
seccion.
METODOLOGIA DE IDENTIFICACION
Hay muchas, muchas tecnicas que pueden ser usadas para identificar
pilas de interconexion. Basicamente, solo buscas
cosas que difieran entre los sistemas operativos y escribes una
prueba para la diferencia. Si combinas suficientes de estas, puedes
aislar el SO con gran exactitud. Por ejemplo nmap puede distinguir
confiablemente Solaris 2.4 vs. Solaris 2.5-2.51 vs Solaris 2.6. Tambien
puede identificar el kernel de Linux 2.0.30 del 2.0.31-34 o 2.0.35.
Aqui hay algunas tecnicas:
La prueba FIN -- Aqui mandamos un paquete FIN (o cualquier paquete sin
una bandera ACK o SYN) a un puerto abierto y esperamos una respuesta.
El comportamiento correcto del RFC793 es
no responder, pero muchas implantaciones quebradas como MS Windows,
BSDI, CISCO, HP/UX, MVS, e IRIX envian un RESET de regreso. Muchas
de las herramientas actuales utilizan esta tecnica.
La prueba de bandera MANIACA -- Queso es el primer escaner que
he visto utilizar esta prueba inteligente. La idea es poner una
"bandera" TCP (64 o 128) en el encabezado TCP de un paquete SYN.
Las cajas Linux antes de 2.0.35 mantienen la bandera puesta en
su respuesta. No he encontrado ningun otro SO que tenga este defecto.
Sin embargo, algunos sistemas operativos parecen cancelar la conexion
cuando reciben un paquete SYN+MANIACA. Este comportamiento podria ser
util para identificarlos.
Probar TCP ISN -- La idea aqui es encontrar patrones en los numeros
de secuencia inicial seleccionados por las implantaciones de TCP
al responder a solicitudes de conexion. Esto puede ser categorizado
en muchos grupos como el tradicional 64K (muchos cajas UNIX viejas),
incrementos aleatorios (nuevas versiones de Solaris, IRIX, FreeBSD,
Digital UNIX, Cray, y muchas otras), "Aleatoriedad" verdadera
(Linux 2.0.*, OpenVMS, AIX mas nuevos, etc). Cajas Windows (y unas
cuantas mas) usan un modelo "dependiente del tiempo" donde el
ISN se incrementa por una pequeña cantidad estatica cada
periodo de tiempo. Sin necesidad de decirlo, esto se vence tan
facilmente como el viejo comportamiento de 64K. Claro que mi
tecnica favorita es la "constante". Las maquinas SIEMPRE usan
exactamente el mismo ISN. :). He visto esto en algunos hubs 3com
(usan 0x803) y en impresoras Apple LaserWriter (usan 0xC7001).
Tambien puedes subdividir grupos tales como incremento aleatorio por
varianzas computacionales, maximos comunes divisores, y otras
funciones en el conjunto numeros de secuencia y las diferencias
entre los numeros.
Debe notarse que la generacion de ISN tiene implicaciones de seguridad
importantes. Para mas informacion de esto, contactar al "experto en
seguridad" Tsutomu "Shimmy" Shimomura en SDSC y preguntenle como se
lo "caminaron". Nmap es el primer programa que he visto que
usa esto para identificacion de SO.
Bit de No-fragmentacion -- Muchos sistemas operativos estan empezando a
poner el bit "no-fragmentacion" de IP en algunos paquetes que manda.
Esto da varios beneficios de desempeño (aunque tambien puede
se enfadoso -- por esto las exploraciones de fragmentacion de nmap
no funcionan desde cajas Solaris). En cualquier caso, no todos los
SO's hacen esto y algunos lo hacen en diferentes casos, asi que
poniendo atencion a este bit podemos obtener aun mas informacion
sobre el SO objetivo. Tampoco he visto esta antes.
Ventana Inicial TCP -- Esto solo requiere checar el tamaño de la
ventana de los paquetes regresados. Escaners mas viejos simplemente
utilizan en una ventana no-zero un paquete RST para querer decir
"derivado de BSD 4.4". Escaners mas nuevos como queso y nmap dan
seguimiento a la ventana exacta, ya que es en realidad bastante
constante segun el tipo de SO. De hecho esta prueba nos da mucha
informacion, ya que algunos sistemas operativos pueden ser identificados
de manera unica por la ventana en si (por ejemplo, AIX es el unico
SO que he visto usa 0x3F25). En su pila TCP "completamente re-escrita"
para NT5, Microsoft usa 0x402E. Interesantemente, ese es exactamente
el numero usado por OpenBSD y FreeBSD.
Valor ACK -- A pesar de que podria pensarse que esto seria completamente
estandar, en algunos casos las implantaciones difieren en el valor que
usan para el campo ACK. Por ejemplo, digamos que mandas un FIN|PSH|URG
a un puerto TCP cerrado. La mayor parte de las implementaciones
pondran el ACK igual que tu numero de sequencia inicial, pero Windows
y algunas impresoras estupidas te mandaran tu secuencia + 1. Si mandas
un SYN|FIN|URG|PSH a un puerto abierto, Windows es muy inconsistente.
Algunas veces regresa tu secuencia, otras veces manda s++, aun otras
veces regresa un valor aparentemente aleatorio. Uno tiene que
preguntarse que tipo de codigo esta escribiendo MS que cambia su
parecer de esta manera.
Control de Error de Mensaje ICMP -- Algunos sistemas operativos
(inteligentes) siguen la sugerencia RFC 1812 de limitar la cantidad en
que diferentes mensjaes de error son mandados. Por Ejemplo, el kernel
de Linux (en net/ipv4/icmp.h) limita la generacion de mensajes de
destino inalcanzable a 80 en 4 segundos, con 1/4 de segundo de castigo
si se sobrepasa ese limite. Una manera de probar esto es mandar una bola
de paquetes a algun puerto UDP alto seleccionado al azar y contar el
numero de inalcanzables recibidos. No he visto que esto se use antes, de
hecho no he agregado esto a nmap (excepto para usarlo con escaneo de
puertos UDP). Esta prueba haria la deteccion de SO un poco mas lenta
ya que se necesita mandar un monton de paquetes y esperar a que regresen.
Y tambien tomar en cuenta la posibilidad de que los paquetes sean
"soltados" por la red seria una lata.
Referenciacion de Mensaje ICMP -- Los RFCs especifican que los mensajes
de error ICMP hacen referencia a una pequeña cantidad de
un mensaje ICMP que provoca errores variados. Para un mensaje de
puerto inalcanzable, casi todas las implementaciones mandan solo
el encabezado IP requerido + 8 bytes de regreso. Sin embargo,
Solaris regresa un poco mas y Linux regresa aun mas que eso. La
belleza de esto es que permite a nmap identificar a maquinas
Linux y Solaris aun cuando no tengan ningun puerto escuchando.
Eco de Integridad de Mensajes de Error ICMP -- Obtuve esta idea de algo
que Theo de Raadt (desarrollador principal de OpenBSD) publico en
comp.security.unix. Como se ha mencionado antes, las maquinas tienen
que regresar parte de tu mensaje original junto con un error de puerto
inalcanzable. Y aun otras maquinas tienden a usar tus encabezados
como 'espacio para rayar' durante su procesamiento inicial, asi que
estan un tanto alterados cuando te los regresan. Por ejemplo, AIX y
BSDI regresan un campo 'longitud total' de IP que es 20 bytes demasiado
grande. Algunos BSDI, FreeBSD, OpenBSD, ULTRIX, y VAXen desmadran el
ID del IP que les mandaste. Mientras la suma de control va a cambiar
debido que se cambia el TTL de todas formas, hay algunas maquinas (AIX,
FreeBSD, etc.) que regresan una suma de control inconsistente o de 0.
Lo mismo sucede con el suma de control UDP. Al final, nmap hace nueve
diferentes pruebas de errores ICMP para "oler" diferencias sutiles como
estas.
Tipo de Servicio -- Para los mensajes de inalcanzable del puerto ICMP
me fijo al valor del tipo de servicio (TOS) en el paquete que
regresan. Casi todas las implantaciones usan 0 para este error
ICMP, aunque Linux usa 0xC0. Esto no indica uno de los valores
TOS estandar, pero en vez de eso, es parte del campo de precedencia
(AFAIK) que no es usado. No se porque se pone asi, pero si cambian
a 0 podremos seguir identificando las versiones anteriores y
podrems identificar entre anteriores y recientes.
Manejo de Fragmentacion -- Esta es una tecnica favorita de Thomas
H. Ptacek de Secure Networks, Inc (ahora propiedad de una bola de
usuarios de Windows en NAI). Esto se aprovecha del hecho de que
diferentes implantaciones seguido manejan fragmentos IP con
translape de manera diferente. Algunos sobreescribiran las viejas
porciones con las nuevas, y en otros casos las cosas viejas tiene
precedencia. Hay muchas pruebas diferentes que se pueden usar
para determinar como el paquete fue reensamblado. No agregue esta
caracteristica ya que no conozco ninguna manera portable para
mandar fragmentos de IP (esta particularmente perron en Solaris).
Para mas informacion sobre fragmentos translapados, pueden leer
este articulo IDS (www.secnet.com).
Opciones TCP -- Estos son una verdadera mina de oro en terminos de fugas
de informacion. La belleza de estas opciones es que:
1) son generalmente opcionales (Doh!) :) asi que no todas las maquinas
las implantan.
2) Sabes si una maquina las implanta mandando una solicitud con una
opcion definida. El objetivo generalmente muestra que soporta la
opcion poniendola tambien en la respuesta.
3) Puedes retacar una bola de opciones en un paquete para probar todo
al mismo tiempo.
Nmap manda estas opciones en casi todos los paquetes de prueba:
Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;
Cuando obtienes una respuesta, miras que opciones te regresaron y
por lo tanto son soportadas. Algunos sistemas operativos como
cajas FreeBSD recientes soportan todas las anteriores, mientras
otras, como las Linux 2.0.X soportan muy pocas. Los kernels
Linux 2.1.x mas recientes soportan todas la anteriores. Por otro
lado, son mas vulnerables a prediccion de secuencia TCP. Imaginense.
Aun si varios sistemas operativos soportan las mismas opciones,
se pueden distinguir algunas veces por los valores de las
opciones. Por ejemplo, si mandas un valor MSS pequeño a una
caja Linux, generalmente te hara un eco con ese MSS de regreso.
Otras maquinas te daran un valor diferente.
Y aun si obtienes el mismo conjunto de opciones soportadas Y los
mismos valores, aun puedes diferenciar por el orden en que
las opciones son dadas, y donde se pone relleno. Por ejemplo
Solaris regresa 'NNTNWME' que significa:
<no op><no op><timestamp><no op><window scale><echoed MSS>
Mientras que Linux 2.1.122 regresa MENNTNW. Mismas opciones, mismos
valores, pero diferente orden!
No he visto ningunas otras herramientas para deteccion de SO que
utilice opciones TCP, pero es muy util.
Hay otras cuantas opciones utiles para las que podria probar en
algun momento, como aquellas que soportan T/TCP y reconocimientos
selectivos.
Cronologia de Explotacion -- Aun con todas la pruebas anteriores,
nmap es incapaz de distinguir entre las pilas TCP de Win95, WinNT,
o Win98. Esto es algo sorprendente, especialmente ya que Win98
salio como 4 años despues que Win95. Pensarias que se
habrian preocupado en mejora la pila de alguna manera (como
soportar mas opciones TCP) y de esta manera podriamos detectar
el cambio y distinguir entre los sistemas operativos. Desafortunadamente
este no es el caso. La pila NT es aparentemente la misma mugre
pila que pusieron en el '95. Y no se molestaron en actualizarla
para el '98.
Pero no desesperes, ya que hay una solucion. Puedes simplemente
empezar con antiguos ataques para Windows DOS (Ping of Death,
WinNuke, etc) y despues cambiar un poco mas arriba a ataques como
Teardrop y Land. Despues de cada ataque, hacer un ping para ver
si tronaron. Cuando finalmente los truenes, ya habras deducido la
la version que estan corriendo, e incluso hasta de paquete o parche.
No he agregado esta funcion a nmap, aunque debo admitir que es muy
tentador :).
Resistencia a Inundacion de SYN -- Algunos sistemas operativos dejan de
aceptar nuevas conexiones si les mandas demasiados paquetes SYN
falsificados (falsificar los paquetes impide que tu kernel corte
las conexiones). Muchos sistemas operativos pueden solo manejar
8 paquetes. Kernels recientes de Linux (entre otros sistemas
operativos) permiten varios metodos, como cookies SYN para prevenir
que esto se convierta en un problema serio. Asi que puedes aprender
algo de tu SO objetivo al mandarle 8 paquetes de una fuentes
falsificada a un puerto abierto y despues probando si puedes
establecer una conexion a ese puerto tu mismo. Esto no fue
implantado el nmap ya que algunas gentes se enojan cuando los
inundas con SYN's. Aun explicando que solo tratabas de determinar que
tipo de SO estan corriendo no ayudara a calmarlos.
IMPLANTACION DE NMAP Y RESULTADOS
He creado una implantacion de referencia para las tecnicas de deteccion
de SO mencionadas arriba (excepto esas que dije estaban excluidas). He
agregado esto a mi escaner Nmap que tiene la ventaja de que ya sabe
que puertos estan abiertos y cerrados para identificacion asi que no
tienes que decirle. Tambien es portable entre Linux, *BSD, y Solaris
2.51 y 2.6, y algunos otros sistemas operativos.
La nueva version de nmap lee un archivo lleno con los esqueletos de
las huellas que siguen una gramatica simple. Aqui hay un ejemplo:
Huella IRIX 6.2 - 6.4 # Gracias a Lamont Granquist
FingerPrint IRIX 6.2 - 6.4 # Thanks to Lamont Granquist
TSeq(Class=i800)
T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT)
T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Miremos la primera linea (Estoy agregando marcadores '>'):
> Huella IRIX 6.2 - 6.3 # Gracias a Lamont Granquist
Esto dice simplemente que la huella cubre las versiones 6.2 y 6.3 de
IRIX y el comentario dice que Lamont Grandquist amablemente me
mando la direccion IP o la huella de las cajas IRIX probadas.
> TSeq(Class=i800)
Esto significa que un muestreo ISN lo puso en la clase "i800". Esto
significa que cada nueva secuencia de numeros es un multiplo de
800 mayor que el ultimo.
> T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
La prueba se llama T1 (por test1 en Ingles, listo eh?). En esta prueba
mandamos un paquete SYN con una bola de opciones TCP a un puerto abierto.
DF=N significa que el bit "no fragmentacion" de la respuesta debe estar
puesto. W=C000|EF2A quiere decir que el anuncio de ventana que recibimos
deber ser 0xC000 o EF2A. ACK=S++ quiere decir que el reconocimiento que
recibimos debe ser nuestra secuencia inicial mas 1. Flags = AS quiere
decir que las banderas ACK y SYN fueron mandadas en la respuesta. Ops=
MNWNNT quiere decir que las opciones en la respuesta deben ser (en este
orden):
<MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp>
> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
La prueba 2 involucra a un NULL con las mismas opciones a un puerto abierto.
Resp=Y significa que debemos obtener una respuesta. Ops= significa que
no debe haber ningunas opciones incluidas en el paquete respuesta. Si
quitaramos '%Ops=' completamente, entonces cualesquier opciones mandadas
corresponderian.
> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)
La prueba 3 es un SYN|FIN|URG|PSH con opciones a un puerto abierto.
> T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
Esta es un ACK a un puerto abierto. Notar que no tenemos un Resp=
aqui. Esto significa que la falta de respuesta (como el paquete que
haya sido "soltado" por la red o un firewall malevolo) no descalificara
correspondecia mientras todas las otras pruebas correspondan. Hacemos
esto porque virtualmente cualquier SO mandara una respuesta, asi que
la falta de esta es generalmente un atributo de las condiciones de
la red y no de el SO en si. Ponemos la etiqueta de Resp en las pruebas
2 y 3 porque algunos sistemas operativos si "suelta" esos sin
responder.
> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
> T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
Estas pruebas son SYN, ACK, y FIN|PSH|URG, respectivamente, a un
puerto cerrado. Las mismas opciones estan puestas, como siempre. Claro
que esto es probablemente obvio dado los nombres descriptivos 'T5',
'T6' y 'T7' :).
> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Este grandulon es la prueba de mensaje de 'puerto inalcanzable'. Ya
deberias reconocer el DF=N a estas alturas. TOS=0 significa que el
campo de tipo de servicio IP era 0. Los siguientes dos campos dan los
valores (hex) del campo de longitud total de IP del encabezado IP del
mensaje y la longitud total dada en el encabezado IP que nos regresan
por eco a nosotros. RID=E significa que el valor RID que obtuvimos
en la copia de nuestro paquete UDP original se esperaba (por ejemplo
el mismo que mandamos). RIPCK=F significa que no fregaron la suma de
control (si lo hicieron, diria RIPCK=F). UCK=E significa que la suma de
control UDP tambien esta correcta. Despues viene la longitud UDP que era
0x134 y DAT=E significa que hicieron un eco de nuestro UDP correctamente.
Ya que la mayoria de las implantaciones (incluyendo esta) no envian
ninguno de nuestros datos UDP de regreso, obtienen DAT=E por omision.
La version de nmap con esta funcionalidad esta actualmente en el 6to
ciclo beta privado. Puede haber salido cuando lean esto en Phrack.
Pero a lo mejor, tal vez no. Vean http ://insecure.org/nmap/
para la version mas reciente.
VISTAS DE SITIOS POPULARES
Aqui estan los divertidos resultados de nuestro esfuerzo. Ahora podemos
tomar sitios de internet de manera aleatoria y determinar que tipo
de SO estan usando. Mucha de esta gente ha eliminado los letreros
telnet, etc. para tratar de mantener esta informacion privada.
Pero esto no sirve de nada con nuestro nuevo identificador! Ademas
esta es una buena manera de descubrir a los usuarios de <tu SO basura
preferido> como los maletas que son :)!
El comando usado en este ejemplo fue: nmap -sS -p 80 -O -v <host>
Tambien noten que muchas de estas exploraciones fueron hechas el 18/10/98.
Algunas de estas gentes pueden haber actualizado/cambiado sus servidores
desde entonces.
Notar que algunos sitios no me gustan.
# sitios "Hacker" o (en un par de casos) sitios que piensan que son
www.l0pht.com => OpenBSD 2.2 - 2.4
insecure.org => Linux 2.0.31-34
www.rhino9.ml.org => Windows 95/NT # sin comentario :)
www.technotronic.com => Linux 2.0.31-34
www.nmrc.org => FreeBSD 2.2.6 - 3.0
www.cultdeadcow.com => OpenBSD 2.2 - 2.4
www.kevinmitnick.com => Linux 2.0.31-34 # liberen a Kevin!
www.2600.com => FreeBSD 2.2.6 - 3.0 Beta
www.antionline.com => FreeBSD 2.2.6 - 3.0 Beta
www.rootshell.com => Linux 2.0.35 # Cambiaron a OpenBSD despues de que
# se los caminaron.
# Proveedores, consultores de seguridad, etc.
www.repsec.com => Linux 2.0.35
www.iss.net => Linux 2.0.31-34
www.checkpoint.com => Solaris 2.5 - 2.51
www.infowar.com => Win95/NT
# Lealtad de proveedores a su SO
www.li.org => Linux 2.0.35 # Linux International
www.redhat.com => Linux 2.0.31-34 # Me pregunto que distribucion:)
www.debian.org => Linux 2.0.35
www.linux.org => Linux 2.1.122 - 2.1.126
www.sgi.com => IRIX 6.2 - 6.4
www.netbsd.org => NetBSD 1.3X
www.openbsd.org => Solaris 2.6 # Ajem :)
www.freebsd.org => FreeBSD 2.2.6-3.0 Beta
# Ligas mayores
www.harvard.edu => Solaris 2.6
www.yale.edu => Solaris 2.5 - 2.51
www.caltech.edu => SunOS 4.1.2-4.1.4 # Hola!! son los 90's :)
www.stanford.edu => Solaris 2.6
www.mit.edu => Solaris 2.5 - 2.51 # Coincidencia que tantas buenas
# escuelas parecen gustar de Sun?
# Tal vez sea el 40 %
# de descuento a .edu :)
www.berkeley.edu => UNIX OSF1 V 4.0,4.0B,4.0D
www.oxford.edu => Linux 2.0.33-34 # Rock on!
# Sitios mas maletas
www.aol.com => IRIX 6.2 - 6.4 # Ahora sabemos por que son tan inseguros :)
www.happyhacker.org => OpenBSD 2.2-2.4 # Te cansaste de que te caminaran Carolyn?
# hasta el SO mas seguro es
# inutil en las manos de un
# admin incompetente.
# Misc
www.lwn.net => Linux 2.0.31-34 # Este sitio de noticias Linux rocks!
www.slashdot.org => Linux 2.1.122
www.whitehouse.gov => IRIX 5.3
sunsite.unc.edu => Solaris 2.6
Notas: En su articulo de seguridad, Microsoft dijo sobre su seguridad
relajada: "esta suposicion ha cambiado con el paso de los años
mientras Windows NT gana popularidad vastamente por sus caracteristicas
de seguridad.". Hmm, desde donde yo estoy no parece que Windows sea muy
popular con la comunidad de seguridad :). Solo veo dos cajas Windows de
todo el grupo, y Windows es facil para nmap de distinguir ya que
esta bien quebrado (en lo referente a estandares).
Y desde luego, hay un sitio mas que debemos checar. Este es el sitio
web de la corporacion ultra-secreta Transmeta. De manera interesante
la compañia fue fundada en gran parte por Paul Allen de Microsoft,
pero emplea a Linus Trovalds. Asi que se quedan con Paul y corren NT o
se unen con los rebeldes y se hacen parte de la revolucion Linux? Veamos:
Usamos el comando:
nmap -sS -F -o transmeta.log -v -O www.transmeta.com//24
Esto dice se revise con SYN los puertos conocidos (de /etc/services), se
guarden los resultados en 'transmeta.log', siendo verbosos al respecto,
hacer un chequeo de SO, y revisar la subred clase 'C' donde
www.transmeta.com reside. Aqui estan los resultados:
neon-best.transmeta.com (206.184.214.10) => Linux 2.0.33-34
www.transmeta.com (206.184.214.11) => Linux 2.0.30
neosilicon.transmeta.com (206.184.214.14) => Linux 2.0.33-34
ssl.transmeta.com (206.184.214.15) => Linux unknown version
linux.kernel.org (206.184.214.34) => Linux 2.0.35
www.linuxbase.org (206.184.214.35) => Linux 2.0.35 ( posiblemente la misma
maquina de arriba )
Bueno, creo que esto contesta a nuestra pregunta de manera clara :).
AGRADECIMIENTOS
La unica razon por la que Nmap puede detectar tantos sistemas operativos
actualmente es que mucha gente del equipo beta privado puso mucho esfuerzo
para buscar nuevas y excitantes cajas para identificar! En particular,
Jan Koum, van Hauser, Dmess0r, David O'Brien, James W. Abendschan, Solar
Designer, Chris Wilson, Stuart Stock, Mea Culpa, Lamont Granquist,
Dr. Who, Jordan Ritter, Brett Eldridge, y Pluvius mandaron toneladas de
direcciones IP de cajas raras y/o huellas de maquinas no alcanzables
desde la Internet.
Gracias a Richard Stallman por escribir GNU Emacs. Este articulo no
estaria tan bien acomodado si estuviera usando vi o cat y ^D.
Preguntas o comentarios pueden ser mandados a fyodor@insecure.org (en ingles!)
(si eso no funciona por alguna razon, usar fyodor@insecure.org ).
Nmap puede ser obtenido de http://insecure.org/nmap .
