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

Vamos ahora a iniciar una serie de capítulos dedicados a las gráficas.

En Wireshark tenemos varias formas de ver y tratar los paquetes capturados. Dependiendo, entonces, de la información que necesitemos extraer de nuestras capturas, Wireshark nos proporciona diferentes herramientas gráficas.

Vamos a estudiar estas gráficas, como siempre, desde lo más básico e iremos complicando en otros capítulos.

Empezamos con IO Graphs y Flow Graph.

IO Graphs

Gráfica personalizable y con diversas opciones que nos muestra el trafico de entrada y salida de una captura.

Accedemos a este tipo de gráfica mediante Statistics > IO Graphs.

En este tipo de gráficos tenemos, como vemos en la captura de arriba, una zona de edición de las gráficas y una zona de opciones. La zona de edición tiene dos ejes:

• Eje X de tiempo. En este eje podemos ajustar el Tick Interval o intervalo de tiempo desde centésimas de segundo a 10 minutos. Tenemos también una especie de Zoom, el Pixel per Ticks, ajustable de 1 a 10. En este eje visualizaremos los tiempos de forma relativa o atendiendo a la hora de la captura View as time of day.
• Eje Y de paquetes capturados. Podemos visualizar los datos por Paquetes, Bytes, Bits, o de forma avanzada realizando ciertas operaciones. Podemos también ajustar la escala del eje en Scale.

En la zona de datos podemos visualizar hasta 5 graficas, cada una de un color diferente que no se puede cambiar, podemos especificar también el tipo o Style, y a cada una de estas gráficas asociar un filtro.

Flow Graph

Permite la visualización gráfica del flujo de datos entre las diferentes conexiones realizadas entre hosts. Accedemos a esta opción desde Statistics > Flow Graphs.

Para ello debemos antes seleccionar una serie de opciones como qué paquetes que queremos tratar: todos o los visualizados. el tipo de flujo: todo el flujo de la captura con todos los protocolos involucrados o solo el flujo TCP.

En esta gráfica podemos ver:

• Datos de tiempo.
• Máquinas involucradas en el flujo de conexión representadas por las líneas verticales.
• Sentido del flujo de los datos. Representado los las flechas que, además, nos indican entre que hosts o máquinas se establece conexión.
• Puertos. Representado entre paréntesis.
• Números de secuencia y acuses de recibo. Representados en la columna de la derecha (Comments). Vemos que los números de secuencia se representan de forma relativa, es decir, el primero 0 (para no mostrar números de secuencia demasiado altos y mejor compresión de los datos).
• Vemos también los indicadores usados indicando el contenido y propósito del segmento TCP.... vamos a recordar esto último:

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

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

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

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

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

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

Para un mejor estudio de las conexiones, lo mejor es filtrar antes los paquetes capturados y luego usar Flow Graph.

Con este tipo de gráficos podemos estudiar, por ejemplo, los problemas que pudiesen surgir en un establecimiento de comnexión.

Como recordatorio:

Establecimiento de una conexión TCP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ejemplo:

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

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

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

Es facil, entonces, ver todo esto explicado en la gráfica:

Comments

En este capítulo terminaremos con este tipo de opciones de reglas con ipopts, flags, flow y window.

IPOPTS

Uno de los campos de la cabecera IP que vimos en su momento es Opciones. Según el RFC:

Las opciones 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.

En algunos entornos la opción de seguridad puede ser requerida en todos los datagramas.

El campo opción es de longitud variable. Pueden existir cero o más opciones.

Ipopts busca en el campo opcion de la cabecera del datagrama IP una de estas opciones:

• rr Registrar Ruta (Record Route). Usado para rastrear la ruta que sigue un datagrama internet.

• eol Fin de la lista de opciones. Esta opción ocupa un sólo octeto.

• nop Sin Operación. Esta opción ocupa un sólo octeto.

• ts Marca de Tiempo Internet (Internet Timestamp)

• sec Seguridad. Usado para Seguridad.

• lsrr Encaminamiento de Origen No Estricto (Loose Source Routing). Usado para encaminar el datagrama internet en base a la información suministrada por el origen.

• ssrr Encaminamiento de Origen Fijo (Strict Source Routing). Usado para encaminar eldatagrama internet en base a la información suministrada por el origen.

• satid Identificador de Flujo (Stream ID). Usado para transportar el identificador de flujo.

• any Si algúna opción está activa.

Ejemplo:

alert tcp any any -> 192.168.1.0/24 any (ipopts:lsrr;)

FLAGS

En el capítulo dedicado al Segmento TCP vimos el campo de bits reservados y bits de indicadores o flags. Lo recordamos:

Campo reservado (para un posible uso futuro) + Bits de código o indicadores. (6 + 6 bits.)

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

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

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

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

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

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

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

Pues bien, la opcion flags de las reglas Snort, detecta la activacion de flags en el segmente TCP. como en otras opciones, admite comodines:

• + aparece el flag especificado y cualquier otro
• * se produce la coincidencia si cualquiera de los flags especificados aparece
• ! notación de negación.

Esta opción se usa, por ejemplo, para la detección de ciertos tipos de escaneos:

alert tcp $EXTERNAL_NET any -> $HOME_NET any /

(msg:"SCAN SYN FIN"; flow:stateless; flags:SF,12; /

reference:arachnids,198; classtype:attempted-recon; sid:624; rev:8;) 

De esta forma para detectar un SYN SCAN, la opción quedaría

flags:S

FLOW

Con esta opción indicamos que se aplique la regla solo a uno de los sentidos del flujo de comunicación. De esta forma podemos aplicar la regla solo a clientes o servidores. Veamos las opciones según los flujos.

• to_client respuesta de servidores A hacia B
• to_server peticiones de servidores A hacia B
• from_client peticiones de clientes A hacia B
• from_server respuesta de servidores de A hacia B
• established conexiones TCP establecidas
• stateless no tiene en cuenta la inspección de estado

Como ejemplo, si establecemos la opción flow de la siguiente forma:

flow:to_server,established;

estamos diciendo que: un cliente haya formalizado una petición, el servidor atiende e indicamos que la conexión haya sido establecida.

Otro ejemplo bastante simple:

alert tcp $HOME_NET 1024: -> $EXTERNAL_NET any /

(msg:"BACKDOOR netbus active"; flow:from_server,established; /

content:"NetBus"; 

WINDOW

Esta opcón verifica el campo del segmento TCP window o tamaño de ventana. (16 bits). Esta opción del segmento tcp establece el número de bytes que el emisor del segmento está dispuesto a aceptar por parte del
destino.

Por ejemplo: window:64857;

Comments

Se reescribe por completo todo el código. Otro cambio es la aparición de una línea de comandos para interactuar con Snort en el mismo momento de ejecutarlo o conectarnos con este mediante la herramientas “snortsp_tool”, pudiendo cambiar la configuración de Snort en "tiempo real".

El control de Snort se realizarán meidamnte el lenguage LUA que ya vimos de forma básica en Tshark, Wireshark en línea de comandos. (IV Parte.) Usando el lenguaje Lua.

Otras características implementadas son:

• Snort toma "consciencia" del entorno de red en el que encuentra, de esta forma es ahora capaz de priorizar alarmas, detectar posibles ataques basados en técnicas de evasión y reducir en todo lo posible la configuración manual.
• Soporte nativo para IPv6, IPv4, MPLS y GR.
• Soporte para operar en modo inline.
• Aumento de plugins y módulos para adquisición de datos, decodificadores y analizadores de tráfico.
• Ejecución multihilo. De esta forma, como ya hemos visto, se ejecutan varios engines que pueden analizar de forma simultánea el mismo tráfico.
• Mejora del rendimiento.
• .......

Podemos descargarlo desde snort-3.0.0-b2.tar.gz.

Comments

TTL

Como ya vimos en su momento, el campo de la cabecera IP (TTL) Tiempo de vida de longitud 8 bits, impide que un paquete esté indefinidamente viajando por la red.

La opción TTL de las reglas Snort comprueba el valor exacto de este valor de la cabecera independientemente del protocolo involucrado en la regla.

alert icmp any any -> any any (msg: "Ping con TTL=100"; ttl:100;)

ID

La opción ID comprueba el campo de la cabecera IP ó 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. Muy útil está regla por cuanto algunas herramientas fijan un valor contreto para este campo, con lo que podremos detectar paquetes "maliciosos".

alert udp any any - any any (msg: "Identificación ID Sopechoso"; ID:0;)

Dsize

Opción que comprueba el tamaño del contenido del paquete ó payload. Admite operadores mayor que o menor que.

alert ICMP $EXTERNAL any -> $INTERNAL any /

(msg: "ICMP ping en Windows 2000."; dsize: 32; itype: 8; /

content: "abcdefghijklmnopqrstuvwabcdefghi"; depth: 32;)

Dsize entre 300 y 400

dsize: 300<>400; 

Dsize mayor que 32

dsize > 32 

Seq y Ack

La opción Seq comprueba el valor del campo de la sequencia TCP.

Ack comprueba el valor de ACK o acuse derecibo del segmento TCP.

alert tcp $EXTERNAL_NET any -> $HOME_NET any / 

(msg:"Escaneo ping con nmap";flags:A;ack:0; / 

reference:arachnids,28;classtype:attempted-recon; sid:628;/ 

rev:1;) 

Como vemos ack es usado, por ejemplo, para detección de Scan con NMAP.

ICODE e ITYPE

Con Icode e Itype entramos en la comprobación de calores de campos de la cabecera ICMP .

• Itype comprueba, para detectar, por ejemplo, posibles DoS, el campoy Type.

• Icode comprueba el campo code ó código de error.

alert icmp 192.168.1.10 any -> $RED_EXTERNA any / 

(msg:"lanzando un ping"; icode:0;itype:8;sid:00001;/ 

classtype:reglas_personales;rev:0;)

Recordando lo visto aquí respecto a ICMP:

......el formato de ICMP cambia dependiendo del tipo de mensaje. El formato sería:

• Tipo (8 bits) Tipo de mensaje ICMP. Y pueden ser:

Tipo	Tipo de Mensaje
0	Respuesta de Eco
3	Destino Inalcanzable
4	Origen saturado
5	Redireccion (cambiar ruta)
8	Solicitud de eco
11	Tiempo excedido para un datagrama
13	Problema de parametros en un datagrama
13	Solicitud de fecha y hora
14	Respuesta de fecha y hora
17	Solicitud de nascara de direccion
18	Respuesta de mascara de direccion

• Codigo (8 bits) Contiene el código de error para el datagrama del que da parte el mensaje ICMP. La interpretación depende del tipo de mensaje. Se utiliza en algunos mensajes para distinguir, dentro de un tipo de mensaje, distintos subtipos.

• Suma de control (16 bits) Campo de control de la integridad de la totalidad del mensaje ICMP.

• Datos Depende del tipo de mensaje.

TOS

Comprueba el valor del campo TOD de la cabecera IP que corresponde al tipo de servicio respecto a la fiabilidad, velocidad, retardo, seguridad... Tiene un tamaño de 8 bits.

tos:!4;

tos:1; 

Comments

Y no solo de Snort, con HSC podemos administrar otros eventos procedentes de TCPDump, Firewall, Syslog, Sebek logs o una red de honeypots y correlacionar los eventos, mostrar gráficas, información detallada de cada evento, decodificación del payload....

Como siempre, vamos a dividir el estudio de Honeynet Security Console en varios capítulos, para, de esta forma, ir complicando su manejo comenzando por lo más básico.

Creación de la base de datos.

Al tratarse de una herramienta de tratamiento de eventos enviado por los diferentes programas, tales como Snort, TCPDump, etc, necesita una base de datos. Para comenzar podemos usar la tipica base de datos snort, cuya creación está ámpliamente documentada en la red. De todas formas aquí tratamos este tema.

Una vez creada la base de datos, pasamos al asiguiente fase.

Configurando Snort para el envío de eventos a la base de datos. Ejecutanado Snort.

Tendremos que descomentar y personalizar la línea del archivo snort.conf para el envío de eventos y altertas a la base de datos creada:

# database: log to a variety of databases
# ---------------------------------------
# See the README.database file for more information about configuring
# and using this plugin.
#
# output database: log, mysql, user=root password=test dbname=db host=localhost
# output database: alert, postgresql, user=snort dbname=snort
# output database: log, odbc, user=snort dbname=snort
# output database: log, mssql, dbname=snort user=snort password=test
# output database: log, oracle, dbname=snort user=snort password=test

Realizamos el siguiente cambio:

Descomentamos:

# output database: log, mysql, user=root password=test dbname=db host=localhost

y los dejamos de esta forma:

output database: log, mysql, user=usuario password=password dbname=snort host=localhost

Ahora las alertas serán dirigidas a la base de datos.

Tener en cuenta que host=localhost cuando Snort lo ejecutamos en local. En remoto pondremos la IP que sea.

Para ejecutar esnort tan solo es neceario una línea tal como esta:

snort -i3 -l c:\snort\log -b -c c:\snort\etc\snort.conf

Donde -i# será la interfaz que pondremos a la escucha.

Logeo y Configuración básica de HSC.

Ejecutamos HSC:

Hacemos Login y añadimos una base de datos:

Rellenamos los campos teniendo en cuenta que hay que pulsar en el botón Fill Databases para escojer la base de datos del repositorio de mysql. En Host address pondremos la dirección del servidor mysql (localhost) o la dirección remota que sea:

Una vez introducidos entros datos, parecera la Base de datos. Si ya hemos usado HSC, aparecerán los sensores ya utilizados y que extrae de la base datos mysql, caso contrario, no aparecerá sensor alguno hasta que ejecutemos Snort en local o máquia remota contra nuestra base de datos.

Los sensores se identifican con nombremáquina/dispositivo_de_red

En este caso ya he usado la base de datos con dos sesores distintos:

Visualización de eventos.

Si pulsamos, en la imagen de arriba, el icono de la derecha (IDS), aparecerá la base de datos creada y una relación de itens correspondiente a todos los eventos del sensor activo. Tendremos, pues, una Relación de Eventos, Eventos únicos, gráfica según una clasificación por prioridades de la alterta, según la clasificacion de la alterta, Origen y destino de IPs, Origeny destino por puertos, protocolos, etc:

Podemos posicionarnos sobre un evento y HSC nos mostrará información detallada:

Información detallada del evento:

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

Bien, ya tenemos lo más básico. En el próximo capítulo avanzaremos en la configuración, gestionaremos varias bases de datos y sensores remotos, etc.

Comments

• fragoffset
• ttl
• id
• dsize
• fragbits
• seq
• ack
• icode
• tos
• .......

Fragoffset y Fragbits.

Ya vimos en el capítulo dedicado a la interpretacion del datagrama IP, que el campo Fragment offset o Posición de longitud de 13 bits. nos informa de la posición del fragmento dentro del datagrama.

De forma muy general podemos decir que la MTU es el tamaño del paquete ó datagrama más grande que una red puede transmitir dependiendo de la tecnología de red usada. Se expresa en bytes. Cuando se sobrepasa la MTU, el paquete se fragmenta, de divide en otro paquetes de menor tamaño. Solo el primero de estos paquetes contendrá la cabecera TCP asociada al paquete origen. El resto de fragmentos contienen la cabecera IP + datos. El campo de la cabecera IP Fragment Offset informa dela existencia de más fragmentos y la relación entre ellos.

Siempre y cuando la longitud total del datagrma sea igual o menor que el valor de MTU, no habrá fragmentación. Ccaso contrario puede ocurrit que el bit de no fragmentación DF este activado y tampoco se pueda fragmentar. se descarta el datagrama y se informa por los mecanismos establecidos. Si DF no está activado entonces hay fragmentación.

Ya vimos en su momento que respecto a la cabecera IP los valores que acabamos de ver se encuentran en el campo Flag:

4 Bandera (Flag) Campo de 3 bits.

• 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.

En los paquetes fragmentados Fragment offset nos indica, pues, la posición que ocupa el paquete actual dentro del datagrama original de forma que el destino pueda reconstruirlo. En el primer o un único fragmento el valor es siempre 0.

La opción Fragoffset de las reglas permite comparar el valor de Fragment offset del datagrama IP contra un valor decimal. Podemos ayudarnos también de la opción Fragbits que comprueba el bit de fragmentación del datagrama IP.

Fragbits inspecciona los bits de fragmentación además de los reservados (3 bits):

• R bit resrervado
• D bit de no fragmentación (DF en el campo de la cabecera IP)
• M bit de más fragmento (MF en el campo de la cabecera IP)

A la hora de aplicar la opción, podemos incluir dos de estos bits usando la notación siguiente:

• + aparece el bit especificado y cualquier otro
• * se produce la coincidencia si cuaklquiera de los bits especificados aparece
• ! notación de negación.

Por ejemplo, la notación D especifica que solo aparece el bit de fragmentación. En el caso de R+ se especifica la aparición del bit reservado independientemente de la activación o no de los demás.

Un ejemplo:

alert ip any any - any any  (msg: "Primer Fragmento"; fragbits: M; fragoffset: 0;)

.

La importancia de esta opción la veremos más adelante. Ataques como evasión de IDS, diversos ataques basados en framentación, etc.

Comments

Todo depende de la topología de red y el uso de hub o switch.

Este artículo es válido para cualquier sniffer de los que ya hemos visto. Wireshark, Tshark, WinDump / TCPdump, etc.

Posición del sniffer en red no conmutada (HUB).

El escenario más básico lo encontramos en una red conectada mediante hub. En este caso posicionamos el sniffer en cualquier ranura o boca del hub y obtendremos, con la tarjeta en modo promíscuo, todo el tráfico de la red. Esto es así porque en un hub todos los paquetes son transmitidos a todos los hosts conectados en el mismo segmento de red. Se divide el ancho de banda entre cada host de la red, ademas, se transmiten los paquetes a la velocidad del dispositivo más lento del segmento. Se producen también colisiones que derivan en una red más lenta debido a las retransmisiones.

Posición del sniffer en red conmutada (SWITCH).

En este caso, a cada host conectado al switch, le llega solo el trafico dirigido a el (unicast ) y el broadcast/multicast. El tráfico dirigido a otros host NO lo veremos. No divide el ancho de banda, esto significa, a grosso modo, que en un switch 10/100 cada puerto es capaz de transmitir a un máximo de 100 dedicado. Es más eficiente que las redes no conmutadas.

Resumiendo entonces, si ubicamos un sniffer en cualquier puerto del switch, solo veremos el tráfico dirigido solo al host donde se encuentre el sniffer y el tráfico broadcast/multicast tal como ARP.

Soluciones.

Solución 1

Una posible solución podría ser el envenenamiento ARP, un Arp Poison. Pero esto es totalmente desaconsejable porque podemos "destabilizar" la red y crear mayores problemas.

Solución 2

Podríamos también colocar el sniffer en el gateway de salida a internet, ó en un host firewall de varias tarjetas, indicar cual de las interfaces nos interesa "olfatear", de esta forma veremos algo más de tráfico que no sea el broadcast/multicast.

Pero para ver todo el tráfico entre dos hosts las soluciones más eficaces son otras.

Solución 3

Una de ellas es aprovechar alguna de las características de un switch administrable como el SPAN (Switch Port Analysis) o llamado de otra forma el Port Mirroring. Esta es una caraterística que lo que hace es, básicamente, copiar el tráfico entre dos puertos a un tercero (ubicación del host sniffer) del switch. Eel Port mirroring tiene el problema que multiplica la carga del switch.

Solución 4

Pero ¿ que pasa si el switch es antiguo y/o no administrable, o simplemente no soporta Port Mirroring ?.

Para este caso tenemos otra opción. Se trata de conectar un hub a una de las salidas o puerto del switch y a este hub conectar el host sniffer (C) y uno de los host a capturar el tráfico (B). El otro host llamémosle (B) sigue en su ubicación del switch . De esta forma C puede ver el tráfico entre A y B. ( B puede ser cualquier otro host conectado al switch o un servidor ).

Esta opción, al igual que el Arp Poison, es algo problemática y desaconsejable.

Solución 5

Otra opción de la que disponemos es instalar otra interface de red en el host sniffer de forma que tenga dos interfaces de red. Una de las tarjetas la conectamos al switch y la otra a uno de los hosts a analizar. Esta opción se considera pasiva, pero necesita de configuración del host sniffer a nivel de interfaces de red para establecer el modo Bridge. (http://technet.microsoft.com/en-us/library/bb457038(TechNet.10).aspx).

Solución 6

Est solución, quizá la más eficiente y aconsejable aunque también más costosa y quizás más incomoda. Consiste en hacer uso de un Network TAP o "Test Access Port" (Puerto de acceso de pruebas). Con este dispositivo podemos capturar el tráfico de una red conmutada de forma pasiva, es decir, no interfiere en el flujo o tráfico de nuestra red.

Sobre la construcción de un TAP:

http://www.snort.org/docs/tap/

Más información sobre sniffers en redes conmutadas y no conmutadas. Su detección:

http://seguridadyredes.nireblog.com/post/2007/12/20/detectando-sniffers-en-nuestra-red-redes-conmutadas-y-no-conmutadas

Comments

La forma más básica de descubrir el tráfico P2P es filtrando por los puertos que, por defecto, suelen usar estos programas. Hay que tener en cuenta que en la mayoría de estos programas estos puertos usados son configurables, pero es ya la primera pista para ir comenzando a abordar el problema.

Algunos puertos usados por los programas P2P.

Gnutella (Bearshare, Limewire)
TCP 6346, 6347, 6348
UDP 6346, 6347, 6348

Kazaa, Grokster, Morpheous
TCP 1214
UDP 1214

WinMX & Napster
TCP 6257
UDP 6257
TCP 6699
UDP 6699

eDonkey
TCP 4661-4672
UDP 4661-4672

BitTorrent
TCP 6881-6889
UDP 6881-6889

Napster
TCP 4444, 5555, 6666, 7777, 8888
UDP 4444, 5555, 6666, 7777, 8888

Analizando el tráfico P2P. Las huellas.

Otra forma de descubrir este tráfico es poe las huellas dejadas en las trazas o paquetes capturados.

Ares suele algunas pistas sobre sue uso en nuestras capturas:

De la misma forma, Napster suele dejar en las capturas:

@napster.com

Emule deja la firma: "Server eMule"

Gnutella suele dejar ditrectamente: "GNUTELLA" ó "GNUTELLA OK"

BitTorrent puede dejar algo parecedo a: "BitTorrent protocol"

En resúmen, casi todos los progrmas P2P suelen dejar una huella bastante evidente. Es cuentión de usarlos y analizar dichas huellas para que nos sirva de filtro.

Filtrando por protocolos en Wireshark / Tshark.

Mientras capturamos en Wireshark o Tshark, podemos o filtrar por puertos (lo hemos visto más arriba), o por protocolo en los filtros de visualizaxión (Display Filter):

Filtrando por protocolos podemos usar la opción -R de Tshark o la ventana de Display Filter de Wireshark introduciendo cualquiera de estos disertores:

gnutella
bittorrent
edonkey

Tambíen podemos usar desde el menú principal de Wireshark:

Edit > Preferences > Protocols> BitTorrent , EDONKEY

Estadísticas de uso.

Usando las estadísticas, podemos también ver según el protocolo P2P la cantidad frames y bytes que circulan por la red. Lo vimos en su momento aquí y aquí :

Otro tipo de estadísiticas:

Vemos claramente el uso de edonkey / Emule en las estadisticas.

Uso de IDS o Sistemas de detección de Intrusos y cortafuegos.

La mayoría de firewalls o cortafuegos tienen estadísticas, logs y sistemas para bloquear el uso de programas P2P. Así mismo, un IDS tal como Snort , contienen una serie de reglas para detectar el uso del tráfico P2P.

Comments

Con IPerf podemos medir el ancho de banda y rendimiento de una conexión entre dos host. Se trata, pues, de una herramienta cliente-servidor.

Podemos descargar Iperf desde aquí. Y para win32 y otras plataformas desde aquí.

Al tratarse de una herramienta cliente-servidor, tendremos que ejecutar Iperf en dos máquinas. Una hará de Servidor y otra de Cliente.

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.

IPerf como cliente.

En la máquina cliente IPerf, de la forma más sencilla lo ejecutamos de esta manera:

>iperf -c 192.168.1.250
------------------------------------------------------------
Client connecting to 192.168.1.250, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------

Conectamos con el servidor (192.168.1.250) y se envian una serie de paquetes para calcular el ancho de banda en la conexión. El resultado es el siguiente:

>iperf -c 192.168.1.250
------------------------------------------------------------
Client connecting to 192.168.1.250, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[844] local 192.168.1.30 port 3545 connected with 192.168.1.250 port 5001
[ ID] Interval Transfer Bandwidth
[844] 0.0-10.0 sec 113 MBytes 94.8 Mbits/sec

94.8 Mbits/sec en una red a 100 Mbits.

Claramente vemos el rendimiento de la conexión.

Configurando IPerf.

Podemos configurar tanto el cliente como el servidor para personalizar un poco las mediciones.

Como servidor.

A parte de la opción -s que deja a IPref a la escucha, podemos usar:

• -D como servicio
• -R remover servicio
• -u recibir datagramas UDP en vez de TCP por defecto.
• -P x número de conexiones simultáneas
• -m muestra MTU (depende del sistema operativo )
• -w specifica el tamaño de Ventana (TCP window size). Muy útil para ir calculando nuestro tamaño de ventana más óptimo según las mediciones de ancho de banda.
• -f[bkmBKB] mostrar resultados en bits/s, kilobits/s, megabytes/s, Bytes/s, KiloBytes/s, MegaBytes/s (s=segundos). Tanto en cliente como servidor:

>iperf -c 192.168.1.250 -f B
------------------------------------------------------------
Client connecting to 192.168.1.250, TCP port 5001
TCP window size: 64512 Byte (default)
------------------------------------------------------------
[844] local 192.168.1.30 port 3591 connected with 192.168.1.250 port 5001
[ ID] Interval Transfer Bandwidth
[844] 0.0-10.0 sec 118792192 Bytes 11860687 Bytes/sec

Como cliente.

Lo más básico es -c IP pero podemos establecer otras opciones, las más importantes:

• -f[bkmBKB] (igual que lo comentado como servidor)
• -w (lo mismio que para servidor)
• -m muestra MTU (depende del sistema operativo)
• -T ttl especifica valor TTL
• -i segundos especifica un intervalo, medido en segundos, en el cual se volverá a realizar la medición.
• -t segundos tiempo duración transmisión. Hace más fiable la medida.

>iperf -c 192.168.1.250 -t 60
------------------------------------------------------------
Client connecting to 192.168.1.250, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[844] local 192.168.1.30 port 3670 connected with 192.168.1.250 port 5001
[ ID] Interval Transfer Bandwidth
[844] 0.0-60.0 sec 669 MBytes 93.5 Mbits/sec

• -p especifica puerto en el que escucha el servidor
• -u envio de UDP en vez de TCP por defecto. Podemos medir también pérdida de paquetes:

cliente:

>iperf -c 192.168.1.250 -u -f MB -t 60
------------------------------------------------------------
Client connecting to 192.168.1.250, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 0.06 MByte (default)
------------------------------------------------------------
[844] local 192.168.1.30 port 3745 connected with 192.168.1.250 port 5001
[ ID] Interval Transfer Bandwidth
[844] 0.0-60.0 sec 7.50 MBytes 0.12 MBytes/sec
[844] Server Report:
[844] 0.0-60.0 sec 7.06 MBytes 0.12 MBytes/sec 0.000 ms 314/ 5351 (5.9%)
[844] Sent 5351 datagrams

respuesta servidor:

>iperf -s -u -f MB -i1
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 0.01 MByte (default)
------------------------------------------------------------
[1964] local 192.168.1.250 port 5001 connected with 192.168.1.30 port 3744
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1964] 0.0- 1.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 544436086/ 89 (6.
1e+008%)
[1964] 1.0- 2.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 2.0- 3.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 3.0- 4.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 4.0- 5.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 5.0- 6.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 6.0- 7.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 7.0- 8.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 8.0- 9.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 9.0-10.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 0.0-10.0 sec 1.25 MBytes 0.12 MBytes/sec 0.000 ms 0/ 893 (0%)
[1964] local 192.168.1.250 port 5001 connected with 192.168.1.30 port 3745
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1964] 0.0- 1.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 1.0- 2.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 2.0- 3.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 3.0- 4.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 4.0- 5.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 5.0- 6.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 6.0- 7.0 sec 0.12 MBytes 0.12 MBytes/sec 0.136 ms 0/ 89 (0%)
[1964] 7.0- 8.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 8.0- 9.0 sec 0.12 MBytes 0.12 MBytes/sec 0.020 ms 0/ 89 (0%)
[1964] 9.0-10.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 10.0-11.0 sec 0.12 MBytes 0.12 MBytes/sec 0.062 ms 0/ 89 (0%)
[1964] 11.0-12.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 12.0-13.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 13.0-14.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 14.0-15.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 15.0-16.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 16.0-17.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 17.0-18.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 18.0-19.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 19.0-20.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1964] 20.0-21.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 21.0-22.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 22.0-23.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 23.0-24.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 24.0-25.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 25.0-26.0 sec 0.12 MBytes 0.12 MBytes/sec 1.108 ms 0/ 89 (0%)
[1964] 26.0-27.0 sec 0.12 MBytes 0.12 MBytes/sec 0.004 ms 0/ 89 (0%)
[1964] 27.0-28.0 sec 0.13 MBytes 0.13 MBytes/sec 0.840 ms 0/ 90 (0%)
[1964] 28.0-29.0 sec 0.12 MBytes 0.12 MBytes/sec 0.003 ms 0/ 89 (0%)
[1964] 29.0-30.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 30.0-31.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 31.0-32.0 sec 0.12 MBytes 0.12 MBytes/sec 1.986 ms 0/ 89 (0%)
[1964] 32.0-33.0 sec 0.12 MBytes 0.12 MBytes/sec 0.006 ms 0/ 89 (0%)
[1964] 33.0-34.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 34.0-35.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 35.0-36.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 36.0-37.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 37.0-38.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 38.0-39.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 39.0-40.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1964] 40.0-41.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 41.0-42.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 42.0-43.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 43.0-44.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 44.0-45.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 45.0-46.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 46.0-47.0 sec 0.00 MBytes 0.00 MBytes/sec 0.000 ms 0/ 1 (0%)
[1964] 47.0-48.0 sec 0.00 MBytes 0.00 MBytes/sec 0.000 ms 0/ 0 (-1.$%)
[1964] 48.0-49.0 sec 0.00 MBytes 0.00 MBytes/sec 0.000 ms 0/ 0 (-1.$%)
[1964] 49.0-50.0 sec 0.11 MBytes 0.11 MBytes/sec 3.386 ms 277/ 355 (78%)
[1964] 50.0-51.0 sec 0.12 MBytes 0.12 MBytes/sec 0.011 ms 0/ 89 (0%)
[1964] 51.0-52.0 sec 0.13 MBytes 0.13 MBytes/sec 0.000 ms 0/ 90 (0%)
[1964] 52.0-53.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 53.0-54.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 54.0-55.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 55.0-56.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 56.0-57.0 sec 0.12 MBytes 0.12 MBytes/sec 0.000 ms 0/ 89 (0%)
[1964] 57.0-58.0 sec 0.07 MBytes 0.07 MBytes/sec 2.658 ms 37/ 90 (41%)
[1964] 58.0-59.0 sec 0.12 MBytes 0.12 MBytes/sec 0.009 ms 0/ 89 (0%)
[1964] 0.0-60.0 sec 7.06 MBytes 0.12 MBytes/sec 0.000 ms 314/ 5351 (5.9%)

Comments

• Depth
• Offset
• Nocase
• Distance
• Within

Ya hemos visto que con la opción content de una regla Snort, podemos buscar un contenido determinado en el payload o carga útil de un paquete, de forma que genere una alerta cuando exista una coincidencia en el patrón. El contenido a buscar puede ser texto, binario o una mezcla de ambos. Sin embargo, para lograr una mayor coincidencia en los patrones y mejor rendimiento existen una serie de modificadores que añaden mayor potencia, flexibilidad y exactitud a la búsqueda de patrones y contenidos.

Puede ser que la coincidencia del patrón a buscar necesite mucha exactitud para darse como valido o que tengamos varios patrones distintos a buscar dentro del payload de un mismo paquete, e incluso que entre ambos patrones haya una determinada distancia en bytes.

Consideraciones previas

Antes que nada una serie de consideraciones sobre la notación de la sintaxis a emplear.

• Podemos usar | para delimitar el contenido en binario:

alert tcp any any -> any any (content: "|73 74 65 6d 61 73| ;)

• El caracter ! niega el patrón:

alert tcp any any -> any any (content: ! "USER" ;)

Buscando el contenido en el payload.

Uno de los casos más simples que se nos pueden dar es el siguiente. Tenemos una captura:

Queremos qe Snort genere una alerta cada vez que aparezca el comando SMTP: EHLO alfon

Lo más rápido, pasando por alto puertos y hosts (por eso ponemos any) sería:

alert tcp any any -> any any (content: "EHLO alfon";)

También lo podríamos ponner en binario:

alert tcp any any -> any any (content:"|45 48 4c 4f 20 6c 63 61 6d 70|";)

Puede ser que el comando pueda ser ehlo alfon en minúscula o máyúscula. Para ello usamos nocase:

alert tcp any any -> any any (content: "EHLO alfon"; nocase ;)

Por cierto, vamos a incluir un manseje para la alerta:

alert tcp any any -> any any (msg: "conexión SMTP"; content: "EHLO alfon"; nocase ;)

Depth y Offset

Para que la búsqueda del patrón sea más eficiente vamos a acotar este de forma que mejoremos el rendimiento. Usaremos Depth.

Depth establece un número determinado de bytes a buscar en el payload del paquete. Se cuenta desde el principio de la zona destinada a los contenidos del paquete. Vamos a verlo de forma más detallada:

Esta captura corresponde a un comando SMB. En este caso: SMB Read AndX Request (0x2e) Apertura de un archivo.

Para comenzar a buscar en el contenido del paquete, una vez terminada la zona destinada a cabecera y segmento TCP , nos situamos en la zona de datos (señalada con una flecha).

Deseamos buscar el "Server Component: SMB" (dentro del cuadro rojo).

Los datos a buscar ocupan 4 bytes y comienza en el byte 4 desde el principio del a zona de datos. (comenzamos desde 0).

Vamos a usar entonces los conceptos Depth, ya explicado y Offset. Con offset indicamos en número de bytes a partir del cual analizamos la busqueda del patrón. Seguimos con el ejemplo y creamos la regla:

alert tcp any any -> any any (msg: "apertura de archivo detectado"; content: "|ff 53 4d 42|"; offset = 4 ; depth = 4)

Es decir; buscamos el patron .SMB o en binario ff 53 4d 42 comenzando en el byte 4 y analizamos 4 bytes a partir de este último.

Distance y Within.

Bien, vamos ahora a complicar un poco la búsqueda. Necesitamos buscar dos patrones diferentes en el mismo paquete. Para que el rendimiento sea mayor y el motor de snort realice su trabajo con mayor precisión y usando menos recursos, vamos a aplicar una regla en la que determinemos el patrón de forma exacta.

Tenemos la siguiwente captura:

Vamos a bucar la Palabra Microsoft Word y a una distancia determinada MSWordDoc. Por si acaso vamos a olvidarnos de mayúsculas y mínusculas (nocase) y acotaremos perfectamente lo patrones.

alert tcp any any -> any any (msg: "Apertura de archivo Microsft Word"; content: "Microsoft Word"; offset = 116 ; depth = 14; content: "MSWordDoc"; nocase ; distance = 14 ; within = 9 ;)

Esto es lo mismo que decir. Genera una alerta con el mensaje Apertura de archivo Microsft Word cuando encuentres la palabra Microsoft Word a una distancia (offset ) de 116 bytes y busca dentro de los 14 primero bytes (depth). Busca también la palabra MSWordDoc a una distancia (distance) del último patron o palabra encontrada de 14 bytes dentro de los 9 primeros bytes (within).

Comments

Partimos de la siguiente captura:

Observemos las tres primeras líneas. Estas corresponden al inicio de la comunicación con el servidor de correo. 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.

Para comprenderlo mejor vemos esta otra traza con el número de secuencia inicial aleatorio:

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

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

Inmediatamente el servidor de correo responde con un código 220 que está listo:

SMTP Response: 220 SERV-CORREO Spectrum Server 1.0 ESMTP ready

Responde le cliente iniciando el diálogo y sesión SMTP con el servidor:

SMTP Command: EHLO alfon

Responde le servidor de correo aceptando con un código 250 y el nombre del servidor:

SMTP Response: 250-SERV-CORREO

El cliente inicia la autentificación con el servidor. (Servidor autentificado):

SMTP Command: AUTH LOGIN

Responde el servidor pidiendo Username y un código 334, en este caso codificado. En caso de fallo de autentificación se responde con un codigo 535. el cliente envia el usuario;

SMTP Response: 334 VXNlcm5hbWU6
SMTP Command: c2lzdGVtYXNAYWJhbmNlLmVz

El servidor pide Password el el cliente responde. Todo ello codificado.:

SMTP Response: 334 UGFzc3dvcmQ6
SMTP Command: JEFETUFOMTAwJQ==

Todo salió bien:

SMTP Response: 235 2.0.0 Authentication successful

Inidicamos al servidor el inicio del mensaje de correo con MAIL FROM. Indicamos remitente y destinatario (RCPT TO):

SMTP Command: MAIL FROM:
SMTP Response: 250 2.1.0 Sender ok
SMTP Command: RCPT TO:
SMTP Response: 250 2.1.5 Recipient ok (local)

Con DATA indicamos al servidor que lo que viene a continuación es el texto del mensaje. El servidor responde aceptando con un código 354 indicando que podemos introducir el mensaje y enviamos los paquetes correspondientes al texto de mensaje:

SMTP Response: 354 Enter mail, end with CRLF.CRLF
SMTP DATA fragment, 1460 bytes
SMTP DATA fragment, 1460 bytes
SMTP DATA fragment, 1460 bytes
SMTP DATA fragment, 1460 bytes
SMTP DATA fragment, 740 bytes

Una vez que finalizamos la transmisión de los paquetes del mensaje y con el comando EOM indica el cliente el fin del mensaje:

SMTP EOM

El servidor se da por enterado y acepta el mensaje:

SMTP Response: 250 2.0.0 48456cd9-0001a6ae Message accepted for delivery

El cliente indica ahora que no hay más operaciones a realizar que se puede cerrar la conexión:

SMTP Command: QUIT

El servidor se da por enterado y cierra conexión con el cliente:

SMTP Response: 221 2.0.0 SMTP closing connection

Cierre de conexión TCP. Al igual que al principio se inicia una petición de conexión por parte del cliente con un diálogo en tres fases, ahora se da por terminada la conexión pero en cuatro pasos. Esto es debido a que cada una de las "direcciones" debe ser cerrada independientemente:

serv_correo -> cliente TCP 25 > 3612 [FIN, ACK] Seq=505 Ack=6732 Win=65524 Len=0
cliente -> serv_correo TCP 3612 > 25 [ACK] Seq=6732 Ack=506 Win=64008 Len=0
cliente -> serv_correo TCP 3612 > 25 [FIN, ACK] Seq=6732 Ack=506 Win=64008 Len=0
serv_correo -> cliente TCP 25 > 3612 [ACK] Seq=506 Ack=6733 Win=65524 Len=0

Comments