Solo comentar, como peqeño resúmen, que hace uso de VoIP gracias a la tecnología P2P (algo vimos aquí sobre detectar P2P en nuestra red ) y usa cifrado fuerte para las comunicaciones. Según Skype:

“Skype usa AES (el Estándar de Cifrado Avanzado), también conocido como Rijndel, que también es usado por organizaciones estadounidenses de gobierno para proteger la información sensible. Skype usa el cifrado de 256 bit, que tiene un total de 1.1 x 10E77 llaves posibles, para cifrar los datos activamente en cada llamada de Skype o en cada mensaje instantáneo. Skype usa 1536 a 2048 bit RSA (Algorithm for Public-Key Encryption) para negociar llaves simétricas AES. Las llaves de usuario público son certificadas por el servidor Skype en la conexión.”

Es decir, que en principio, descifrar una conversación Skype es algo prácticamente imposible. Además, el software o protocolo de seguridad de Skype es propietario, cerrado y secreto.

En este artículo nos centraremos en como bloquear el uso de este software. Eso sí, haciendo uso de las herramientas de captura de tráfico como Wireshark, y Snort en todo lo que nos sea posible. Además no servirá para bloquear otros tipos de tráfico usando la misma "técnica".

NOTA: Iré actualizando con soluciones de bloqueo avanzadas de distintos dispositivos hardare.

Para llegar a donde queremos, que menos que saber un poco, muy brevemente, algo sobre la arquitectura Skype. Por ejemplo que su red tiene tres tipos de hosts:

• Nodo. cualquier host cliente
• Super-Nodo. host con IP pública con grandes recursos de ancho de banda, procesamiento y memoria. sirven para lagestión de directorios de usuarios, datos de nodos, etc. Cualquier Nodo se puede converti, si tiene estos recursos mencionados, en Super-Nodo, siempre y cuando no estén detrás de un proxy o firewall/cortafuegos.
• Skype Login Server.host servidor único y solo este es centralizado. Se encarga de la autentificación de usuarios, almacenamiento de usuarios / contraseñas y que los usuarios sean únicos.

¿ Como interactúan entre ellos?. Cada host Nodo o cliente debe conectar con un host Super-Nodo y registrarse/autentificarse en el  Skype Login Server. Aunque existe un solo servidor central Skype Login Server para las funciones que acabo de comentar, todo el tráfico, información, etc se realiza de forma descentralizada.

Como se inicia la conexión, el proceso de conexión, conexión a Super-Nodos y Skype Login Server, búsqueda de contactos, establecimiento de llamada, obtención de certificado, cifrado y muchos otros aspectos, no entran en el objetivo de este artículo. Para otro.. ya veremos. Son procesos complicados.

¿ Qué puertos usa ?. Skype usa puertos TCP y UDP. La numeración del puerto suele ser, por defecto, alta para las conexiones entrantes. Si en nuestro cortafuegos o firewall, tenemos bloqueados los puertos que usa Skype, este intentará acceder a los puertos 80 y/o 443.También puede usar proxies HTTP / SOCKS5, con lo que habrá que indicarle Servidor y Puerto y, en su caso, usuario / contraseña.

Esto ya nos  da una pista de como bloquear Skype en una red local:

• El usuario no tiene acceso a internet.  Solucionado.
• El usuario tiene acceso pero solo a determinados puertos o servicios. Los podría usar Skype.
• El usuario solo tienen acceso a los puertos 80 y/o 443. Los usa Skype.

¿ Eso es todo ?. Pues no. Lo normal es que los usuarios tengan acceso a internet, y, sobre todo, necesitan el puerto 80 y para algunos servicios 443, con lo cual, de momento no hemos avanzado gran cosa.

¿ Entonces como bloqueamos Skype ?. Independientemente de que algunos cortafuegos o firewalls tengan ya implememtados algunos filtros para Skype, que no lo se, vamos a usar Wireshark para buscar alguna firma identificativa de Skype, patrón o característica única que nos sirva para crear un filtro o política para nuestro cortafuegos.

Capturando el tráfico Skype.

NOTA: Vamos a realizar un estudio no demasiado profundo. Eso lo dejaremos para otra entrega. Se trata de dar una serie de pistas, consideraciones sobtre el bloqueo de este tipo de software.

Nuestro escenario es el siguiente. Un host cliente Skype con salida a internet a través de un cortafuegos sin ningún tipo de restricción a puertos TCP / UDP. Un host cliente remoto cualquiera. Skype está ya instalado y no es la primera vez. De ser el primer uso la captura cambia en algunos aspectos.

NOTA: Bajo otros escenarios, como por ejemplo, habilitar solo el puerto 443, las capturas cambian. Podemos, además, obtener mucha información sobre las transacciones SSL.

Lo primero que observamos es una peticion DNS. Un Standard Query request A para resolver ui.skype.com. A lo que se responde con un Standard query response A 204.xxx.xxx.158.

Ya tenemos la primera pista. Skype conecta con un servidor ui.skype.com.

Vemos, a continuación, un establecimiento de conexión a tres bandas. Entre el Nodo host cliente con el servidor ui.skype.com.

Una vez establecida la conexión se realiza una petición HTTP GET. Si realizamos un Follow TCP Stream desde Wireshark, veremos:

GET /ui/0/3.8.32.115/es/getlatestversion?ver=3.8.32.115&uhash=1540f7874177b01d4df58ee305d933e23 HTTP/1.1

User-Agent:

Host: ui.skype.com

Cache-Control: no-cache

A lo que se responde:

HTTP/1.1 200 OK

Date: Tue, 10 Nov 2009 17:11:56 GMT

Server: Apache

Cache-control: no-cache, must revalidate

Pragma: no-cache

Expires: 0

Set-Cookie: SC=CC=:CCY=:LC=es:TM=1257873116:TS=1257873116:TZ=:VER=0/3.8.32.115/0; expires=Wed, 10-Nov-10 17:11:56 GMT; path=/; domain=.skype.com;

Content-Length: 8

Connection: close

Content-Type: text/html; charset=utf-8

Content-Language: en

2.0.32.0

Pues ya lo tenemos bastante más claro.

• GET /ui/0/3.8.32.115/es/getlatestversion
• Host: ui.skype.com

En cada una de las conexiones realizadas con Skype, estos dos patrones, por poner dos ejemplos, se repiten. Aunque no exactamente, ya que la numeración marcada en rojo es la versión del cliente y, lógicamente, puede cambiar.

¿ Algo más que nos pueda servir ?. Bueno, tenemos también un número de puerto UDP:

Se trata del puerto 59907, Pero no nos sirve de mucho. Este puerto es configurable desde Opciones de Skype.

De todas formas ya tenemos suficiente para esta primera aproximación
a la  identificación del tráfico de Skype.

Creación de regla Snort para detectar el uso de Skype. 

De no tener políticas que impidan la instalación de programas en las máquinas de nuestros usuarios, podríamos, por ejemplo, crear una regla Snort tal como esta:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Uso de GET para nueva version Skype"; flow:to_server,established;
uricontent:"/ui/"; uricontent:"/getnewestversion"; content:"Host|3A|
ui.skype.com"; classtype:policy-violation; rev:1;)

Esta regla nos generará una alerta, pero no bloqueará tráfico alguno.

Creación filtro y/o reglas para firewall cortafuegos.

Podríamos crear una regla que denegara el acceso si se accede a una URL que contenga  getlatestversion. Pero no, Skype sigue funcionando.Bueno pues denegamos mediante una regla el acceso al host ui.skype.com, e incluso detallamos la IP de dicho host. Pero cuando abrimos Skype y capturámos su tráfico vemos que sigue igual. A Skype no le importa mucho no acceder al host ui.skype.com, al parecer, solo le serive para descargar, si es el caso, la última versión del programa. En nuestra nueva captura ya no aparece:

GET /ui/0/3.8.32.115/es/getlatestversion?ver=3.8.32.115&uhash=1540f7874177b01d4df58ee305d933e23 HTTP/1.1

User-Agent:

Host: ui.skype.com

Cache-Control: no-cache

Pero ya digo, no nos sirve. Tampoco podemos bloquear por puertos porque no tienen ningún puerto predefinido ni servicios. Puede usar TCP , UDP, 443, 80, etc. El único puerto que tiene predefinido para las conexiones entrantes lo puede manipular el usuario en el cliente.

Inpeccionar los paquetes en busca de firmas que denoten, por ejemplo, el uso de SSL por parte de Skype, ya no vale. Antes, en versiones anteriores, el handshake SSL/TLS era facilmente identificable mediante la firma |16 03 01 00| (Client Hello) y |17 03 01 00| (Server Hello), ahora esto ya no nos vale. Todo la información transferida por Skype está cifrada.

En la captura, más adelante, podemos ver (probadlo) que se usa mucho el protocolo UDP para muchas conexiones, transferencias de voz, etc. Podríamos bloquear el uso de UDP, ya que no afecta significativamente al uso de internet. Pues bien, tras unos momentos en los que Skype inicia, inicia sesión en el  Skype Login Server,etc, vemos que no encuentra ninguno de nuestros contactos. Parece que va todo bien. Pero, cuando Skype ve que no puede usar UDP por defecto para estas tareas, usa TCP, con lo cual la opción de bloquear UDP no nos sirve de nada.

¿ Bloqueamos SSDP?

Skype usa SSDP para el descubrimiento de dispositivos UPnP. Esto lo realiza enviando 4 paquetes a la dirección Multicast 239.255.255.250 al puerto, por defecto, 1900. Pues bien, tanto si desahabilitamos el servicio en el host cliente, como si denegamos en nuestro firewall el acceso al puerto 1900 UDP o a la dirección multicast  239.255.255.250, el resultado es el mismo. Skype se "adapta" y no le afecta. Hay routers que pueden so ser PnP.

NAT Port Mapping Protocol

Como vemos en esta serie de paquetes capturados:

Skype usa NAT-PMP que le permitere mantener una conexión abierta con el exterior de nuestra red de forma persistente. Aunque se le pueda bloquear su uso, Skype puede usar los Super Nodos para esta tarea. En la versions 4.x creo que se puede deshabilitar el uso de NAT-PMP.

Como bloquear de forma efectiva el uso de Skype.

En un entrono de empresa, hay varias formas de bloquear el uso de Skype.

• Se impide el acceso total a internet y a partir de ahí se da salida solo a los servicios y/o protocolos necesarios.
• Se impide el acceso acceso total a internet excepto a servicios necesarios (IMAP, SMTP,...) y se da salida solo a una serie de sitios que establezaca la empresa para sus usuarios. Sería una especie de lista blanca de acceso.
• Uso de políticas de seguridad en la empresa. Dependiendo del tipo de usuario, uso de directorio activo o grupo de trabajo:

• Usuarios sin permiso de instalación de software. Esto no es válido si los usuarios pueden ejecutar un Skype portable a través de USB o lectos CD/DVD.
• Políticas de restricción de software en directivas de seguridad local. Se crea una regla para impedir el uso de Skype.exe.
• En un entorno de Directorio Activo, podemos especificar una restricción al uso de Skype.exe.

Existen algunos dispositivos Hardware que son capaces de detectar el tráfico de red Skype. No los he probado. Incluso algún firewall avanzados de hardware que puede bloquear Skype, pero las técnicas de "evasión" que usa Skype casi siempre va por delante. Además, la inspección del contenido de paquetes es practicamente imposible, debido a que toda la transferencia de información suscentible de usarse para bloquear, está cifrada.

Relacionado: Wireshark. Tshark. Detectando tráfico P2P en nuestra red.

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

En la siguiente entrega estudiaremos de forma más profunda como funciona Skype e iremos descubriendo más aspectos muy interesantes sobre este software.

También veremos las capturas realizadas bajo otros escenarios como, por ejemplo, dehabilitar todos los puertos y servicios y habilitar solo el puerto 443. Vremos como cambia la captura y la cantidad de datos que podemos obtener, sobre todo las transacciones SSL.

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

Comments

• Echo ping request
• Echo ping reply

que son necesario para obtener la dirección MAC, y el segundo: establecimiento de conexión con el host CLIENTE, donde se ubica el recurso compartido, mediante three-way handshake o negociación a tres pasos.

Inmediatemente el host SERVIDOR envía una petición de sesion al host CLIENTE.... lo vemos todo a continuación.

Partimos, como siempre, de nuestra captura:

y nos centramos en los paquetes:

• 13. Echo (ping) request. Petición que realiza el host SERVIDOR 192.168.1.30
• 14. Echo (ping) response. Responde host CLIENTE 192.168.1.5.

este paso se realiza para la obtención de la dirección MAC de destino (del host 192.168.1.5).

A continuación se realiza el establecimeinto de conexión mediante  negociación a tres pasos ó three-way handshake: paquetes 15, 16 y 17. Observad que la negociacion para el etablecimiento de conexión se realiza sobre el puerto 139. Este tipo de paquetes ya lo hemos estudiado aquí.

Una vez establecida la conexión, el host servidor envia una petición de sesion o Session request: lo vemos en el paquete 18:

• 18. Session request, to CLIENTE(20) from SISTEM(00)
  

En el paquete 19 tenemos la respuesta a esta petición de sesión:

• 19. Positive session response

Para estudiar mejor estos dos mensajes, incluimos aquí el formato para SESSION REQUEST, TO y POSITIVE SESSION RESPONSE:

Vemos para Session request, to CLIENTE(20) from SISTEM(00) que:

• Message Type: Session request. El código es x81 (en haxadecimal).
• Flags: 0x00 siempre debe ser 0
• Length: 68
  
• Called name CLIENTE(20). Se refiere al recurso servidor
• Calling name SISTEM(00). Se refiere al recurso cliente que accede al servidor del recurso compartido.

Para TYPE o message Type, tenemos los mensajes y sus códigos pueden ser:

• 00. Session message.
• 81. Session request.
• 82. Positive session response
• 83. Negative session response
• 84. Retarget session response
• 85. Session keep alive.

Vemos para Positive session response que:

• Message Type: Positive session response. El código es x82 (en haxadecimal).
• Flags: 0x00 siempre debe ser 0

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

En la cuarta parte de esta serie veremos la negociación Negotiate protocol Request y response.

Comments

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

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

Comments

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