Manual / Tutorial de Hping (con ejemplos) By: Gustavo

En vista de que no he encontrado un manual que hable bien amplia mente sobre las posibilidades que nos brinda hping, me parece interesante comenzar a dedicar tiempo a comenzar a darle forma a la idea de tener un manual que explique y ejemplifique el uso de hping. Sin embargo, existen varios artculos dispersos en la web, los cuales voy a citar y al final de este artculo podrn encontrar una lista de los mas interesantes. Preeliminares Como reza la pagina oficial de hping, esta herramienta de linea de comando, esta inspirada el comando ping de unix, sin embargo su utilidad es 1024 veces superior (lo de mil 1024 es un chiste geek). Su finalidad es la de poder crear paquetes personalizados para poder analizar las respuestas. Dentro de sus funciones, con hping podemos hacer: Firewall testing Advanced port scanning Network testing, using different protocols, TOS, fragmentation Manual path MTU discovery Advanced traceroute, under all the supported protocols Remote OS fingerprinting Remote uptime guessing TCP/IP stacks auditing

Actualmente hping tiene una versin 3, la cual nos permite realizar scripts sobre tcl para poder crear nuestras propias herramientas, como veremos mas adelante. El primer problema que muchos encuentran al querer utilizar hping, es que hping no es una herramienta que como muchas otras le especificamos un target y esperamos ver resultados. Para poder utilizar hping, necesitamos conocer exactamente que estamos haciendo. Por eso, antes de continuar leyendo te recomiendo que obtengas conocimientos en TCP, UDP, IP, ICMP y el Modelo OSI y DOD. Para los que estn interesados en ms que aprender alguna receta interesante, les recomiendo encarecidamente leer los siguientes RFC (estan en espaol): RFC 768 Protocolo UDP (original) RFC 793 Protocolo TCP (original) RFC 791 Protocolo IP (original) RFC 702 Protocolo ICMP (original) Para los que necesitan recordar el funcionamiento del modelo osi, pueden ver una representacin muy interesante en este link

Opciones generales
Hping tiene un funcionamiento parecido al ping en el sentido de que envia reiteradamente un paquete ( en el caso de hping uno armado por nosotros ) hasta que cortemos la ejecucin del programa con un control C. - Para poder elegir la cantidad de veces que se quiere enviar el paquete podemos usar la opcin -c la cual especifica el nmero de paquetes que queremos enviar (Si no, enva paquetes hasta que lo cortemos con un control c). - Para elegir el intervalo (la rapidez) con que envia los paquetes usamos -i y como argumento el intervalo de tiempo (en segundos) entre paquete y paquete. Si quisieramos usar microsegundos en lugar de segundos utilizamos u100 para 100 microsegundos. Ademas, podemos usar los alias fast, faster o flood para enviar paquetes a 10000

microsegundos, 1000 microsegundos o tan rpido como se pueda respectivamente. Finalmente quiero recalcar el uso del -z y -Z: La combinacin de teclas Control Z, esta ligada por defecto a aumentar el numero de puerto al que estamos enviando el paquete (para tcp y udp), de esta manera podemos escanear un host aumentando en 1 el numero de puerto. Cuando especificamos -z ligamos la combinacin de teclas a aumentar el nmero del TTL de los paquetes que estamos enviando (ver mas adelante) y con -Z desligamos dicha combinacin de cualquiera de las dos funciones posibles, esto es lo dejamos librado a las funciones de la consola, generalmente dejarlo en sleep.

Firewall Testing ( en modo TCP )

Hping puede crear paquetes del tipo IP crudo, ICMP, TCP y UDP. Para seleccionar el tipo de paquete que queremos crear, debemos seleccionar el Modo (Mode) en que ejecutaremos hping. El modo por defecto es TCP, en este modo, hping nos permite crear un paquete TCP a nuestra medida, es decir, especificando los valores de los distintos campos de un paquete TCP. Los valores que no sean explcitos, sern puestos en sus valores por defecto (calculados si fuera necesario). Al usar el modo TCP (al igual que en UDP e ICMP), podemos modificar tambin los valores de los campos del protocolo IP. Veamos un ejemplo: Isis:~# hping3 -p 80 192.168.1.1 HPING 192.168.1.1 (eth0 192.168.1.1): NO FLAGS are set, 40 headers + 0 data bytes ^C 192.168.1.1 hping statistic 3 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms Al ejecutar hping sin ningn parmetro, solo especificando una ip, hping crea un paquete tcp sin ningn flag, el cual monta sobre un paquete IP modificando el campo de su destino a 192.168.1.1. De aqu que todas las opciones no especificadas son calculadas por hping. En este ejemplo, al no configurar los flags del paquete tcp, hping crea un paquete tcp sin flags y sin puerto de destino, y comienza a enviarlo iterativa mente como lo hace el programa ping. Como es de esperarse ningn sistema debera responder a este tipo de paquetes ya que el RFC indica que deben ser descartados sileciosamente. Si bien puede parecer un ejemplo simple, este ejemplo es la base para el NULL Scan, ya que podemos verificar la respuesta a un paquete TCP sin las flags correspondientes. Especificando el puerto tcp, es suficiente para realizar el NULL Scan sobre ese puerto. Si probamos agregando la opcion -p seguido de cualquier numero de puerto, es probable que la respuesta sea idntica. En este caso (NULL Scan), hping no nos permite ver el WIN devuelto, que es lo interesante de un NULL Scan. Tanto el modo TCP y UDP comparten la opcin de poder seleccionar el puerto de origen ( con -s, esto toma importancia en algunos sistemas que validan, por ejemplo si el puerto de origen es inferior al 1024 ), el cual si no es explicitado se elije de forma aleatoria, y el puerto de destino,

como lo hicimos anteriormente con -p. Una de las opciones mas interesantes de hping, encontramos la posiblidad de selecionar los flags de un paquete TCP, estos son a saber SYN, ACK, RST, PUSH, URG y FIN. Los que mas nos interesan por el momento son: SYN: Sincroniza la conexin, es usado durante toda la conexin. ACK: Confirmacin de datos recibidos FIN: Solicitud para cerrar la conexin. RST: Aborta la conexin sin negociacin ( a diferencia de FIN). Como dije anteriormente, para comprender esta parte del uso de hping debemos saber como se usan en una conexin TCP dichos flags, ya que si no, no comprenderemos los resultados obtenidos. A pesar de eso, es probable que si seguis leyendo, los ejemplos te hagan comprender un poco. Vemos en la ayuda de hping, las siguientes opciones:
-F -S -R -P -A -U --fin --syn --rst --push --ack --urg set set set set set set FIN flag SYN flag RST flag PUSH flag ACK flag URG flag

Con estas opciones podemos decidir las flags que llevar los paquetes TCP, de esta forma simple, podemos elegir que las lleve todas, ninguna, o las que querramos. La mayoria de los distintos tipos de escaneos TCP dependen de estos flags. El mas comn, utilizado por los scanners mas simples, es el SYN scan, el cual consiste en enviar un SYN ( indicador de inicio de conexin ) y esperar la respuesta ( normalmente SYN/ACK si el puerto esta abierto, y RST si esta cerrado ). Comprendiendo esto, podemos comenzar a usar hping como un escaneador de puertos:

Isis:~# hping -c 5 -p 80 -S 192.168.1.1 HPING 192.168.1.1 (eth0 192.168.1.1): S set, 40 headers + 0 data bytes len=46 ip=192.168.1.1 ttl=64 id=17576 sport=80 flags=SA seq=0 win=8192 rtt=2.0 ms len=46 ip=192.168.1.1 ttl=64 id=17578 sport=80 flags=SA seq=1 win=8192 rtt=1.5 ms len=46 ip=192.168.1.1 ttl=64 id=17580 sport=80 flags=SA seq=2 win=8192 rtt=1.5 ms len=46 ip=192.168.1.1 ttl=64 id=17582 sport=80 flags=SA seq=3 win=8192 rtt=1.5 ms len=46 ip=192.168.1.1 ttl=64 id=17584 sport=80 flags=SA seq=4 win=8192 rtt=1.5 ms

--- 192.168.1.1 hping statistic --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 1.5/1.6/2.0 ms

Un ejemplo simple, pero eficiente para mostrar el funcionamiento de esta dichosa herramienta: Con -c 5 le pedimos a hping que solo envie 5 paquetes, al puerto 80, con el SYN activado en la cabecera TCP, en consecuencia, el host target, nos responde un paquete TCP, con puerto de origen 80, y los flags SYN y ACK. Esta respuesta, corresponde a un host target con el puerto 80 abierto, ya que los flags SYN/ACK son indicadores de que el SYN inicial fue recibido. Si recordamos lo que mas arriba mencion acerca de la opcion de Control Z, podemos convertir a hping en un tcp-port-scanner:
Isis:~# hping3 -p 1 -S 192.168.1.1 HPING 192.168.1.1 (eth0 192.168.1.1): S set, 40 headers + 0 data bytes 2: 3: 20: len=46 ip=192.168.1.1 ttl=64 id=40704 sport=20 flags=RA seq=24 win=0 rtt=1.3 ms len=46 ip=192.168.1.1 ttl=64 id=40706 sport=20 flags=RA seq=25 win=0 rtt=1.3 ms len=46 ip=192.168.1.1 ttl=64 id=40708 sport=20 flags=RA seq=26 win=0 rtt=1.3 ms 21: len=46 ip=192.168.1.1 ttl=64 id=40710 sport=21 flags=RA seq=27 win=0 rtt=1.4 ms len=46 ip=192.168.1.1 ttl=64 id=40712 sport=21 flags=RA seq=28 win=0 rtt=1.4 ms len=46 ip=192.168.1.1 ttl=64 id=40714 sport=21 flags=RA seq=29 win=0 rtt=1.4 ms 22: 23: len=46 ip=192.168.1.1 ttl=64 id=40716 sport=23 flags=RA seq=32 win=0 rtt=1.3 ms 35: z^C --- 192.168.1.1 hping statistic --45 packets transmitted, 7 packets received, 85% packet loss round-trip min/avg/max = 1.3/1.3/1.4 ms

Observemos que el parametro de -p es 1 (es decir puerto TCP 1), y al no haber respuesta (ni un RST de parte del host target) Hping no muestra ninguna respuesta. Luego, al presionar Control Z, en lugar de enviar los paquetes al puerto nmero 1, lo hace al puerto 2, as sucesivamente, hasta el puerto 20, donde comenza a recibir respuestas RA (RST / ACK ). Interpretar esta respuesta, involucra un poco de estudio acerca del host objetivo, sin embargo, a priori, podemos ver, que los puertos del 1 al 19, no responden nada, y sin embargo, el puerto 20 responde RST/ACK. Es decir, que el objetivo, reacciona de manera distinta frente al puerto 20 (lo mismo pasa en el puerto 21 y 23 ). Esto se debe generalmente, a reglas de filtrado, como podemos ver los puertos del 1 al 19, han de estar cerrados, y existe una regla que impide todo tipo de egreso y/o ingreso desde/a estos puertos (an las respuestas RST), a diferencia de los puertos 20, 21, y 23, en los cuales, nuestro paquete con flag SYN, es recibido, procesado y respondido, indicando que el puerto correspondiente esta cerrado. Nmap tambien nos muestra esta diferencia, de la siguiente forma:

Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-05-31 15:56 ART Interesting ports on Orus (192.168.1.1): Not shown: 995 filtered ports PORT STATE SERVICE 20/tcp closed ftp-data 21/tcp closed ftp 23/tcp closed telnet

Notemos, que nmap (en un escaneo normal) nos muestra solo los puertos 20,21, y 23, ya que es de los cuales ha recibido respuestas ( RST/ACK indicando que dichos puertos estan cerrados, closed) Este caso puede darse por ejemplo, en un host, donde el puerto esta abierto en el firewall, pero no existe ningn daemon/sistema/programa escuchando en dicho puerto. Tambin puede darse de un router haciendo forwarding a un puerto cerrado. Para dar un cierre a esta primera parte, imitaremos con hping los algunos de los distintos tipos de escaneos que pueden realizarse con nmap, para que comprendamos exactamente como funcionan: SYN Scan: Como vimos anteriormente, un SYN scan TCP SYN (en nmap la opcion -sS ) lo hacemos de la siguiente manera:
Isis:~# hping -c 1 -S -p 80 google.com HPING google.com (eth0 74.125.65.147): S set, 40 headers + 0 data bytes len=46 ip=74.125.65.147 ttl=53 id=13915 sport=80 flags=SA seq=0 win=5720 rtt=155.5 ms --- google.com hping statistic --1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 155.5/155.5/155.5 ms

Enviamos un paquete TCP con flag SYN activado y recibimos uno con flags SYN/ACK, verificando que el puerto 80 esta abierto, si la respuesta fuera RA, es decir RST/ACK, estaramos frente a un puerto cerrado, y si no hubiera respuesta, el puerto 80, est de alguna manera filtrado. FIN Scan: El FIN Scan consiste en eviar al paquete TCP con el flag FIN activado (en nmap -sF ), algo que no sucede en ninguna conexin normal.

Isis:~# hping -c 1 -F -p 443 mytarget.com HPING mytarget.com (eth0 201.235.102.256 ): F set, 40 headers + 0 data bytes

--- mytarget.com hping statistic --1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms

Isis:~# hping -c 1 -F -p 80 mytarget.com HPING mytarget.com (eth1 201.235.102.256 ): F set, 40 headers + 0 data bytes len=46 ip=9.13.80.179 ttl=64 DF id=42533 sport=80 flags=RA seq=0 win=0 rtt=0.7 ms

--- mytarget.com hping statistic --1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.7/0.7/0.7 ms

Aqui vemos dos respuestans distintas, en dos puertos distintos. En el primer caso, enviamos un FIN Scan al puerto 443, y no obtenemos respuesta y en el segundo caso lo enviamos al puerto 80 y recibimos un RST/ACK ( flags=RA). Mytarget.com, es en este ejemplo un FreeBSD, y responde como lo indica el RFC de TCP, enviando un RST/ACK en los puertos cerrados y no envia respuesta en los puertos abiertos. Sin embargo, esto varia de sistema en sistema, por lo que realizar un FIN Scan no es la ltima palabra, si no, solo una comprobacin ms. Xmas Scan: Del mismo modo que el FIN Scan, Xmas consiste en enviar un paquete TCP con flags que nunca deberan ir activadas en el primer paquete de la conexin, estas son FIN, URG y PUSH (en nmap -sX)

Isis:~# hping -c 1 -F -P -U -p 443 mytarget.com HPING mytarget.com (eth0 201.235.102.256 ): FPU set, 40 headers + 0 data bytes

--- mytarget.com hping statistic --1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms

Isis:~# hping -c 1 -F -P -U -p 80 mytarget.com HPING mytarget.com (eth1 201.235.102.256 ): FPU set, 40 headers + 0 data bytes

len=46 ip=9.13.80.179 ttl=64 DF id=42533 sport=80 flags=RA seq=0 win=0 rtt=0.7 ms

--- mytarget.com hping statistic --1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.7/0.7/0.7 ms

El analisis de las respuestas es el mismo, RA para los puertos cerrados, y sin respuesta para los abiertos / filtrados. Sin embargo, insisto, estas respuestas van a variar contra que sistema se prueben. Nota: en lugar de usar -F -P -U, podemos abreviar usando -X Win Scan: Para culminar esta primera parte, abandonamos un poco los flags TCP, y nos concentramos en otro parmetro de la cabezera, a saber, el Win. Al iniciarse una conexin TCP, se negocia el tamao de los paquetes que cada parte de la conexin puede procesar antes de enviar una confirmacin (ACK) , este tamao es el Window Size (aka Win). Ahora bien, observemos esta respuesta:

Isis:~# hping3

-c 1 -S -p 21 mytarget.com

HPING mytarget.com (eth0 201.235.102.256): S set, 40 headers + 0 data bytes len=46 ip=201.235.102.256 ttl=64 id=47842 sport=21 flags=RA seq=0 win=9192 rtt=1.6 ms

--- 201.235.102.256 hping statistic --1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 1.6/1.6/1.6 ms

En este caso, si jusgamos la respuesta por las flags (RA), el puerto pareceria cerrado, sin embargo, si esto fuera as, el win de respuesta debera ser 0, como en el ejemplo del Xmas scan, por ejemplo. Queda claro entonces, que alguna regla/firewall/router esta filtrando la respuesta, para saber si este filtro esta en el mismo host o en otro distinto, vas a tener que esperar a la segunda parate de este manual. Por el momento, solo hemos visto como usar hping como un simple scanner de puertos TCP.

Comparamos el uso de hping con el de nmap, para quienes esten famialiarizados con el el uso de esta herramienta, pero veremos que an tiene mas potencial que el que hemos mostrado hasta ahora. Sin embargo, tendrn que esperar a la segunda parte del manual! Hasta la prxima!

Manual / Tutorial de Hping ( con ejemplos ) II

Una vez visto el uso mas comn de hping (aqu), podemos avanzar un poco mas en el uso de esta herramienta. En la entrega anterior vimos como usar hping como un port scanner ( uno avanzado ). En esta oprtunidad revisaremos una utilidad que hping nos presenta, y que no encontramos en muchas herramientas ms, a saber Trace route avanzado. Concepto: Todo paquete ip, tiene una propiedad llamada TTL o Time to life, que originalmente fue pensado para medir el tiempo que un paquete vivia en una red. El paquete ip salia del host de origen con un TTL de (por ejemplo) 255, y en cada router que era procesado se le deba restar la cantidad de segundos que tard en procesarse. Posteriormente ya sea por la velocidad de los routers o por comodidad, en lugar de restarse la cantidad de segundos en que tardo en procesarse, comenz a restarse 1 en cada router por el que pasaba. Por lo que el TTL hoy en da indica la cantidad mxima de saltos que un paquete ip puede dar (255 en este ejemplo) antes de ser descartado.

TTL Esta propiedad del paquete ip, aunque puede parecer trivial, en realidad nos puede brindar bastante informacin si la usamos bien. Para empezar, si estamos sentados frente al host destino, cuando recibimos un paquete ip ( sea tcp, udp o icmp), podemos calcular por cuantos routers paso el paquete. Esta informacin puede parecernos indiferente, sin embargo como veremos no lo es. En segundo lugar, como cada sistema operativo puede elegir con que TTL envia/responde un paquete, calcular con que TTL se envi el paquete, nos proporciona informacin sobre el sistema operativo.

Manos al teclado
Veamos como responde Google, ante un ping comn y corriente:
Isis:~# ping -c 3 google.com PING google.com (209.85.195.104) 56(84) bytes of data. 64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_seq=1 ttl=57 time=22.2 ms 64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_seq=2 ttl=57 time=14.5 ms 64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_seq=3 ttl=57 time=13.6 ms --- google.com ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2006ms rtt min/avg/max/mdev = 13.684/16.839/22.254/3.846 ms

Pueden ver que el TTL que nos llega es 57. Como el TTL suele ser un numero multiplo de 2, puede tomar valores de 2,4,8,16,32,64,128 etc. Lo mas probable, es que el TTL original, haya sido de 64, y paso por 7 routers antes de llegar hasta nosotros ( 64 7 = 57 ) Para comprobar feacientemente esto hacemos un traceroute:
Isis:~# traceroute google.com traceroute to google.com (209.85.195.104), 30 hops max, 40 byte packets 1 Orus (x.x.x.x) 8.654 ms 8.959 ms 9.246 ms 2 host13.222-3-64.telefonica.net.ar (221.3.64.13) 19.917 ms 25.344 ms 30.208 ms 3 host114.194-224-165.telefonica.net.ar (194.224.165.114) 36.107 ms 41.545 ms 45.936 ms 4 host142.194-225-248.telecom.net.ar (194.225.248.142) 52.120 ms 56.516 ms 61.675 ms 5 209.85.251.28 (209.85.251.28) 66.672 ms 72.279 ms 76.667 ms 6 209.85.251.6 (209.85.251.6) 93.145 ms 102.719 ms 103.364 ms 7 eze03s01-in-f104.1e100.net (209.85.195.104) 21.835 ms 15.071 ms 19.948

Tal como pensamos, hay 7 saltos, desde donde enviamos nuestro ping a google. Este mismo procedimiento, se puede imitar con hping, pero sera complicarse un poco, siendo que tenemos estas herramientas que son muy comunes y simples. Sin embargo, habiendo entendido esto, podemos usar hping para una tcnica un tanto mas avanzada.

Trace route con Hping

Las herramientas anteriormente usadas, usan el protocolo ICMP implicitamente ( Request y Echo). Nosotros en lugar de usar ICMP, usaremos un paquete TCP, sobre un puerto especifico, para estudiar la respuesta del mismo. Como primer experimento, enviamos un paquete TCP al puerto 21 de un target cualquiera, con el TTL en uno.
Isis:~# hping3 -c 3 -S -p 21 -t 1 nasa.dnsalias.net HPING nasa.dnsalias.net (eth0 2xx.1x7.x0.x9): S set, 40 headers + 0 data bytes TTL 0 during transit from ip=192.168.1.1 name=Orus TTL 0 during transit from ip=192.168.1.1 name=Orus TTL 0 during transit from ip=192.168.1.1 name=Orus

--- estbissio.dnsalias.net hping statistic --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms

-c 3 : Indica la cantidad de paquetes que enviaremos -S : Activa el flag SYN, indicando la intencin de iniciar una nueva conexin -p 21 : Puerto de destino 21 -t 1 : TTL en 1 nasa.dnsalias.net : Puerta tracera de la nasa La respuesta nos llega desde (en este caso) mi super Cisco Pix (192.168.1.1) , informandons que el paquete no pudo ser entregado dado que el paquete muri en el camino (que en paz descanse). Esto significa que mientras el paquete intentaba llegar a destino, su tiempo de vida lleg a su fin, y el paquete se descart, por consecuencia, el router que lo descart, nos informa sobre su deceso. En la entrega anterior, habiamos comentado, que con el flag -z, asociamos el uso de Control Z al incremento del numero de TTL.

Isis:~# hping3 -S -p 21 -z -t 1 nasa.dnsalias.net HPING nasa.dnsalias.net (eth0 2xx.1xx.9x.x9): S set, 40 headers + 0 data bytes TTL 0 during transit from ip=192.168.1.1 name=Orus TTL 0 during transit from ip=192.168.1.1 name=Orus TTL 0 during transit from ip=192.168.1.1 name=Orus 2: TTL 0 during transit from ip=201.90.61.19 name=host19.201-9061.telefonica.net.ar TTL 0 during transit from ip=200.3.63.19 name=host19.200-363.telefonica.net.ar 3: TTL 0 during transit from ip=204.117.127.90 name=host90.204-117127.telecom.net.ar TTL 0 during transit from ip=204.117.127.90 name=host90.204-117127.telecom.net.ar TTL 0 during transit from ip=204.117.127.90 name=host90.204-117127.telecom.net.ar 4: 5: TTL 0 during transit from ip=200.117.90.39 name=UNKNOWN TTL 0 during transit from ip=200.117.90.39 name=UNKNOWN TTL 0 during transit from ip=200.117.90.39 name=UNKNOWN

6: len=46 ip=2xx.1xx.9x.x9 ttl=123 id=16854 sport=21 flags=SA seq=15 win=16384 rtt=33.7 ms len=46 ip=2xx.1xx.9x.x9 ttl=123 id=16855 sport=21 flags=SA seq=16 win=16384 rtt=34.3 ms len=46 ip=2xx.1xx.9x.x9 ttl=123 id=16856 sport=21 flags=SA seq=17 win=16384 rtt=57.8 ms len=46 ip=2xx.1xx.9x.x9 ttl=123 id=16863 sport=21 flags=SA seq=18 win=16384 rtt=235.6 ms ^C --- nasa.dnsalias.net hping statistic --23 packets transmitted, 19 packets received, 0% packet loss round-trip min/avg/max = 33.1/1158.4/3119.4 ms

Cada vez que presionamos Control Z, hping aumenta el ttl en uno, as de tener un ttl de uno ( -t 1 ) paso a tener ttl 2, 3, 4 (donde no recibimos respuesta), 5, y 6 donde finalmente obtenemos una respuesta, indicando que el puerto 21 esta a la escucha ( flags=SA ). Cual es el beneficio ente hping y traceroute que hace esto automaticamente? Bien, una de las diferencias, es que al hacer esto puerto por puerto podemos encontrar los puertos que han sido redirigidos a otro host dentro de la red interna del target. Repitamos este proceso, en distintos puertos, y si obtenemos una respuesta de distintos TTLs, ya podemos empezar a desconfiar de que provengan del mismo host. Veamos dos ejemplos:

Isis:~# hping3 -S -p 21 -z -t 1 nasa.dnsalias.net ... 6: len=46 ip=2xx.1xx.9x.x9 ttl=123 id=16854 sport=21 flags=SA seq=15 win=16384 rtt=33.7 ms len=46 ip=2xx.1xx.9x.x9 ttl=123 id=16855 sport=21 flags=SA seq=16 win=16384 rtt=34.3 ms

Isis:~# hping3 -S -p 22 -z -t 1 nasa.dnsalias.net ... 7: len=46 ip=2xx.1xx.9x.x9 ttl=122 id=16854 sport=22 flags=SA seq=12 win=12503 rtt=31.3 ms len=46 ip=2xx.1xx.9x.x9 ttl=122 id=16855 sport=22 flags=SA seq=13

win=16384 rtt=39.1 ms

Aqui visualizamos, como haciendo el mismo analisis a dos puertos diferentes, obtenemos las respuestas con distintos TTLs ( 122 y 123 ). Esto sucede por que el puerto 22 esta siendo redirigido a un host interno de la red. Razon: El router que provee el acceso a internet, en la red target (nasa.dnsalias.net), al redirigir el puerto, decrementa en uno el ttl cuando nos envia la respuesta. Esta simple tecnica nos permite tener mas datos sobre el target, y nos permite adentrarnos en otras tecnicas que podemos utilizar con Hping Pero quedara para el proximo capitulo Fuentes: http://www.netsecure.com.ar/2010/05/20/manual-tutorial-de-hping-con-ejemplos-i/ http://www.netsecure.com.ar/2010/10/20/manual-tutorial-de-hping-con-ejemplos-ii/