analizando la red con tcpdump

26
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)

Upload: laciana

Post on 23-Jun-2015

559 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Analizando La Red Con TCPDump

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>windumpwindump: listening on\Device\Packet_{604C8AE3-5FAC-45A17:18:16.375082 FIERY.138 > 192.168.4.255.138:>>> NBT UDP PACKET(138) Res=0x1102 ID=0xE IP=192 (0xc00xeb) Port=138 (0x8a) Length=187 (0xbb) Res2=0x0SourceName=FIERY X2E NameType=0x00 (Workstation)DestName=WARNING: Short packet. Try increasing the snap length

17:18:16.679312 INFO2.1027 > INFO8.3233: udp 25617:18:16.792878 arp who-has FIERY tell INFOGRAFIA317:18:16.793204 arp reply FIERY is-at 0:c0:85:27:39:1517:18:16.793217 INFOGRAFIA3.137 > FIERY.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST17:18:16.793729 FIERY.137 > INFOGRAFIA3.137:>>> NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST17:18:16.898314 INFO8.3233 > INFO2.3234: udp 25617: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

Page 2: Analizando La Red Con TCPDump

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) win 64240 <mss 1460,nop,nop,sackOK> (DF)

09:24:00.495018 ABANCECOMU.8080 > INFOGRAFIA3.1087: S 4260015886:4260015886(0) ack 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 formatohora:minutos:segundos.microsegundos o milisegundos

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

> 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

Page 3: Analizando La Red Con TCPDump

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

Page 4: Analizando La Red Con TCPDump

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 8080windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}09:50:18.618057 INFOGRAFIA3.3039 > ABANCECOMU.8080: S 3194034207:3194034207(0) win 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 icmpwindump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}09:53:00.509648 SERVING > 192.168.2.75: icmp: echo request09:53:00.509729 192.168.2.75 > SERVING: icmp: echo reply09:53:00.811224 SERVING > INGEN12: icmp: echo request09: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-811709:55:49.116908 ABANCECOMU.8080 > INFO8.3132: P 1224555679:122455

Page 5: Analizando La Red Con TCPDump

805272 win 6391009:55:49.119780 ABANCECOMU.8080 > INFO8.3132: FP 348:802(454) ack09:55:49.119872 INFO8.3132 > ABANCECOMU.8080: . ack 803 win 795809:55:49.211881 INFO8.3132 > ABANCECOMU.8080: F 1:1(0) ack 803 wi09: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,

Page 6: Analizando La Red Con TCPDump

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:

U A P R S F------------------0 0 0 0 0 0 1 0------------------7 6 5 4 3 2 1 0

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:

0 0 0 0 0 0 1 0

si pasamos este binario a decimal nos da 2

de ahí viene tcp[13] = 2.

Page 7: Analizando La Red Con TCPDump

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

0 0 0 1 0 0 1 0

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 110windump: 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 )

Page 8: Analizando La Red Con TCPDump

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

 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        |

Page 9: Analizando La Red Con TCPDump

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

|                  Options                      |    Padding    |

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

|                              Data                             |

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

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

sequence number= 4 bytes u octeososease 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

 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         |

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

Page 10: Analizando La Red Con TCPDump

|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 camporeservado 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] = 1windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}11:53:19.608992 SERVING > INGEN12: icmp: echo request11:53:19.609176 INGEN12 > SERVING: icmp: echo reply11:53:20.546035 SERVING > 192.168.2.64: icmp: echo request11:53:20.546045 192.168.2.64 > SERVING: icmp: echo reply11:53:20.858635 SERVING > 192.168.2.197: icmp: echo request11:53:20.862108 192.168.2.197 > SERVING: icmp: echo reply11:53:22.108340 SERVING > 192.168.2.3: icmp: echo request11:53:22.108547 192.168.2.3 > SERVING: icmp: echo reply

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

Page 11: Analizando La Red Con TCPDump

....

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

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

C:\scan>windump icmp[0] = 8windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}11:59:19.610921 SERVING > INGEN12: icmp: echo request11:59:20.548039 SERVING > 192.168.2.64: icmp: echo request11:59:20.860784 SERVING > 192.168.2.197: icmp: echo request11:59:22.113748 SERVING > 192.168.2.3: icmp: echo request11:59:22.422977 SERVING > 192.168.2.91: icmp: echo request11: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] = 0windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}12:37:47.559653 ABANCECOMU > TALLER: icmp: echo reply12:37:47.560038 ADMIN02 > TALLER: icmp: echo reply12:37:47.561493 CCZ > TALLER: icmp: echo reply12:37:47.567877 FIERY > TALLER: icmp: echo reply12: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] != 0windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}12:41:47.484354 ABANCE-2 > TALLER: icmp: host 192.168.1.150 unreachable12:41:47.486477 ABANCE-2 > TALLER: icmp: host 205.134.182.163 unreachable12:41:47.856538 ABANCE-2 > TALLER: icmp: host 192.168.1.151 unreachable12:41:48.358227 ABANCE-2 > INFOGRAFIA3: icmp: host 192.168.1.150 unreachable12: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:

Page 12: Analizando La Red Con TCPDump

C:\scan>windump tcp[13] = 0 and dst host INFOGRAFIA3windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81119: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,

Page 13: Analizando La Red Con TCPDump

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.3windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}192.168.4.3.43174 > 192.168.4.15.80: . ack 1827959592 win 1024192.168.4.15.80 > 192.168.4.3.43174: R 1827959592:1827959592(0) win 0192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.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.3windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}192.168.4.3.57766 > 192.168.4.15.80: . ack 185616010 win 3072arp who-has 192.168.4.3 tell 192.168.4.15arp reply 192.168.4.3 is-at 0:4:76:f2:c9:5f192.168.4.15.80 > 192.168.4.3.57766: R 185616010:185616010(0) win 0192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.57746 > 192.168.4.15.8080: S 565404479:565404479(0) win 3072192.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

Page 14: Analizando La Red Con TCPDump

C:\scan\nmap3>nmap -sN 192.168.4.15 -p8080 | windump -nt host 192.168.4.15 and host 192.168.4.3windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}192.168.4.3.57420 > 192.168.4.15.80: . ack 678437475 win 4096arp who-has 192.168.4.3 tell 192.168.4.15arp reply 192.168.4.3 is-at 0:4:76:f2:c9:5f192.168.4.15.80 > 192.168.4.3.57420: R 678437475:678437475(0) win 0192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.57400 > 192.168.4.15.8080: . win 4096192.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.3windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}192.168.4.3.50665 > 192.168.4.15.80: . ack 83760541 win 1024arp who-has 192.168.4.3 tell 192.168.4.15arp reply 192.168.4.3 is-at 0:4:76:f2:c9:5f192.168.4.15.80 > 192.168.4.3.50665: R 83760541:83760541(0) win 0192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.137 > 192.168.4.15.137:>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST192.168.4.3.50645 > 192.168.4.15.8080: udp 0192.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.3windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}192.168.4.3 > 192.168.4.15: icmp: echo request192.168.4.15 > 192.168.4.3: icmp: echo reply192.168.4.3 > 192.168.4.15: icmp: echo request192.168.4.15 > 192.168.4.3: icmp: echo reply192.168.4.3 > 192.168.4.15: icmp: echo request192.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 2416:34:27.131434 192.168.4.1.137 > 192.168.4.2.137: udp 6216:34:29.503733 192.168.4.1.520 > 192.168.4.255.520: udp 2416:34:59.506694 192.168.4.1.520 > 192.168.4.255.520: udp 2416:35:29.509226 192.168.4.1.520 > 192.168.4.255.520: udp 24

Page 15: Analizando La Red Con TCPDump

TCP

16:37:34.672005 192.168.4.15.4036 > 192.168.4.1.139: tcp 28016: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 4316: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 8192 <mss 1460> (DF)16:39:55.697567 192.168.4.1.139 > 192.168.4.11.2635: S 51131010:51131010(0) ack1990793 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 unreachable16:45:29.386430 192.168.4.1 > 192.168.4.10: icmp: host 205.134.xxx.xxx unreachable16:45:35.160914 192.168.4.1 > 192.168.4.10: icmp: host 192.168.1.151 unreachable16:45:40.910035 192.168.4.10 > 192.168.4.1: icmp: echo request16: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.6016:51:21.538845 arp who-has 192.168.2.64 tell 192.168.2.6016:51:21.850790 arp who-has 192.168.2.76 tell 192.168.2.6016:51:21.851784 arp who-has 192.168.2.197 tell 192.168.2.6016:51:21.851863 arp who-has 192.168.2.200 tell 192.168.2.6016: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 1460>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 6424016: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 6422416: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)

Page 16: Analizando La Red Con TCPDump

192.168.4.15.25 > 192.168.4.3.2605: P 1:42(41) ack 1 win 64240... __________________Un saludo,

Page 17: Analizando La Red Con TCPDump

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: Normaleth0:3: Normaleth0:2: Normaleth0:1: Normaleth0: *** 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----------------------------------------------------------

Page 18: Analizando La Red Con TCPDump

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

Page 19: Analizando La Red Con TCPDump

C:\scan>promiscdetect

PromiscDetect 1.0 - (c) 2002, Arne Vidstrom ([email protected]) - 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.plhttp://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:

Page 20: Analizando La Red Con TCPDump

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

Page 21: Analizando La Red Con TCPDump