Taller de TcpDump / WinDump: Analizando la Red - Avanzando con los filtros

4 - Avanzando con los filtros

""<H3>INTRODUCCIÓN</H3>
 Ya comenté en el primer capítulo que Windump / TCPDump tiene filtros para su mejor manejo. Estos filtros pueden llegar a ser tan sofisticados como queramos y extraer cualquier tipo de datos de los datagramas, paquetes, etc que circulen a través de nuestra red.
 Como la mejor manera de explicar el funcionamiento de los filtros es la práctica, vamos a analizar una combinación y encadenamiento de filtros con un ejemplo muy simple.
 <H3 align=justify>Ejemplo</H3>
 Tenemos el servidor de correos un tanto colapsado, este servidor no aguanta demasiadas conexiones, o el tráfico es mayor de lo previsto. Analicemos entonces qué es lo que pasa.
 Vamos a crear un filtro para averiguar las conexiones al puerto 110 de nuestro servidor de correos.
 <DL>
 <DD>
 <DIV align=justify><PRE class=tiny>C:\scan&gt;windump -qn -X -s 0 tcp[13] = 2 and port 110
 </PRE></DIV></DD></DL>
 Aquí vemos algunas opciones ya comentadas y otras nuevas:
 <UL>
 <LI>
 –q establecemos el indicador de salida rápida que hará que nos devuelva menos información y que las líneas sean más cortas. Esto es así, porque, en realidad, sólo nos interesa los host/IP y las marcas de tiempo, ya que, como veremos más adelante, estamos filtrando establecimientos de conexión TCP al puerto 110. 
 <LI>
 -n no resolver nombres de host 
 <LI>
 -X vuelca en la consola los datos. 
 <LI>
 -s 0 es el snaplen. A cero estamos cogiendo los paquetes completos. Si hubiéramos puesto -s 512 se capturarían sólo los primeros 512 bytes del paquete tcp. 
 <LI>
 tcp[13] = 2 esta es la parte interesante. Con este filtro estamos diciendo a windump que queremos escoger los paquetes TCP cuyo indicador, bandera o flag sea SYN "S". Para entender esto hay que tener en cuenta cómo es el formato de una cabecera TCP, que los indicadores o flags se encuentran en el octeto 13. 
 <LI>
 and port 110, unido a lo anterior, analizará el puerto 110. Podriamos añadir que lo hiciera sólo para un determinado host:and port 110 and host ALFON.</LI></UL>
 
 Vamos a echarle un ojo al octeto 13 y simulemos que el flag SYN está activo, pero antes, recordemos el Formato de la cabecera del TCP.
 <DIV align=center>
 <CENTER>
 <TABLE style="LINE-HEIGHT: 100%; BORDER-COLLAPSE: collapse; TEXT-ALIGN: justify" borderColor=#111111 cellSpacing=10 cellPadding=10 width="84%" summary=tabla border=0>
 <TBODY>
 <TR>
 <TD width="100%" bgColor=#f2f3f9>
 <H3 style="LINE-HEIGHT: 150%">Formato de la cabecera (header) del TCP:</H3>
 <IMG alt=IMAGEN src= http://www.wikilearning.com/imagescc/4737/cabecera_tcp.jpg border=0>
 
 <UL>
 <LI>
 Puerto origen (16 bits). Puerto de la máquina origen. Al igual que el puerto destino es necesario para identificar la conexión actual. 
 <LI>
 Puerto destino (16 bits). Puerto de la máquina destino. 
 <LI>
 Número de secuencia (32 bits). Indica el número de secuencia del primer byte que trasporta el segmento. 
 <LI>
 Número de acuse de recibo (32 bits). Indica el número de secuencia del siguiente byte que se espera recibir. Con este campo se indica al otro extremo de la conexión que los bytes anteriores se han recibido correctamente. 
 <LI>
 Posición de los datos (4 bits). Longitud de la cabecera medida en múltiplos de 32 bits (4 bytes). El valor mínimo de este campo es 5, que corresponde a un segmento sin datos (20 bytes). 
 <LI>
 Reservado (6 bits). Bits reservados para un posible uso futuro. 
 <LI>
 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: </LI></UL>
 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.
 <UL>
 <LI>
 Ventana (16 bits). Número de bytes que el emisor del segmento está dispuesto a aceptar por parte del destino. 
 <LI>
 Suma de verificación (24 bits). Suma de comprobación de errores del segmento actual. Para su cálculo se utiliza una pseudo-cabecera que también incluye las direcciones IP origen y destino. 
 <LI>
 Puntero de urgencia (8 bits). Se utiliza cuando se están enviando datos urgentes que tienen preferencia sobre todos los demás e indica el siguiente byte del campo Datos que sigue a los datos urgentes. Esto le permite al destino identificar donde terminan los datos urgentes. Nótese que un mismo segmento puede contener tanto datos urgentes (al principio) como normales (después de los urgentes). 
 <LI>
 Opciones (variable). Si está presente únicamente se define una opción: el tamaño máximo de segmento que será aceptado. 
 <LI>
 Relleno. Se utiliza para que la longitud de la cabecera sea múltiplo de 32 bits. 
 <LI>
 Datos. Información que envía la aplicación. </LI></UL>
 &nbsp;</TD></TR></TBODY></TABLE></CENTER></DIV>
 
 <H3 align=justify>¿Qué significa realmente tcp[13] = 2?</H3>
 En el flag SYN, que es utilizado para la sincronización de los números de la secuencia tendremos:
 U A P R S F ------------------ 0 0 0 0 0 0 1 0 (en binario) ------------------ 7 6 5 4 3 2 1 0
 vemos que el byte 7 y 6 están reservados, el 5 es para URGENT, el 4 es para ACK, el 3 es para PUSH, el 2 es para RESET y el byte 0 para FIN. Tenemos entonces el octeto completo.
 En binario quedaría como acabamos de ver: 0 0 0 0 0 0 1 0, que pasado a base decimal, vemos que es el 2, de ahí viene tcp[13] = 2.
 *Es fácil deducir entonces que para detectar un SYN/ACK: 0 0 0 1 0 0 1 0, el 18 en base decimal, entonces tcp[13] = 18.
 Lo vemos más claramente en las siguientes líneas.
 &nbsp; 
 <DIV align=center>
 <CENTER>
 <TABLE style="LINE-HEIGHT: 100%; BORDER-COLLAPSE: collapse; TEXT-ALIGN: justify" borderColor=#111111 cellSpacing=10 cellPadding=10 width="84%" summary=tabla border=0>
 <TBODY>
 <TR>
 <TD width="100%" bgColor=#f2f3f9>
 <H3 style="LINE-HEIGHT: 150%" align=justify>La teoría</H3>
 Antes que nada, decir que TCPDump usa el formato: proto[x:y] = valor para leer datos en cabeceras de los protocolos involucrados.
 <UL>
 <LI>
 proto (protocolo) puede ser ip, arp, rarp, tcp, udp, icmp, etc 
 <LI>
 [x:y] x es el octeto ó byte de comienzo e y significa: "leer" y bytes a partir del byte x 
 <LI>
 Si sólo aparece [x] es lo mismo que decir [x:1], es decir leer sólo el byte x, esto lo hace TCPDump por defecto. </LI></UL>
 Ya sabemos que significa cada uno de los valores. Vamos entonces a averiguar de dónde sacamos el 13 de la expresión tcp[13] = 2
 *por maty: la escala que está encima del dibujo está mal.
 <IMG alt=IMAGEN src= http://www.wikilearning.com/imagescc/4737/cabecera_tcp.jpg border=0>
 
 Vamos a analizar la cabecera por filas:
 <UL>
 <LI>
 puerto origen = 2 bytes u octetos o 16 bits 
 <LI>
 puerto destino = 2 bytes u octetos. La cuenta siempre empieza por el 0, con lo cual los octetos van del 0 al 3 
 <LI>
 número secuencia = 4 bytes u octetos, es decir del 4 al 7 
 <LI>
 número acuse recibo = 4 bytes u octetos del 8 al 11 </LI></UL>
 OJO: Tenemos doce octetos (0,1, ...11) Hemos de tener en cuenta que se empieza a contar desde cero, es decir, el primer byte es el octeto 0.
 El siguiente octeto es el 12 (el décimo tercero) va desde el bits 0 al 7 que corresponden a posición de datos u offset -4 bits- y a Reservado -4+2-; dos bits de Reservado pertenecen ya al siguiente octeto el 13, que tiene los 2 bits reservados anteriores y 6 que son los flags (UAPRSF). 6 + 2 = 8 bits que es el octeto o byte 13 (o décimo cuarto).
 &nbsp;</TD></TR></TBODY></TABLE></CENTER></DIV>
 
 
 <H3 align=justify>Vamos a analizar ahora de dónde viene el valor 2 de la expresión tcp[13] = 2</H3>
 Esta es la representación de octeto ó byte 13. Si ponemos el flag SYN activado y el resto NO activados, resulta que SYN lo ponemos a 1 y el resto a 0:
 Queda entonces: 0 0 0 0 0 0 1 0 (los dos primeros bits dijimos que eran reservados y siempre están a 0)
 U A P R S F ------------------ 0 0 0 0 0 0 1 0 (en binario) ------------------ 7 6 5 4 3 2 1 0
 Si pasamos este número (0 0 0 0 0 0 1 0 ), que es binario, a decimal nos queda el número decimal 2 (2 elevado a 1), que es el valor que debemos de introducir para que la expresión quede así:
 tcp[13] = 2
 Esto le dice a windump o TCPDump que busque en la cabecera TCP el valor 2 que se encuentra en el byte u octeto 13. Y ya sabemos que corresponde al flag SYN activado (y los otros flags/banderas estarán desactivados).
 
 Usando esta técnica, con windump o tcpdump, podríamos detectar escaneos y otras intrusiones en nuestros sistemas.
 Siguiendo con el ejemplo práctico y quitando la opción -X que ahora es irrelevante:
 <DL>
 <DD>
 <DIV align=justify><PRE class=tiny>C:\scan&gt;windump -qn -s 0 tcp[13] = 2 and port 110
 windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
 19:11:20.914698 192.168.2.71.1117 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:22.442635 192.168.4.10.3531 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:29.321747 192.168.2.90.2310 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:29.350083 192.168.4.9.1392 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:30.167786 192.168.2.9.1118 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:40.848757 192.168.2.90.2311 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:47.603914 192.168.2.70.1400 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:48.692990 192.168.4.2.2349 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:48.946846 192.168.4.2.2350 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:49.167414 192.168.4.2.2351 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:11:53.689934 192.168.4.11.2360 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:21.576147 192.168.2.71.1118 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:22.885469 192.168.4.10.3532 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:29.776688 192.168.2.90.2312 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:29.799274 192.168.4.9.1393 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:41.142773 192.168.2.90.2313 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:42.594882 192.168.4.2.2352 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:42.828622 192.168.4.2.2353 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:43.060723 192.168.4.2.2354 &gt; 192.168.4.15.110: tcp 0 (DF)
 19:12:47.896352 192.168.2.70.1401 &gt; 192.168.4.15.110: tcp 0 (DF)
 </PRE></DIV></DD></DL>
 Faltan muchas líneas, pero podemos observar en éstas que algunos host tenían sus clientes de correo configurados para "mirar" el correo cada minuto. En la realidad fueron casi todos, con lo cual tenían el servidor bastante atareadillo.
 <DIV align=center>
 <CENTER>
 <TABLE style="BORDER-COLLAPSE: collapse" borderColor=#111111 cellSpacing=10 cellPadding=10 width="80%" summary=tabla border=1>
 <TBODY>
 <TR>
 <TD style="LINE-HEIGHT: 150%; TEXT-ALIGN: justify" width="100%" bgColor=#f2f3f9>NOTA: Como nota final decir, para los que me comentan por mail, que el Ethereal es mejor en algunos aspectos por ser gráfico y más intuitivo, pero que tanto Ethereal como TCPDUMP / WINDUMP se basan en la misma librería de captura de paquetes y por tanto para filtrar usan la MISMA sintaxis. Es decir, todo esto que os escribo es válido también para Ethereal.</TD></TR></TBODY></TABLE></CENTER></DIV>""

Añade una nota a tu edición que explique en qué consisten tus cambios:

Opinar
Sé el primero en opinar

Tutoriales relacionados con 'Taller de TcpDump / WinDump: Analizando la Red'

Taller de TcpDump / WinDump: Analizando la Red

Una de las actividades más comunes en la administación de una red o administración de... Más »

Taller de Sistemas de detección de intrusiones SNORT

Vamos a ver cómo funciona Snort en todas sus facetas, instalación y configuración (sistemas Windows),... Más »

Anuncios Google

Autor y licencia de 'Taller de TcpDump / WinDump: Analizando la Red'

Tutorial de Alfon. Extraido de: http://www.nautopia.net CopyLeft

Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador.

Este contenido ha sido recopilado por el equipo de Wikilearning. Todo el contenido recopilado se ha obtenido respetando y comunicando en nuestro site la licencia de cada fuente.

Wikilearning tiene permiso expreso por escrito de los autores para publicar los contenidos que ha extraído de otras webs, incluyendo su uso comercial.