Ya vimos en el capítulo Analisis capturas tráfico red. Interpretación Datagrama IP. (Parte I) los campos contenidos en la cabecera de un datagrama IP. Ante la petición de aclaración y mejor explicación de estos conceptos en comentarios y algún correo, paso a actualizar el mencionado artículo, avanzar y explicar mejor todos los conceptos involucarados.

Decíamos en el artículo de referencia......:

Una de las tareas habituales de un administrador de red es el análisis de los logs de tráfico de la red. Análisis que puede ser de rendimiento ó seguridad. Tráfico de la LAN, entrante y saliente a través de cortafuegos, análisis de Sistemas de Detección de Intrusos, capturas de tráfico de red, etc.

Para ello contamos con variadas herramientas. Entre ellas Snort, TCPDump/Windump, WireShark, etc. (Destaco estas tres últimas por estar basadas en la librería libpcap).

En este artículo vamos a analizar las capturas en hexadecimal de estas herramientas para obtener todos los datos posibles de las cabeceras IP, segmento TCP, además de comprender de forma más visual los conceptos TCP/IP.

En esta actualización del artículo, veremos también estos conceptos, no solo a través de una captura tcpdump / windump, tambíen a través de WireShark.

Las herramientas mencionadas hacen uso de Libpcap, que es una librería de código abierto que ofrece al programador una interfaz desde la que capturar paquetes en la capa de red. La implementación para windows es Winpcap. Entre las utilidades más importantes de los analizadores de tráfico de red está la que nos proporciona la salida en hexadecimal de las capturas.

En este artículo vamos a analizar dichas capturas en hexadecimal para obtener todos los datos posibles de las cabeceras IP y segmentos TCP, además de comprender de forma más visual los conceptos TCP/IP.

Para ello usaremos TCPDump (Linux/Unix) / Windump (Windows).También usaremos Wireshark.

Antes que nada recordar un poco como funciona TCPDump / Windump:

• Seguridad y Redes Analizando la Red con WinDump / TCPDump (I Parte)
• Seguridad y Redes Analizando la Red Con WinDump / TCPDump (II Parte)
• Seguridad y Redes Analizando la Red con WinDump/TCPDump (Parte III)

Recordamos algo básico sobre el funcionamiento de Wireshak.

Y recordar también los conceptos TCP/IP:

• http://es.wikipedia.org/wiki/TCP/IP
• http://www.saulo.net/pub/tcpip/

Para las salidas en hexadecimal usaremos la opción -x de tcpdump / windump que captura por defecto 68 bytes.

Para capturar toda la información usamos el snaplen (-s0). A cero estamos cogiendo los paquetes completos.

Si hubiéramos puesto -s 512 se capturarían sólo los primeros 512 bytes de un determinado paquete.

Comenzamos.

Interpretación de un Datagrama IP.

Para mejor referencia tenemos abajo el formato de la cabecera de datagrama IP:

Esta es una salida en hexadecimal de cualquiera de los analizadores
de red mencionados más arriba, en este caso tcpdump, aunque podemos usar también Tshark:

En la primera línea tenemos ya algunos datos (esto ya lo hemos visto en el artículo de tcpdump). Si embargo vamos a descifrar la cabecera para obtener los mismos y otros datos importantes.

NOTA: Para no perder detalle, observemos al gráfico de la cabecera IP y la captura hexadecimal para ver a que corresponde cada valor quepaso a explicar a continuación. Coloreo los primeros valores para que sea más facil localizarlos.

DATAGRAMA IP

VERSION: 4 Tiene una longitud de 4 bits. En este caso 4 (0100 en binario) Se trata de la versión del formato de la cabecera IP. Vemos que 4 corresponde a la versión ipv4. si el valor fuera 6, se trataría de la versión ipv6.

IHL: 5  ó longitud de la cabecera en palabras de 32 bits. En este caso: 5*32=160 bits. El valor mínimo es 5. Este campo indica en que punto o bit  termina la cabecera del datagrama. Esto es así porque al ser el datagrama de longitud variable devido a las opciones, también de tamaño variable, se necesita saber donde comenzará la parte de datos del paquete.

TOS: 00 Tipo de servicio respecto a la fiabilidad, velocidad, retardo, seguridad, etc deseados. Tiene un tamaño de 8 bits, en este caso 00000000. Hay que tener en cuenta que algunas redes ofrecen prioridad de servicio para dar mayor importancia a este tipo de tráfico.

Tabla de valores para TOS

• Bits 0-2 Prioridad.

• Bit 3 0 = Demora Normal, 1 = Baja Demora.

• Bit 4 0 = Rendimiento Normal, 1 = Alto rendimiento.

• Bit 5 0 = Fiabilidad Normal, 1 = Alta fiabilidad.

• Bits 6-7 Reservado para uso futuro.

En este caso:

prioridad 0 y demora, rendimiento y fiabilidad: normal

TOTAL LENGTH: 0064 Longitud total del datagrama medida en octetos. Se incluyen los datos encapsulados, cabecera y datos.

La longitud del campo es de 16 bits. De esta manera la longitud máxima es (1111111111111111) = 65535 bytes. En este caso 100 bytes.

ID: 8a01 Número de identificación único por cada datagrama que permitirá el reensamblaje posterior al ser dividido en fragmentos más pequeños. Longitud 16 bits. En este caso Id=35329. Lo asigna el remitente en la conexión. El valor de este campo junto a la información de Source IP y Destination IP, resuelve la identificación única del paquete al que hace referencia.

FLAGS: 4 Bandera (Flag) Campo de 3 bits.Indicadores de control. Usado en caso de defragmentación.

• El primer bit esta reservado y es siempre 0.
• El segundo es el el bit de indicación de no fragmentación (DF). (010)
• El tercero (MF) es de verificación que el datagrama llega a su destino (001) completo, está activo en todos los datagramas enviados excepto en el último para informar que ya no hay más fragmentos.

FRAGMENT OFFSET: 000 Posición. Longitud de 13 bits. Posición del fragmento dentro del datagrama en caso de fragmentación.

TTL: 80 Tiempo de vida. Longitud 8 bits. Impide que un paquete esté indefinidamente viajando por la red. En este caso 128 indica que cada vez que un datagrama atraviese un router este numero se decrementa en 1. cuando el TTL llege a 0 el datagrama se descarta y se informa de ello al origen con un mensaje de tiempo excedido.

PROTOCOL: 06 Protocolo. Se refiere al protocolo de siguiente nivel que se usa en la parte de datos. Longitud 8 bits. En este caso hex(06) (00000110) = TCP en decimal sería 6.

Valores para los protocolos

1 ICMP, 2 IGMP, 6 TCP, 9 IGRP, 17 UDP, 47 GRE, 50 ESP, 51 AH, 88 EIGRP, 89 OSPF, 115 L2TP.

HEADER CHEKSUM: ec4e (CRC) o Suma de Control de la Cabecera. Longitud 16 bits. Es la suma de comprobación de errores de la cabecera del datagrama. Este número se calcula nuevamente en cada salto del datagrama a través de los routers.

SOURCE ADDRESS: c0.a8 01.f0 dirección origen: 192.168.1.240 longitud 32 bits.

DESTINATION ADDRESS: c0.a8 01.03 dirección destino: 192.168.1.3 longitud 32 bits.

Tenemos otro campo que es Options (Opciones) de longitud variable con información opcional para el datagrama. Puede tener 0 o más opciones. Y Padding (Relleno) también de longitud variable. Asegura que la cabecera IP termine en múltiplo de 32 bits.

Según el RFC0791 Las opciones Options pueden o no aparecer en los datagramas. Deben ser implementadas por todos los módulos IP (host y pasarelas). Lo que es opcional es su transmisión en cualquier datagrama en particular, no su implementación.

NOTA: Este campo de opciones lo veremos de forma más detallada en otro artículo.

El último campo es Data, de longitud variable, conteniendo los datos a enviar. La longitud máxima es 64 Kbytes y comienza con el contenido de la cabecera del protocolo de siguiente nivel, es decir TCP o UDP. Los datos y encabezamiento del segmento TCP van dentro del campo Data del datagrama IP, es lo que llamamos encapsulación.

En este caso el campo Data comienza con con los campos de la cabecera del segmento TCP puerto origen y puerto destino:

008b Puerto origen 139

044a Puerto Destino 1098

Formato de la cabecera TCP (encapsulado en el Data del segmento IP)

Valores Cabecera Datagrama IP en Wireshark.

Bien. Vamos ahora a ver los conceptos estudiados sobre la cabecera del datagrama IP, pero en una captura Wireshark cualquiera.

Vemos en la ventana de protocolos señalado el item correspondiente a los datos de la cabecera IP. Internet Protocol y su correspondencia (abajo) con los datos en hexadecimal.

Apreciamos valores, ya explicados al principio de este artículo, de

• Version: 4
• Header Length: 20 bytes, se refiere a IHL de la cabecera.
• Differenciated Services Field. (TOS). Tipo de servicio.
• Total Length: 40
• Identification 0xb680 (46720)
• Flags: 0x04. E nes te caso vemos activado en bit de No fragmentado.
• Fragment Offset: 0
• Time to Live: 128 (TTL)
• Protocol: TCP (0x06) como viemos en el cuadro de protocolos posibles.
• Header checksum:  0x6e36
• source y destination

Apreciamos unos campos para mostrar información de geolocalización de las IP GeoIP (vimos como usar Wireshark y GeoIP en este artículo ):

• no procede la geolocalización de la IP de origen por ser local.
• procede la geolocalización de IP destino

--------------------------------------------------------------------------------

volvemos a la captura de la Parte 1 de la serie:

Paquete 11. NAME QUERY RESPONSE NB 192.168.76.1  (00)

Comienza la sesión con una petición de de resolución de nombre de host mediante Name query NB CLIENTE<00> Esto se hace usando NetBios mediante broadcast (192.168.1.255).

Responde 192.168.1.30 con Name query response NB 192.168.76.1

NOTA: Observad que aparcece la IP 192.168.76.1 en vez de 192.168.1.30 que sería lo lógico. Esto es así porque el host CLIENTE tiene otra interface de red (virtual) que corresponde a VMWare. De cualquier forma, vemos que la NIC física está indicada en la captura en la columna Source: (192.168.1.30)

Al igual que Name query NB, response también usa el puerto UDP 137:

Vemos muchas más diferencias respecto a Name query NB, vamos a verlas.

Antes que nada nos fijamos en el campo Transaction ID. (0x8022) que ya vimos que se refería a la identificación del proceso de resolución de nombre. Pues esta identificación es la misma (0x8022) tanto para Name query NB como para Name query response. Esto es así para indentifica un mismo proceso, proceso de petición y de respuesta. Paquetes 7 y 11.

Vamos ahora al resto de campos.

... antes que nada la referencia de la cabecera:

• Opcode. código de tipo de paquete. Se divide a su vez en dos campos: Response (1) en este caso inica un Message is a response y Opcode propiamente dicho (0) que indica un query.

• Flags (0x8500) :

• Truncated (0). Indica no truncado. Para establecer si el contenido es mayor que 576 bytes.
• Recursion desired (1) se encuentra activado e indica que se trata de un query o pregunta recurrente.
• Broadcast (0) desactivado, indica que no es un paquete broadcas y no se usa.

Se añaden otros flags / campos que son los siguientes:

• Authoritative (1).
• Recursion available (0)
• Reply code (0) ó RECODE Muestra un código con el resultado de la petición name query (paquete 7de la captura wireshark). En este caso (0) indicando No error. Otros códigos son:

• 0 indica que no hay error
• 1 error de formato
• 2 error de servidor
• 3 error de nombre
• 4 solicitud no compatible.
• 5 por politicas de servidor, denegación de respuesta.
• 6 Active error.
• 7 error de nombre. Conflico.

Seguimos:

• QUESTION ENTRIES ó Questions. (0) Número entero que indica en número de entradas coincidente con una pregunta por nombre. En este caso 0. Se trata de una respuesta.
• ANCOUNT ó Answer RRs (1). Indica número de recursos o registros que se tratan de una respuesta.
• NSCOUNT ó Authority RRs (0). Número de registros de la sección authority de Name Serivce packet
• ARCOUNT ó Additional RRs. (0) Número indicando recursos adicionales.

El siguiente campo tratándose de un paquete Name query response NB, se llama Answers, al contratio de Queries, que veíamos en el capítulo anterior para un paquete Name query NB.

Este campo contiene la respuesta a la petición del Name query NB. REsponde con el nombre de host y su IP. Aquí vemos 3 IPs que corresponden a las tres interfaces de red: 2 VMWare y una física 192.168.1.30:

Básicamente y de forma sencilla. En el procedimiento de resolución del nombres, que se basan en broadcast, en servidor o en ambos, se pueden usar:

• broadcast a la red,
• usando NETBIOS: NBNS ó WINS (sistemas Windows).

por ello, cada host se puede configurar:

• solo usando broadcast
• solo NBNS
• primero broadcast y seguidamente NBNS en el  caso de no respuesta al broadcast.
• lo contrario de lo anterior. Primero NBNS y en caso de no respuesta broadcasting.

Eso lo vemos en nuestra captura en los campos:

• b-node (00). cuando solo se usa broadcast a la red
• p-node (01). cuando solo se usa NBNS
• m-node (10). cuando se usa primero broadcast y en caso de no obtenerr respuesta se usa NBNS.
• h-node (11). cuando primero se realiza mediante NBNS y en caso de no respuesta broadcasting.

Vemos en nuestra captura que las 3 respuestas obtenidas para las tres IPs, se realizan bajo b-node (00) o broadcast a la red.

Apreciamos también otras informaciones como TTL (Time To Live), Type NB (Servicios de nombres de NETBIOS), Class (Resource Record Class), en este caso Internet Class.
-----------------------------------

En el siguiente capítulo veremos los siguientes paquetes correspondientes a ICMP Echo request y Echo reply para  obtención de la dirección MAC, el establecimiento de conexión con el recurso, ngoaciación del protocolo Request y Response (SMB), etc.

Comments

SMB (Server Message Block), básicamente se trata de un protocolo que permitre compartir archivos, impresoras, puertos serie, etc entre hosts conectados en red. Pertenece a la capa de aplicación OSI y es un protocolo del tipo cliente-servidor. SMB se encuentra por encima de NETBIOS, que es la que se encarga de la resolución de Nombre host / IP.

CIFS (Common Internet File System) es una implementación que supone, también, una evolución de SMB para el sistema Windows en sus versiones más modernas. Al tratarse de un protocolo de alto nivel, necesita apoyarse en protocolos de transporte como NETBIOS. Al ser una evolución e implementación de SMB, es también un protocolo cliente-servidor.

La forma de trabajar de CIFS, como envía paquetes request de cliente a servidor, como responde, etc, etc.

Todo esto lo veremos, como siempre, con ejemplos de capturas Wireshark.

Para, en este artículo,  entender SMB/CIFS, vamos a centrarnos, en las capturas, a todo lo referente a estos protocolos y las trazas quese ven involucradas.

Comenzamos con la siguiente captura con los filtros adecuados para la ocasión y observemos el intercambio de paquetes entre CLIENTE (192.168.1.30 ) Y SISTEM (192.168.1.5), los dos host involucrados en una sesión en la que SISTEM se conecta a CLIENTE para usar el recurso compartido COMPARTIR y usa los archivos de dicha carpeta editándolos, borrando o creando un nuevo.

Parte de la captura es la siguiente:

Paquete 7. NAME QUERY NB CLIENTE (00)

Comienza la sesión con una petición de de resolución de nombre de host mediante Name query NB CLIENTE<00> Esto se hace usando NetBios mediante broadcast (192.168.1.255).

Responde 192.168.1.30 con Name query response NB 192.168.76.1

NOTA: Observad que aparcece la IP 192.168.76.1 en vez de 192.168.1.30 que sería lo lógico. Esto es así porque el host CLIENTE tiene otra interface de red que corresponde a VMWare.

Name query NB y Name query response usan el puerto 137y UDP.

Vamos a hora a fijarnos en la ventana de protocolos (imagen de arriba). Observamos como hemos indicado ya los puertos usados (137) y nos centramos en NetBIOS Name Service.

Y para tener una referencia tenemos aquí el formato de paquete de Name Service de NETBIOS:

Y, a continuación el Header o cabecera:

Y ahora a destripar los datos.

Tenemos una sere de campos y Flags:

• NAME_TRN_ID ó Transaction ID. (0x8022) Identificación del proceso de resolución de nombre.

• Opcode. código de tipo de paquete. Se divide a su vez en dos campos: Response (0) en este caso inica un message is a query y Opcode propiamente dicho (0) que indica un query.

• Flags (0x0110) :

• Truncated (0). Indica no truncado
• Recursion desired (1) se encuentra activado e indica que se trata de un query o pregunta recurrente.
• Broadcast (1) está activado e indica que la resolución se realiza a través de un paquete broadcast.

• RCODE. Muestra un código con el resultado de la petición name query (paquete 7 de la captura wireshark). Lógicamentre no aparece aquí, aparecerá en el resultado o Name query response.

• QUESTION ENTRIES ó Questions. (1) Número entero que indica en número de entradas coincidente con una pregunta por nombre.
• ANCOUNT ó Answer RRs (0). Indica número de recursos que se tratan de una respuesta, en este caso obviamente es 0 porque es una pregunta.
• ARCOUNT ó Additional RRs. (0) BNúmero indicando recursos adicionales.

Vemos también el campo Queries que nos da infomación de la pregunta o consulta solicitada, en este caso preguntamos por la máquina CLIENTE.

Y hasta aquí la primera parte en la que hemos tratado de destripar, sacar información, del paquete Name query NB, paquete nº 7 de nuestra captura. En los siguientes cápitulos veremos la resupuesta o Name query response (paquete 11) de la captura.

Comments

Los distintos filtros para GeoIP son los siguientes:

filtro | tipo de cadena | descripción | versión wireshark

La manera de aplicarlos es la misma que para cualquier filtro:

Aplicado el filtro aparecerán las trazas correspondientes.

Podríamos usar otro filtro como este para depurar algo más:

ip.geoip.country == "Spain" && ip.geoip.city contains "Barcelona"

Wireshark nos muestra también la información GeoIP en la misma ventana de protocolos, en un campo denominado Source GeoIP:

Podemos hacer uso también de los filtros GeoIP con Tshark en línea de comandos:

Comments

Descarga y ubicación de bases de datos GeoIp.

Necesitamos las siguientes bases de datos:

• Geoip.dat 
• GeoLiteCity.dat
• GeoIPASNum.dat

Creamos una carpeta, por ejemplo C:\Archivos de programa\Wireshark\goip y volcamos ahílos ficheros dat descargados.

Configuración  Wireshark para GeoIP.

En el menú Edit > Preferences > Name Resolution, a la derecha tenemos GeoIP database directories, pulsamos el botón Edit y se nos  abre una ventana GeoIP Database Paths, pulsamos New e introducimos la ruta (C:\Archivos de programa\Wireshark\goip) donde descargamos las base de datos GeoIP:

Ahora nos situamos dentro de la ventana de detalles del protocolo, en Internet Protocol, botón derecho del ratón y Protocol preferences... marcamos la opción Enable GeoIP lookups:

Ya tenemos configurado Wwireshark para GeoIP.

Visualización de los datos GeoIP de una captura.

Realizamos una captura o abrimos un fichero de captura previamente grabado.

En el menú Statistics > Endpoints, se nos abre la ventana en la cual seleccionamos la pestaña IPv4. Veremos como se han añadido a las columnas por defecto, otras como:

• Country
• AS Number
• City
• Latitude
• Longitude

todas correspondiente a los datos obtenidos a través de la Geolocalización de GeoIP / GeoLite.

NOTA: En esta captura desplazo la barra para ver solo los datos de GeoIP. pero tenemos las IP (Address), Paquetes, Bytes, etc, etc :

En esta misma ventana de Endpoints, vemos un botón: Map. Si pulsamos en Map, se nos abrirá nuestro navegador por defecto desplegando un mapa (similar a google maps) con la localización geográfica de las IP:

----------------------------------------------------------------

Para la próxima haremos una reseña a los filtros Geoip con opciones para filtrar por lo calización ciudad, etc.

Comments

Vamos a estudiar estas opciones.

Para usar esta caracterísitica de Wireshark, debemos completar las opciones de uso de multiples archivos:

Vemos las opciones de Capture File(s):

• File. Aquí indicamos el archivo y ruta de los archivos .cap de captura.

El formato resultante del archivo .cap es el siguiente:

cap__ es el nombre que indicamos en el campo File.

00002 número de serie o de captura

20091026085612 marca de tiempo: fecha  2009-10-26 tiempo 08:56:12 en horas, minutos y segundos.

• Use multiple files. Marcamos esta opción para captura a multiples archivos.
• Next file every. Wireshark grabará un archivo nuevo cada n Megabytes, Kilobytes o Gigabytes.
• Next file every. wireshark también grabará un archivo nuevo cada n segundos, minutos, horas o dias.

NOTA:  Tanto si usamos la opción de grabar archivo nuevo cada n tiempo o cada n cantidad de bytes, ambas la podemos usar de forma independiente o marcar las dos. Si marcamos las dos, Wireshark grabará un archivo nuevo cada n cantidad de bytes, pero  si sobrepada el tiempo que marquemos en la segunda opción (opción de tiempo), entonces grabará un archivo nuevo aunque no llegue a la cantidad en bytes.

Lo vemos con un ejemplo. Fijaos en la captura anterior, tenemos marcado que grabe un archivo nuevo cada 1 Megabyte o cada 15 segundos. Si vemos los archivos .cap grabados:

Podeis observar que, a pesar de indicar que grabemos archivo nuevo cada 1 Megabyte, no llega a tal cantidad, ya que sobrepasa los 15 segundos marcado como límite de captura. Observad las marcas de tiempo, vereis como entre una y otra pasan exactsmente 15 segundos.

• Stop capture after. Wireshark parará la captura cuando se graben n ficheros .cap.
• Ring buffer with. Wireshark creará una serie de archivos de cáptura (buffer en anillo) cada n ficheros de captura.

NOTA: En Capture filter, podemos establecer un filtro para la captura de los multiples. cap. De esta forma optimizamos el rendimiento y el tamaña de los ficheros.

Navegando por los archivos de captura.

Podemos navegar a través de los set de archivos de captura de la forma siguiente en el menú de Wireshark: File > File Set > List Files:

Cuando seleccionemos cualquiera de los archivos de la captura, se visualizarán todos los datos correspondientes en Wireshark.

-----------------

Comments

Jperf es una interface gráfica para Iperf. Está basado en Java y tiene las mismas funcionalidadesque Iperf. Lo podemos descargar desde aquí: (http://code.google.com/p/xjperf/).

Para su instalación, tan solo tenemos que descargar el archivo comprimido, descimprimir y ejecutar el archivo jperf.bat

La filosofia de uso es la misma que Iperf. Al tratarse de una herramienta cliente-servidor, ejecutaremos Iperf en dos máquinas, una hará de Servidor y otra de Cliente. Tanto en una como en otra podemos ejecutar indistintamente Jperf o Iperf. Es decir, podemos usar en un extremo y en otro Jperf como cliente y servidor o, como lo haremos aquí, Iperf como servidor y jperf como cliente y herramienta de análisis.

IPerf como servidor.

La forma más básica de ejecución como servidor es:

>iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------

En este momento IPerf se encuentra a la "escucha" en le puerto 5001.

JPerf como cliente.

Como ya hemos comentado, tan solo tenemos que  ejecutar jperf.bat, archivo contenido en la carpeta descomprimida del paquete descargado de Jperf. Una vez ejecutado el fichero por lotes mecionado, se nos abrirá el interface gráfico:

Tenemos en la interface los siguientes campos u opciones importantes:

• iperf command: se rellenará automáticamente al introducir la IP del host remoto en el campo server address
• Choose iPerf Mode: Indicamos si estamos usando jperf en modo cliente o servidor. En este caso lo haremos como client.
• Server address: dirección del host remoto. Aquí introducimos la IP del host remoto. Automáticamente se rellenará el campo iperf command con unas opciones por defecto que irán cambiando a medida que rellenemos los cuadros Aplication layer options y Transport layer options.

Transport layer options.

Aquí indicaremos el protocolo TCP o UDP. Podemos ajustar valores como el Tamaño de la ventana, Longitud de buffer y el MSS (Maximum Segment Size) o cantidad de datos enviados en cada paquete. Ajustanto estos valores en nuestras mediciones podemos encontrar los valores óptimos para el mejor rendimiento de la red. La opción de ajuste más importante es el tamaño de ventana o Window Size. Lo común es que aumentando el Tamaño de Ventana, aumente el rendimiento, pero no siempre es así.

Pasa lo mismo con la Longitud de Buffer o Buffer Length. En valores pequeños podemos tener una red con un rendimiento bajo y subir demasiado este valore puede desencadenar retardos.

Respecto al Max Segment Size o Tamaño máximo de Segmento, cantidad de datos enviados en cada paquete sin fragmentar (expresado en bytes). Extraigo de la Wikipedia esta explicación bastante buena sobre Max Segment Size (MSS).:

"Para una comunicación óptima la suma del número de bytes del segmento de datos y la cabecera debe ser menor que el número de bytes de la unidad máxima de transferencia (MTU) de la red.

El MSS tiene gran importancia en las conexiones en Internet, particularmente en la navegación web. Cuando se usa el protocolo TCPMTU que ambos puedan aceptar. El valor típico de MTU en una red puede ser, por ejemplo, 576 ó 1500 bytes. Tanto la cabecera IP como la cabecera TCP tienen una longitud variable de al menos 20 bytes. En cualquier caso, el MSS es igual a la diferencia MTU - cabecera TCP - cabecera IP. para efectuar una conexión, los ordenadores que se conectan deben acordar y establecer el tamaño de la

A medida que los datos son encaminados por la red deben pasar a través de múltiples routers. Idealmente, cada segmento de datos debería pasar por todos los routers sin ser fragmentado. Si el tamaño del segmento de datos es demasiado grande para cualquiera de los routers intermedios, los segmentos son fragmentados. Esto aminora la velocidad de conexión, y en algunos casos esta bajada de velocidad puede ser muy apreciable. La posibilidad de que ocurra esa fragmentación puede ser minimizada manteniendo el MSS tan pequeño como sea razonablemente posible. En la mayoría de los casos, el MSS es establecido automáticamente por el sistema operativo."

Application layer options.

De esta ventana destacar las opciones para cantidad de transmisión en Bytes o segundos de muestreo. Formato de Salida , el valor de intervalos de tiempo y el puerto al que se dirigirá y en el que escucha el host remoto (por defecto 5001).

Ejecutando Jperf

Una vez tenemo los valores en los campos correspondientes, tan solo nos resta pulsar el botón Run Iperf!:

Una vez realizada las pruebas, podemos ir modificando en el registro de Windows los valores más óptimos de rendimiento.

Vamos a realizar una prueba. Ajustaremos el valor de tiempo de transmisión (Transmit) en 30 segundos. En Transport layer option > TCP window Size ponemos 6 KBytes y Run Iperf!:

Vemos que el rendimiento con un tamaño de ventana de 6 Kbyes es de unos 75 Mbits / sec. apreciamos también las oscilaciones del rendimiento en el Bandwidth.

Cambiemos ahora el valor del tamaño de ventana (TCP windows Size) a 56 Kbytes.Vea mos que ocurre ahora:

Vemos ahora como el rendimiento y la estabilidad son mejores. Tanto en  el host remoto como en la ventana de Bandwidth de este captura vemos que nos da unos valores de  93,7 Mbits / sec.

Podeis probar, por ejemplo, cambiando los valores de Buffer Length. Vereis como a distintos valores y forma la gráfica va cambiando en función del rendimiento obtenido.

------------------------------------------------------------------------

NOTA: Atualizaré periódicamente este artículo con nuevas pruebas, resolución de problemas, etc.

-------------------------------------------------------------------------

Comments

RPCAPD es una herramienta que nos sirve para conetarnos a una interfaz de red en un host remoto. Se encuentra por defecto en C:\Archivos de programa\WinPcap.

Preparando el host remoto 192.168.1.30

Para capturar desde un host local A a nuestro host remoto B, necesitamos saber que dispositivo o interfaz de red vamos a usar del host remoto B en la captura. Para ello tan sencillo como, entre otras formas, usar Tshark en el host remoto B para el descubrimiento de dicha información:

La interfaz que nos interesa es la número 4 que está reseñada. Copiamos o volcamos la información a un archivo de texto para luego usarla en Wireshark.

Para terminar la preparación del host remoto B, una vez tenemos la información anterior, tan solo nos hace falta dejar RPCAPD escuchando en el host remoto B:

Con -n le decimos que no requiera autentificación. La opción -p3333 es para indicar el puerto a la escucha.

Preparación del host local 192.168.1.5 para la captura con Wireshark.

Ahora cargamos Wireshark. Introducimos los datos necesarios:

Le damos a OK. Y ahora tenemos que introducir el nombre del dispositivo de red del host remoto B que descubrimos anteriormente con Tshark -D. Lo haremos usando esta forma (en negrita el nombre del dispositivo):

rpcap://192.168.1.30:3333/\Device\NPF_{58C21E09-0C1F-4F85-9463-12328CA28B9A}

Lo vemos mejor:

Reseñado está lo que hemos introducido en el campo de la interface. Esto lo podemos hacer escribiendo directamente en el campo.

Pulsamos ahora el botón Remote Setting y decimos a Wireshark que no capture el tráfico RPCAP:

OK y en el panel principal pulsamos Start.

Y capturamos a traves de Wireshark todo el tráfico de red de la interfaz remota Device\NPF_{58C21E09-0C1F-4F85-9463-12328CA28B9A} de forma, también remota; del host local A a host remoto B tal como podemos comprobar:

NOTAS de uso RPCAPD:

Si bien en este artículo hemos usado Wireshark con la opción Null Authentication para comunicarse con RPCAPD (usamos la opcion -n de RPCAPD), lo mejor es hacerlo  mediante credenciales (Password authentication).

Podemos guardar la configuración de RPCAPD  en un archivo (rpcapd.ini) con la opción -s y cargar ese mismo fichero con -f

Con la opción -b de RPCAPD podemos decir que eschuche y comunique con un determinado host o hacerlo a través de una lista blanca -l

Con la opción -d podemos usar RPCAPD como servicio en sistemas win32.

-------------------------------

Comments

De forma básica, podemos decir que FTP es un protocolo de red para la transferencia de archivos de un sistema a otro conectados a una red TCP, basado en la arquitectura cliente-servidor y de una forma fiable y eficiente.

Dicho esto, vamos, a continuación, estudiar la captura realizada.

Las primeras lineas que observamos en la captura corresponden al inicio de la comunicación con el servidor FTP. Se trata, como vemos, del establecimiento de conexiónen tres pasos. El número de secuencia incial es relativo y por tanto en este caso 0.

cliente       servidor    TCP      2203 > 21 [SYN] Seq=0 Win=64512 Len=0 MSS=1460
servidor     cliente      TCP      21 > 2203 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
cliente       servidor    TCP      2203 > 21 [ACK] Seq=1 Ack=1 Win=64512 Len=0

1. cliente envia SYN con un número secuencia Seq=0 y Ack=0
2. servidor lo recibe, envia SYN-ACK y responde con su propio número de secuencia Seq=0 y con un ACK = al número de secuencia anterior + 1, es decir: Ack=1
3. cliente a su vez responde con ACK y número de secuencia inicial (Seq=0) +1 y ACK = número de secuecia anterior (Seq=0) +1, es decir: Ack=1

En la siguiente línea vemos como el servidor responde al cliente con el código 220 que indica servicio preparado para nuevo usuario y nuestra información del software/versión del servidor FTP:

Response: 220-FileZilla Server version 0.9.29 beta

NOTA: En la ventana de detalles del paquete, vemos que wireshark nos proporciona más información sobre el sevidor:

Seguimos. Responde le cliente iniciando el diálogo y sesión FTP con el servidor. USER identifica al usuario para acceder al sistema de ficheros del servidor:

Request: USER xxxxxxxx

El servidor requiere la contraseña del usuario con el código 331 que indica OK al usuario y que necesita contraseña:

Response: 331 Password required for xxxxxxxx

El cliente responde con la contraseña

Request: xxxxXxxxxXX

En la siguiente linea, el servidor responde con código 230 que indica usuario conectado y que continúe con la sesión:

Response: 230 Logged on

El cliente requiere mostrar el directorio de trabajo con la orden PWD:

Request: PWD

El servidor responde a la petición con un código 257 que indica el nombre  de la ruta:

Response: 257 "/" is current directory.

El cliente con la siguiente orden PORT n1,n2,n3,n4,n5,n6  indica al servidor el establecimiento del modo activo. Con esta orden, se indica que se espera conexión del servidor en la dirección IP n1,n2,n3,n4, en este caso 192.168.1.5 tal como vemos en la captura gráfica de Wireshar, y en el puerto n5 y n6. El puerto se calcula de la siguiente forma:

n5*256+n6

Así pues, siendo n5=8 y n6=156, 8*256+156=2204. que, como vemos en la captura un poco más a bajo, es el puerto usado por el cliente. el servidor inicia conexión desde el puerto 20 hacian el puerto "resultante" de la orden PORT:

Request: PORT 192,168,1,5,8,156

El servidor responde con un código 200 indicando que la orden es correcta:

Response: 200 Port command successful

El cliente con la orden TYPE A, indica el tipo de representación de los datos  A, es decir ASCII. Podría ser también:

• tipo ABCDIC (Código Extendido de Binario Codificado en Decimal)
  
• tipo imagen

Request: TYPE A

El servidor responde con codigo de orden correcta y establecimiento de tipo de datos en TYPE A:

Response: 200 Type set to A

El cliente cursa orden LIST. Esta orden hace que el servidor envíe una listado de los ficheros a través del proceso de transferencia de datos:

Request: LIST

En las siguientes lineas vemos que se establece comunicación en los puertos especficados en PORT y el puerto 20:

20 > 2204 [SYN] Seq=0 Win=65535 Len=0 MSS=1460

2204 > 20 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460

20 > 2204 [ACK] Seq=1 Ack=1 Win=65535 Len=0

Se transmiten los datos pedidos por LIST por parte del servidor:

FTP Data: 175 bytes

NOTA: En la ventana de detalles del paquete, vemos que Wireshark nos proporciona, en la línea  FTP Data: 175 bytes más información sobre el listado LIST:

Más abajo responde el servidor con un código 150 indicando estado del fichero correcto; va a abrirse la conexión de datos:

Response: 150 Opening data channel for directory list.

Se realiza en las siguientes dos trazas el trasiego de datos de apertura de conexión de datos del listado que se pidió y el servidor responde, a su termino con código 226 que cierra la conexión de datos:

Response: 226 Transfer OK

NOTA: Se cerró la conexión y el sistema vuelve a establecer comunicación:

20 > 2204 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
2204 > 20 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460
20 > 2204 [ACK] Seq=1 Ack=1 Win=65535 Len=0

Se repite el proceso en las siguientes líneas. Hasta la línea:

Request: RETR 1.psd

Esta línea de arriba, con la orden RETR, indica petición para transferir una copia del fichero especificado (1.psd).

Se transmiten los datos del fichero a transferir del servidor al cliente:

FTP-DATA FTP Data: 1460 bytes

FTP-DATA FTP Data: 588 bytes

El servidor responde con un código 150 que el estado del fichero correcto; va a abrirse la conexión de datos

Response: 150 Opening data channel for file transfer.

En las líneas siguientes se transfiere el fichero.

servidor       cliente           FTP-DATA FTP Data: 1460 bytes
servidor       cliente           FTP-DATA FTP Data: 1460 bytes
cliente         servidor       TCP      2206 > 20 [ACK] Seq=1 Ack=4969 Win=64512 Len=0
servidor       cliente           FTP-DATA FTP Data: 1460 bytes
servidor       cliente           FTP-DATA FTP Data: 1460 bytes
cliente         servidor       TCP      2206 > 20 [ACK] Seq=1 Ack=7889 Win=64512 Len=0
servidor       cliente           FTP-DATA FTP Data: 1460 bytes
servidor       cliente           FTP-DATA FTP Data: 1460 bytes
cliente         servidor       TCP      2206 > 20 [ACK] Seq=1 Ack=10809 Win=64512 Len=0

...

...

Todo este proceso terminará con un código 226 que cierra la conexión de datos y que la transferencia está completada:

Response: 226 Transfer OK

Observemos las líneas siguientes en las que el cliebnte cursa petición de establecimiento de datos tipo binario (por tratarse de una imagen la trasferencia) y las respuesta OK del servidor:

cliente         servidor       FTP      Request: TYPE I
servidor       cliente         FTP      Response: 200 Type set to I

El las siguientes líneas se cierra la conexión.

-----------------------------------------------------------------

Comments

STRINGS de Sysinternals es una utilidad que nos sirve para encontrar cadenas ASCII  o UNICODE en un archivo determinado

Pero, como he dicho, vamos a verlo con un ejemplo....

Haremos un muy sencillo análisis forense de la carpeta Prefetch de Windows XP ó Vista. Pero, antes que nada ¿ qué es la carpeta Prefetch ?.

Comments

Comenzamos con NBTSCAN (NETBIOS nameserver scanner).Recalcar que tan solo se trata de referencias y no un manual de uso. Más que nada por la sencillez de uso de las herramientas.

Decir, también, que sigo con las series de articulos ya comenzadas en este blog y profundizando en otros aspectos de la serguridad y las redes con artículos nuevos.

NBTSCAN (nameserver scanner)

nbtscan.txt :

Más información: http://unixwiz.net/tools/nbtscan.html

Comments

Tenemos una captura cualquiera con algunas etiquetas de información del tipo TCP segment of a reassembled PDU, no sabemos a cuantos paquetes afecta esta información, error o lo que sea, así que aplicamos un Display Filter:

tcp.reassembled_in

Ya tenemos todos los paquetes afectados. Elegimos uno cualquiera para ver todos los datos del paquete:

Reseñado en rojo vemos Reassembled PDU in frame 19225, bien, vamos al frame o paquete 19225. quitemos el filtro anterior y buscamos el frame o aplicamos el filtro: tcp.segments:

Y vemos que se nos informa de que el frame 19255 es un paquete reensamblado formado por una lista de segmentos, entre ellos el que elegimos al principio.

¿ Y que significa esto. ?. Sencillamente que en el paquete 19225, Wireshark a concatenado una serie de segmento mostrando en el toda la información completa.

No se trata de ningún error.

Básicamente. En ocasiones los paquetes vienen "fragmentados" en unidades Protocol Data Units (PDU) y Wireshark los reensambla enun nivel más alto, en este caso, http.

Comments

El preprocesador frag3.

Este preprocesador sustituye a frag2. Es más rápido y sencillo en su funcionamiento interno.

Frag3 tiene como objetivo principal la detección de evasión del IDS por fragmentación. Es decir, se encarga del reensamblaje de paquetes fragmentados para que al pasar al motor de detección se pueda comparar el contenido de los paquetes o payload con las reglas de detección de ataques. Reconstruye el flujo lógico de los datos.

Existen dos directivas de configuración defrag3:

• frag3_global. Solo una directiva global.
• frag3_engine. Puede haber varias directiva de engine o motor con configuraciones distintas.

frag3_global tiene las siguientes opciones:

• max_frags número. Número máximo de fragmento simultáneos a analizar. Por defecto es 8192.
• memcap bytes. Memoría máxima de alamacenamiento para uso de frag3. Pr defecto es 4 MB.
• prealloc_frags número. Número preasignado máximo de fragmentos individuales que pueden ser procesados a la vez.

frag3_engine tiene las siguientes opciones:

• timeout segundos. Cantidad de segundos que se mantiene el fragmento en antes de que expire (por tieme out). Por defecto son 60 segundos.
• ttl_limit valor. Máximo valor TTL que adepta frag3. Por defecto 5.
• min_ttl valor. Mínimo valor aceptable para TTL de un paquete fragmentado. Por defecto es 1.
• detect_anomalies si se quiere detectar anomalias en los fragmentos.
• bind_to lista de IPs. Lista de IPs que analiza "frag3". Por defecto entran todas las Ips.
• policy tipo de politica según plataforma. "Plantilla" modo de fragmentación según la plataforma a analizar por frag3, es decir, según la plataforma sea Windows, Linux, BSD, etc. Tenemos las siguientes subopciones:
• bsd
• Last
• Firs
• linux
• BSD-right

Tabla de opciones según plataforma:

Vemos algunos ejemplos de uso de frag3.

preprocessor frag3_global: prealloc_frags 8192 

preprocessor frag3_engine: policy linux, bind_to 192.168.1.0/24 

preprocessor frag3_engine: policy first, bind_to [192.168.2.0/24,] 

preprocessor frag3_engine: policy last, detect_anomalies

Vemos que, como ya hemos dicho, solo una directiva frag3_global.
Varias directivas frag3_engine para plataformas basadas en:

• linux con lista de ips
• first (windows)
• last en este caso con detección de anomalias

¿ Complicado ?. Puede ser, pero saldremos de dudas más adelante cuando entremos en los ejemplos, frabricando paquetes a medida para ir porbando distintas configuraciones y el funcionamiento de frag3.

Comments

Los preprocesadores, básicamente, son unos módulos, añadidos o plugins que usa Snort para arreglar, rearmar, modificar tramas que vienen del decodificador de paquetes antes de que pasen por el motor de detección y las reglas. Pero donde se sitúan, como actúan, que preprocesadores tiene Snort y como funcionan....

Donde se sitúan dentro de la arquitectura Snort.

Se sitúan entre el decodificador de paquetes y el motor de detección.

Con lo que son activados después del Decodificador para luego llamar al motor de detección.

Qué son y como funcionan los preprocesadores.

Se trata de pequeños plugins programados normalmente en C que sirven para tratar los paquetes provenientes del Decodificador. El tratamiento que realiza sobre los paquetes es para darle forma de manera que se pueda interpretar la información de los paquetes de foma más sencilla y lógica. Una vez reordenados los paquetes, al pasar por el motor de Detección se le aplicarán las Reglas en busca de patrones de ataques,virus, información, etc.

Los preprocesadores pueden defragmentar paquetes, ordenarlos, decodificar URLs, reensamblar, etc.

Estos preprocesadores de configuran en el archivo de configuración etc/snort.conf que, como ya hemos visto en otros artículos, tiene la forma dentro del epígrafe 3 configure preprocessors:

De qué preprocesadores disponemos en Snort.

Tenemos varios preprocesadores según la tarea a realizar:

• frag3
• stream4
• stream4_reassemble
• flow
• stream5
• sfportscan
• rpc_decode
• bo (Back Orifice detector)
• arpspoof
• ssh
• etc,

Los iremos viendo uno a uno, como funcionana y como configurarlos en la parte 2 de Snort. Preprocesadores.

Comments

Tanto Expert Infos como Expert infos composite nos aparece en el menu: Analize > Expert Infos / Expert Infos composite

Expert Infos.

Si echamos una visión rápida a la captura de pantalla de la ventana Expert Infos, vemos que la primera diferenciación que hace la herramienta es por los colores indicando severidad (columna Server.) de la información.

• Rojo. Error. Problema serio. Normalmente paquetes malformados.
• Amarillo. Warn. Peligro. Problemas de conexión.
• Cian. Note. Información. Reporte de errores usuales que no significan un problema serio.
• Verde. Chat. Información sobre conversaciones de protocolos.

Tenemos también una clasificación por grupos (columna Group) Entre los más usuales:

• Cheksum. Cheksum inválido. Por ejemplo TCP Bad Checksum.
• Secuence. Números de secuencias sospechosos o fueran de orden, detección de retransmisiones o retransmisiones rápidas, ACKs duplicados, segmentos perdidos, etc.
• Malformed. Paquetes malformados. Errores graves.
• Reassemble. Problemas de reensamblaje, fragmentación, etc.
• Response Code. Errores o problemas en códigos de respuesta.Por ejemplo código de errores HTTP.
• Request Code. Errores o problemas en códigos de petición.

Otras columnas informativas de la ventana Expert Infos son:

• No. Número de paquete o frame.
• Protocol. Información del protocolo involucrado. TCP, HTTP, etc.
• Summary. Información del evento. Explicación de lo ocurrido.

Podemos, además, filtrar la información con Severity Filter:

De esta forma podemos visualizar solo los paquetes con

• Rojo. Error Only. Solo los errores.
• Rojo. Error + Amarillo. Warn. Errores y problemas, situaciones peligrosas en conexión.
• Rojo. Error + Amarillo. Warn + Cian. Note.La suma de lo anterior y las notas de información y errores usuales.
• Rojo. Error + Amarillo. Warn + Cian. Note + Verde. Chat. Todos los eventos.

Expert Infos Composite.

En este caso, la información facilitada por Wireshark eá organizada por pestañas atendiendo a la Severidad del evento. A la información suministrada por Expert Infos, Expert Infos Composite, ademas, no da información de cantidad de paquetes que forman parte de cada evento en la columna Count. En details veríamos la misma información que en Expert Infos con sius diferenciación pro colores, etc.

Expert Infos Composite nos ofrece una información más detallada y mejor organizada, para visualizar de forma más rápida.

Comments

Tenemos una captura cualquiera. Como ya hemos estudiado en el artículo dedicado a las gráficas Wwireshark abrimos esta herramienta y aplicamos una serie de filtros quedando la gráfica de esta forma:

Como veréis hemos aplicado los siguientes filtros:

• tcp.analysis.lost_segment Perdida de paquetes o segmentos
• tcp.analysis.retransmission Mecanismo de rentransmision
• tcp.analysis.fast.retransmission Mecanismo de rentransmision rápida
• tcp.analysis.duplicate_ack Análisis de ACKs duplicados

Y como ya hemos vistos en el artículo de detección de problemas en la red comprobamos que, explicado de forma básica:

Si se reciben tres o más ACKs duplicados, se asume la pérdida de un segmento o paquete lost_segment esto desencadenala retransmisión del dicho segmento perdido fast.retransmission.

Vamos ahora a centrarnos en la misma gráfica pero desactivando Graph 4:

Vemos entonces, la zona reseñada en rojo, que algunos segmentos llegados fuera de orden e incluso perdidos reseñados en azul en la primera gráfica, generaron también (estaba oculto) ACKs duplicados . Sin embargo observamos que no hubo Retransmision o Retransmision rápida. Esto es debido a que, se ve cláramente en la gráfica, tan solo se produjo 1 o 2 ACKs duplicados. Lo vemos de forma muy clara en la zona reseñada con el ciculo rojo. También vemos que si se generó una retransmision en uno de ellos que si tiene 3 ACKs Duplicados.

Comments

Vamos a estudiar porqué ocurre esto, si es tan grave como parece y como solucionarlo.

Una vez detectado el Error vamos a analizar unos de los paquetes con TCP Bad Checksum:

Tenemos una pista. Wireshark interpereta que puede tratarse de TCP checksum offload. ¿ Pero que es esto exactamente ?.

TCP Checksum offload.

En la gran mayoría de implementaciones de la pila de protocolos el checksum de los segmentos TCP o datagramas UDP salientes no los realiza la CPU. Esta funciónestá encomendada a la tarjeta de red. Esto es así para reducir la carga de la CPU y que de esta forma aumente el rendimiento de host.

Pero hay un problema y es que Wireshark no puede comprobar el checksum de los paquetes salientes. Literalmente no le da tiempo a comprobar este valor. Cuando se coloca el valor del campo el paquete correspondiente ya no se encuentra, así que devuelve un error por incorrecto.

Como solucionarlo.

Existen dos métodos. Uno es desactivar esta función de la tarjeta de red, pero provocará un rendimiento bajo. El segundo método y el más correcto es configurar wireshark para que no compruebe este campo.  Esto lo haremos de la siguiente forma:

Edit >  Preferences > Desplegamos la lista de protocolos y elegimos TCP:

En las tarjetas de red y en el caso de las Broadcom NetXtrem Ggigabit el parámetro "Checksum Offload" (Descarga de suma de comprobación) se desactiva en las propiedades avanzadas de la NIC o tarjeta de red.

Entre los prosible valores de la propiedad Checksum Offload de la Tarjeta tenemos:

• Rx TCP/IP Checksum (Suma de comprobación de TCP/IP Rx): activa la recepción de la descarga de suma de comprobación de TCP, IP y UDP
• Tx TCP/IP Checksum (Suma de comprobación de TCP/IP Tx): (valor predeterminado) activa la transmisión de la descarga de suma de comprobación de TCP, IP y UDP
• Tx/Rx TCP/IP Checksum (Suma de comprobación de TCP/IP Tx/Rx): activa la transmisión y recepción de la descarga de suma de comprobación de TCP, IP y UDP
• None (ninguno) - desactiva la descarga de la suma de comprobación y es la que elegiremos.

Aunque, como ya he comentado más arriba, no es la mejor opción por la disminución de rendimiento.

Comments

Veamos parte de la una captura cualquiera:

Podemos observar que de momento no hay problema alguno. La transmisión de paquetes entra dentro de lo normal.

Sin embargo, en un momento de la captura, nos encontramos ya con algún problema:

Vemos notaciones como TCP Previous segment lost, TCP Dup ACK y TCP Retransmission.

Vamos a analizar la captura.

TCP Previous segmento lost (frame 188) nos indica que un segmento TCP anterior ha fallado. Un TCP Dup ACK (frame 189) puede deberse a un desorden de paquetes que hace que el receptor provoque un ACK duplicado ante un segmento que no sigue la secuencia normal. Vemos la duplicidad de secuencias (Seq=2313). Puede ser también debido a la perdida de algún segmento de datos. Al recibir segmentos no ordenados, se genera ACKs duplicados, reenvía nuevamete el mismo ACK (acuse de recibo), es decir nuevos requerimientos para recibir el segmento de forma correcta. ( Vemos el ACK=4126 repetido).

El problema también puede deberse a incremento de tiempo en la trasmisión del paquete, retraso del paquete, con lo que se espera nuevos ACKs duplicados.

Normlamente la pérdida de orden secuencia es notificado por Tshark con la notación TCP Out-Of-Order segment.

Por regla general:

• Solo se esperan hasta 3 ACKs duplicados.
• Uno o dos ACKs duplicados indica una reordenación de los segmentos.
• Tres o más ACKs duplicados indica que se perdió el paquete.

TCP Retransmission ocurre, explicado de forma muy básica, cuando el cliente no obtiene respuesta a un requerimiento y vuelve a reintentarlo.

En resúmen podemos decir que cuando ocurre un TCP Previous segment lost se indica que durante el curso de transferencia de datos, un paquete se ha perdido o tarda en ser transmitido. En respuesta, el cliente envía un paquetel TCP Dup ACK al servidor, solicitando que el paquete perdido sea enviado nuevamente. El cliente seguirán enviando ACKs duplicados hasta que sea atendida la petición.

ACKs Duplicados.

Cuando se pierde algún segmento de datos tanto por errores del canal o por problemas de congestión TCP recibe segmentos fuera de orden y en consecuencia genera ACK duplicados. Puede ser consecuencias de picos de retardo o desorden de paquetes. Podemos decir entonces que los ACKs duplicados son síntomas también de un problema en nuestra red.

Cuando se reciban 3 ACKs duplicados es entonces cuando aparece el mecanismo de Fast Retransmit o Retransmision rápida que vemos en las capturas que consiste en la retransmisión de segmento perdido.

Abajo, uso de Expert Info para visualizar los eventos de ACK Duplicados:

ACKs Duplicados en Tshark:

Hasta aquí todo explicado de forma muy básica. En próximos capítulos iremos profundizando en estos conceptos y estudiaremos los mecanismo de TCP para evitar la congestión, etc.

Comments

Las entidades representativas de la comunidad internauta, los profesionales y los consumidores informáticos en España estiman en cuatro millones la cifra de clientes de banda ancha, ADSL y cable, que podrían darse de baja si finalmente se confirma el acuerdo que REDTEL está negociando con las sociedades de gestión de los derechos de autor abanderadas por la SGAE, para que en España se den tres avisos antes de desconectar o ralentizar la conexión a Internet por usar redes P2P.

A la disminución de ingresos se sumarían las posibles indemnizaciones que podrían derivarse por incumplimiento de contrato de las operadoras y las sanciones aplicables en base a los artículos 8 (”Restricciones a la prestación de servicios y procedimiento de cooperación intracomunitario”) y 11 (”Deber de colaboración de los prestadores de servicios de intermediación”) de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico, modificado por la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información.

Mientras las operadoras de telecomunicaciones tratan de sortear la crisis, las sociedades de gestión de los derechos de autor, intentan conseguir prebendas para las empresas productoras de contenidos tratando de convencer a todo el mundo de que el intercambio de archivos entre particulares por Internet es un acto delictivo y que supone fuertes pérdidas al sector de entretenimiento.

Sin embargo tanto la fiscalía como las sentencias dictadas establecen que el intercambio de archivos con copyright restrictivo por redes P2P no es un delito y no es punible de ninguna forma cuando se trata de archivos públicos o bajo licencias copyleft (la mayoría de los casos).

Las propias entidades de gestión de derechos de autor han reconocido en el “Informe de la industria de contenidos en España“, publicado por ASIMELEC, que no hay una bajada de ingresos en el sector y que solo la música tiene un retroceso en la venta a través del canal tradicional (aunque no se informa del aumento de ingresos por, entre otros, actuaciones en directo, descargas y publicidad).

Lo cierto es que las negociaciones que se están llevando a cabo bajo el auspicio del Ministerio de Cultura, pueden suponer que algunas de las empresas más solventes y con mayor capacidad tecnológica de España empiecen a perder clientes a marchas forzadas. Lo que repercutirá en su cuenta de resultados y en su capacidad de mantener el empleo.

Pero lo más grave es que un acuerdo de esta naturaleza atenta contra la libre competencia, frena en seco el acceso a la Sociedad de la Información en España menoscabando los derechos civiles de los ciudadanos y alejando aún más el derecho constitucional de acceso a la cultura y al conocimiento.

Firmado: SeguridadyRedes (Alfon) y 6.030 firmas más (por el momento). Pon la tuya publicando el texto en tu blog.

Comments

Gráficas tcptrace.

Dentro del menu Statistics > TCP Stream Graphs, nos encontramos con un tipo de gráficas basado en el número de secuencia respecto al tiempo. Este tipo de gráfica es el Time-Secuence Graph (tcptrace).

Una vez seleccionado un segmento cualquiera de la conexión TCP que nos interese en el campo de edición de las capturas,podemos activart ya en el menú más arriba mencionado nuestra gráfica tcptrace.

En una conexión TCP entre dos hosts, existen dos sentidos de la comunicación: Host A hacia Host B y Host B hacia Host A, por eso, hay que seleccionar antes uno de los segmento para que la gráfica nos muestre uno de ellos.

Se nos presentarán dos ventanas, una con la grafica y otra con una serie de opciones para el mejor manejo y tratamiento de la gráfica:

Como la ventana de la gráfica nos presenta esta al completo, disponemos de una serie de controles y opciones.

Los ejes presentados en la gráfica son:

• Eje X: Información de Tiempo en segundos.
• Eje Y: Información de Números de Secuencia.

Volvamos, a las opciones y controles.

Veamos primero la ventana de opciones (captura de arriba).

• Pestaña Zoom: Seleccionado in u out, realizamos el tipo de zoom y lo aplicamos con el botón izquierdo del ratón en la pantalla de la gráfica. La información del zoom aplicado se muestra en Horizontal y Vertical. En Horizontal y Vertical Step indicamos el número de divisiones de los intervalos en ambos ejes. Podemos bloquear el zoom tanto en un eje como en el otro en Zoom Lock.
• Pestaña Magnify: Se trata de una ventana de zoom como si de una lupa se tratase. En esta pestaña podemos indicar el tamaño de esta, el zoom aplicado.
• Origin: Como vamos a mostrar la gráfica dependiendo del origen de los datos, es decir, desde el principio de la conexión TCP o desde el principio de la captura, y el origen del número de secuencia: 0 (absoluto) o número de secuencia inicial.
• Cross: Como se nos muestra el puntero del ratón. De la forma típica o en forma de cruz de ejes (guias).
• Graph type: Tipo de grafico mostrado, en este caso Time/Secuence o tipo tcptrace. Estudiaremos los demás tipos en otros artículos.

Tenemos también una serie de controles con el ratón y teclado para ejecutar sobre la ventana gráfica:

• Seleccionar paquete de la pantalla de edición dese la gráfica. Nos situamos en uno de los segmentos de la gráfica, pulsamos Contro+botón izquierdo ratón. Con esta acción de resaltará el paquete en la pantalla de edidión de la captura. Es muy útil para saber en que parte y paquete de la captura nos encontramos dentro de la gráfica.
• Zoom. In Boton derecho ratón Out May+botón derecho ratón.
• Desplazamiento. Nos desplazaremos por la pantalla con el botón derecho pulsado y arrastrando.
• Mostrar guias. Lo mismo que la opción Cross de la ventana de opciones. Lo realizaremos pulsando la barra de espacio.

Vamos ahora a mentiendo en la gráfica e ir viendo que significa cada cosa.

Tenemos la captura de arriba, nos posicionamos en el paquete 18 y activamos la gráfica. En la ventana de opciones indicamos las que nos interesen. Por ejemplo, activamos Cross, tiempo de origen desde el principio de la captura. Los pasos o intervalos tanto en horizontal como vertical en 1.2, etc. para dejar la gráfica de esta manera:

Voy a dar unas páutas para ir comprendiendo este tipo de gráficas. Más a delante usaremos escenerarios más complejos y profundizar más.

Indico con el circulo rojo el paquete 18. Casi no se ve, pero es una pequeña traza de color negro que indica que en el segundo 11.81 un paquete (http) tiene el flag ACK activado y con un número de secuencia 1. En el segundo 12.18 vemos un segmento TCP (línea vertical negra) con número secuencia 1 y una longitud (Len = 365) que corresponde con la longitud que tiene la línea color negro, le sigue una línea horizontal gris claro, se trata de un ACKs recibidos, la línea vertical gris claro sugiere la ventana anunciada por el otro extremo de la conexión. En el paquete 20 recibimos un ACK (hay que hacer bastante zoom o usar Mangnify) y en el 21 volvemos a tener en el segundo 12.327 otro segmento TCP pero ya con un número de secuencia 366 una longitud (Len = 349). Vemos otra pequeña traza (corresponde a http) en el segundo 12.51. Más adelante vemos otro segmento TCP en el segundo 12.62, paquete 28 con un número de secuencia 715 u una longitud (Len = 364).

Esta es, a grandes rasgos la manera de leer la grafica.

¿ Qué problemas podemos detectar con tcptrace. ?

TCP ACK Retrasmission. Todos tienen el mismo número de secuencia, mismo ack pero son trasmitidos en diferentes instantes en el tiempo:

Son retransmisiones del mismo paquete que denotan problemas de conentividad.

ACKs Duplicados:

ACKs duplicados que son también un síntoma de problemas en la red debido a desorden de paquetes, pérdida de datos, etc.

Comments