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
artículos dispersos en la web, los cuales voy a citar y al final de este artículo podrán 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 versión 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 están interesados en más que aprender alguna “receta”
interesante, les recomiendo encarecidamente leer los siguientes RFC (estan en español):
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 representación
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 ejecución del
programa con un control C.
- Para poder elegir la cantidad de veces que se quiere enviar el paquete podemos usar la opción -c la
cual especifica el número de paquetes que queremos enviar (Si no, envía 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 rápido como se pueda respectivamente.
Finalmente quiero recalcar el uso del -z y -Z:
La combinación 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 combinación de teclas a aumentar el número del TTL de los
paquetes que estamos enviando (ver mas adelante) y con -Z desligamos dicha combinación 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 explícitos, serán puestos en sus valores por defecto (calculados si fuera necesario). Al
usar el modo TCP (al igual que en UDP e ICMP), podemos modificar también 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 ningún parámetro, solo especificando una ip, hping crea un paquete tcp sin
ningún 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 ningún
sistema debería 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 idéntica. 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 opción 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 conexión, es usado durante toda la conexión.

ACK: Confirmación de datos recibidos
FIN: Solicitud para cerrar la conexión.
RST: Aborta la conexión sin negociación ( a diferencia de FIN).

Como dije anteriormente, para comprender esta parte del uso de hping debemos saber como se usan
en una conexión 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 --fin set FIN flag
-S --syn set SYN flag
-R --rst set RST flag
-P --push set PUSH flag
-A --ack set ACK flag
-U --urg set 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 común, utilizado
por los scanners mas simples, es el SYN scan, el cual consiste en enviar un SYN ( indicador de
inicio de conexión ) 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 número 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
(aún 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 ningún daemon/sistema/programa “escuchando” en dicho puerto. También 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, estaríamos
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 conexión 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 comprobación más.
Xmas Scan:
Del mismo modo que el FIN Scan, Xmas consiste en enviar un paquete TCP con flags que nunca
deberían ir activadas en el primer paquete de la conexión, 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
parámetro de la cabezera, a saber, el “Win”.
Al iniciarse una conexión TCP, se negocia el tamaño de los paquetes que cada parte de la conexión
puede procesar antes de enviar una confirmación (ACK) , este “tamaño” 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 debería 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 aún tiene mas potencial que el que hemos mostrado hasta ahora.
Sin embargo, tendrán que esperar a la segunda parte del manual! Hasta la próxima!

Manual / Tutorial de Hping ( con ejemplos ) II

Una vez visto el uso mas común 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 más, 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 debía 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 día indica la cantidad
máxima 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
información 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 información 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 información sobre el sistema
operativo.
Manos al teclado
Veamos como responde Google, ante un ping común 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 sería complicarse un poco, siendo que
tenemos estas herramientas que son muy comunes y simples. Sin embargo, habiendo entendido
esto, podemos usar hping para una técnica 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 intención de iniciar una nueva conexión
-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) , informandonós
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-90-

61.telefonica.net.ar

TTL 0 during transit from ip=200.3.63.19 name=host19.200-3-

63.telefonica.net.ar

3: TTL 0 during transit from ip=204.117.127.90 name=host90.204-117-

127.telecom.net.ar

TTL 0 during transit from ip=204.117.127.90 name=host90.204-117-

127.telecom.net.ar

TTL 0 during transit from ip=204.117.127.90 name=host90.204-117-

127.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/