Daboweb

Herramientas para la interpretación de capturas de red. (8/10)

Publicado por Alfon on Mayo 04, 2011
Seguridad Informática

En anteriores entregas:

Presentación | Parte 1 | Parte 2 | Parte 3 | Parte4 | Parte 5 | Parte 6 | Parte 7

Wireshark III Parte.


En la segunda parte del artículo dedicado a Wireshark, aprendimos: Como salvar los datos de captura. Opciones de captura y salvado múltiple. Navegación por las capturas múltiples. Ring buffer. Truncado de paquetes. Extracción de binarios y uso de Follow TCP Stream. Extracción objetos HTTP.
Estadísticas Wireshark. Estadísticas Service Response Time.
Estadísticas Flow Graph. Otras estadísticas. Estadísticas gráficas. IO Graph y Gráficas tcptrace.

En esta ocasión vamos a ver:

  • Geolocalización con Wireshark. GeoIP y filtros.
  • El lenguaje Lua.
  • Mensajes se error u otros en wireshark; TCP segment of a reassembled PDU y otros.
  • Uso remoto de Wireshark.

Vamos a ello…

Geolocalización con Wireshark. GeoIP y filtros.

GeoIP es un recurso que nos sirve para, a partir de una determinada IP, saber la ubicación geográfica correspondiente. Podemos usar GeoIP con ASP, con APIs, puede integrarse en un Web Server, etc. Pero lo más importante para nosotros es su integración con Wireshark. Para ello usaremos la versión gratuíta GeoLite.

Descarga y ubicación de bases de datos GeoIp.

Necesitamos las siguientes bases de datos:

Configuración  Wireshark para GeoIP.

En el menú Edit > Preferences > Name Resolution, a la derecha tenemos GeoIP database directories, pulsamos el botón Edit y se nos  abre una ventana GeoIP Database Paths, pulsamos New e introducimos la ruta (C:\Archivos de programa\Wireshark\goip) donde descargamos las base de datos GeoIP:

Ahora nos situamos dentro de la ventana de detalles del protocolo, en Internet Protocol, botón derecho del ratón y Protocol preferences marcamos la opción Enable GeoIP lookups:

 

Visualización de los datos GeoIP de una captura.

Realizamos una captura o abrimos un fichero de captura previamente grabado.

En el menú Statistics > Endpoints, se nos abre la ventana en la cual seleccionamos la pestaña IPv4. Veremos como se han añadido a las columnas por defecto, otras como:

  • Country
  • AS Number
  • City
  • Latitude
  • Longitude

todas correspondiente a los datos obtenidos a través de la Geolocalización de GeoIP / GeoLite.

NOTA: En esta captura desplazo la barra para ver solo los datos de GeoIP. pero tenemos las IP (Address), Paquetes, Bytes, etc, etc :

En esta misma ventana de Endpoints, vemos un botón: Map. Si pulsamos en Map, se nos abrirá nuestro navegador por defecto desplegando un mapa (similar a google maps) con la localización geográfica de las IP:

 

Filtros GeoIP para Wireshark y Tshark.

filtro                      | tipo de cadena | descripción |             versión wireshark

ip.geoip.asnum String Source or Destination GeoIP AS Number 1.2.1 to 1.2.2
ip.geoip.city String Source or Destination GeoIP City 1.2.1 to 1.2.2
ip.geoip.country String Source or Destination GeoIP Country 1.2.1 to 1.2.2
ip.geoip.dst_asnum String Destination GeoIP AS Number 1.2.1 to 1.2.2
ip.geoip.dst_city String Destination GeoIP City 1.2.1 to 1.2.2
ip.geoip.dst_country String Destination GeoIP Country 1.2.1 to 1.2.2
ip.geoip.dst_isp String Destination GeoIP ISP 1.2.1 to 1.2.2
ip.geoip.dst_lat String Destination GeoIP Latitude 1.2.1 to 1.2.2
ip.geoip.dst_lon String Destination GeoIP Longitude 1.2.1 to 1.2.2
ip.geoip.dst_org String Destination GeoIP Organization 1.2.1 to 1.2.2
ip.geoip.isp String Source or Destination GeoIP ISP 1.2.1 to 1.2.2
ip.geoip.lat String Source or Destination GeoIP Latitude 1.2.1 to 1.2.2
ip.geoip.lon String Source or Destination GeoIP Longitude 1.2.1 to 1.2.2
ip.geoip.org String Source or Destination GeoIP Organization 1.2.1 to 1.2.2
ip.geoip.src_asnum String Source GeoIP AS Number 1.2.1 to 1.2.2
ip.geoip.src_city String Source GeoIP City 1.2.1 to 1.2.2
ip.geoip.src_country String Source GeoIP Country 1.2.1 to 1.2.2
ip.geoip.src_isp String Source GeoIP ISP 1.2.1 to 1.2.2
ip.geoip.src_lat String Source GeoIP Latitude 1.2.1 to 1.2.2
ip.geoip.src_lon String Source GeoIP Longitude 1.2.1 to 1.2.2
ip.geoip.src_org String Source GeoIP Organization 1.2.1 to 1.2.2

Un ejemplo de aplicación podría ser el siguiente:

ip.geoip.country == “Spain” && ip.geoip.city contains “Barcelona”

Wireshark nos mostrará también la información GeoIP en la misma ventana de protocolos, en un campo denominado Source GeoIP:

 

Sobre Geolocalización de eventos portscan, tenéis más información aquí:

Prelude IDS / IPS. Geolocalización de eventos de scan de puertos con Prelude-correlator y PortscanGeoinfo.

 

Wireshark, Tshark y el Lenguaje Lua.

Lua es un lenguage de programación extensible diseñado para una programación procedimental general con utilidades para la descripción de datos. También ofrece un buen soporte para la programación orientada a objetos, programación funcional y programación orientada a datos. Se pretende que Lua sea usado como un lenguaje de script potente y ligero para cualquier programa que lo necesite. Es un lenguaje embebido en una aplicación. A parte de Tshark y Wireshark, también lo usa Snort en la proxima generación de este IDS, la V 3.0.

Es decir, que a la ya potente herramienta de captura y análisis de paquetes Tshark podemos añadir la todo el potencial de un lenguaje de programación para extraer todos los datos que necesitemos.

Comenzando con Lua

Antes que nada, para usar Lua tenemos que editar el fichero lua.ini que se encuentra en:

C:\Archivos de programa\Wireshark

En este archivo se encuentra la siguiente línea:

disable_lua = true; do return end;

y la cambiamos por:

disable_lua = false; do return end; 

Salvamos y listo.

La sintáxis para usar un script de Lua es:

-Xlua_script:nombrefichero.lua

Vamos entonces a crear nuestreo primer ejemplo. El más básico:

-- Hola.lua
-- Mi primer ejemplo programa con Lua
print("Hola mundo!")

Lo llamaremos hola.lua, guardamos e invocamos desde Tshark:

Ahora vamos con algo más prácticopara ilustrar el funcionamiento de witreshark / Tshark con Lua, por ejemplo un contador de paquetes. Lo llamaremos contador.lua:

do
packets = 0;
local function init_listener()

local tap = Listener.new(“frame”,”ip.addr == 192.168.1.30″)
function tap.reset()

packets = 0;

end
function tap.packet(pinfo,tvb,ip)

packets = packets + 1

end
function tap.draw()
print(“Paquetes desde/hacia 192.168.1.30”,packets)
end
end

init_listener()

end

 

Ejecutamos el script de Lua:

Más sobre Lua:
http://www.wireshark.org/docs/wsug_html_chunked/wsluarm.html#wsluarm_intro

 

Mensajes se error y otros tipos de mensajes en Wireshark.

Veremos uno de cada tipo.

TCP segment of a reassembled PDU

En muchos casos el emnsaje TCP segment of a reassembled PDU puede inducir erróneamente a pensar que se trata de error. Nada más lejos de la realidad.

Tenemos la siguiente capatura con varios de estos mensajes:

Aplicamos el siguiente filtro para visualizar solo los paquetes afectados po este tipo de mensajes:

tcp.reassembled_in

Detalle de uno de estos mensajes:

Reseñado en rojo vemos Reassembled PDU in frame 19225, bien, vamos al frame o paquete 19225. quitemos el filtro anterior y buscamos el frame o aplicamos el filtro: tcp.segments:

vemos que se nos informa de que el frame 19255 es un paquete reensamblado formado por una lista de segmentos, entre ellos el que elegimos al principio.

¿ Y que significa esto. ?. Sencillamente que en el paquete 19225 Wireshark a concatenado una serie de segmento mostrando en el toda la información completa.

No se trata de ningún error.

Básicamente. En ocasiones los paquetes vienen “fragmentados” en unidades Protocol Data Units (PDU) y Wireshark los reensambla enun nivel más alto, en este caso, http.

 

Error TCP Bad Checksum

Ocurre en ocasiones que, cuando analizamos los paquetes capturados en una sesión Wireshark, nos encontramos una serie de errores que por su número y/o descripción parece que tenemos un problema grave en un host o en la red. Por ejemplo:

Pues bien, vamos a ver que significa este tipo de mensaje y como podemos solucionarlo. Una vez que hemos detectado el error, vamos a analizar unos de los paquetes con TCP Bad Checksum:

Tenemos una pista. Wireshark interpereta que puede tratarse de TCP checksum offload. ¿ Pero que es esto exactamente ?.

En la gran mayoría de implementaciones de la pila de protocolos el checksum de los segmentos TCP o datagramas UDP salientes no los realiza la CPU. Esta funciónestá encomendada a la tarjeta de red. Esto es así para reducir la carga de la CPU y que de esta forma aumente el rendimiento de host.

Pero hay un problema y es que Wireshark no puede comprobar el checksum de los paquetes salientes. Literalmente no le da tiempo a comprobar este valor. Cuando se coloca el valor del campo el paquete correspondiente ya no se encuentra, así que devuelve un error por incorrecto.

Entonces, ¿ como podemos solucionarlo ?. Existen dos métodos. Uno es desactivar esta función de la tarjeta de red, pero provocará un rendimiento bajo. El segundo método y el más correcto es configurar wireshark para que no compruebe este campo.  Esto lo haremos de la siguiente forma:

EditPreferences > Desplegamos la lista de protocolos y elegimos TCP:

En las tarjetas de red y en el caso de las Broadcom NetXtrem Ggigabit el parámetro “Checksum Offload” (Descarga de suma de comprobación) se desactiva en las propiedades avanzadas de la NIC o tarjeta de red.

Entre los prosible valores de la propiedad Checksum Offload de la Tarjeta tenemos:

  • Rx TCP/IP Checksum (Suma de comprobación de TCP/IP Rx): activa la recepción de la descarga de suma de comprobación de TCP, IP y UDP
  • Tx TCP/IP Checksum (Suma de comprobación de TCP/IP Tx): (valor predeterminado) activa la transmisión de la descarga de suma de comprobación de TCP, IP y UDP
  • Tx/Rx TCP/IP Checksum (Suma de comprobación de TCP/IP Tx/Rx): activa la transmisión y recepción de la descarga de suma de comprobación de TCP, IP y UDP
  • None (ninguno) – desactiva la descarga de la suma de comprobación y es la que elegiremos.

Aunque, como ya he comentado más arriba, no es la mejor opción por la disminución de rendimiento.

 

Uso de captura remota con Wireshark.

Para ello usaremos la utilidad RPCAPD que es una herramienta que nos sirve para conetarnos a una interfaz de red en un host remoto. Se encuentra por defecto en C:\Archivos de programa\WinPcap.

Veremos como realizar una captura remota en unos sencillos pasos.

Preparando el host remoto.

El host remoto B tendrá la IP 192.168.1.30

Para capturar desde un host local A a nuestro host remoto B, necesitamos saber que dispositivo o interfaz de red vamos a usar del host remoto B en la captura. Para ello tan sencillo como, entre otras formas, usar Tshark en el host remoto B para el descubrimiento de dicha información. Como ya vimos en anteriores capítulos de esta serie, lo haremos con:

tshark -D

La interfaz que nos interesa es la número 4 que está reseñada. Copiamos o volcamos la información a un archivo de texto para luego usarla en Wireshark.

Para terminar la preparación del host remoto B, una vez tenemos la información anterior, tan solo nos hace falta dejar RPCAPD escuchando en el host remoto B en el puerto 3333:

Con -n le decimos que no pida autentificación. La opción -p3333 es para indicar el puerto a la escucha.

aunque hemos indicado la opción -n, es mejor usar, por motivos de seguridad: Password authentication.

También podemos:

  • Guardar la configuración de RPCAPD en un archivo (rpcapd.ini) con la opción -s y cargar ese mismo fichero con -f
  • Con la opción -b de RPCAPD podemos decir que eschuche y comunique con un determinado host o hacerlo a través de una lista blanca -l
  • Con la opción –d podemos usar RPCAPD como servicio en sistemas win32.

Preparación del host local para la captura con Wireshark.

El host local A tendrá la IP 192.168.1.5

Ejecutamos Wireshark. Introducimos los datos necesarios:

Le damos a OK. Y ahora tenemos que introducir el nombre del dispositivo de red del host remoto B que descubrimos anteriormente con Tshark -D. Lo haremos usando esta forma (en negrita el nombre del dispositivo):

rpcap://192.168.1.30:3333/\Device\NPF_{58C21E09-0C1F-4F85-9463-12328CA28B9A}

Lo vemos mejor:

Reseñado está lo que hemos introducido en el campo de la interface. Esto lo podemos hacer escribiendo directamente en el campo.

Pulsamos ahora el botón Remote Setting y decimos a Wireshark que no capture el tráfico RPCAP:

OK y en el panel principal pulsamos Start.

Y capturamos a traves de Wireshark todo el tráfico de red de la interfaz remota Device\NPF_{58C21E09-0C1F-4F85-9463-12328CA28B9A} del host local A a host remoto B tal como podemos comprobar en la barra de título arriba:

 

Sobre captura remota usando Tshark y para Linux tenéis más información:

Windump / Tshark. Captura de red de forma remota en Linux.

 

.

Y hasta aquí esta II parte de wireshark.

Tags: , , ,

¿Quieres comentar algo sobre este post? Puedes hacerlo en nuestro foro de noticias.

Puedes seguir nuestras actualizaciones vía RSS, en Facebook y también desde Twitter.