|-----------------------------------------------------------------------------|
  [ 7a69#15 ]                                                  [ 23-11-2003 ]
 \                                                                           /
  \-------------------------------------------------------------------------/
   { 4 - Evadiendo la deteccion de OS por fingerprint             }{ tomac }
   |-----------------------------------------------------------------------|



Un enfoque prctico para engaar la deteccin remota de SO de Nmap

   tomac

   <tomac@somoslopeor.com>

   La deteccin remota de SO es est haciendo cada vez ms
   popular, no slo para los auditores de redes, sino tambin
   para cualquier atacante. Ya que Nmap es cada vez ms popular
   como la herramienta utilizada para adivinar qu SO est
   corriendo en un sistema remota, estn surgiendo algunas
   herramientas de seguridad para engaanar a Nmap en su
   propsito de la deteccin de SO. Este artculo describe
   diferentes mtodos para engaar a Nmap y comportarse como
   cualquier otro sistema operativo elegido, as como
   demostraciones de cmo se realiza.
     _________________________________________________________

   Tabla de contenidos
   1. Introduccin
   2. Razones para ocultar tu SO al mundo
   3. Nmap
   4. Soluciones de Linux

        4.1. IP Personality
        4.2. Parche Stealth
        4.3. Fingerprint Fucker
        4.4. IPlog

   5. Soluciones *BSD

        5.1. Blackhole
        5.2. Fingerprint Fucker
        5.3. OpenBSD packet filter
        5.4. FreeBSD TCP_DROP_SYNFIN

   6. Soluciones generales
   7. Ms cosas para jugar
   8. Conclusin
   Referencias

1. Introduccin

   El propsito de este artculo es intentar enumerar y describir
   brevemente todas las aplicaciones y tcnicas desarrolladas
   para engaar la deteccin remota de SO de Nmap, pero en
   cualquier caso, la seguridad por oscuridad no es ninguna buena
   solucin; puede ser una buena medida de seguridad, pero por
   favor, ten en cuenta que es ms 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. Supn que encuentran un puerto
   abierto en su (aprobada o no) penetracin; saber el SO hace
   que encontrar y ejecutar un exploit contra ese servicio sea
   ms fcil, ya que a menudo los exploitsson para versiones
   especficas de SO, y un exploit para Sendmail sobre HP-UX no
   funcionar para Sendmail sobre AIX, o para ser ms 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
   artculo sobre la deteccin remota de SO, describiendo algunos
   mtodos diferentes de detectar con xito el SO remoto, desde
   los mtodos ms bsicos, hasta los ms complejos.

   Al principio, adivinar el SO remoto se haca mirando el banner
   de un servicio especfico. Por ejemplo, un tpico banner de
   telnet o ftp siempre era mostrado a todo el mundo, diciendo
   que SO estaba siendo ejecutado; o si el banner haba sido
   quitado o cambiado, se podan ejecutar algunos comandos para
   conocer el SO (recuerda el SYST en el FTP). Otros mtodos
   bsicos para conocer el SO pueden ser buscar entradas HINFO en
   el servidor DNS, o intentar conseguir informacin usando snmp
   (un montn 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 ingeniera social son
   mtodos vlidos de intentar averiguar el SO remoto.

   Despus, se desarrollaron algunas soluciones ms avanzadas,
   aprovechndose 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 implementacin comn para todos los SO, y este
   hecho permite crear una clasificacin de los SO y versiones de
   acuerdo a sus respuestas. De esta forma es como funcionan las
   herramientas de deteccin remota de SO; algunas de ellas
   usando el protocolo TCP/IP, y otras usando el protocolo ICMP.

   Hay un artculo sobre'Defeating TCP/IP Stack Fingerprinting'
   que describe en un modo terico el diseo y la implementacin
   de un programa de recogida de implementaciones de pilas
   TCP/IP. Ese artculo describe cmo y porqu puedes vencer a la
   deteccin de SO, por lo que no voy hablar mucho sobre ello;
   por lo tanto, me centrar en la soluciones que podemos usar y
   estn disponibles.
     _________________________________________________________

2. Razones para ocultar tu SO al mundo

   Quizs 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 ms
       fcil.
     * Tener un SO no parcheado o una verson antigua no es muy
       conveniente para el prestigio de tu compaia. Imagina que
       tu compaia es un banco y algunos usuarios se dan cuenta
       de que tienes varias mquinas sin parchear. No creo que
       confen ms en ti. Adems, este tipo de 'malas' noticias
       siempre salen a la luz pblica.
     * El conocer el SO que tienes puede llegar a ser ms
       peligroso, porque la gente puede adivinar que aplicaciones
       ests ejecutando en ese SO (inferencia de datos). Por
       ejemplo, si tu sistema es MS Windows, y ests ejecutando
       un base de datos, es muy probable que ests ejecutando
       MS-SQL.
     * Puede llegar a ser conveniente para otras compaias 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 ests ejecutando.
     _________________________________________________________

3. Nmap

   Nmap 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
   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 Dr
eamcast */
        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, tamao de ventanta 0x1d4c, b
it no fragmentar
        no activado, y slo 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, rec
onocimiento seq,
        tamao 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 p
uerto abierto.
        Obtenemos un SYN+ACK, reconocimiento seq +1, tamao de ventana
0x1d4c, el
        bit no fragmentar no activado, y slo 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. Obten
emos un RST,
        reconocimiento seq, tamao 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 c
errado. Obtenemos
        un ACK+RST, reconocimiento seq, tamao de ventana 0x0, bit de n
o 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, tamao 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, tamao 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 engaar a Nmap y decir al atacante que
   estamos corriendo un sistema operativo diferente, slo
   necesitamos engaar las respuestas a los tests de Nmap. La
   solucin que voy a describir es slo vlida para engaar Nmap
   pero no a todas las herramientas de deteccin remota de SO. En
   la Conclusin otras herramientas sern mencionadas, as como
   algunas recomendaciones para el auditor de sistemas y/o el
   atacante.
     _________________________________________________________

4. Soluciones de Linux

   Los mtodos para engaar la deteccin remota de SO de Nmap
   estn escritos como mdulos del kernel, o al menos, como
   parches al kernel de Linux. La razn 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 mdulos del kernel, todos ellos
   independientes del rbol del kernel de Linux; tienes que
   descargarlos y parchear tu kernel para aadirlos. 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 opcin es IP Personality.
   Es un mdulo de netfilter (por lo tanto, slo disponible para
   kernels 2.4) que permite cambiar el comportamiento de la pila
   IP, pudiendo tener mltiples personalidades dependiendo de los
   parmetros que le especifiques en una regla de iptables. De
   hecho, podemos cambiar las siguientes opciones:

     * Nmero de Secuencia Inicial TCP (ISN)
     * Tamao inicial de ventana TCP
     * Opciones TCP (sus tipos, valores y orden en el paquete)
     * IP nmeros de ID
     * respuestas a algunos paquetes TCP 'anmalos'
     * 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 paquetes queremos responder de esa forma (puede ser
   dependiendo de la direccin ip origen, el puerto destino, o, y
   es lo que vamos a usar, esos paquetes especiales que manda
   Nmap)

   La instalacin es bastante sencilla y bien explicada en el
   fichero INSTALL que viene en el paquete; para nuestros
   propsitos, nuestra mquina de pruebas es una Debian stable
   con un kernel 2.4.19. Por defecto, el mdulo de netfilter de
   IP Personality no est disponible en los ltimos kernels, as
   que tenemos que parchear el cdigo fuente del kernel. El
   parche para aadir IP Personality a nuestras fuentes de
   netfilter est disponible en la pgina del programa. Tambin
   necesitamos parchear nuestro comando iptables para que
   reconozca nuestra nueva opcin. Una vez que el kernel ha sido
   parcheado y compilado, necesitamos reiniciar la mquina ya que
   el parche modifica otros ficheros de netfilter (connection
   tracking)

   El siguiente paso es incluir nuestras reglas de iptables
   relacionadas con IP Personality en nuestro kernel. Antes de
   hacerlo, ejecutamos Nmap para ver que SO tenemos:
           # nmap (V. 3.10ALPHA4) scan initiated Wed Feb 19 20:26:52 20
03 as: nmap -sS -O -oN nmap1.log 192.168.0.19
           Interesting ports on 192.168.0.19:
           (The 1597 ports scanned but not shown below are in state: cl
osed)
           Port       State       Service
           22/tcp     open        ssh
           25/tcp     open        smtp
           80/tcp     open        http
           143/tcp    open        imap2
           Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
           Uptime 106.832 days (since Tue Nov  5 00:29:33 2002)
           # Nmap run completed at Wed Feb 19 20:26:58 2003 -- 1 IP add
ress (1 host up) scanned in 7.957 seconds


   Ahora, podemos reiniciar en nuestro nuevo kernel parcheado, y
   aadir las reglas iptables para engaar a Nmap:
           voodoo:~/ippersonality-20020819-2.4.19/samples#/usr/local/sb
in/iptables -t mangle -A PREROUTING -s 192.168.0.50 -d192.168.0.19 -j P
ERS --tweak dst --local --conf dreamcast.confi
           voodoo:~/ippersonality-20020819-2.4.19/samples#/usr/local/sb
in/iptables -t mangle -A OUTPUT -s 192.168.0.19 -d192.168.0.50 -j PERS
--tweak src --local --conf dreamcast.conf


   Lo que estamos haciendo con estas reglas es:

     * La primera significa que todos los paquetes que vengan de
       192.168.0.50 (yo) contra 192.168.0.19 (servidor) tienen
       que ser modificados y reescritos para simular una
       Dreamcast. La cadena de PREROUTING es la que lo tiene que
       hacer.
     * La segunda significa que todos los paquetes que vengan de
       192.168.0.19 (servidor) contra 192.168.0.50 (yo) tienen
       que ser modificados y reescritos para simular una
       Dreamcast. Como son paquetes que salen del servidor,
       tenemos que usar la cadena OUTPUT

   Comprobamos nuestra configuracin:
           voodoo:~/ippersonality-20020819-2.4.19/samples#/usr/local/sb
in/iptables -L -t mangle
           Chain PREROUTING (policy ACCEPT)
           target     prot opt source            destination
           PERS       all      192.168.0.50      192.168.0.19   tweak:d
st local id:Dreamcast
           Chain INPUT (policy ACCEPT)
           target     prot opt source            destination
           Chain FORWARD (policy ACCEPT)
           target     prot opt source            destination
           Chain OUTPUT (policy ACCEPT)
           target     prot opt source            destination
           PERS       all      192.168.0.19      192.168.0.50   tweak:s
rc local id:Dreamcast
           Chain POSTROUTING (policy ACCEPT)
           target     prot opt source            destination


   Ahora podemos ver si Nmap todava nos dice que tenemos Linux
   kernel 2.4.0-2.5.20 o quizs averiguamos que nuestro SO ha
   cambiado:
           # nmap (V. 3.10ALPHA4) scan initiated Wed Feb 19 21:49:18 20
03 as: nmap -sS -O -oN nmap2.log 192.168.0.19
           Interesting ports on 192.168.0.19:
           (The 1597 ports scanned but not shown below are in state: cl
osed)
           Port       State       Service
           22/tcp     open        ssh
           25/tcp     open        smtp
           80/tcp     open        http
           143/tcp    open        imap2
           Remote operating system guess: Sega Dreamcast
           # Nmap run completed at Wed Feb 19 21:49:23 2003 -- 1 IP add
ress (1 host up) scanned in 5.886 seconds


   Como puedes ver, hemos engaado a Nmap con nuestra respuesta.
   Es fcil elegir qu SO queremos 'ejecutar' en el fichero de
   firmas de SO de Nmap y decir a IP Personality que se comporte
   como el SO elegido. Vamos a ver el fichero dreamcast.conf que
   hemos especificado al aadir nuestras reglas de iptables:
           /* Nuestra nueva identificacin de SO */
           id "Dreamcast";

           /* slo los paquetes que entran sern cambiados pero el tama
o de ventana TCP no ser cambiado */
           tcp {
             incoming yes;
             outgoing no;
             max-window 32768;
           }

           /* Necesitamos emular el generador de ISN de la Dreamcast qu
e es dependiente del tiempo; esto lo
           podemos hacer usando el generador fixed-inc y un pequeo inc
remento */
           tcp_isn {
             type fixed-inc 2;
             initial-value random;
           }

           tcp_options {
             keep-unknown yes;
             keep-unused no;
             isolated-packets yes;
             code { copy(mss); }
           }

           /* ahora podemos seguir la firma de la Dreamcast y comportar
nos como ella */
           tcp_decoy {
             code {
               if (option(mss)) { /* nmap tiene mss en todos sus paquet
es */
                 set(df, 0);
                 if (listen) {
                   if (flags(syn&ece)) { /* nmap test 1 */
                     set(win, 0x1D4C);
                     set(ack, this + 1);
                     set(flags, ack|syn);
                     insert(mss, this+1);
                     reply;
                   }
                   if (flags(null)) { /* nmap test 2 */
                     set(win, 0);
                     set(ack, this);
                     set(flags, ack|rst);
                     reply;
                   }
                   if (flags(syn&fin&urg&push)) { /* nmap test 3 */
                     set(win, 0x1D4C);
                     set(ack, this + 1);
                     set(flags, ack|syn);
                     insert(mss, this+1);
                     reply;
                   }
                   if (ack(0) && flags(ack) && !flags(syn|push|urg|rst)
) { /* nmap test 4 */
                     set(win, 0);
                     set(ack, this);
                     set(flags, rst);
                     reply;
                   }
                 } else {
                   set(win, 0);
                   if (flags(syn) && !flags(ack)) { /* nmap test 5 */
                     set(ack, this);
                     set(flags, ack|rst);
                     reply;
                   }
                   if (ack(0) && flags(ack) && !flags(syn|push|urg|rst)
) { /* nmap test 6 */
                     set(ack, this);
                     set(flags, rst);
                     reply;
                   }
                   if (flags(fin&push&urg)) { /* nmap test 7 */
                     set(ack, this + 1);
                     set(flags, ack|rst);
                     reply;
                   }
                 }
               }
             }
           }

           /* No respondemos con ICMP a conexiones a puertos UDP cerrad
os */
           udp_unreach {
             reply no;
             df no;
             max-len 56;
             tos 0;

             mangle-original {
               ip-len 32;
               ip-id same;
               ip-csum zero;
               udp-len 308;
               udp-csum same;
               udp-data same;
             }
           }


   IP Personality es an ms poderoso. Puedes configurar un
   firewall/router Linux que cambiar la respuesta de las
   mquinas detrs de l. Todos las mquinas que estn detrs de
   tu router Linux pueden parecer consolas Sega Dreamcast para
   tus atacantes!.

   Tambin hay un interesante parche para Nmap en el mismo sitio,
   llamado osdet, que nos permite hacer una deteccin remota de
   SO usando el motor de Nmap, pero con la interesante
   caracterstica de que vemos los paquetes que mandamos y
   recibimos en formato de tcpdump. Algunas veces viene muy bien
   y nos ayuda a comprender la tcnica de deteccin remota de SO
   el ver los paquetes corriendo por tu pantalla (todos los tests
   de Nmap y sus respuestas).
     _________________________________________________________

4.2. Parche Stealth

   La solucin que se va a describir ahora es el parche stealth ,
   disponible en Security Technologies. Est disponible como
   mdulo del kernel para kernels de Linux 2.2.x (y en un futuro
   cercano para 2.4.x), y cmo un parche del kernel (para kernels
   de Linux 2.4.x sin soporte de mdulos). Para comprobar su
   funcionamiento, usamos el parche para el kernel 2.4.19; una
   vez parcheado, aparecen dos nuevas opciones en nuestro fichero
   de configuracin:

     * IP: TCP Stack Options: opcin que tenemos que seleccionar
       si queremos usar el parche stealth Si seleccionas esta
       opcin, se activa por defecto cuando arrancas el sistema.
       Para deshabilitarlo, necesitas ejecutar:
           echo 0 > /proc/sys/net/ipv4/tcp_ignore_ack
           echo 0 > /proc/sys/net/ipv4/tcp_ignore_bogus
           echo 0 > /proc/sys/net/ipv4/tcp_ignore_synfin

     * Log all dropped packets: guarda todos los paquetes con
       opciones extraas.

   Este parche simplemente ignora los paquetes TCP/IP recibido
   que cumplan las siguientes caractersticas:

    1. Paquetes con SYN y FIN activado (tcp_ignore_synfin) (test
       de QueSO).
    2. Paquetes Bogus: si la cabecera TCP tiene el bit res1
       activo (uno de los bits reservados, entonces es un paquete
       bogus) o si no tiene nada de lo siguiente activado: ACK,
       SYN, RST o FIN (test 2 Nmap).
    3. Paquetes con FIN, PUSH y URG activado (test 7 Nmap).

   Esta es una solucin ms simple que la que hemos descrito
   antes. No podemos comportarnos como cualquier otro Sistema
   Operativo, ya que simplemente ignoramos todos los paquetes
   'extraos' que se supone que estn dirigidos a adivinar
   nuestro SO, y esperamos que sea suficiente para engaar a
   nuestro atacante, o al menos, poner las cosas ms difciles.
   Estas modificaciones al kernel son fciles de comprender, y es
   relativamente fcil aadir nuestras frmulas caseras para la
   deteccin de 'paquetes malvados'.
     _________________________________________________________

4.3. Fingerprint Fucker

   Fingerprint Fucker es un mdulo del kernel disponible para
   kernels 2.2.x que puede tambin esconder tu SO y comportarse
   como otro. Es un mdulo que acepta parmetros desde la lnea
   de comandos para configurar su respuesta. Por defecto, simula
   un VAX. Tambin contiene un fichero, llamado fing_parses.c,
   que recorre un fichero de firmas de Nmap y carga el mdulo de
   Fingerprint Fucker con los parmetros correctos (al ejecutar
   fing_parses , tienes que especificar que SO quieres emular).
   Entonces espera a recibir los paquetes de Nmap, y responde
   cmo le hayas configurado. Hasta donde he podido comprobar,
   slo algunos tests de Nmap son tratados (T1, T2 y T7). 

   Atencin

   El cdigo no es muy estable. Momentos despus de cargar el
   modulo mi mquina Linux se colg.
     _________________________________________________________

4.4. IPlog

   IPlog es un logger de TCP/IP que tambin detecta algunos
   >scans (XMAS, FIN, SYN, ...). Para nuestros propsitos, tiene
   una opcin (-z) que permite engaar a los intentos de Nmap, y,
   aun cuando no podemos comportarnos como otro SO, podemos
   engaar totalmente a Nmap en su intento de adivinar
   remotamente nuestro SO.

   Al ejecutar iplog, observamos los resultados:
        voodoo:~#iplog -o -L -z -i eth0


   Las opciones son las siguientes: -o (qudate en primer plano),
   -L (resultados a la salida estndar), -z (engaa a Nmap), -i
   eth0 (escucha en eth0). Si ejecuto un Nmap contra la mquina,
   iplogempieza a escribir un montn de informacin a la salida
   estndar, sobre todas las conexiones establecidas, e incluso
   sobre qu tipo de scan est siendo llevado a cabo; he incluido
   slo la informacin relevante sobre la identificacin de SO de
   Nmap en la salida de iplog
        Feb 20 13:20:54 TCP: SYN scan detected [ports 10082,1430,770,81
5,440,86,848,797,560,5998,...] from 192.168.0.50 [port 49047]
        Feb 20 13:20:56 TCP: Bogus TCP flags set by 192.168.0.50:49054
(dest port 22)
        Feb 20 13:20:56 UDP: dgram to port 1 from 192.168.0.50:49047 (3
00 data bytes)
        Feb 20 13:20:56 ICMP: 192.168.0.50: port is unreachable to (udp
: dest port 1, source port 49047)
        Feb 20 13:20:58 UDP: dgram to port 1 from 192.168.0.50:49047 (3
00 data bytes)
        Feb 20 13:20:58 ICMP: 192.168.0.50: port is unreachable to (udp
: dest port 1, source port 49047)
        Feb 20 13:21:01 UDP: dgram to port 1 from 192.168.0.50:49047 (3
00 data bytes)
        Feb 20 13:21:01 ICMP: 192.168.0.50: port is unreachable to (udp
: dest port 1, source port 49047)
        Feb 20 13:21:04 TCP: Xmas scan detected [ports 1,9,49055,49056,
49054] from 192.168.0.50 [ports 49060,49056,49054,9]
        Feb 20 13:21:05 UDP: dgram to port 1 from 192.168.0.50:49047 (3
00 data bytes)
        Feb 20 13:21:05 ICMP: 192.168.0.50: port is unreachable to (udp
: dest port 1, source port 49047)
        Feb 20 13:21:12 TCP: null scan detected [ports 9,49056,49060,49
054] from 192.168.0.50 [ports 49055,9,1,49056,49054,...]
        Feb 20 13:21:13 TCP: FIN scan detected [ports 49060,49054,9,1]
from 192.168.0.50 [ports 1,9,49055,49056,49054,...]
        Feb 20 13:21:56 TCP: SYN scan mode expired for 192.168.0.50 - r
eceived a total of 1647 packets (33440 bytes).
        Feb 20 13:21:56 TCP: Xmas scan mode expired for 192.168.0.50 -
received a total        of 33812 packets (676300 bytes).
        Feb 20 13:22:03 TCP: null scan mode expired for 192.168.0.50 -
received a total of 16462 packets (329300 bytes).
        Feb 20 13:22:04 TCP: FIN scan mode expired for 192.168.0.50 - r
eceived a total of 16343 packets (326860 bytes)


   Iplogreconoce los paquetes TCP bogus, los paquetes TCP
   'vacos', todos los intentos de reconocimiento remoto de Nmap.
   Esa es la razn por la que puede actuar consecuentemente y
   mandar una respuesta errnea para engaar a Nmap. La salida de
   Nmap es la siguiente:
        # nmap (V. 3.10ALPHA4) scan initiated Thu Feb 20 13:20:54 2003
as: nmap -vv -sS -O -oN nmap3.log 192.168.0.19
        Insufficient responses for TCP sequencing (1), OS detection may
 be less accurate
        Insufficient responses for TCP sequencing (1), OS detection may
 be less accurate
        Insufficient responses for TCP sequencing (1), OS detection may
 be less accurate
        Interesting ports on voodoo (127.0.0.1):
        (The 1599 ports scanned but not shown below are in state: close
d)
        Port       State       Service
        22/tcp     open        ssh
        25/tcp     open        smtp
        80/tcp     open        http
        143/tcp    open        imap2
        No exact OS matches for host (If you know what OS is running on
 it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
        TCP/IP fingerprint:
        SInfo(V=3.10ALPHA4%P=i586-pc-linux-gnu%D=2/20%Time=3E54C833%O=9
%C=1)
        T1(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
        T2(Resp=Y%DF=N%W=0%ACK=O%Flags=BA%Ops=)
        T2(Resp=Y%DF=Y%W=100%ACK=O%Flags=BARF%Ops=)
        T2(Resp=Y%DF=Y%W=100%ACK=O%Flags=BPF%Ops=)
        T3(Resp=Y%DF=N%W=0%ACK=O%Flags=BA%Ops=)
        T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
        T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
        T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
        T7(Resp=Y%DF=N%W=0%ACK=O%Flags=BA%Ops=)
        T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
        PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%U
LEN=134%DAT=E)

        # Nmap run completed at Thu Feb 20 13:21:07 2003 -- 1 IP addres
s (1 host up) scanned in 13.633 seconds


   Como podis ver, iplog responde a todos los paquetes que enva
   Nmap; veamos el cdigo fuente de iplog
         file iplog_tcp.c, line 99:

         if (opt_enabled(FOOL_NMAP) &&
         ((tcp_flags & TH_BOG) || (tcp_flags == TH_PUSH) || (tcp_flags
== 0) ||
         ((tcp_flags & (TH_SYN | TH_FIN | TH_RST)) && (tcp_flags & TH_U
RG)) ||
         ((tcp_flags & TH_SYN) && (tcp_flags & (TH_FIN | TH_RST)))))


   Esa sentencia 'if' significa que si hemos ejecutado iplog con
   la opcin '-z' (engaar Nmap), y si las opciones de la
   cabecera TCP son:

     * bogus (uso de los bits reservados), o
     * slo PUSH , o
     * NULL (sin opciones), o
     * SYN+URG, FIN+URG, RST+URG, o
     * SYN+FIN, SYN+RST

   entonces crear un nuevo paquete para responder con las
   opciones que queramos (algunas opciones dependen en la hora de
   la mquina, por ejemplo DF, esta es la razn por la que
   algunas veces es 1 y otras 0, o el tamao de ventana, que est
   definido como current_time & 1).

   Naturalmente podemos cambiar el fichero iplog_tcp.c para que
   iplog siempre se comporte como una Sega Dreamcast contra esos
   paquetes malvados, pero no tenemos la flexibilidad de tener
   mltiples personalidades o de especificar que queremos
   comportarnos como una Dreamcast slo para un trfico
   especfico o una direccin ip especfica. Es una buena idea
   responder de esta manera a estos paquetes 'anormales', pero es
   mejor tener el control sobre ello, y que sea ms granular.
     _________________________________________________________

5. Soluciones *BSD

5.1. Blackhole

   Blackhole es una opcin especial presente en el kernel *BSD
   para controlar el comportamiento del sistema cuando alguien se
   conecta a puertos TCP o UDP cerrados. Hay dos opciones que
   podemos cambiar:
         sysctl -w net.inet.tcp.blackhole=[0 | 1 | 2]
         sysctl -w net.inet.udp.blackhole=[0 | 1]


   Blackhole TCP se comporta de la forma siguiente: si el valor
   es 0, cuando un paquete se conecta a un puerto TCP cerrado, se
   devuelve un RST. Si el valor es 1, si un paquete SYN se llega
   un puerto TCP cerrado, se ignora; y si el valor es 2, tambin
   se ignora.

   Blackhole UDP es similar; si el valor es 0, cualquier conexin
   a un puerto UDP cerrado, devuelve un paquete ICMP port
   unreachable; si el valor es 1, entonces no lo devuelve.

   Si activamos estas opciones, los tests 5, 6 y 7, y el test del
   port unreachable no funcionarn, por lo que no seremos capaces
   de conocer el SO.
     _________________________________________________________

5.2. Fingerprint Fucker

   Existe tambin otro Fingerprint fucker para los sistemas
   FreeBSD, escrito por Darren Reed, que simplemente reescribe la
   pila TCP/IP y manda paquetes con otras opciones (diferente
   tamao de ventana, ttl, ...) intentando ocultar su verdadero
   SO.
     _________________________________________________________

5.3. OpenBSD packet filter

   El OpenBSD packet filter puede ser tambin configurado para
   engaar la identificacin remota de SO. Hay algunas opciones
   en el fichero de configuracin ip.conf(Normalizacin del
   trfico) donde puedes cambiar algunos campos del paquete IP
   (bit DF, TTL, MSS, ID), tal como se puede ver en la pgina de
   manual de ip.conf:
           no-df
           Pone a cero el bit de no fragmentar del paquete ip.

           min-ttl _numero_
           Asigna un ttl mnimo para el paquete ip.

           max-mss _numero_
           Asigna un mximo mss para el paquete ip.

           random-id
           Remplaza el campo de identificacin IP con valores aleatorio
s para
           compensar los valores predecibles generados por muchas mqui
nas. Esta
           opcin slo se aplica a los paquetes de salida que no son fr
agmentados
           despus del opciones reemsamblado de paquetes.

     _________________________________________________________

5.4. FreeBSD TCP_DROP_SYNFIN

   El kernel de FreeBSD tiene una opcin especial,
   TCP_DROP_SYNFIN, que ignora todos los paquetes con SYN y FIN
   activados (el test #3 de Nmap manda un paquete TCP con
   SYN+FIN+PSH+URG) ; esta opcin puede ser tambin un mtodo
   vlido para engaar a Nmap cuando realiza sus tests (acurdate
   de activarlo en el arranque en el fichero /etc/rc.conf).
     _________________________________________________________

6. Soluciones generales

   Hemos visto al hablar de IP Personality que podemos configurar
   un router linux protegiendo a nuestra red interna, y ese
   router podra engaar a Nmap y otras herramientas de deteccin
   de SO en sus intentos de adivinar remotamente el SO de
   nuestras mquinas de la red interna. Si no tenemos una mquina
   linux, pero tenemos un Checkpoint FW-1 , entonces podemos
   hacer algo similar gracias al lenguaje INSPECT. Usando este
   lenguaje, es fcil crear nuestro propio 'inspector de
   paquetes' para los paquetes que atraviesan nuestro fw-1.
   Existe una referencia en la lista de correo de FW-1
   describiendo un servicio fw-1 para tratar estos paquetes
   bogus.
     _________________________________________________________

7. Ms cosas para jugar

   La siguiente solucin no nos permite ocultar o cambiar nuestro
   SO, pero seremos capaces de crear tantos dispositivos
   virtuales como queramos con cualquier Sistema Operativo que
   podamos imaginar. Esta idea est siendo aplicada en el tema de
   los honeypots, simplemente porque puedes crear una clase C
   entera virtual con un montn de diferentes SO ejecutndose; el
   atacante puede ser fcilmente atrado por todas esas mquinas
   corriendo tantos servicios vulnerables...Puede ser la panacea
   que busca todo atacante.

   Los honeypots en general, y esta aproximacin en particular,
   es altamente recomendable no slo para aprender las
   herramientas y tcticas de los atacantes, sino tambin para
   redirigir a los atacantes contra tu honeynet y no contra tus
   mquinas en produccin. Puede tambin hacer creer a a los
   atacantes que tienes muchas mquinas de un SO especfico (el
   virtual) y ocultar tu SO real.

   El programa que voy a describir brevemente es honeyd, de Niels
   Provos. Una de sus grandes caractersticas es que podemos
   asignar a cada una de nuestros dispositivos virtuales el SO
   que queramos. Esa personalidad tambin se especifica con un
   fichero normal de firmas de SO de Nmap, permitindonos
   convertirnos en el SO que queramos. No voy a describir con
   detalles esta gran herramienta, simplemente voy a ejecutar la
   configuracin que viene como ejemplo para demostrar de lo que
   es capaz.

   Despus de instalarlo, hay un fichero que se llama
   config.localhost con un montn de dispositivos configurados.
   Por ejemplo, si vemos la definicin del dispositivo 10.0.0.1:
        route entry 10.0.0.1
        route 10.0.0.1 link 10.0.0.0/24
        [snip]
        create routerone
        set routerone personality "Cisco 7206 running IOS 11.1(24)"
        set routerone default tcp action reset
        add routerone tcp port 23 "router-telnet.pl"
        [snip]
        bind 10.0.0.1 routerone
        [snip]


   La explicacin a grandes rasgos es que tenemos un dispositivo
   cuya direccin ip es 10.0.0.1, que se comportar como un Cisco
   7206 ejecutando una IOS 11.1(24), resetear todas las
   conexiones TCP menos las que vayan al puerto 23, ya que
   entonces el script router-telnet.pl (una emulacin del demonio
   telnet) ser ejecutado. Bien, ejecutemos Nmap para comprobar
   el SO que se ejecuta en el dispositivo virtual que acabamos de
   crear:
        # nmap (V. 3.10ALPHA4) scan initiated Thu Feb 20 16:17:44 2003
as: nmap -v -sS -oN nmap4.log -O 10.0.0.1
        Warning:  OS detection will be MUCH less reliable because we di
d not find at least 1 open and 1 closed TCP port
        Interesting ports on 10.0.0.1:
        (The 1604 ports scanned but not shown below are in state: filte
red)
        Port       State       Service
        23/tcp     open        telnet
        Remote OS guesses: Cisco 7206 running IOS 11.1(24), Cisco 7206
 (IOS 11.1(17)
        TCP Sequence Prediction: Class=random positive increments
        Difficulty=26314 (Worthy challenge)
        IPID Sequence Generation: Incremental

        # Nmap run completed at Thu Feb 20 16:20:42 2003 -- 1 IP addres
s (1 host up) scanned in 178.847 seconds


   De nuevo, cuando recibimos los paquetes bogus de Nmap, honeyd
   responde con la personalidad que hemos escogido.
     _________________________________________________________

8. Conclusin

   Tal como se dice en IP Personality Limitations, el cambiar
   nuestra pila TCP/IP nos puede crear algunos problemas:

     * algunas caractersticas de los SO estn relacionadas con
       la arquitectura de la mquina (por ejemplo el tamao de
       pgina en varias CPU), lo que podra conllevar problemas
       de eficiencia.
     * algunos de estos cambios son cambios 'polticos' de la
       pila IP (nmeros iniciales de secuencia, tamao de
       ventana, opciones TCP disponibles, ...). Modificarlos
       permite engaar a un scanner pero puede romper nuestra
       conectividad en la red. Puede incluso hacer que el sistema
       sea menos seguro, al cambiar nuestra pila IP por otra
       menos segura.

   En mi opinin, est bastante claro que no podemos fiarnos slo
   de una sola herramienta de seguridad para adivinar el Sistema
   Operativo. Este artculo ha mostrado que es muy fcil engaar
   a Nmap (y otras herramientas similares) cuando intentan
   detectar un SO, y que todos esos intentos pueden ser
   convenientemente guardados por el administrador remoto. Para
   detectar con xito el SO remoto, se tienen que ejecutar todos
   los posibles mtodos, empezando desde los ms simples (captura
   de banner , buscar anuncios de trabajo, ingeniera social,
   ...) hasta los ms complejos (identificacin por red). Cada
   servicio abierto en un dispositivo remoto tiene que ser
   debidamente analizado (banner, respuestas, comportamiento ante
   ataques, DoS, errores conocidos) y documentado. Puede que sea
   incluso posible (aunque no tico) ejecutar algunas
   herramientas que se sabe que 'cuelgan' versiones especficas
   de SO (nuke, land, teardrop, ...) para clarificar nuestra
   suposicin.

   Aun cuando todas estas soluciones descritas pueden ser
   modificadas para detectar y engaar cualquier otra herramienta
   de deteccin de SO basada en TCP/IP (simplemente sabiendo qu
   paquetes manda), es bastante recomendable usar varias
   herramientas al intentar averiguar un SO remoto. Nmap es
   quizs la ms usada, pero tambin existe otra herramienta que
   funciona bien: Xprobe. Xprobe tiene tambin una base de datos
   de firmas (no actualizada muy a menudo), y la suposicin final
   es una suposicin probabilstica (fuzzy matching) dependiendo
   de varias respuestas. Uno de los mayores problemas de Xprobe
   es que no se actualizada muy a menudo, e incluye muy pocas
   firmas. Nmap detecta el SO remoto si el resultado de sus tests
   es igual a la firma de ese SO en la base de datos, pero
   tambin puedes ejecutar Nmap con la opcin --osscan_guess o
   --fuzzy, y entonces realiza una bsqueda de SO ms agresiva
   encontrando la firma que ms se parece en su base de datos de
   firmas. Existe un artculo sobre la especificacin y uso de
   Xprobe donde se explica porqu su idea e implementacin parece
   ser tan buena y vlida. Pienso que se debe ejecutar
   conjuntamente con Nmap, en caso de que puedas mandar tanto
   paquetes TCP como ICMP. Xprobe puede ser una herramienta muy
   efectiva en redes no muy seguras, ya que manda paquetes ICMP
   timestamps request y ICMP netmask request, lo cual puede
   resultar muy sospechoso para un administrador de red. No enva
   paquetes bogus (paquetes TCP no muy comunes, ya que los bits
   reservados raramente son utilizados) para detectar el SO
   remoto, sino que simplemente manda trfico ICMP 'normal'
   contra la mquina de destino, haciendo ms difcil (si no
   imposible) detectar esos paquetes (y de esta forma, actuar
   consecuentemente). Este mtodo fue utilizado primero en sing
   (Send Internet Nasty Garbage), que puede ser ejecutado con la
   opcin '-O' para realizar la deteccin de SO (con el tipo de
   ICMP que elijas). Es difcil para cualquier IDS detectar que
   estos paquetes ICMP tienen una funcin extraa, ya que existe
   una gran cantidad de estos paquetes ICMP diariamente en
   nuestras redes. Por otro lado, ICMP cada vez se bloquea ms
   por defecto en casi todos los entornos de red, haciendo
   imposible hacer una deteccin remota de SO basada en ICMP,
   pero normalmente en esos casos puedes encontrar algunos
   servicios TCP y disparar tus paquetes Nmap.

   Para ser ms exactos, existe otra herramienta de deteccin
   remota de SO, llamada p0f; p0f escucha en tu red buscando por
   el primer SYN de una conexin TCP y guarda las opciones del
   paquete. Si concuerda con alguno de su base de datos de firma,
   entonces puede averiguar el SO: de nuevo, si cambiamos
   cualquiera de las opciones que busca p0f , podemos engaarlo.
   Si, por ejemplo, usamos IP Personality, podemos cambiar el
   tamao de ventana de los paquetes, y haremos que p0f no sepa
   qu SO tenemos.

   Los administradores deberan configurar con cuidado todos sus
   dispositivos para no mostrar ninguna informacin que pueda ser
   usada para identificarlos (banners, issue, servicios comunes
   abiertos por defecto, ...) y ejecutar alguna de estas
   herramientas que pueden guardar los intentos de deteccin
   remota de SO, ya que es muy probable que, esas direcciones ip
   que quieren saber tu SO, te estarn atacando tu red en breve
   tiempo. Adems, configurar un router linux usando IP
   Personality y engaar a todo el mundo de fuera de tu red
   diciendo que tienes un SO diferente (con cualquiera de las
   opciones presentadas en este artculo), puede ser una buena
   medida de seguridad.
     _________________________________________________________

Referencias

   Matthew Smart, Robert Malan, y Farnan Jahanian, Defeating
   TCP/IP Stack Fingerprinting, Usenix Security Symposium 2000,
   URL:
   http://www.usenix.org/publications/library/proceedings/sec2000
   /smart.html .

   Fyodor, Remote OS Detection via TCP/IP Stack Fingerprinting,
   June 11, 2002, URL:
   http://www.insecure.org/nmap/nmap-fingerprinting-article.html
   .

   Gael Roualland y Jean-Marc Saffroy, IP Personality, URL:
   http://ippersonality.sourceforge.net/ .

   Sean Trifero y Derek Callaway, Stealth, URL:
   http://www.innu.org/%7Esean/ .

   Ryan McCabe, IPlog, URL:
   http://ojnk.sourceforge.net/stuff/iplog.readme .

   Fusys y |CyRaX|, Fingerprint Fucker, URL:
   http://www.s0ftpj.org/tools/fingfuck.tgz .

   FreeBSD, Blackhole, URL:
   http://www.gsp.com/cgi-bin/man.cgi?section=4&topic=blackhole .

   Darren Reed, Fingerprint Fucker, URL:
   http://packetstormsecurity.org/UNIX/misc/bsdfpf.tar.gz .

   OpenBSD, ip.conf manual, URL:
   http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5
   &arch=i386&apr .

   FreeBSD, Kernel Options, URL:
   http://www.freebsd.org/doc/en_US.ISO8859-1/articles/dialup-fir
   ewall/kernel.html .

   Alfredo Andrs Omella, Trying to stop the security tool queSO,
   URL: http://www.phoneboy.com/fom-serve/cache/82.html ,
   October, 6th, 1998.

   Niels Provos, Honeyd - Network Rhapsody for You", URL:
   http://www.citi.umich.edu/u/provos/honeyd/ .

   Gael Roualland y Jean-Marc Saffroy, IP Personality
   Limitations, URL:
   http://ippersonality.sourceforge.net/doc/ippersonality-en-2.ht
   ml .

   Fyodor Yarochkin y Ofir Arkin, Xprobe, URL:
   http://www.sys-security.com/html/projects/X.html .

   Fyodor Yarochkin y Ofir Arkin, Xprobe2 - A'Fuzzy' Approach to
   Remote Active Operating System Fingerprinting, URL:
   http://www.sys-security.com/archive/papers/Xprobe2.pdf .

   Alfredo Andrs Omella, Sing, URL: http://sing.sourceforge.net
   , October, 6th, 1998.

   Michael Zalewski y William Stearns, p0f, URL:
   http://www.stearns.org/p0f/ .


*EOF*
