Ventajas de Hacer un Traceroute con TCP

Esto puede parecer un poco obvio, pero mucha gente desconoce que hacer un Traceroute con TCP, es mucho más efectivo que hacerlo con ICMP o UDP, protocolos utilizados en las implementaciones de Traceroute de Windows y Linux.

Es más, como Traceroute trabaja con el campo TTL de la cabecera IP, podríamos utilizar cualquier protocolo que trabaje con IP. El problema con ICMP y UDP, es que cualquier administrador de Firewall's que medianamente sabe lo que hace, sin dudas va a filtrar estos protocolos.

Veamos un ejemplo usando ICMP con el clásico Traceroute de Linux/BSD:

kfs:~ root# traceroute -n www.presidencia.gov.ar
traceroute to www.presidencia.gov.ar (200.1.116.83), 64 hops max, 40 byte packets
1  192.168.1.1  0.453 ms  0.140 ms  0.151 ms
2  201.216.xxx.xxx  1.917 ms  3.164 ms  1.733 ms
3  200.61.175.126  1.281 ms  1.362 ms  1.466 ms
4  200.61.173.2  1.422 ms  1.437 ms  1.494 ms
5  200.0.17.104  12.159 ms  9.444 ms  5.563 ms
6  * * *
7  * * *
8  * * *
9  * * *
^C
kfs:~ root#

Pueden ver que a partir del salto 6 ya perdemos el rastro de la ruta que seguia el paquete.

Por otro lado, la ventaja de utilizar TCP, es que siempre vamos a poder encontrar una Web con el puerto 80 abierto hacia donde podamos hacer nuestro Traceroute. Para esto, vamos a necesitar alguna herramienta para customizar paquetes como puede ser Scapy o Hping.

Veamos un ejemplo con Hping (con "CTRL+z" hacen crecer la TTL):

kfs:~ root# hping3 -S -t 1 -p 80 -n -z www.presidencia.gov.ar
HPING www.presidencia.gov.ar (en0 200.1.116.83): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=192.168.1.1                                 2:
TTL 0 during transit from ip=201.216.xxx.xxx                             3:
TTL 0 during transit from ip=200.61.175.126                              4:
TTL 0 during transit from ip=200.61.173.2                                5:
TTL 0 during transit from ip=200.0.17.104                                6:
TTL 0 during transit from ip=200.1.116.83                                7:
len=46 ip=200.1.116.83 ttl=249 DF id=55502 sport=80 flags=SA seq=13 win=1608 rtt=4.6 ms
len=46 ip=200.1.116.83 ttl=249 DF id=55607 sport=80 flags=SA seq=14 win=1608 rtt=7.5 ms
len=46 ip=200.1.116.83 ttl=249 DF id=55775 sport=80 flags=SA seq=15 win=1608 rtt=14.0 ms
^C
--- www.presidencia.gov.ar hping statistic ---
21 packets tramitted, 19 packets received, 10% packet loss
round-trip min/avg/max = 4.4/7.7/14.0 ms
kfs:~ root#

A diferencia del ejemplo anterior, pueden ver que ahora hemos logrado descubrir el salto numero 6, y también logramos llegar a destino, ya que recibimos el SYN/ACK del paquete SYN que enviamos al puerto 80.

Casi todos los IDS's pueden detectar un Traceroute debido al valor tan bajo con el que llega la TTL del paquete, pero es mucho menos sospechoso usar TCP que ICMP o UDP, que son comúnmente usados por los Traceroute de Windows y Linux.

Por otro lado, si queremos usar UDP, es recomendable usar algún protocolo específico como DNS. El clásico Traceroute UDP de Linux, envía paquetes UDP a puertos altos (generalmente filtrados) esperando recibir mensajes de error ICMP "port unreachable" cuando llega a destino. Pero si en vez de hacer esto, enviamos paquetes al puerto 53/UDP, con un payload de DNS, no solamente el firewall nos permitiría pasar, sino que también sabríamos que llegamos a destino porque el DNS contestaría nuestro request.