Analizando la red con TCPDump / Windump

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

seguridad es la del análisis de tráfico de dicha red. No sólo el tráfico que fluye a través de
nuestra LAN si no que también debemos analizar el tráfico entrante y saliente hacia internet a
tráves de los servicios que tengamos instalados, proxies, etc. Esto es así porque, como ya
sabeis, es necesario para la detección de problemas y sobre todo para detectar trafico no
esperado, presencia de puertas traseras, escaneos y cualquier otra intrusión.

Existen muchas herramientas que pueden sernos muy últiles dependiendo del S.O. y tipo de
red por ejemplo. Una de estas herramientas, un sniffer de red, basada en la librería de captura
de paquetes (pcap) y que además funciona en plataformas tanto windows como LInux/UNIX es
TCPDump ( Linux ) / Windump ( Windows ) esta última hace uso de la librería Winpcap. Estas
dos librerías son unsadas por otras herramientas como Ethereal o Snort e incluyen un lenguaje
de filtro común para todos. Quizás Windump/TCPDump no sea la herramienta perfecta
atendiendo a la interpretación fácil de los datos reportados, pero si que es de las mejores en
cuanto a su potencia y cantidad de datos de que nosp provee.

Una vez instalada la libreria y el programa en si, tan sólo debemos de introducir en la línea de
comandos: ( haremos referancia a Windump, para windows, aunque casi todo es válido para su
versión Linux.

code:

C:\scan>windump
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A
17:18:16.375082 FIERY.138 > 192.168.4.255.138:
>>> NBT UDP PACKET(138) Res=0x1102 ID=0xE IP=192 (0xc0
0xeb) Port=138 (0x8a) Length=187 (0xbb) Res2=0x0
SourceName=FIERY X2E NameType=0x00 (Workstation)
DestName=
WARNING: Short packet. Try increasing the snap length

17:18:16.679312 INFO2.1027 > INFO8.3233: udp 256

17:18:16.792878 arp who-has FIERY tell INFOGRAFIA3
17:18:16.793204 arp reply FIERY is-at 0:c0:85:27:39:15
17:18:16.793217 INFOGRAFIA3.137 > FIERY.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:18:16.793729 FIERY.137 > INFOGRAFIA3.137:
>>> NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
17:18:16.898314 INFO8.3233 > INFO2.3234: udp 256
17:18:17.185571 0:a0:c9:1c:c1:f5 > Broadcast sap e0 ui/C
>>> Unknown IPX Data: (43 bytes)

vaya, a parte de unas peticiones ARP, parece que no nos enteramos de casi nada. A aparte de
esto windump capturará TODOS los datos de tráfico de nuestra red y puede ser que los datos a
través de la consola vayan tan rápido y de tal cantidad que nos sea imposible discifrar o ver
algo

Veamos entonces como funciona Windump, como interpretar sus datos y como sacar el
máximo partido de el.

NOTA: Esta mini-explicación de windump es muy básica y me saltaré algunas cosas, si hay
interes por este tema pues profundizamos lo que haga falta.

Hay que decir que windump interpreta los datos dependiendo del protocolo involucrado en la
captura, esto es obvio, ya que no es lo mismo una captura de consulta DNS que un inicio de
sesión o establecimiento de conexión TCP o una captura icmp. Aunque las diferencias son
pocas. En una captura icmp aparece la palabra icmp, sin embargo en una captura tcp no
aparece esta palabra.

Veamos el establecimiento de una conexión TCP.

code:

9:24:00.494825 INFOGRAFIA3.1087 > ABANCECOMU.8080: S

2740385268:2740385268(0) w
in 64240 <mss 1460,nop,nop,sackOK> (DF)

09:24:00.495018 ABANCECOMU.8080 > INFOGRAFIA3.1087: S

4260015886:4260015886(0) a
ck 2740385269 win 64240 <mss 1460,nop,nop,sackOK> (DF)

09:24:00.495039 INFOGRAFIA3.1087 > ABANCECOMU.8080: . ack 1

win 64240 (DF)

Estas tres trazan se refieren a un inicio de sesión de TCP. En este caso INFOGRAFIA3 ( que
soy yo mismo ) quiere iniciar una sesion con ABANCECOMU al proxy establecido en el para
consultar una determinda página web usando http. Vemos el modelo de establecimiento de
conexión a tres bandas de forma muy clara.

El formato para la salida de los datos es la siguiente:

fecha src > dst: flags data-sqno ack window urgent options

fecha nos da la hora en que se produjo el evento en formato

hora:minutos:segundos.microsegundos o milisegundos

src y dst son las direcciones IP y puertos TCP/UDP de las conexiones fuente y
destino.

> dirección de flujo de los datos

flags son una combinación de los posibles banderas de un segmento/datagrama TCP/UDP: S

(SYN), F (FIN), P (PUSH), R (RST) y "." (no hay flags).

data-sqno1describe el número de secuencia de la porción de datos.

ack es el número de secuencia del próximo byte que espera recibir el otro extremo TCP/UDP.

window es el tamaño de la ventana que advierte el receptor al transmisor.

urgent indica que hay datos urgentes en ese segmento/datagrama.

options son las opciones TCP que suelen estar entre corchetes del tipo < >, por ejemplo el
tamaño máximo del segmento (ej. <mss 1460,nop,nop,sackOK> )

Hemos dicho que el ejemplo anterior trata de una conmexión TCp. Pero como se realiza esta:

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 (INFOGRAFIA3.1087), envía un paquete

de SYN con un número de secuencia inicial (740385268) y final (740385268) asociado a esta
conexión al sistema / host destinatario o servidor (ABANCECOMU.8080). Como no se
transmiten datos, el numero de secuencia inicial y final son los mismos y los datos 0 (0).

2. Este responde con un paquete SYN-ACK (acuse de recibo) confirmando la recepción del
SYN inicial enviado por (INFOGRAFIA3.1087) y enviándole a su vez su propio número de
secuencia inicial (4260015886) y final (4260015886) y ACK+1 (2740385269).

Estos números de secuencias son absolutos. Windump/TCPDump para no mostrar números

demasiado grandes muestra números desecuencia relativos. En el paso siguiente pasa esto
mismo.

3. Para finalizar, el cliente (INFOGRAFIA3.1087) reconoce la recepción del SYN del servidor
(ABANCECOMU.8080) mediante el envío de un ACK (1). Vemos que hay un "." con lo que
deducimos que no hay flag (en este caso SYN). Este es el momento en que queda establecida
la conexión. Ya se puede iniciar la transferencia de datos entre (INFOGRAFIA3.1087) y
(ABANCECOMU.8080).

Veremos más adelantes capturas de consultas DN0, UDP, escaneos de puertos, troyanos, etc.

Algunas opciones de Windump.

Para ver las interfaces de que disponemos:

code:
C:\scan>windump -D
1.\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
(3Com EtherLink PCI)
2.\Device\Packet_NdisWanIp (NdisWan Adapter)

No queiro que me resuleva los nombres de host.

code:
C:\scan>windump -n

Cantidad de información que nos devuelve.

code:
C:\scan>windump -v o -vv

Filtros de Windump.

Puede ser que no nos interese ver todo el tráfico, sino sólo un determinado protocolo o un sólo
host, etc.

Captura el tráfico de origen y destino sólo en el host INFOGRAFIA3 (se puede poner tambien la
IP)

code:
C:\scan>windump host INFOGRAFIA3

Captura el tráfico de origen host INFOGRAFIA3

code:
C:\scan>windump src host INFOGRAFIA3

Captura todo el tráfico cuyo puerto de destino sea 8080

code:
C:\scan>windump dst port 8080
 windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
09:50:18.618057 INFOGRAFIA3.3039 > ABANCECOMU.8080: S
3194034207:3194034207(0) w
in 64240 <mss 1460,nop,nop,sackOK> (DF)
09:50:18.618224 INFOGRAFIA3.3039 > ABANCECOMU.8080: . ack
1114838386 win 64240 (
DF)
09:50:18.643251 INFOGRAFIA3.3039 > ABANCECOMU.8080: P
0:611(611) ack 1 win 64240
(DF)

Captura todo el tráfico cuyo puerto de origen o destino sea 8080

code:
C:\scan>windump port 8080

Captura todo el tráfico icmp

code:
C:\scan>windump icmp
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
09:53:00.509648 SERVING > 192.168.2.75: icmp: echo request
09:53:00.509729 192.168.2.75 > SERVING: icmp: echo reply
09:53:00.811224 SERVING > INGEN12: icmp: echo request
09:53:00.811410 INGEN12 > SERVING: icmp: echo reply

Combinando filtros.

code:
C:\scan>windump tcp and port 8080 windump: listening
on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-8117
09:55:49.116908 ABANCECOMU.8080 > INFO8.3132: P
1224555679:122455
805272 win 63910
09:55:49.119780 ABANCECOMU.8080 > INFO8.3132: FP
348:802(454) ack
09:55:49.119872 INFO8.3132 > ABANCECOMU.8080: . ack 803 win
7958
09:55:49.211881 INFO8.3132 > ABANCECOMU.8080: F 1:1(0) ack 803
wi
09:55:49.211970 ABANCECOMU.8080 > INFO8.3132: . ack 2 win
63910

Bueno hay muchísimos filtros más y maneras de combinarlos, anidarlos, etc. si el tema este es
de interés podemos seguir adelante.
__________________
Un saludo,
Analizando la red con TCPDump ( Parte II )

Esta es la segunda parte del hilo sobre: Analizando la red con TCPDump
/ Windump que se encuentra en:

Hilo de la primera parte.

Ya comenté que Windump / TCPDump tiene filtros para su mejor manejo. Estos filtros pueden
llegar a ser tan sofisticado como queramos y extrar cualquier tipo de datos de los apquetes que
circulen a través de nuestra red.

Como la mejor manera de explicar el funcionamiento de los filtros es la practica, vamos a

analizar una combinación y encadenamiento de filtros coun un ejemplo:

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 que es lo que pasa.
Vamos a crear un filtro para averiguar las conexionesal puerto 110 de nuestro servidor.

code:
C:\scan>windump -qn -X -s 0 tcp[13] = 2 and port 110

Aquí vemos algunas opciones ya comentadas y otras nuevas:

–q estableceremos 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 amrcas de tiempo, ya que
como veremos más adelante estamos filtrando establecimientos de conexión TCP al puerto
110.

-n no resolver nombres de host

-X vuelca en la consola los datos.

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

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 y simulemos que el flag SYN está activo:

UAPRSF
------------------
00000010
------------------
76543210

vemos que el byte 7 y 6 estánm reservados., el 5 es para URGENT, 4 es para ACK, 3 es para
PUSH, 2 es para RESET y el byte o para FIN. Tenemos entonces el octeto completo. En
binario quedaría como acabamos de ver:

00000010

si pasamos este binario a decimal nos da 2

de ahí viene tcp[13] = 2.

Es facil deducir entonces que para detectar un SYN/ACK:

00010010

si pasamos este binario a decimal nos da 18

entonces tcp[13] = 18

Seguimos con el resto de opciones....

and port 110 esto es que unido a lo anterior analice el puerto 110.

Podriamos añadir que lo hiciera sólo para un dterminado host:

and port 110 and host ALFON.

Usando esta técnica, con windump o tcpdump odríamos detectar escaneos y otras intrusiones
en nuestros sistemas.

Siguiendo con el ejemplo práctico y quitando la opción -X que ahora es irelevante:

C:\scan>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 > 192.168.4.15.110: tcp 0 (DF)
19:11:22.442635 192.168.4.10.3531 > 192.168.4.15.110: tcp 0 (DF)
19:11:29.321747 192.168.2.90.2310 > 192.168.4.15.110: tcp 0 (DF)
19:11:29.350083 192.168.4.9.1392 > 192.168.4.15.110: tcp 0 (DF)
19:11:30.167786 192.168.2.9.1118 > 192.168.4.15.110: tcp 0 (DF)
19:11:40.848757 192.168.2.90.2311 > 192.168.4.15.110: tcp 0 (DF)
19:11:47.603914 192.168.2.70.1400 > 192.168.4.15.110: tcp 0 (DF)
19:11:48.692990 192.168.4.2.2349 > 192.168.4.15.110: tcp 0 (DF)
19:11:48.946846 192.168.4.2.2350 > 192.168.4.15.110: tcp 0 (DF)
19:11:49.167414 192.168.4.2.2351 > 192.168.4.15.110: tcp 0 (DF)
19:11:53.689934 192.168.4.11.2360 > 192.168.4.15.110: tcp 0 (DF)
19:12:21.576147 192.168.2.71.1118 > 192.168.4.15.110: tcp 0 (DF)
19:12:22.885469 192.168.4.10.3532 > 192.168.4.15.110: tcp 0 (DF)
19:12:29.776688 192.168.2.90.2312 > 192.168.4.15.110: tcp 0 (DF)
19:12:29.799274 192.168.4.9.1393 > 192.168.4.15.110: tcp 0 (DF)
19:12:41.142773 192.168.2.90.2313 > 192.168.4.15.110: tcp 0 (DF)
19:12:42.594882 192.168.4.2.2352 > 192.168.4.15.110: tcp 0 (DF)
19:12:42.828622 192.168.4.2.2353 > 192.168.4.15.110: tcp 0 (DF)
19:12:43.060723 192.168.4.2.2354 > 192.168.4.15.110: tcp 0 (DF)
19:12:47.896352 192.168.2.70.1401 > 192.168.4.15.110: tcp 0 (DF)

faltan muchas trazas pero podemos ver en s´lo unas pocas que algunos tenian sus clientes de
correo configurado para "mirar" el correo cad minuto. En la realidad fueron casi todos, con lo
cual tenían el servidor bastante atareadillo.

ETHEREAL:

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, que tanto Etheral como TCPDUMP y WINDUMP se
basan en la misma librería de captura de paquetes y por tanto para filtrara usan la MISMA
sintaxis. Es decir, todo esto que os escribo es válido también para Etheral.
__________________
Un saludo,
Analizando la red con TCPDump ( Parte III )
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:

citar:

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

PHP:

0 1 2 3

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+

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

PHP:

0 1 2 3

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+

|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

__________________
Un saludo,
Analizando la red con TCPDump ( Parte IV )

Casos de estudio.

Analizamos aquí las salidas de TCPDump / Windump ante escaneos básicos nmap y otras
utilidades en la red para su estudio. De esta manera aprenderemos a identificar los problemas
o intrusiones a la red.

Si hay algún problema en identificar el caso concreto dentero de la salida lo comentais y lo

marco en negrita. He añadido algunso datos más para que no sea todo tan fácil :cantar:

code:

C:\scan\nmap3>nmap -sT 192.168.4.15 -p8080 | windump -nt

host 192.168.4.15 and host 192.168.4.3
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
192.168.4.3.43174 > 192.168.4.15.80: . ack 1827959592 win 1024
192.168.4.15.80 > 192.168.4.3.43174: R
1827959592:1827959592(0) win 0
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.1884 > 192.168.4.15.8080: S 189871296:189871296(0)
win 64240 <mss 1460,nop,nop,sackOK> (DF)
192.168.4.15.8080 > 192.168.4.3.1884: S
1772688780:1772688780(0) ack 189871297 win 64240 <mss
1460,nop,nop,sack OK>
192.168.4.3.1884 > 192.168.4.15.8080: . ack 1 win 64240 (DF)
192.168.4.3.1884 > 192.168.4.15.8080: R 189871297:189871297(0)
win 0 (DF)

C:\scan\nmap3>nmap -sS 192.168.4.15 -p8080 | windump -nt

host 192.168.4.15 and host 192.168.4.3
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
192.168.4.3.57766 > 192.168.4.15.80: . ack 185616010 win 3072
arp who-has 192.168.4.3 tell 192.168.4.15
arp reply 192.168.4.3 is-at 0:4:76:f2:c9:5f
192.168.4.15.80 > 192.168.4.3.57766: R 185616010:185616010(0)
win 0
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.57746 > 192.168.4.15.8080: S
565404479:565404479(0) win 3072
192.168.4.15.8080 > 192.168.4.3.57746: S
1818962999:1818962999(0) ack 565404480 win 64240 <mss 1460>
192.168.4.3.57746 > 192.168.4.15.8080: R
565404480:565404480(0) win 0
 C:\scan\nmap3>nmap -sN 192.168.4.15 -p8080 | windump -nt
host 192.168.4.15 and host 192.168.4.3
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
192.168.4.3.57420 > 192.168.4.15.80: . ack 678437475 win 4096
arp who-has 192.168.4.3 tell 192.168.4.15
arp reply 192.168.4.3 is-at 0:4:76:f2:c9:5f
192.168.4.15.80 > 192.168.4.3.57420: R 678437475:678437475(0)
win 0
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.57400 > 192.168.4.15.8080: . win 4096
192.168.4.15.8080 > 192.168.4.3.57400: R 0:0(0) ack 0 win 0

C:\scan\nmap3>nmap -sU 192.168.4.15 -p8080 | windump -nt

host 192.168.4.15 and host 192.168.4.3
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
192.168.4.3.50665 > 192.168.4.15.80: . ack 83760541 win 1024
arp who-has 192.168.4.3 tell 192.168.4.15
arp reply 192.168.4.3 is-at 0:4:76:f2:c9:5f
192.168.4.15.80 > 192.168.4.3.50665: R 83760541:83760541(0) win
0
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.137 > 192.168.4.15.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.4.3.50645 > 192.168.4.15.8080: udp 0
192.168.4.15 > 192.168.4.3: icmp: 192.168.4.15 udp port 8080
unreachable

C:\scan\nmap3>ping 192.168.4.15 | windump -nt host

192.168.4.15 and host 192.168.4.3
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
192.168.4.3 > 192.168.4.15: icmp: echo request
192.168.4.15 > 192.168.4.3: icmp: echo reply
192.168.4.3 > 192.168.4.15: icmp: echo request
192.168.4.15 > 192.168.4.3: icmp: echo reply
192.168.4.3 > 192.168.4.15: icmp: echo request
192.168.4.15 > 192.168.4.3: icmp: echo reply

Identificar protocolos. Descifrando la salida.

UDP

16:33:59.501208 192.168.4.1.520 > 192.168.4.255.520: udp 24

16:34:27.131434 192.168.4.1.137 > 192.168.4.2.137: udp 62
16:34:29.503733 192.168.4.1.520 > 192.168.4.255.520: udp 24
16:34:59.506694 192.168.4.1.520 > 192.168.4.255.520: udp 24
16:35:29.509226 192.168.4.1.520 > 192.168.4.255.520: udp 24

TCP
16:37:34.672005 192.168.4.15.4036 > 192.168.4.1.139: tcp 280
16:37:34.674529 192.168.4.1.139 > 192.168.4.15.4036: tcp 131 (DF)
16:37:34.674949 192.168.4.15.4036 > 192.168.4.1.139: tcp 43
16:37:34.675151 192.168.4.1.139 > 192.168.4.15.4036: tcp 43 (DF)
16:37:34.680743 192.168.4.15.4036 > 192.168.4.1.139: tcp 280

16:39:23.854768 192.168.4.1.139 > 192.168.4.11.2027: . ack 2920 win 8760 (DF)

16:39:23.854973 192.168.4.1.139 > 192.168.4.11.2027: P 1:52(51) ack 4163 win 751

16:39:42.082752 192.168.4.11.2027 > 192.168.4.1.139: . ack 33380 win 8632 (DF)

16:39:55.697455 192.168.4.11.2635 > 192.168.4.1.139: S 1990792:1990792(0) win 81
92 <mss 1460> (DF)
16:39:55.697567 192.168.4.1.139 > 192.168.4.11.2635: S 51131010:51131010(0) ack
1990793 win 8760 <mss 1460> (DF)
16:39:55.697756 192.168.4.11.2635 > 192.168.4.1.139: . ack 1 win 8760 (DF)
16:39:55.697793 192.168.4.11.2635 > 192.168.4.1.139: P 1:73(72) ack 1 win 8760

ICMP

16:45:29.386197 192.168.4.1 > 192.168.4.10: icmp: host 192.168.1.150 unreachable

16:45:29.386430 192.168.4.1 > 192.168.4.10: icmp: host 205.134.xxx.xxx unreachable
16:45:35.160914 192.168.4.1 > 192.168.4.10: icmp: host 192.168.1.151 unreachable
16:45:40.910035 192.168.4.10 > 192.168.4.1: icmp: echo request
16:45:40.910160 192.168.4.1 > 192.168.4.10: icmp: echo reply

ARP

16:51:21.227113 arp who-has 192.168.2.86 tell 192.168.2.60

16:51:21.538845 arp who-has 192.168.2.64 tell 192.168.2.60
16:51:21.850790 arp who-has 192.168.2.76 tell 192.168.2.60
16:51:21.851784 arp who-has 192.168.2.197 tell 192.168.2.60
16:51:21.851863 arp who-has 192.168.2.200 tell 192.168.2.60
16:51:21.857060 arp reply 192.168.2.197 is-at 0:a0:c9:1c:c1:f5

POP3

16:53:43.824474 192.168.2.90.2040 > 192.168.4.15.110: S 1607781:1607781(0) win 8192

<mss 1460> (DF)
16:53:43.824575 192.168.4.15.110 > 192.168.2.90.2040: S 4064642994:4064642994(0) ack
1607782 win 64240 <mss 14
60>
16:53:43.824920 192.168.2.90.2040 > 192.168.4.15.110: . ack 1 win 8760 (DF)
16:53:43.863694 192.168.4.15.110 > 192.168.2.90.2040: P 1:89(88) ack 1 win 64240
16:53:43.864264 192.168.2.90.2040 > 192.168.4.15.110: P 1:17(16) ack 89 win 8672 (DF)
16:53:43.962939 192.168.4.15.110 > 192.168.2.90.2040: P 89:120(31) ack 17 win 64224
16:53:43.963439 192.168.2.90.2040 > 192.168.4.15.110: P 17:33(16) ack 120 win 8641 (DF)
16:53:44.009535 192.168.4.15.110 > 192.168.2.90.2040: P 120:188(68) ack 33 win 64208

SMTP

192.168.4.3.2605 > 192.168.4.15.25: S 3369617405:3369617405(0) win 64240 <mss

1460,nop,nop,sackOK> (DF)
192.168.4.15.25 > 192.168.4.3.2605: S 138683007:138683007(0) ack 3369617406 win 64240
<mss 1460,nop,nop,sackOK
>
192.168.4.3.2605 > 192.168.4.15.25: . ack 1 win 64240 (DF)
192.168.4.15.25 > 192.168.4.3.2605: P 1:42(41) ack 1 win 64240
...
__________________
Un saludo,
Detectando Sniffers en nuestra red (actualizado)

Vamos a tratar aquí la detección de sniffers en nuestra red desde el escenario más básico
posible. Este escenarío sería una subred o red no conmutada.

En entornos Linux o UNIX la verificación de una interface en modo promiscuo se puede hacer
usando ifconfig. Este programa configura la interface de red instalada en un determinado host
y obtiene información de la configuración en el momento de ejecutar el programa. Cuando un
adaptador de red se encuentra en modo promiscuo, ifconfig nos devuelve la siguiente
información:

code:

$ ifconfig -a

eth0 Link Encap: 10Mbps Ethernet HWaddr: xx:xx:xx:xx:xx:xx

inet addr: a.b.c.d Bcast: a.b.c.f Mask: m.m.m.m
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
(OJO: Modo promiscuo).
RX packets: 0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Interrupt:15 Base Address:0x300

Este sistema no es infalible.

Existen programas que pueden hacer esta labor como:

cpm (Check Promiscuous Mode)

Este pequeño programa realizado por la Universidad de Carnegie Mellon, chequea el interfaz
de red de la máquina descubriendo si está siendo utilizado en modo promiscuo (escuchando
todo el tráfico de la red).

code:

$ cpm

4 network interfaces found:

eth0:5: Normal
eth0:3: Normal
eth0:2: Normal
eth0:1: Normal
eth0: *** IN PROMISCUOUS MODE ***

Esisten otros programas como Antisniff, Sentinel, ifstatus o NEPED:

Veamos como trabaja NEPED.

Tenemos que introducir la interface de red:

code:

$ neped eth0
----------------------------------------------------------
> My HW Addr: 00:50:BF:1C:41:59
> My IP Addr: 192.168.0.1
> My NETMASK: 255.255.255.0
> My BROADCAST: 192.168.1.255
 ----------------------------------------------------------
Scanning ....
* Host 192.168.0.3, 00:C2:0F:64:05:FF **** Promiscuous mode
detected !!!
End.

NEPED utiliza la técnica de realizar una simple petición ARP para cada una de las IPs de la red
a diagnosticar, pero ojo, los paquetes no van destinados a broadcast (FF:FF:FF:FF:FF:FF),
sino a una dirección aleatoria e inexistente. Sólo las interfaces en modo promiscuo verán estos
paquetes, y de esta manera, sólo estas interfaces contestarán a estas peticiones.

Existe también un dispositivo de hardware llamado Tap. Este dispositivo permite conectarse a
un Hub o incluso a un switch de red al cual conectáremos un dispositivo (ordenador) para
monitorizar la red. Existen tipos de Taps para cada tipo de red Ethernet 10 Mbps, 100 Mbps y 1
Gbps.
Más información en www.netoptics.com

Otras formas de detectar posibles sniffers

- Detectar y controlar los logs que suelen generar los sniffers.

- Detectar y controlar las conexiones al exterior.

- Monitorizados los programas que acceden al dispositivo de red.

- Normalmente una interface en modo promiscuo, queda reflejada en el fichero de logs:

code:

$ cat /var/log/messages
]

Esto es a grandes rasgos. espero que los usuarios de Linux del foro putualicen o corrigan lo
que haga falta.

Para sistemas Windows exite también programas que detectan una interface en modo
promíscuo.

PromiScan

"PromiScan (www.securityfriday.com) es una utilidad de distribución gratuita diseñada para dar

caza a los nodos promiscuos en una LAN rápidamente y sin crear una carga pesada en la red.
Hay que tener en cuenta que localizar un nodo promiscuo es una tarea ardua, y que en muchos
casos el resultado es incierto; no obstante, PromiScan consigue mostrar cada uno de esos
nodos de una manera transparente, claramente visible. Para usar PromiScan es necesario
contar con Windows 2000 Professional y haber instalado previamente el controlador WinPcap,
cuya versión más reciente se encuentra en netgroup-serv.polito.it/winpcap/."

http://www.securityfriday.com/ToolD...iscan_003.html.

PromiscDetect

code:

C:\scan>promiscdetect

PromiscDetect 1.0 - (c) 2002, Arne Vidstrom

(arne.vidstrom@ntsecurity.nu)
- http://ntsecurity.nu/toolbox/promiscdetect/
 Adapter name:

- NIC PCI 3Com EtherLink XL 10/100 PCI para administraci¾n

completa del equipo
(3C905C-TX)

Active filter for the adapter:

- Directed (capture packets directed to this computer)

- Multicast (capture multicast packets for groups the computer is a
member of)
- Broadcast (capture broadcast packets)
- Promiscuous (capture all packets on the network)

WARNING: Since this adapter is in promiscuous mode there

could be a sniffer
running on this computer!

http://www.ntsecurity.nu/cgi-bin/do...scdetect.exe.pl
http://ntsecurity.nu/downloads/promiscdetect.exe

ProDETECT 0.1 BETA

http://packetstormsecurity.org/Win/prosrc.zip

Otras técnicas de detección

Sólo por nombrarlas y que alguna de ellas son usadas por los programas anti-sniffers:

- Ping de latencia
- Test ARP
- Test DNS
- monitorización SNMP

Protegerse contra la acción de los sniffwers

A grandes rasgos para protegernos de los sniffers y para que estos no cumplan sus objetivos
de olfateo de contraseñas y en general nos " lean datos sensibles" en texto plano, podemos
hacer uso de diversas técnicas o utilizar sistemas como:

- PGP
- SSL
- SSH
- VPN, etc.

y en general el uso de sesiones encriptadas.

Otras consideraciones respecto a la protección contra sniffers pueden ser:

- evitar en lo posible las relaciones de confianza entre maquinas.

- uso de redes conmutadas.

- cambio periódico de claves de accesos y contraseñas.

- hacer copias periódicas de seguridad

A parte de estas consideraciones expongo aquí otras más generales sobre seguridad y no
menos importantes;

- no tener activos servicios innecesarios que no usemos en nuestros sistemas.

- dotar a nuestros sistemas de las últimas actualizaciones en seguridad

- auditorias de seguridad

- uso de firewalls y antivirus

- uso de IDS.

- cuidar diseño de red y separar convenientemente la red interna de la externa

etc.

__________________
Un saludo,