Foro de elhacker.net

Hola amigos:

Estuve echando un ojo al RFC 793 https://tools.ietf.org/html/rfc793 (https://tools.ietf.org/html/rfc793) que corresponde al protocolo TCP, y siendo más preciso, quiero "descifrar" el diagrama de estado (aquí mejor graficado http://www.sungju.org/?p=57 (http://www.sungju.org/?p=57)). Lo que quiero saber exactamente es:

¿Qué hace un host cuando recibe un segmento TCP FIN en un puerto cerrado?

Ya he leido en diferentes fuentes que si está cerrado se debe enviar un TCP RST, pero no lo capto en el diagramas.

Gracias.

alomejor me equivoco y no te sirve mi ayuda, pero creo que si el host es el que abrió la conexion virtual (TCP) con el host de destino, el origen no puede cerrar el puerto hasta que no reciba el paquete ACK FIN...

nose si te sirve de ayuda.

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.

Si el puerto está cerrado, nos responde con un paquete con los flags RST y ACK.

En este ejemplo vemos cómo enviamos un paquete con el flag SYN al puerto 21 de 192.168.1.9 y nos responde
con otro con los flags SYN y ACK. El puerto 21 de 192.168.1.9 está abierto.

# hping2 -c 1 -S -p 21 192.168.1.9
HPING 192.168.1.9 (en0 192.168.1.9): S set, 40 headers + 0 data bytes
len=46 ip=192.168.1.9 ttl=64 DF id=37670 sport=21 flags=SA seq=0 win=32768 rtt=0.4 ms
--- 192.168.1.9 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms

***********************************************************************************************************

En este otro ejemplo vemos que al enviar un paquete con flag SYN al puerto 80 de la misma máquina, nos
responde con otro con flags RST y ACK. El puerto 80 de esa máquina está cerrado.

# hping2 -c 1 -S -p 80 192.168.1.9
HPING 192.168.1.9 (en0 192.168.1.9): S set, 40 headers + 0 data bytes
len=46 ip=192.168.1.9 ttl=64 id=38005 sport=80 flags=RA seq=0 win=0 rtt=0.6 ms
--- 192.168.1.9 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.6/0.6 ms



Salu2

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.

Hombre, que reciba una FIN sin que haya una conexión previa es imposible (que yo sepa). Hasta donde yo sé, el FIN es para decir que se ha terminado la conexión, no pongo la mano en el fuego, pero que yo recuerde es así, por lo tanto no puedes recibir un segmento TCP con FIN activado sin que haya una conexión previa.

Salu2

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.

Es bueno saberlo, me tendré que tomar nota.

Salu2