| Técnicas de Detección Avanzada de interconectividad: Detección de equipos conectados a la red | ||
|---|---|---|
| Anterior | Siguiente | |
La mayoría de los diseñadores de sistemas han tenido más o menos presentes las RFCs pertinentes a la hora implementar cada una de las capas de la pila TCP/IP, por lo que sus respuestas son básicamente iguales a la hora de tratar con peticiones válidas tipificadas en las RFCs. Sin embargo las RFCs especialmente la RFC 791 referente al protocolo IP a menudo omite voluntariamente referencia alguna a cómo tratar los datagramas (IP) , segmentos (TCP) o paquetes completos inválidos. El objetivo de las RFCs es proponer un estándar que luego los diseñadores y desarrolladores deberán seguir, pero precisamente por su carácter unificador éstas a menudo dicen cómo han de hacerse la interconexión mediante implementaciones que siguen las normas, pero intentan evitar en la medida de lo posible indicar qué es lo que se debe hacer con las implementaciones que se salgan de la norma.
Un ejemplo de esto es qué hacer cuando dos fragmentos distintos se solapan. La solución drástica es eliminar los dos fragmentos y por ende descartar el paquete entero y forzar la retransmisión. Dado que esta es una medida muy drástica y que disminuye el rendimiento, hay dos opciones que se pueden llevar a cabo:
Algunos sistemas como Solaris y Windows NT prefieren quedarse con el primer fragmento que llegó descartando el último.
Otros sistemas en cambio como Linux y *BSD prefieren quedarse con el último fragmento sobreescribiendo al primero que llegó.
Esta forma diferente de actuar puede utilizarse para diversos propósitos, como por ejemplo:
Determinar el Sistema operativo de la máquina que se analiza en función de la respuesta a ciertos paquetes (firma TCP/IP).
Evadir los sistemas de detección de intrusión basados en red (NIDS) mediante por ejemplo la inserción de fragmentos solapados.
Detectar la presencia de máquinas dedicadas al filtrado de paquetes ya sean routers, cortafuegos, etc.
El uso que nosotros daremos al envío de paquetes inválidos será precisamente la detección de máquinas al responder ésta a ciertos tipos de peticiones con algunos mensajes de error. Para generar la respuesta ante peticiones inválidas del servidor, básicamente nos centraremos en el protocolo IP siendo éste independiente de los protocolos superiores que lo encapsulan (TCP,UDP,etc).
Principalmente existen estos tipos de peticiones no válidas ante un servidor:
Envío de paquetes fragmentados que hacen saltar temporizadores.
Envío de datagramas IP con longitudes de cabeceras inválidas.
Envío de datagramas IP con contenido no válido en los campos de las cabeceras.
Todas las implementaciones TCP/IP definen un temporizador que inicializan ante la llegada del primer fragmento IP recibido de un paquete. Para que el paquete completo se de por válido todos los fragmentos de dicho paquete deberán llegar antes de que caduque el temporizador encargado de controlar la defragmentación. Si transcurrido dicho tiempo no se han reensamblado todos los datagramas IP por la falta de alguno de ellos se genera una respuesta ICMP Tipo 11 y código 1 indicando que el tiempo de reensamblaje de los fragmentos ha concluído (Time Exceed Fragment Reassembly).
Para forzar este tipo de respuesta podemos enviar un paquete tcp con los flags "More fragments" y "Don't fragment" activos simultánemente.
Veamos un ejemplo contra un Debian GNU/Linux 2.2 Potato al que enviamos un paquete tcp indicando que no se puede fragmentar y al mismo tiempo diciendo que se esperan más fragmentos:
delorian:/# hping2 -c 1 -x -y xxx.xxx.xxx.xxx default routing interface selected (according to /proc) HPING xxx.xxx.xxx.xxx (eth0 xxx.xxx.xxx.xxx): NO FLAGS are se --- xxx.xxx.xxx.xxx hping statistic --- 1 packets tramitted, 0 packets received, 100% packet round-trip min/avg/max = 0.0/0.0/0.0 ms
No hemos recibido ninguna respuesta, pero esto tan sólo es aparentemente, puesto que lo que está sucediendo es que hping no registra los datagramas ICMP que genera la máquina remota.
Si ejecutarámos un tcpdump, snoop o cualquier sniffer de red veremos una respuesta similar a ésta:
18:34:55.964952 xxx.xxx.xxx.xxx > xxx.xxx.xxx.xxx: icmp: ip reassembly time exceeded (DF) [tos 0xc0]
En ocasiones este tipo de respuestas son filtradas, pero entonces el cliente no tiene forma de darse cuenta que debe retransmitir el paquete, da por hecho que llegó bien y sigue retransmitiendo sucesivos paquetes, hasta que recibe la indicación por parte del servidor de que reduzca la ventana de emisión y tendrá que reenviar varios paquetes de nuevo ralentizando las comunicaciones vía WAN.
| Anterior | Inicio | Siguiente |
| Métodos ICMP | Obtención de respuesta provocada por una longitud no válida de cabecera IP |