En múltiples ocasiones hemos hablado en este blog de tshark como herramienta de análisis forense de red. Esta herramienta proporciona una versatilidad que se va ampliando con cada nueva versión, donde se le añaden nuevos filtros y mejoras.
Supongamos que nos encontramos analizando un incidente de seguridad en el que tenemos tráfico hacia varios servidores ubicados detrás de una misma dirección IP. Debido a esto, no se puede filtrar por dirección IP así que hay que buscar otra solución. En este artículo voy a mostrar una manera de extraer únicamente aquellos paquetes que están relacionados con un servidor (host) y no con una dirección IP.
Para ilustrar el ejemplo voy a utilizar un archivo de captura de tráfico en formato PCAP descargado desde NETRESEC de una máquina infectada con W32/Sdbot, proporcionado por Russ McRee.
Cuando estamos analizando tráfico hacia un servidor web podemos ver los paquetes enviados por el cliente utilizando el filtro “http.host==
El problema es que únicamente se muestran los enviados hacia el servidor, ya que se basa en el parámetro Host de la cabecera HTTP. En el caso en el que queramos capturar también la respuesta podremos utilizar el filtro tcp.stream pero debemos hacer un paso previo; para ello recordaremos este filtro.
El filtro “tcp.stream” es un valor que tshark asigna a los paquetes en función del flujo TCP al que pertenecen, así aquellos paquetes que formen parte de una misma conversación o flujo TCP tendrán el mismo valor.
La idea que pretendemos llevar a cabo es identificar los flujos TCP que vayan dirigidos al host que queremos para, posteriormente, extraer todos los paquetes que sean de esos flujos TCP, no sólo las peticiones HTTP.
Primero listamos el flujo TCP de los paquetes dirigidos al host:
Ahora un poquito de Kung-Fu, y listo:
Lo que se ha hecho en la captura anterior es obtener el mismo listado y realizar otra búsqueda utilizando el filtro tcp.stream con esos valores, por tanto recorremos el archivo un número de veces igual al número de flujos anterior y creamos un archivo (stream{n}.pcap) por cada uno de ellos. Finalmente, se fusionan en un único archivo PCAP con mergecap, llamado www_age_ne_jp.pcap.
Para ver que no sólo tenemos las peticiones al servidor sino también las respuestas de éste, mostramos el contenido del archivo:
Para comprobar que las peticiones son hacia el servidor que queremos mostramos únicamente los campos de dirección IP origen y destino, el host al que va dirigida la petición HTTP y el flujo TCP al que corresponden (el valor tcp.stream varia porque es relativo al propio archivo PCAP, no obstante se puede comprobar que el número de flujos es el mismo):
Por último, como nota añadida a esta manera de extraer aquellos paquetes que nos interesan, recalcar que el archivo se procesa un número de veces igual al de flujos que devuelva la operación anterior. Esto, si el archivo con el que estamos trabajando es muy pesado, puede sobrecargar el sistema.
Para evitar esto, en lugar de utilizar el filtro para un único flujo, se encadenan todos los filtros con un OR y así sólo procesamos el archivo una única vez, aunque se hagan más comprobaciones.
Mientras que el tiempo para ejecutar el comando de la primera manera es:
Quizá éste archivo no sea el mejor ejemplo ya que su tamaño es pequeño, aunque se puede apreciar que se reduce en más de una quinta parte el tiempo real de proceso.
Por experiencia propia, en una búsqueda similar en un archivo de 4 GB la diferencia está entre tres minutos para su ejecución con la primera opción, y no terminar tras más de una hora con la segunda.
Espero que os sirva para futuras búsquedas.
El libro que me gustaría comentar ha caído hace pocos días en mis manos y se titula “
