Análisis capturas tráfico de Red. Interpretacion segmento TCP (II). Establecimento conexión TCP.

Ya vimos en la primera parte de este estudio sobre Análisis de capturas de tráfico de red la interpretación del datagrama IP, la interpretación de los valores hexadecimales de la salida de TCPDump/WinDump referente al datagrama IP. Ahora vamos a estudiar e interpretar el segmento TCP. TCP es el protocolo del nivel de transporte orientado a conexión. Veremos los mecanismos que implementa TCP para dar la mayor fiabilidad posible a dicha conexión. Mecanismos como los números de secuencia y las confirmaciones de recepción. También veremos en modo de apéndice, para comprender mejor lo estudiado, el establecimento de una conexión TCP.

A continuación una salida TCPDump/WinDump de una conexión cualquiera. En este caso un update de informacion a una tabla de BD mysql desde el puesto STATION a traves del puerto 1472 hacia INFO01 donde se ubica la base de datos mysql a la escucha en puerto 3306.

code1.jpg

Vamos a distinguir las partes que nos interesan.

Cabecera IP:

code2.jpg

Segmento TCP:

code3.jpg


Datos (incluye Opciones y Campo Relleno):

code4.jpg

La cabecera IP ya fue tema de estudio en la primera parte de este artículo. Así pues nos centramos en el Segmento TCP.

CAbecera TCP

La salida hexadecimal que vamos a analizar:

code3.jpg

  • 05c0 Puerto origen. En este caso 1472.
  • 0cea Puerto destino. En este caso 3306.
  • 27dd 44a3 Número de secuencia. (32 bits). Indica el número de secuencia del primer byte que trasporta el segmento. En este caso 1020517571.
  • 6fad 253b Número de acuse de recibo. (32 bits). Indica el número de secuencia del siguiente byte que se espera recibir. Con este campo se indica al otro extremo de la conexión que los bytes anteriores se han recibido correctamente. En este caso 1873618235.
  • 5 Posición de los datos (Data Offset). (4 bits). Longitud de la cabecera medida en múltiplos de 32 bits (4 bytes). El valor mínimo de este campo es 5, que corresponde a un segmento sin datos (20 bytes).
  • 018 Campo reservado (para un posible uso futuro) + Bits de código o indicadores. (6 + 6 bits.)

    Bits de código o indicadores. (6 bits). Los bits de código determinan el propósito y contenido del segmento. A continuación se explica el significado de cada uno de estos bits (mostrados de izquierda a derecha) si está a 1:

URG. El campo Puntero de urgencia contiene información válida.

ACK. El campo Número de acuse de recibo contiene información válida, es decir, el segmento actual lleva un ACK. Observemos que un mismo segmento puede transportar los datos de un sentido y las confirmaciones del otro sentido de la comunicación.

PSH. La aplicación ha solicitado una operación push (enviar los datos existentes en la memoria temporal sin esperar a completar el segmento).

RST. Interrupción de la conexión actual.

SYN. Sincronización de los números de secuencia. Se utiliza al crear una conexión para indicar al otro extremo cual va a ser el primer número de secuencia con el que va a comenzar a transmitir (veremos que no tiene porqué ser el cero).

FIN. Indica al otro extremo que la aplicación ya no tiene más datos para enviar. Se utiliza para solicitar el cierre de la conexión actual.

En este caso:

Si pasamos 018 (hex) a binario, obtenemos: 11000

Como ya hemos explicado en los artículos de TCPDump/windump:

….U A P R S F
——————
0 0 0 1 1 0 0 0 (en binario)
——————
7 6 5 4 3 2 1 0

los bytes 7 y 6 son los reservados. Vemos entonces que tenemos activados con 1 los indicadores A y P que corresponden a SYN +PSH

NOTA: Esto último ya los estudiamos en el capítulo de filtros TCPDump/ WinDump

  • fd59 Window (ventana). (16 bits). Número de bytes que el emisor del segmento está dispuesto a aceptar por parte del
    destino. En este caso 64857.
  • 2def Checksum o suma de vdrificación (16 bits). Suma de comprobación de errores del segmento actual. Para su cálculo se utiliza una pseudo-cabecera que también incluye las direcciones IP origen y destino.
  • 0000 Urgent Pointer o Puntero urgente (16 bits). Se utiliza cuando se están enviando datos urgentes que tienen preferencia sobre todos los demás e indica el siguiente byte del campo Datos que sigue a los datos urgentes. Esto le permite al destino identificar donde terminan los datos urgentes.

Nos quedan dos campos. Options y Padding o relleno

  • Opciones (variable). Si está presente únicamente se define una opción: el tamaño máximo de segmento que será aceptado.
  • Relleno. Se utiliza para que la longitud de la cabecera sea múltiplo de 32 bits.

Inmediatamente después nos encontramos con los datos. En este caso vemos las información del update de la base de datos mysql.

Hasta aquí el estudio del segmento TCP. En posteriores entregas estudiatremos UDP e ICMP.

Apéndice complementario.

Establecimiento de una conexión TCP.

Un ejercicio interesante puede ser analizar la salida en hexadecimal ttratando de comprender un establecimiento de conexión TCP. Para comprender como se realiza, a continuación una breve explicación ya publicada por mi Nautopía.

En los ejemplos veremos los campos del segmento TCP que acabamos de estudias de una forma más práctica.

Veremos en este apéndice cómo se realiza una conexión TCP. Nos ayudará a interpretar logs, trazas y técnicas de escaneo. Veremos también algunos componentes de los paquetes TCP aparte de los puertos de la máquina origen y destino. Estos componentes importantes son los números de secuencia y de confirmación (SEQ y ACK) que se utilizan para asegurar la integridad de la conexión y los flags o banderas que son los encargados de indicar la finalidad del paquete (para iniciar o finalizar una conexión, para transmitir datos, etc).

Una conexión TCP se realiza en tres pasos. Es lo que técnicamente se llama three-way handshake:

  1. En el sistema / host que inicia la conexión o cliente (TCP A), envía un paquete de SYN con un número de secuencia inicial asociado a esta conexión al sistema / host destinatario o servidor (TCP B).

  2. Este responde con un paquete SYN-ACK (acuse de recibo) confirmando la recepción del SYN inicial enviado por (TCP A) y enviándole a su vez su propio número de secuencia.

  3. Para finalizar, el cliente (TCP A) reconoce la recepción del SYN del servidor (TCP B) mediante el envío de un ACK. Este es el momento en que queda establecida la conexión. Ya se puede iniciar la transferencia de datos entre (TCP A) y (TCP B).

Vamos a avanzar un poco más ya que ocurren algunas otras cosas. Lo vemos gráficamente:

Sean dos hosts pretenden inciciar una conexión TCP. TCP A y TCP B, siguiendo la analogía de la explicación anterior.

  1. TCP A _SYN( SEQ=x ) -> y TCP B

  2. TCP B _SYN( SEQ=y, ACK=x+1 ) -> TCP A,

  3. TCP A _SYN( SEQ=x+1, ACK=y+1 ) -> TCP B.

Vemos como TCP A envía un paquete SYN con un número de secuencia inicial x que además es aleatorio a TCP B. El resto es fácil deducir.

Las letras x e y son los números de secuencia (SEQ). Se utilizan números de secuencia distintos para cada sentido de la comunicación. El primer número para cada sentido se acuerda al establecer la comunicación. Cada extremo se inventa un número aleatorio y envía éste como inicio de secuencia.

Un paso más para terminar de comprender la conexión TCP totalmente imprescindible para entender muchas técnicas de escaneo.

Ejemplo:

Sean dos hosts (TCP A) y (TCP B) que pretenden iniciar una conexión. Veremos también que pasa con los números de secuencia (SEQ):

establecimento conexion tcp

Todo esto es lo que ocurre cuando realizamos un escaneado de puerto TCP conect ().

Si la opción elegida es TCP SYN no dejamos que se establezca totalmente la conexión, esto significaría el envío por parte de TCP A de un RST (reset) cerrando así la conexión.

Ejercicios y ejemplos

1.- Como ejercicio podríamos descifrar esta traza capturada por Ethereal. Se trata de un escan Nmap TCP conect() al puerto 25.

La orden para escanear sería:

C:\nmap –sT –v 192.168.4.15 –p25

La traza resultante:

INFOGRAFIA3 ABANCECOMU TCP 1125 > smtp [SYN] Seq=13766490 Ack=0 Win=16384 Len=0
ABANCECOMU INFOGRAFIA3 TCP smtp > 1125 [SYN, ACK] Seq=472370892 Ack=13766491 Win=8736 Len=0
INFOGRAFIA3 ABANCECOMU TCP 1125 > smtp [ACK] Seq=13766491 Ack=472370893 Win=17472 Len=0

 

2.- Ahora vamos a ver un escaneo nmap tipo –sS al puerto 25 (smtp) desactivando el ping.

La orden para escanear sería:

C:\nmap –sS –P0 IFOGRAFIA3 –p 25

La traza resultante:

ABANCECOMU INFOGRAFIA3 TCP 38428 > smtp [SYN] Seq=2093898103 Ack=0 Win=2048 Len=0
INFOGRAFIA3 ABANCECOMU TCP smtp > 38428 [SYN, ACK] Seq=3462674933 Ack=2093898104 Win=16616 Len=0
ABANCECOMU INFOGRAFIA3 TCP 8428 > smtp [RST] Seq=2093898104 Ack=2093898104 Win=0 Len=0

 

Vemos claramente el RST (reset) enviado en la última línea de la traza, no completando o estableciendo la conexión.

 

NOTA: Observemos en ambos casos los incrementos y valores de números de secuencias, los indicadores o flags TCP que se intercambian en el diálogo, etc.

Esta entrada fue publicada en Actualizaciones de Artículos, Seguridad y redes y etiquetada , , , , , , , , , , , , , , , , , , , , , . Guarda el enlace permanente.

19 respuestas a Análisis capturas tráfico de Red. Interpretacion segmento TCP (II). Establecimento conexión TCP.

  1. natalia dijo:

    me gustaria tener un listado de para que sirve cada puerto

  2. rolando dijo:

    Me parecen muy atinados todos tus aportaciones, felicidades

  3. Fernando dijo:

    Hola, muy bueno el articulo, me ayudo bastante porque tengo un examen mañana y no entendia este tema. Lo unico, esta mal convertido el hexa 018, da 0000 0001 1000 y cambia el significado de los bits.
    Saludos y gracias!

  4. Cristian dijo:

    Excelente aporte, muchas gracias.

  5. CarLOx dijo:

    Tremendo articulo, muy puntual, gracias por el aporte….

  6. cesk dijo:

    hola, no soy muy entendido en la materia pero hace poco hice un analisi tcp con el wireshark i en el campo de bit reservados al codigo tambien tenia el 018. I creo que hay un error porquè el 018 passado a binario és 0001 (para el uno) i 1000 (para el ocho) entonces no son los campos syn i ack, sino los campos ack (0001) i el campo push del (1000).
    si estoy equivocado por favor hagame-lo saber en el correo electronico adjunto. muchas gràcias.

  7. Carl dijo:

    No suelo postear en ningun foro , pero macho me has ganao 😉 , el mejor resumen del funcionamiento de tcp/ip que he visto en castellano , creia saber como funcionaba tcp , pero desconocía por ejemplo cosas tan importantes como que el numero de SEQ es diferente para cada sentido de la conexión ,
    Gracias Alfon !!!
    Sigue así por favor ,
    Un saludo

  8. Alfon dijo:

    Estimado cesk. Gracias por la correción. Efectivamente había un error de conversión. Esta solventado. Saludos.

  9. cesar dijo:

    Hola
    En el ejercicio 2 (RST) xq manda el RST al final ?

  10. Alfon dijo:

    Cesar, al recibir el SYN,ACK ya intuimos que el puerto escaneado está a la escucha, por tanto, no necesitamos establcer formalmente la conexión con ACK, usamos un RST para romper la conexión y que no quede el intento registrado ?. También podríamos no enviar nada y dejar la conexión a medias. no es necesario enviar el RST.

  11. cesar dijo:

    Ok Alfon
    Entoces si entendio es normal q se mande el RST en lugar de un FIN ?
    Esto es xq tengo una app donde al final me aparecen los RST sobre los puertos galileolog y ecmport.

  12. Pingback: Modificando ficheros de tráfico de red .pcap con Bittwiste. | Seguridad y Redes

  13. Joaquin Sala dijo:

    Muchas gracias, muy buena explicación.

  14. gerardo dijo:

    0000: 4500 0034 0000 4000 3806 6bd2 5641 c5d4
    0010: c0a8 fa33 0050 c6ba 88da 7a6b d94d f48c
    0020: 8012 16d0 e91a 0000 0204 05ac 0101 0402
    0030: 0103 0308

    a) ¿Qué función dentro del protocolo TCP cumple el segmento enviado?
    b) Caracterice a los hosts A y B como cliente/servidor.
    c) ¿Cuál será el número de secuencia que utilizará el host A en el próximo segmento que le envíe a B?
    d) Asumiendo que B publica un valor de MSS similar al que publica A ¿Cuántos segmentos le
    enviará A hasta agotar la ventana?
    e) ¿Cuál es el servicio que origina la comunicación?

    necesito resolver esto me pueden ayudar

  15. Pingback: TNV. Herramienta gráfica de visualización e interpretación de tráfico de red. | Seguridad y Redes

  16. Alex Sucari dijo:

    Excelente, todos los datos son muy interesante, no lo encontré tan detallado ni en wikipedia :V

  17. Pingback: Tshark. Extrayendo información de imágenes en capturas HTTP. | Seguridad y Redes

  18. Isaac dijo:

    No soy tan entendido en estos temas. ¿Como podría saber que es lo que me esta cortando una conexion de envio y recepcion de ficheros entre dos maquinas de distintas redes? El log que deja es muy amplio.

Deja un comentario