Analizando la red con TCPDump ( Parte III )

[Alfon]

Esta tercera parte es más bien una aclaración de conceptos para los que me enviarón sus dudas por mail y de paso avanzar un poco más.

La duda más generalizada fue referente a este párrafo:

"....tcp[13] = 2 esta es la madre del cordero. con este filtro estamos diciendo a windump que queremos escoger los paquetes TCP cuyo indiccador, bandera o flag sea SYN "S". Para entender esto hay que tener en cuenta como es el formato de un paquete TCP, que los indicadores o flags se encuentran en el octeto 13.
Vamos a echarle un ojo a ese octeto 13....."

De donde coño saque eso de que los indicadores o flags TCP comienzan en el octeto 13.

Vamos a ello.

Código PHP:

   0                   1                   2                   3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|          Source Port          |        Destination Port       | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                         Sequence Number                       | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                      Acknowledgement Number                   | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Offset |  Reserver |U|A|P|R|S|F|             Window            | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|           Checksum            |         Urgent Pointer        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                  Options                      |    Padding    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                              Data                             | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   

source port= 2 bytes u octetos o 16 bits
destination port = 2 bytes u octetos
la cuenta siempre empieza por el 0
con lo cual los octetos van del 0 al 3

sequence number= 4 bytes u octeos
osease del 4 al 7

acknowledgement number= 4 bytes u octeos del 8 al 11

ya tenemos 12 bytes u octeos

vamos ahora a la parte que nos interesa el siguiente octeo, el 12 va desde el bits 0 al 7 que corresponde al offset y a reserver, dos bits de reserver pertenencen ya al siquiente octeo el 13 que tiene 2 bits reservados y 6 que son los flags. 6 + 2 = 8 bits que el el octeto o byte 13.


Esto no sólo es válido para la cabecera y datos TCO, también para IP, UDP e ICMP. Veamos un ejemplo.

Analicemos una cabecera IP.

Código PHP:

   0                   1                   2                   3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Versión|  IHL  | Tipo Servicio |         Longitud Total        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|         Identificación        |Flags|        Posición         | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Tiempo de Vida |   Protocolo   | Suma de Control de Cabecera   | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                       Dirección de Origen                     | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                       Dirección de Destino                    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                    Opciones                   |    Relleno    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   

Vemos claramente que el campo protocolo comienza en el byte u octeo 9 y tiene 8 bits.

Entonces si a un filtro de tcpdump ponemos ip[9] le estamos diciendo que
"mire" dentro del datagrama IP a partir del octeto o byte 9 que es el campo
reservado al protocolo. El campo protocolo puede tomar varios valores:

1 = ICMP, 6 = TCP, 17 = UDP, 88 = IGRP

entonces vamos a nuestro filtro y añadimos:

ip[9] = 1 le estamos diciendo que "mire" dentro del datagrama IP a partir del octeto o byte 9 el valor = 1 que corresponde a ICMP

lo vemos en la practica:

C:\scan>windump ip[9] = 1
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
11:53:19.608992 SERVING > INGEN12: icmp: echo request
11:53:19.609176 INGEN12 > SERVING: icmp: echo reply
11:53:20.546035 SERVING > 192.168.2.64: icmp: echo request
11:53:20.546045 192.168.2.64 > SERVING: icmp: echo reply
11:53:20.858635 SERVING > 192.168.2.197: icmp: echo request
11:53:20.862108 192.168.2.197 > SERVING: icmp: echo reply
11:53:22.108340 SERVING > 192.168.2.3: icmp: echo request
11:53:22.108547 192.168.2.3 > SERVING: icmp: echo reply

11:53:22.420849 SERVING > 192.168.2.91: icmp: echo request
11:53:22.421046 192.168.2.91 > SERVING: icmp: echo reply
11:53:24.608394 SERVING > CCLOPEZ: icmp: echo request
11:53:24.608663 CCLOPEZ > SERVING: icmp: echo reply
11:53:42.942371 TALLER > 192.168.1.150: icmp: echo request
11:53:42.942476 ABANCE-2 > TALLER: icmp: host 192.168.1.150 unreachable
11:53:42.944944 TALLER > 205.134.182.163: icmp: echo request
11:53:42.945017 ABANCE-2 > TALLER: icmp: host 205.134.182.163 unreachable
11:53:42.947160 TALLER > ABANCECOMU: icmp: echo request
....

estamos "viendo" todo el tráfico de nuestra red que corresponde a
paquetes ICMP de ltipo que sea.

Podemos afinar un poco más y "mirar" sólo un tipo determinado:


C:\scan>windump icmp[0] = 8
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
11:59:19.610921 SERVING > INGEN12: icmp: echo request
11:59:20.548039 SERVING > 192.168.2.64: icmp: echo request
11:59:20.860784 SERVING > 192.168.2.197: icmp: echo request
11:59:22.113748 SERVING > 192.168.2.3: icmp: echo request
11:59:22.422977 SERVING > 192.168.2.91: icmp: echo request
11:59:24.300615 SERVING > CCLOPEZ: icmp: echo request

vemos sólo los del tipo "echo request" utilizando la misma técnica pero con el protocolo icmp.

C:\scan>windump icmp[0] = 0
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
12:37:47.559653 ABANCECOMU > TALLER: icmp: echo reply
12:37:47.560038 ADMIN02 > TALLER: icmp: echo reply
12:37:47.561493 CCZ > TALLER: icmp: echo reply
12:37:47.567877 FIERY > TALLER: icmp: echo reply
12:37:47.576310 INFO8 > TALLER: icmp: echo reply

vemos sólo los del tipo "echo reply".

Un pasito más y vemos otra forma más de crear filtros tcpdump.

Veamos en el siguiente ejemplo una condición de negación.

si usamos != estamos diciendo a windump que "no sea igual a":

en este ejemplo queremos ver los paquetes que NO sean del tipo "echo reply" o "echo request", osease, el resto.

C:\scan>windump icmp[0] != 8 and icmp[0] != 0
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
12:41:47.484354 ABANCE-2 > TALLER: icmp: host 192.168.1.150 unreachable
12:41:47.486477 ABANCE-2 > TALLER: icmp: host 205.134.182.163 unreachable
12:41:47.856538 ABANCE-2 > TALLER: icmp: host 192.168.1.151 unreachable
12:41:48.358227 ABANCE-2 > INFOGRAFIA3: icmp: host 192.168.1.150 unreachable
12:41:49.858193 ABANCE-2 > INFOGRAFIA3: icmp: host 192.168.1.150 unreachable

Combinamos algunas opciones de windump.

todos los ICMP tipo echo request con destino al host ABANCE-2

C:\scan>windump icmp[0] = 8 and dst host ABANCE-2

Detectando escaneos

Si realizamos un Null Scan con nmap, osease sin ningún flag activado:

nmap -sN INFOGRAFIA3 -P139

obtendremos con tcpdump:

C:\scan>windump tcp[13] = 0 and dst host INFOGRAFIA3
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-811
19:03:12.630859 ABANCECOMU.35366 > INFOGRAFIA3.139: . win 2048

vemos el filtro aplicado tcp[13] = 0 y la respuesta de tcpdump con el indicador de flag indicando, valga la redundancia, que no hay flags activados "."

Ea, hasta la próxima

[trenkos]

Este manual es genial.
Me he registrado unicamente para felicitar al autor.
Señor, dediquece a la docencia. Tiene futuro.