La duda más generalizada fue referente a este párrafo:
Cita:
De donde coño saque eso de que los indicadores o flags TCP comienzan en el octeto 13. "....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....."
Vamos a echarle un ojo a ese 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
