La forma de indicar al TCPDump los datos que queremos filtrar es válida para otros protocolos como ICMP, IP, etc. Lo vemos con un ejemplo.
EJEMPLO 1
Analicemos una cabecera IP:
Vemos "claramente" que el campo protocolo comienza en el byte u octeto 9 (que es el décimo; cada fila del esquema son 4 bytes u octetos y no 3) 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:
- Version, IHL, Type of service y Total Lenght ocupan 4 bytes (del 0 al 3)
- Identification, Flags y Fragment Offset ocupan 4 bytes (del 4 al 7)
- Time to live, Protocol y Header Checksum ocupan 4 bytes (del 8 al 11). Protocol (protocolo) comienza entonces en el byte 9
El campo protocolo puede tomar varios valores, que nos indicará el tipo de protocolo utilizado.
- 1 = ICMP
- 6 = TCP
- 17 = UDP
- 88 = IGRP
Campo PROTOCOLO:
Por defecto existen 4 protocolos de comunicaciones:
-
TCP para comunicaciones fiables -confirmación de la llegada del paquete de datos-.
-
UDP para aquellas no fiables y rápidas (para el DNS -dominio de nombres, a cada dirección IP numérica le corresponde un nombre, como http://nautopia.iespana.es- o utilizado cuando falla el TCP, de ahí que, en algunas aplicaciones con permiso negado, debamos incluir los dos protocolos).
-
ICMP para operaciones de control de errores entre enrutadores o gateways (puertas de enlace), innecesarias habitualmente para internet si se está en monopuesto y conexión directa, sin red local -se están utilizando indebidamente para rastrearnos-.
-
IGMP para el control de los grupos.
|
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 al protocolo de control ICMP.
Nos permite "ver" todo el tráfico de nuestra red que corresponde a paquetes ICMP del tipo que sea.
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
....
- Podemos afinar un poco más y "mirar" sólo un tipo determinado y ya vemos el filtro proto[x:y]= valor aplicado al protocolo ICMP. Por ejemplo, si queremos ver sólo los del tipo "echo request", utilizaremos la misma técnica pero con el protocolo ICMP.
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
- Otro tanto para ver sólo los del tipo "echo reply".
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
EJEMPLO 2
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", osea, 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
CASOS PRÁCTICOS
Combinemos 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, osea 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 "."
