6.3. Obtención de respuesta provocada por contenido no válido en los campos de cabecera IP

Hay muchos campos que pueden modificarse en la cabecera de un datagrama IP. De todos ellos uno de los más interesante es el que campo llamado IP Proto que indica el protocolo de la capa superior al que hace referencia. Este campo tiene una longitud de 8 bits por lo que hay hasta 256 posibles valores.

Según las RFCs cualquier datagrama que haga referencia a un protocolo de nivel superior no soportado en el destino provocará que éste genere una respuesta ICMP de tipo 3 y código 2 indicando que el protocolo de destino no es válido (Destination Unreachable/Protocol Unreachable). Cualquier protocolo que se especifique y no genere respuesta ICMP deberá considerarse válido. De esta forma no sólo daremos a conocer la existencia de un equipo en ese destino al que estamos analizando, sino que además nos indicará cuales son los protocolos que soporta indicando de alguna forma el sistema operativo que utiliza, pues muchos protocolos no están implementados mientras que otros son característicos de ciertos fabricantes como Microsoft.

Podemos probarlo de muchísimas formas, por ejemplo usando la opción --ipproto o -H de hping, con programas en perl como apsend o con una versión reciente de nmap:

Una de las opciones avanzadas recientemente incorporadas al nmap es el escaneo de protocolos soportados, que usaremos aquí para mostrar un ejemplo:

delorian:~# nmap -sO xxx.xxx.xxx.xxx -p 1,6,17
Starting nmap V. 2.54BETA29 ( www.insecure.org/nmap/ )
Interesting protocols on  (xxx.xxx.xxx.xxx):
Protocol   State       Name
1          open        icmp                    
6          open        tcp                     
17         open        udp                     


Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

El equipo remoto no ha enviado ningún mensaje ICMP, por lo que nmap ha dado por hecho que estos protocolos están disponibles. Si bien esto es cierto en este caso pues son típicos protocolos usados en Internet, hay muchas implementaciones que no envían nunca el error de tipo 3 y código 2 indicando un protocolo no alcanzable, por lo que conviene tener cuidado.

Por ejemplo si escaneamos los protocolos disponibles contra un AIX de IBM obtendremos una respuesta similar a ésta:

delorian:~# nmap -sO xxx.xxx.xxx.xxx -p 1,6,17,254,255
Starting nmap V. 2.54BETA29 ( www.insecure.org/nmap/ )
Interesting protocols on  (xxx.xxx.xxx.xxx):
Protocol   State       Name
1          open        icmp                    
6          open        tcp                     
17         open        udp                     
254        open        unknown                 
255        open        unknown                 


Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

En el caso que acabamos de ver, el AIX que acabamos de atacar nos ha comunicado que incluso los tipos 254 y 255 están implementados en su pila de protocolos, lo que es totalmente falso.

Es bien conocido que diversas implementaciones de Unix no envían este tipo de mensajes ICMP, por ejemplo AIX, HP-UX y Digital UNIX rehusan enviar el mensaje ICMP que esperábamos por lo que éste método no nos es válido con ellos.