Hping3 no funciona?

Question

Hping3 no funciona?

#1 de Tobi Nary (1 votos)
#2 de camp0 (-3 votos)

-2

Estaba intentando realizar un ataque de inundación SYN y estaba usando hping3. Así es como se ve el comando:

 sudo hping3 -S -a 192.168.100.88 --flood -p 80 192.168.100.15

Donde 192.168.100.88 es una dirección IP no existente. El servidor atacado debería responder y hacer conexiones medio abiertas.

Como resultado tengo esto:

    elvin@elvin-VPCZ21X9R:~$ sudo hping3 -S -a 192.168.100.88 --flood -p 80 192.168.100.15
HPING 192.168.100.15 (wlp2s0 192.168.100.15): S set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
--- 192.168.100.15 hping statistic ---
22082825 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

¿Qué es esto: 100% packet lost ? Qué significa eso?

Luego abrí Wireshark y no vi ningún tráfico que pareciera una inundación.

¿He realizado la inundación SYN? ¿O eso no funcionó?

También hice ping a la dirección IP al enviar paquetes usando este comando

ping 192.168.100.15

¿Es correcto verificar con este comando el estado del servidor apache2?

tcp flooding ping

pregunta Elvin 02.05.2018 - 11:48

fuente

2 respuestas

Lea otras preguntas en las etiquetas tcp flooding ping

¿Qué software puedo usar para editar y reproducir paquetes? [cerrado] ¿Cómo dejar una puerta trasera en una aplicación Laravel?

score 1 · Answer 1

Primero que nada, si falsifica una dirección IP de origen, no obtendrá respuestas del destino cuando los paquetes SYN / ACK vayan a la dirección falsificada.

Aparte de eso, si wireshark no muestra el tráfico saliente adecuado, suponiendo que lo haya utilizado correctamente, hay algunas razones posibles:

su pila de IP podría filtrar paquetes falsificados,
su filtro de paquetes local puede eliminar los paquetes con un SRC que no sea su dirección real.

Además, un ping en la máquina de destino no es lo que le dará resultados precisos sobre el estado de la pila TCP del destino (y un servidor web no tiene nada que ver con esto).

Mira, cuando te desincrustas, tu objetivo es tener tantas conexiones medio abiertas que la pila TCP del sistema operativo no permita que se hagan nuevas conexiones.

Solo en las conexiones completas, el objetivo es que el programa que maneja las conexiones (en este caso parece un apache) agote la memoria, los manejadores de archivos o la CPU.

Solo en este último caso, puede esperar que la memoria o el agotamiento de la CPU eviten que el sistema operativo responda a los pings, y eso no es confiable. Además, Apache no hace girar procesos como locos, incluso en conexiones completas, probablemente se alcanzará el número máximo de procesos antes de que el agotamiento de los recursos sea un problema.

Por lo tanto, para comprobar si su ataque tiene algún impacto en la disponibilidad del servidor web atacado, debería hacer curl en lugar de ping para que se realice una solicitud completa. Si esa conexión se agota, su ataque funciona. p>

score -3 · Answer 2

Creo que deberías revisar tus tablas de enrutamiento del servidor y del host. Estás utilizando la opción -a

-a --spoof hostname
          Use this option in order to set a fake IP source address, this option ensures that target will not gain your real address. However  replies  will  be  sent  to
          spoofed address, so you will can't see them. In order to see how it's possible to perform spoofed/idle scanning see the HPING3-HOWTO.

Esto significa que si su máquina fuente tiene una IP como 192.168.100.1 y usted la cambia a 192.168.100.88, el servidor responderá a 192.168.100.88, no a 192.168.100.1. También sería una buena idea hacer un pcap del tráfico en el lado del servidor para ver este efecto.