Para la construcción de la topología de una red de caja negra se emplean herramientas como Traceroute; seguro que la conocen. Esta herramienta emplea el campo TTL o tiempo de vida de la cabecera IP para averiguar por qué dispositivos de red pasan los paquetes hasta llegar al host destino.
La aplicación manda 3 paquetes con TTL valor 1 hacia la máquina objetivo; cuando estos paquetes llegan al primer dispositivo intermedio, éste decrementa el TTL en 1, pasando a valer 0, y es descartado notificándonos mediante un paquete ICMP tipo 11 Time Exceeded. La siguiente vez se enviará con TTL valor 2, posteriormente con valor 3… así hasta llegar a la máquina destino, la cual no contestará con el Time Exceeded.
Lo más importante para una auditoría de seguridad son los últimos saltos que nos permitirán obtener la topología de la red que se está auditando. Ahora bien, seguramente nos habrá ocurrido que en ocasiones los resultados obtenidos no son los correctos puesto que llegado a un firewall de la red no conseguimos poder avanzar hasta el host; incluso dependiendo del programa que empleemos los resultados son distintos. Esto es debido a combinación de las reglas de filtrado de los firewalls y los protocolos empleados por cada programa “traceroute”.
Por ejemplo, traceroute (linux) emplea por defecto paquetes UDP con el puerto destino incremental por cada paquete que envia, empezando el primer paquete en 33434. Por tanto si el firewall filtra los paquetes UDP excepto en ciertos puertos de ciertas aplicaciones nuestro traceroute será filtrado. Esta implementación también permite emplear paquetes ICMP tipo 8 (opción I) en vez de UDP. En cambio, el traceroute en Windows (llamado tracert) solo emplea paquetes ICMP echo request (tipo 8), sin opción a emplear UDP, por lo que si el firewall filtra los paquetes ICMP del tipo 8 (pings) el tracert no funcionará.
Por ello, dependiendo de la herramienta que empleemos podremos obtener unos resultados u otros, o incluso no llegar al host nunca. De estos problemas surgió la herramienta Layer Four Traceroute (LFT) que permite emplear tanto protocolo ICMP, UDP como TCP (a diferencia de traceroute y tracert), así como permitir fijar puertos destinos y orígenes para envío de paquetes. ¿Por que es interesante emplear TCP y poder fijar un puerto? Muy sencillo: por muchas reglas de filtrado que tengamos en los firewall, si tenemos un host ofreciendo un servicio al exterior, el puerto de acceso a dicho servicio debe estar abierto, y por tanto podremos emplear LFT para enviar un paquete al host cuyo puerto destino y protocolo sea el del servicio.
Veámoslo de forma práctica. Imagínense que tuviéramos un host con un servidor web disponible al exterior en una red cuyo firewall de entrada rechazara los paquetes ICMP tipo 8 (ping), y todos aquellos paquetes UDP y TCP, excepto a aquellos puertos de los servicios que ofrezcan los host de la red (como el servidor web). Tanto el traceroute como el tracert no pasarían del firewall, en cambio si empleáramos LFT indicándole que el puerto destino es el 80 y el protocolo es TCP, éste no sería rechazado, obteniendo la topología de la red que permite conectar dicha máquina con el exterior. Si el servidor web fuera la máquina 192.168.5.90 la orden sería la siguiente:
# lft -d 80 192.168.5.90
Espero que les haya gustado (y les sea útil) la curiosidad. Como siempre, pasen un buen fin de semana.
Hola Ximo
me ha gustado bastante este post, pero mirando en el man de traceroute veo que también soporta TCP (a parte de UDP e ICMP). De todas maneras me ha resultado interesante la herramienta porque no la conocía, así que gracias :)
Por último comentar que en el comando lft te ha faltado poner “-d”, aunque a mí me da error al utilizarlo para ver los saltos cuando con traceroute me funciona perfectamente :|
# lft -d 80 -n http://www.google.com
Tracing _______________________
LFT can’t seem to round-trip. Local packet filter in the way?
TTL LFT trace to 209.85.229.103:80/tcp
1 192.168.1.1 1.5ms
2 192.168.153.1 51.3ms
** [80/tcp failed] Try alternate options or use -V to see packets.
Un saludo
Hola damontero,
lo primero que comentas depende de la versión de traceroute que se emplea, el soporte TCP no es nativo y es heredado de tcptraceroute. No todas las distribuciones Linux/Unix soportan la opción “-T”. Por ello se programo LFT.
Por ejemplo en mi portátil no está soportado, en cambio en el sobremesa si:
Portatil $ sudo traceroute -T -p 80 http://www.google.es
Password:
Version 1.4a12
Usage: traceroute [-dFInrvx] [-g gateway] [-i iface] [-f first_ttl]
[-m max_ttl] [ -p port] [-q nqueries] [-s src_addr] [-t tos]
[-w waittime] [-z pausemsecs] host [packetlen]
Portatil $
Como ves la opción I está soportada pero no así la T.
Respecto a la segunda observación es un fallo al pasar del documento en pdf al blog puesto que si te fijas se ha añadido un salto y se ha quitado el “-“, pero la d como opción está puesto que se refiere al puerto destino 80, la web:
“# lft d
80 192.168.5.90”
Tendría que ser: # lft -d 80 192.168.5.90
Errata corregida.
Buenas :)
no conocía el hecho de que la opción -T dependiera de la implementación. Así que me lo apunto y lo dicho, interesante información.
Un saludo
Pensando en el ejemplo práctico del último parrafo, me pregunto si podríamos usar un IDS o IPS tras el firewall para detectar/bloquear intentos de traza a traves de LFT.
Como se explica arriba, con LFT podemos elegir protocolo de transporte y el puerto destino, con lo cual,eligiendo los valores adecuados podremos cruzar el firewall. Sin embargo seguimos teniendo un patron en campo TTL de los paquetes enviados: el valor del TTL se incrementa en una unidad en paquetes sucesivos desde la misma IP origen al mismo par IP/puerto destino. Por lo tanto, si tuviesemos un IDS o IPS capaz de detectar este patron podríamos detectar y/o bloquear los intentos de traza.
He estado googleando un poco al respecto y parece que Snort tiene opciones para inspeccionar el campo TTL y levantar alarmas si el valor en este campo esta por debajo de un cierto umbral. Esto bloquea los intentos de traza también podría levantar falsas alarmas en ciertas circunstancias.
¿Sabeis si alguna solución de IDS o IPS realmente detecta el patron del incremento en el TTL de los paquetes?
Daniel
Excelente, gracias por compartir conocimiento