Está en la página 1de 12

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/

También podría gustarte