Hola,

Gracias al mensaje anterior que me llevó a leer más al respecto he comprendido que para realizar el SYN Flood es necesario Spoofear la dirección IP de origen, por eso no me resultaba el ataque. Por otro lado quería compartirles una diferencia más que importante e interesante al Spoofear de manera aleatoria la dirección IP tanto con Nping (--source-ip rand) y Hping3 (--rand-source).

La diferencia consiste en que Nping generará una única dirección IP aleatoria que utilizará en todos los paquetes enviados, mientras Hping3 generará una dirección IP aleatoria por cada paquete enviado. Siendo más provechoso creo yo desde el punto de vista del ataque lo realizado por Hping3 y no pude encontrar la manera que Nping lo realizara de esta forma.

¡Saludos!

Hola de nuevo ccrunch:

Previamente había buscado esa documentación en la página de nmap y no la había encontrado, ¡muchas gracias! :-D la leeré, espero no sea la misma del "man nping".

En cuanto a la segunda pregunta, que yo sepa en el segmento TCP no hay información (como comentas) si es generado por nping o el SO. Lo querías saber porque en el caso remoto que se pueda saber si es generado por nping, entonces quería decir podría evitar el envío del segmento final TCP RST con alguna opción de nping, pero si es una respuesta automática de mi SO  Ni idea.

¿A qué viene todo esto? He estado tratando de hacer un ataque de SYN Flood en mi laboratorio de pruebas con nping pero no lo he logrado, y culpo de ello a este último segmento TCP RST.

Gracias de nuevo, saludos.

Hola ccrunch:

Claro, en una conexión TCP normal no es posible, por normal me refiero por ejemplo a un navegador comunicándose con un servidor apache.

Pero imagina lo siguiente:


Ahí acabo de enviar el segmento TCP con el flag FIN sin conexión previa de manera manual. Quería saber lo que pregunté porque estaba haciendo pruebas con diferentes sistemas operativos y servicios pero como obtenía diferentes comportamientos, quería darme cuenta cuáles cumplian y cuales no con esa parte del RFC 793, pero para eso debía conocer qué establecía el RFC.

Pero ya encontré la respuesta (lamentablemente no en el RFC que era lo que yo quería): Un host debe responder con un segmento TCP RST si el puerto está cerrado y descartar el segmento si el puerto está abierto según lo establecido en el RFC, pero no todos lo cumplen, por ejemplo Windows XP responde con un segmento TCP RST sin importar el estado del puerto.

Saludos.

Hola amigos:

He estado usando Nping de la siguiente manera:


Y obtengo la siguiente captura en Wireshark (con su respectivo filtro):


Mis dudas son:
 
- ¿Es posible evitar que se envíe el último segmento TCP RST al objetivo?
- ¿Existe alguna manera para saber si el último paquete es enviado por Nping o por mi SO?

Gracias.

Saludos ccrunch:

Gracias por la respuesta pero esa parte ya la sabía, creo que no me he hecho entender en lo que quiero preguntar, por lo tanto vuelvo a plantear la pregunta:

En base al diagrama de estado de una conexión TCP planteado en el RFC 793, ¿Qué debe hacer un host cuando recibe un segmento TCP con el flag FIN activado sin que exista una conexión TCP previa?

La pregunta no era qué hace cuando recibe un TCP SYN para el inicio del handshake.

Estuve leyendo más detalladamente el RFC y creo que al parecer no se puede leer en el diagrama lo que estoy preguntando ya que me encuentro con el siguiente comentario sobre el diagrama en el RFC 793:


Por lo que asumo que dicho comportamiento no se puede leer en el diagrama al no ser algo esperado durante una conexión TCP, creo que la respuesta a lo que estoy buscando estará en las entrañas de las 176 páginas del RFC en su versión en PDF. Tarea que dejaré para más adelante.

Gracias por sus repuestas amigos, saludos.

La situación que se plantea es que no hay ninguna conexión TCP establecida con anterioridad, simplemente se recibe un paquete TCP con el flag FIN por ejemplo en algun servidor. La idea es entender en base al diagrama cómo debe responder el host que recibe el segmento.