En esta ocasión una herramienta algo diferente a las demás: netsniff-ng.  Principalmente porque no le hace falta las típicas librerías libpcap, aunque se pueden tratar archivos en formato .pcap, tiene un modo de ejecución de alto rendimiento y la salida tampoco se ajusta a lo visto, por ejemplo, con tshark, windump, TCPDump, argus, bro, etc. Vermos también, a lo largo de otros capítulos, alguans de las herramienta que acompañan.

Lo vemos.

Instalación netsniff-ng

wget http://www.netsniff-ng.org/pub/netsniff-ng/netsniff-ng-0.5.5.0.tar.gz
tar zxf netsniff-ng-0.5.5.0.tar.gz
cd netsniff-ng
cd src
make
sudo make install

Listo, ya está instalado.

Uso básico de netsniff-ng.

El uso más básico pasa por indicar una interface de red (-d) o un fichero .pcap (-i). Una lista de las interfaces que tenemos disponible con -I.

Pero hay mucho más. Lo primero es analizar como es la salida de netsniff-ng. Para ello capturamos desde la inteface de red y realizamos un sencillo ping:

sudo netsniff-ng -deth0

Un momento. Me surge un problema. Estoy conectado mediante SSH al host donde se encuentra netsniff-ng, así que este capturará también todo el tráfico SSH. Para que capture solo ICMP, habrá que aplicar algún filtro.

Los filtros netsniff-ng son en formato BPF (Berkley Packet Filter), pero además deben ser introducidos en un fichero para leerlo mediante -f. Netsniff-ng disponen en /etc/netsniff-ng/rules de una serie de ficheros preconfigurados para diferentes protocolos. En mi caso usaré: icmp.bpf. Así pues la línea de comandos quedará:

sudo netsniff-ng -deth0 -f /etc/netsniff-ng/rules/icmp.bpf

Aunque también podríamos haber aplicado otro filtro más adecuando: not_ssh.bpf.

Observad bien el resultado porque aquí radica una de las  diferencias con otros sniffers tipo tcpdump. Para entenderlo mejor, más abajo lo compraremos con una salida Wireshark:

En verde tenemos el parseado del filtro BPF, en azul el icmp echo request y en rojo icmp echo reply.

Vemos el echo request:

< 74 Byte, Unix TS (1320998570 s 537387 us), Fri Nov 11 09:02:50 2011
 [ MAC (00:04:75:ed:89:df => 00:14:22:5e:cc:af), Proto (0x0800, IPv4) ]
 [ Vendor (3 Com Corporation => Dell Inc.) ]
 [ IPv4 Addr (192.168.1.5 => 192.168.1.96), Proto (1), TTL (128),
   TOS (0), Ver (4), IHL (1280), Tlen (60), ID (37204),
   Res: 0 NoFrag: 0 MoreFrag: 0 offset (0), Chsum (0x25b7) is ok ]
 [ ICMP Type (8), Code (0), Chsum (0x415c) ]
 [ Payload hex  (61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68
   69 ) ]
 [ Payload char (a b c d e f g h i j k l m n o p q r s t u v w a b c d e f g h i ) ]

Lo primero que se observa es que esta salida se asemeja, en modo texto, a la zona de detalle de paquete en Wireshark:

De esta forma, netsniff-ng mestra de forma estructurada todos los datos del paquete incluído el payload, campos de protocolo, etc.

Si no queremos que aparezca el payload, añadimos -N.

Observad parte el payload (Data), marcado en azul en la captura Wireshark que se corresponde en netsniff-ng con Payload char.

Sobre interpretación del tráfico ICMP, aquí os hable en su momento:

Análisis capturas tráfico de Red. Interpretacion tráfico ICMP (I).

Otros filtros BPF, por protocolos / tipo de tráfico, que tenemos ya preconfigurados son:

• all_traffic.bpf
• arp.bpf
• atalk.bpf
• broadcast.bpf
• ftp.bpf
• http.bpf
• icmp.bpf
• icq.bpf
• imap.bpf
• ip_broadcast.bpf
• ip_multicast.bpf
• multicast.bpf
• not_ip.bpf
• not_ssh.bpf
• pop3.bpf
• rarp.bpf
• rsync.bpf
• skype_pre.bpf
• smtp.bpf
• ssh.bpf
• vlan1000.bpf

Vamos aplicar otro filtro y un formateo de salida (-l) para imprimir en pantalla solo la información contenida en el payload.

sudo netsniff-ng -i ./pcap1/ftp.pcap -f /etc/netsniff-ng/rules/ftp.bpf -l

De esta forma en pantalla tendremos todo el trafico ftp (comandos incluidos, usuarios contraseñas, etc) en texto plano:

Sobre filtros BPF, .pcap, etc:

Wireshark / Tshark / Windump – Filtros pcap. Creación de filtros y filtros avanzados para captura de paquetes.

Comandos básicos y usuales netsniff.ng.

Podemos evitar (una de las formas)  que netsniff-ng muestre el payload con (-q) y cada paquete se muestre en una sola línea y con una información mínima que incluye entre otros:

• bytes
• marca de tiempo
• protocolo y vetrsión IP
• origen, destino
• suma comprobación
• puertos origen destino:

Con -e (expresión regex) podemo realizar una búsqueda en la captura. Lo probamos indicando también un fichero .pcap:

netsniff-ng -i ./pcap/captura.pcap -e “elmundo”

Podemos también capturar desde una interface red y pasar la catura a un fichero .pcap (–dump o -p). Es posible que no nos interese imprimir el resultado en pantalla, con lo que aplicamos también -s.

Quedará sí:

sudo netsniff-ng -deth0 –dump salida.pcap -s

Otro filtro que podemos aplicar es el tipo de tráfico, atendiendo a:

• broadcast para ver solo tráfico broadcast
• multicast para ver solo tráfico multicast
• host para ver solo tráfico de entrada a al host netsniff-ng
• others para ver solo el tráfico no host
• outgoing para ver solo tráfico salida desde el host

Un ejemplo:

sudo netsniff-ng -deth0 -t outgoing -q

Como vemos en la captura de pantalla, solo vemos los paquetetes icmp echo reply :

Hasta aquí por hoy. En la parte II avanzaremos un poco más y veremos como optimizar el rendimiento, tipos de salida, ajustes CPU, etc.

Y ya que estamos, relacionado con los sniffers…. Detección de sniffer:

Detección de Sniffers.

—–

Hasta la próxima.

En esta ocasión vamos a ver la herramienta assniffer, un sniffer HTTP para sistemas Windows, que tomando como fuente una interface de red o un fichero de captura tráfico de red en formato .pcap, vuelca toda la información por carpetas según los dominios visitados. Lo vemos.

Instalación de assniffer.

Es muy sencilla la instalación. Solo tenemos que descargar un archivo comprimido desde http://www.cockos.com/assniffer/assniffer02.zip, descomprimir y usar.

Uso básico de assniffer.

Creamos una carpeta para el volcado de los datos extraidos. Una vez realizado esto, ya podemos usar assniffer:

assniffer c:\as\volcado -r c:\pcap\fichero_captura.pcap

Indicamos primero el lugar a volcar los datos, fuente de los datos (-r para fichero .pcap o -d para interface de red).

De esta forma extrae todos los ficheros binarios, imagenes, video, css, js, archivos comprimidos, etc que estén involucrados en la captura. Se volcará nen la carpeta que indiquemos bajo una estructura ordenada para mejor identificación del contenido:

Por defecto crea carpetas según dominios, pero también podemos indicar que lo haga por IP (-splitbyclient).

También la ejecución por defecto extraerá todos los tipos MIME, pero podemos indicar que tipo quetremos con -mimetype que puede ser image, text, application, video, etc.

Por ejemplo:

assniffer c:\as\volcado -r c:\pcap50608.cap -splitbyclient -mimetype image

Como he dicho, crea una estructura de carpetas, pero las podemos obviar con -nosubdirs

assniffer c:\as\volcado -r c:\pcap\captura.pcap -splitbyclient -nosubdirs

El resultado:

———-

Y hasta aquí por hoy. Hasta la próxima.

En esta ocasión vamso a ver un sniffer que reensambla, reordena y mustra flujos TCP de forma muy personalizable, con una salida “humanizada” en diferentes tipos de formatos. Realiza también defragmentación e imita en su salida el formato de logs Apache… y muchas cosas más. Se trata de Justniffer. Es ideal para tratar tráfico en servidores web, correo, etc. Lo vamos viendo, de momento, para un uso básico.

Al lío..

Istalación de Justniffer.

La instalación de esta herramienta no tiene ninguna complicación. En mi caso, como tengo instalado snort, suricata, etc, las mayoría de librerías ya las tengo instaladas. Solo me faltaba Boost C++ Libraries (libboost1.42-all.dev). Para ello lo más sencillo es instalar desde apt-get install o un gestor de paquetes gráfico.

Una vez tengamos Boost C++ Libraries, el procedimiento es:

wget http://ignum.dl.sourceforge.net/project/justniffer/justniffer/justniffer%200.5.11/justniffer_0.5.11.tar.gz
tar zxf justniffer_0.5.11.tar.gz
cd justniffer-0.5.11
./configure
make
sudo make install

Uso básico de Justniffer.

Un uso muy básico seria el siguiente:

sudo justniffer -i eth0

Solo con esto veremos que la salida no es la misma que, por ejemplo, tshark, tcpdump, etc:

Si hacemos un ping, para generar algo de tráfico, esperamos que parezca el tráfico SSH (estoy conectado al host donde se ejecuta justniffer mediante SSH), vemos que no aparece nada. Ahora voy a realizar un scan nmap…  pues tampoco veo salida alguna. Probamos navegar por alguna web…:

Aquí ya vemos alguna diferencia con otros sniffers. El formato de salida por defecto se asemeja a un logs Apache, con toda la información que este formato nos aporta:

192.168.1.96 – - [08/Nov/2011:12:45:55 +0100] “GET /scripts/snort HTTP/1.1″ 304 0 “http://www.snort.org/” “Mozilla/5.0 (X11; U; Linux i686; es-CL; rv:1.9.2.23) Gecko/20110921 Ubuntu/10.10 (maverick) Firefox/3.6.23″

Esta es la información y salida standart para tráfico HTTP, aunque soporta también JDBC, RTSP, SIP, SMTP, IMAP, POP, LDAP.

Ahora vamos a incluir -r . Parte del resultado es:
GET / HTTP/1.1
Host: www.snort.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-CL; rv:1.9.2.23) Gecko/20110921 Ubuntu/10.10 (maverick) Firefox/3.6.23
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-cl,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: __utma=3232757.6; __utmz=32316004.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=3231602.1320752757
If-None-Match: “14ff819fbc0760d24ee1002634466eb7″

HTTP/1.1 304 Not Modified
Date: Tue, 08 Nov 2011 11:54:01 GMT
Server: Apache
Keep-Alive: timeout=3, max=97
ETag: “14ff819fbc0760d24ee1002634466eb7″
Cache-Control: max-age=300, public
Set-Cookie: _radiant_session=BAh7BzOGNmm9ydC5vcmcv–aa7585f9fe4781d9d4387bb0c2af0; path=/; HttpOnly
Connection: close

GET /stylesheets/smoothness-css HTTP/1.1
Host: www.snort.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-CL; rv:1.9.2.23) Gecko/20110921 Ubuntu/10.10 (maverick) Firefox/3.6.23
Accept: text/css,*/*;q=0.1
Accept-Language: es-cl,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.snort.org/
Cookie: __utma=3232.1.6; __utmz=323160.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=323152757; _radiant_session=BAh7ByIaaHR0cDovL3d3dy5zbm9ydC5vcmcv–aa75c2af0
If-None-Match: “224d206d2007″

HTTP/1.1 304 Not Modified
Date: Tue, 08 Nov 2011 11:54:06 GMT
Server: Apache
Keep-Alive: timeout=5, max=96
ETag: “224d206314a763fb1ab1cd2007″
Cache-Control: max-age=300, public
Set-Cookie: _radiant_session=BAh7BzNjk4MDc0MWI2MDU6DnJldHVybl90byIaaHR0cDovL3d3dy5zbm9ydC5vcmcv–aa7585f9fe4780c2af0; path=/; HttpOnly
Connection: close

Obtenemos más información y de una forma distinta (formato raw stream).

Estos dos ejemplos no da la idea de que puede ser muy intersante para capturar tráfico de red y auditar, investigar este tráfico en servidores web por ejemplo.

Filtros para formato log.

Volvemos al formato log Apache. Bajo este formato podemos modelar, establecer filtros para configurar una salida personalizada.

Por ejemplo, queremos una salida que incluya los “campos”:

• source.ip
• dest.ip
• request.url
• connection.time

Pra ello:

sudo justniffer -i eth0 -l “%source.ip %dest.ip %request.url %connection.time”

el resultado:

Vemos claramente las 4 columnas con la información que hemos pedido.

Algo más de información:

sudo justniffer -i eth0 -l “%source.ip %dest.ip %request.url %connection.time %response.size %close.time %close.originator”

Que otros filtros tenemos:
 %close.originator
 %close.time
 %close.timestamp
 %close.timestamp2
 %connection
 %connection.time
 %connection.timestamp
 %connection.timestamp2
 %dest.ip
 %dest.port
 %idle.time.0
 %idle.time.1
 %newline
 %request
 %request.grep
 %request.header
 %request.header.accept
 %request.header.accept-charset
 %request.header.accept-encoding
 %request.header.accept-language
 %request.header.authorization
 %request.header.connection
 %request.header.content-encoding
 %request.header.content-language
 %request.header.content-length
 %request.header.content-md5
 %request.header.cookie
 %request.header.grep
 %request.header.host
 %request.header.keep-alive
 %request.header.range
 %request.header.referer
 %request.header.transfer-encoding
 %request.header.user-agent
 %request.header.value
 %request.header.via
 %request.line
 %request.method
 %request.protocol
 %request.size
 %request.time
 %request.timestamp
 %request.timestamp2
 %request.url
 %response
 %response.code
 %response.grep
 %response.header
 %response.header.accept-ranges
 %response.header.age
 %response.header.allow
 %response.header.cache-control
 %response.header.connection
 %response.header.content-encoding
 %response.header.content-language
 %response.header.content-length
 %response.header.content-md5
 %response.header.content-range
 %response.header.content-type
 %response.header.date
 %response.header.etag
 %response.header.expires
 %response.header.grep
 %response.header.keep-alive
 %response.header.last-modified
 %response.header.pragma
 %response.header.server
 %response.header.set-cookie
 %response.header.transfer-encoding
 %response.header.value
 %response.header.vary
 %response.header.via
 %response.header.www-authenticate
 %response.line
 %response.message
 %response.protocol
 %response.size
 %response.time
 %response.time.begin
 %response.time.end
 %response.timestamp
 %response.timestamp2
 %source.ip
 %source.port
 %tab

Captura IMAP:

Ahora vamos a realizar un análisis del trafico IMAP pero apartir de un fichero de captura de ráfico en formato .pcap. Para ello usamos -p:

justniffer -f imap_xxxxx.pcap

si añadimos -r:

justniffer -f imap_xxxxx.pcap -r

la información es mayor:

OK ZX Sptectrum Server Mail. 2.6.5 IMAP4rev1 server ready

0000 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 IDLE ACL LITERAL+ UIDPLUS QUOTA ID SORT ANNOTATE ANNOTATEMORE STATUS-COUNTERS UNSELECT LISTEXT START$
0000 OK CAPABILITY completed

0001 LOGIN “yomismo” “559874gtg”
0001 OK LOGIN completed

0002 IDLE
+ idling

DONE
0002 OK IDLE completed

0003 SELECT “INBOX”
* FLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk)
* 33 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1214826302] UID validity
* OK [UIDNEXT 52468] Predicted next UID
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk)] Perman$
0003 OK [READ-WRITE] SELECT completed

0004 IDLE
+ idling

DONE
0004 OK IDLE completed

0005 UID FETCH 52467:* (BODY.PEEK[HEADER.FIELDS (References X-Ref X-Priority X-MSMail-Priority X-MSOESRec Newsgroups)] ENVELOPE R$
* 33 FETCH (UID 52467 RFC822.SIZE 2327 INTERNALDATE “26-May-2010 09:52:17 +0200″ ENVELOPE (“Wed, 26 May 2010 09:52:17 +0200″ {24}
78% Discount. Best sale. ((“RX-Store” NIL “yomismo” “dominio.es”)) ((“RX-Store” NIL “yomismo” “dominio.es”)) ((“RX-Store” NIL “cc$

 FLAGS (\Recent))
0005 OK UID FETCH completed

0006 UID FETCH 1:52466 (UID FLAGS)
* 1 FETCH (UID 21719 FLAGS ())
* 2 FETCH (UID 21876 FLAGS ())
* 3 FETCH (UID 22006 FLAGS ())
* 4 FETCH (UID 23451 FLAGS ())
* 5 FETCH (UID 23463 FLAGS ())
* 6 FETCH (UID 24037 FLAGS ())

…….. etc, etc, etc, …..

0007 IDLE
+ idling

DONE
0007 OK IDLE completed

0008 UID FETCH 52466 (BODY.PEEK[] UID)
* 32 FETCH (UID 52466 BODY[] {1540}
Return-Path: <origen@dominio.es>
X-Spam-Status: No, hits=0.0 required=5.0
        tests=AWL: -0.243,BAYES_00: -1.665,RATWARE_GECKO_BUILD: 1.691,
        CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -0.217
X-Spam-Level:
Received: from [127.0.0.1] ([192.168.xx.xxx])
        by dominio.es (ZX Sptectrum Server Mail. 2.6.5)
        (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits))
        for yomismo@dominio.es;
        Wed, 26 May 2010 09:44:22 +0200
Message-ID: <4Bxxx99x704@dominio.es>
Date: Wed, 26 May 2010 09:50:15 +0200
From: “El que envia” <origen@dominio.es>
Reply-To: origen@dominio.es
Organization: LA ORGANIZACION
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: “Yomismo” <yomismo@dominio.es>
Subject: El asunto=
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Antivirus: elquesea! (VPS 100525-1, 25/05/2010), Outbound message
X-Antivirus-Status: Clean

Hola,

Aquí probando un par de cositas.

Saludos,

Filtrado de paquetes.

Podemos establecer filtros con la opción -p:

sudo justniffer -i eth0 -p “port 80 and port 25″

sobre filtrado tenéis aquí información suficiente:

Wireshark / Tshark / Windump – Filtros pcap. Creación de filtros y filtros avanzados para captura de paquetes.

Extracción de binarios con Justniffer.

Para esta tarea usamos la herramienta justniffer -grab-http-traffic. Indicaremos (-d) el lugar donde almacenar estos datos y la forma de captura. Además indicamos un usuario  (-U) que no sea root:

sudo justniffer-grab-http-traffic -ieth0 -d /home/preludeids/binarios -U preludeids

el resultado:

esto se traduce en que en la carpeta /binarios/ se crearán una estructura de directorios por dominios y dentro de estos los binarios, imagenes, etc capturados:

Y hasta aquí por hoy. En el proximo artículo dedicado a Justniffer, avanzaremos más.

—

En esta ocasión vamos a estudiar una heramienta desarrollada en ruby que, conectando a un servidor local o remoto mediante SSH, es capaz de mostrar en tiempo real una serie de datos que toma de los ficheros logs. De esta forma es capaz de mostrar datos de logs de herramientas como Apache, Rails, IIS, Postfix/spamd/clamd, Nginx, Squid, PostgreSQL, PureFTPD, MySQL, Tshark, qmail/vmpop3d. Además es capaz de mostrarlos de forma simultánea. Esta herramiente es glTail.rb.

Muestra, en tiempo real, datos como: dirección de orígen/destino, protocolos usados, peticiones por minuto, ancho de banda, etc.

Instalando glTail.rb.

Para instalar glTail.rb he seguido la siguiente secuencia:

sudo apt-get install rubygems rake ruby1.8-dev libgl1-mesa-dev libglu1-mesa-dev libglut3-dev build-essential
sudo gem install net-ssh ruby-opengl -r

sudo gem install -y file-tail -r

Ahora descargamos glTail.rb:

wget http://rubyforge.org/frs/download.php/39787/gltail-0.1.8.tgz
tar -zxf gltail-0.1.8.tgz
cd gltail-0.1.8

Ahora tenemos que modificar / personalizar el archivo config.yaml que se ubica en gltail-0.1.8/dist/config.yaml para incluir lo servidores y comentar lo que no proceda. En mi caso y para este primer ejemplo:

servers:
    site1:
        host: 192.168.1.96
        user: preludeids
        password: tatachintatachan
        command: tail -f -n0
        #files: /var/log/apache/access_log
        files: /var/log/apache2/other_vhosts_access.log
        parser: apache
        color: 0.2, 1.0, 0.2, 1.0
#    rails:
#        host: anotherfunsite.com
#        user: anotherfunuser
#        port: 222
#        command: tail -f -n0
#        files: /var/www/apps/funapp/current/log/production.log
#        parser: rails
#        color: 0.2, 0.2, 1.0, 1.0
#    dev:
#        host: clockingit.com
#        source: local
#        files: /var/www/clockingit/logs/production.log
#        parser: rails
#        color: 0.2, 0.2, 1.0, 1.0

¿ Qué hemos hecho ?.

Hemos indicado para el site1 la IP del host remoto, usuario y contraseña para conectar mediante SSH y en files la ubicación del archivo log de apache.

Este sería una configuración de los más simple. Podríamos configurar dos fuentes de datos. Por ejemplo logs de Apache y Tshark:

Observad como he sustutuido el por defecto site1 por algo más personalizado para mi server donde se ubica prewikka (SIEM Prelude IDS / IPS) y otro para la ubicación de un log de Tshark donde estoy ejecutando esta herramienta en tiempo real.

La línea de comandos simple para volcar la salida de tshark en un fichero log sería:

tshark -ieth0 > tshark.log

También podemos, en el tag config, modificar dimensiones, tamaño de nodos, etc.

Ejecutando glTail.rb.

Ejemplo.1

En este primer ejemplo voy a usar un solo site. Un servidor HTTP Apache:

    prewikka_1:
        host: 192.168.1.96
        user: preludeids
        password: tatachintatachan
        command: tail -f -n0
        #files: /var/log/apache/access_log
        files: /var/log/apache2/other_vhosts_access.log
        parser: apache
        color: 0.2, 1.0, 0.2, 1.0

Una vez salvado el archivo y dentro de la carpeta bin donde se encuentra gl_tail, ejecutamos de la forma:

alfon@alfonubuntu:~/gltail-0.1.8/bin$ ./gl_tail ../dist/config.yaml

El resultado es:

Tenemos 3 columnas:

• Columna izquierda. Tenemos información del site o sites. En este caso el site (prewikka_1).  Vemos un resúmen del contenido de las peticiones (imagenes, hojas de estilo, javascript..). Status HTTP y usuarios, en este aso dos IP que realizan peticiones al servidorHTTP  Apache junto a las peticiones o requests por minuto (r/m).
• Columna central. Representa la información grafica, en tiempo real de los request o peticiones (de izquierda a derecha)  y las respuestas del servidor mediante nodos en 3D. El tamaño corresponde al “volumen” de la petición. Como respuesta del servidor, tendremos otros nodos que irán de derecha a izquierda.
• Columna derecha. Información sobre las URLs requeridas por el origen de las peticiones junto a requests/minuto. Información de User Agent usado por el user o usuario que realiza las peticiones.

La información de las columnas varian dependiendo del parser usado. En este caso se trata del parse apache. Para Tshark, Poxfix, etc sería distinta la información.

Sobre visualización gráfica de logs de apache tenéis también:

Representación gráfica Apache access.log con apache2dot y Graphviz

Ejemplo.2

Bien, ahora vamos a usar Inguma-0.4 y nikto para realizar una auditoría del sitio web y vamos a observar el tráfico. El resultado es:

Observad la cantidad de requerst / minuto que genera nikto y en la columna de la derecha aparece una nueva columna: WARNINGS. código 404.

El User Agent, que no se aprecia bien en la captura, es Python urllib/2.6. GlTail ha detectado que se trata de un script de python.

Si realizáis esta prueba veréis en movimiento (tiempo real) todas estas “transacciones” y los nodos más pequeños de respuestas del servidor (de derecha a izquierda).

Ejemplo.3

Ahora voy a desactivar le site prewikka_1 y activar el site y parser Tshark. Ponemos en marcha Tshark.

sudo tshark -ieth0 > tshark.log

Ahora para probar realizo un scan con nmap.

En este caso solo tendremos información en columna izquierda y central:

Aquí vemos un nuevo tag de información que es TYPE. Referidos a los protocolos. En este caso TCP con 293.04  r/m.

==========

Hasta aqui por hoy. Hasta la próxima.

Relacionado con Snort y herramientas de análisis de alertas, centros IDS/IPS, etc ya hemos visto aquí otras otras soluciones similares como Snorby, EASY IDS, Security Onion, SIEM Prelude IDS/IPS, Smooth-Sec, Suricata, IDS Policy Manager, etc, etc.

En esta ocasión vamos a hablar de SNEZ. Se trata de una GUI o interface gráfica web basada en PHP/mysql para gestión y análisis de alertas Snort. La gran ventaja de SNEZ es su facilidad de instalación y configuración.

Al lío.

Instalación y configuración de SNEZ.

wget http://sourceforge.net/projects/snez/files/downloads/SNEZ-0.1.tar.gz
 tar -xzvf SNEZ-0.1.tar.gz
 cd SNEZ-0.1

Una vez dentro de SNEZ,  tenemos lo siguiente:

~/SNEZ-0.1$ ls
AUTHORS  BUGS  COPYING  README  SNEZ  SNEZcreate  SNEZcreatetables  TODO  urldecode.txt  urlencode.txt

Pues bien, ejecutamos SNEZcreate para crear la base de datos SNEZ y usuario:

$ ./SNEZcreate
provide root password for sql db:xxxxxxxxxxxxxxxx
provide a password for the SNEZ db:yyyyyyyyyyyyyy

• provide root password for sql db. Se refiere a la contraseña root de mysql.
• provide a password for the SNEZ db. Se refiere a la contraseña del usuario snort para la base de datos mysql snort donde se alamacenan los datosde alertas, etc.

Ahora entramos en la carpeta SNEZ que se encuentra en SNEZ-0.1/SNEZ y editamos SNEZconfig.php:

Tanto en SNEZ.password como en  ids.paswword, ponemos la contraseña que indicamos en provide a password for the SNEZ db cuando ejecutamos el script SNEZcreate.

Ejecutando SNEZ.

Ahora copiamos tosdo el contenido de SNEZ-0.1/SNEZ/ en el sitio web. En mi caso yo he creado /usr/share/snez/htdocs y en esté ultimo he copiado todo el contenido. He creado también un virtualhost en puerto 83 en mi Apache. De esta forma indico en el navegador web la IP donse se encuentra SNEZ:

http://192.168.1.96:83/SNEZ/SNEZlogin.php

Nos pide Username y Password. Para los dos es admin y:

A partir de ahí podemos ir navagando por las opciones, análisis, criterios de búsqueda (columna filter), etc, etc.

Base datos Snort.

Evidentemente tenemos que tener nuestro sensor Snort preparado par aque envíe las alertas a una base de datos mysql:

Creamos la base se datos:

echo “create database snort;” | mysql -u root -p
mysql -u root -p -D snort < ./schemas/create_mysql

Otorgamos permisos:

echo “grant create, insert, select, delete, update on snort.* to snort@localhost \
identified by ‘adman100′” | mysql -u root -p

En este caso permisos para localhost. Yo, además, otorgé permisos para que Snort (192.168.1.30) enviara las alertas a un host remoto donde se encuentra la base de datos snort y SNEZ (192.168.1.96).

En el archivo de configuración snort.conf debemos indicar que las alertas las enviamos a una base de datos mysql:

output database: log, mysql, user=snort password=yyyyyyyy dbname=snort host=192.168.1.96

El password debe ser el mismo que indicamos:

• SNEZ.password
• ids.paswword

que vimos en el archivo SNEZconfig.php más arriba y también el mismo que indicamos en:

• provide a password for the SNEZ db

indicado al principio cuandio ejecutamos el script SNEZcreate.

======================================0

Esto es todo por hoy. Hasta la próxima.

En esta ocasión vamos a parsear un fichero access.log de Apache para convertirlo en un fichero .dot y crear una gráfica a partir de éste.

Para ello vamos a descargar el fichero script de perl: apache2dot.pl que se encuentra aquí: http://www.chaosreigns.com/code/apache2dot/apache2dot.pl

Parseamos el access.log de esta forma:

cat /var/log/apache/access.log | perl apache2dot.pl > access.dot

para Windows podemos reemplazar el cat por type.

Una vez tengamos el fichero .dot, solo nos resta usar neato, circo, fdp, etc, para crear la gráfica:

neato -Tpng -o access.png access.dot

el resultado:

si hacemos un zoom:

===============================

Agradecimiento a javcasta.com @javcasta por su colaboración en este artículo.

Relacionado:

• Visualización gráfica datos GeoIP con Argus, ra y Afterglow.
• Visualización interactiva de tráfico de red con INAV.
• Argus. Auditando el tráfico de red. Parte 4. Generación de gráficas con AfterGlow.
• Argus. Auditando el tráfico de red. Parte 5. Auditoría de host remoto.
• Argus. Auditando el tráfico de red. Parte I
• Argus. Auditando el tráfico de red. Parte 2
• Argus. Auditando el tráfico de red. Parte 3. Generación de gráficas con ragraph.
• Visualización gráfica Nmap / Scapy Scan con Afterglow / Argus racluster. Clustering y gráficas fdp. Parte 1
• Argus. Auditando el tráfico de red. Parte 6. Argus y Geolocalización con GeoIP

===============================

Y hasta aquí por hoy. Hasta la próxima.

===============================

En esta ocasión vamos a mostrar gráficas Argus /Afterglow con datos GeoIP.

Preparando los datos.

Partimos de una archivo de captura, del laboratorio,  ya convertido a un fichero de datos Argus (050608.out).

Podemos ordenar antes los datos según el criterío que, en cada momento necesitemos. Yo voy a usar racluster para agrupar (lo hemos visto en otros capítulos) y rasort para ordenar:

alfon@alfonubuntu:~$ racluster -m saddr daddr -r 050608.out -w – | rasort -m saddr daddr -w final.out

Ahora, como ya hemos visto aquí sobre Argus y GeoIP, extraemos los datos con información GeoIP y volcamos a un archivo .csv. Para pasar los datos a .csv debemos indicar la opción (-c,):

alfon@alfonubuntu:~$ ra -c, -r final.out -s saddr:15 bytes +label:70 -N50 > final.csv

Creando la gráfica Afterglow.

Ya tenemos nuestro fichero .csv, ahora parseamos con Afterglow:

alfon@alfonubuntu:~$ cat final.csv | perl afterglow/src/perl/graph/afterglow.pl -c afterglow/src/perl/graph/color.properties > final.dot
Verbose mode is on.
Skipping 0 lines.
Reading a maximum of 999999 lines.
Split mode for events is 0.
Threshold 0.
Source Threshold 0.
Target Threshold 0.
Event Threshold 0.
Maximum Node Size 0.2.

----------- Property File:
----------- Done Reading Properties

Lines read so far: 1. Skipped: 0. Processed: 1====> Processing: 62.43.206.126 -> 46100760 -> scity=Valencia
Lines read so far: 2. Skipped: 0. Processed: 2====> Processing: 195.235.188.81 -> 328036650 -> scity=San Fernando
Lines read so far: 3. Skipped: 0. Processed: 3====> Processing: 192.168.1.224 -> 23050380 -> dcity=Valencia
Lines read so far: 4. Skipped: 0. Processed: 4====> Processing: 192.168.101.240 -> 164019783 -> dcity=San Fernando
Lines read so far: 5. Skipped: 0. Processed: 5====> Processing: 192.168.101.240 -> 4979568 -> dcity=(null)
Lines read so far: 6. Skipped: 0. Processed: 6====> Processing: 192.168.101.240 -> 14920770 -> dcity=(null)
Lines read so far: 7. Skipped: 0. Processed: 7====> Processing: 80.58.61.250 -> 2489784 -> scity=(null)
Lines read so far: 8. Skipped: 0. Processed: 8====> Processing: 192.168.1.11 -> 10699554 -> dcity=(null)
Lines read so far: 9. Skipped: 0. Processed: 9====> Processing: 192.168.101.240 -> 10438476 -> dcity=(null)
Lines read so far: 10. Skipped: 0. Processed: 10====> Processing:  ->  ->
Lines read so far: 11. Skipped: 0. Processed: 11====> Processing:  ->  ->
Lines read so far: 12. Skipped: 0. Processed: 12====> Processing: 192.168.101.240 -> 10230186 -> dcity=Mountain View
Lines read so far: 13. Skipped: 0. Processed: 13====> Processing: 217.76.130.116 -> 7460385 -> scity=(null)
Lines read so far: 14. Skipped: 0. Processed: 14====> Processing: 192.168.101.240 -> 10363986 -> dcity=Mountain View
Lines read so far: 15. Skipped: 0. Processed: 15====> Processing: 192.168.101.240 -> 9167040 -> dcity=(null)
Lines read so far: 16. Skipped: 0. Processed: 16====> Processing: 192.168.101.240 -> 10190376 -> dcity=(null)
Lines read so far: 17. Skipped: 0. Processed: 17====> Processing: 192.168.100.241 -> 9626100 -> dcity=San Fernando
Lines read so far: 18. Skipped: 0. Processed: 18====> Processing: 192.168.101.240 -> 9184074 -> dcity=(null)
Lines read so far: 19. Skipped: 0. Processed: 19====> Processing: 192.168.101.240 -> 7606644 -> dcity=(null)
Lines read so far: 20. Skipped: 0. Processed: 20====> Processing: 195.76.110.84 -> 5349777 -> scity=(null)
Lines read so far: 21. Skipped: 0. Processed: 21====> Processing: 192.168.101.240 -> 6389856 -> dcity=Sunnyvale
Lines read so far: 22. Skipped: 0. Processed: 22====> Processing: 192.168.101.240 -> 5981544 -> dcity=Plano
Lines read so far: 23. Skipped: 0. Processed: 23====> Processing: 81.93.209.50 -> 5219238 -> scity=(null)
Lines read so far: 24. Skipped: 0. Processed: 24====> Processing:  ->  ->
Lines read so far: 25. Skipped: 0. Processed: 25====> Processing:  ->  ->
Lines read so far: 26. Skipped: 0. Processed: 26====> Processing: 212.81.197.9 -> 7054578 -> scity=(null)
Lines read so far: 27. Skipped: 0. Processed: 27====> Processing: 192.168.101.240 -> 5570526 -> dcity=Madrid
Lines read so far: 28. Skipped: 0. Processed: 28====> Processing: 216.9.253.4 -> 1778478 -> scity=(null)
Lines read so far: 29. Skipped: 0. Processed: 29====> Processing: 72.14.247.91 -> 5115093 -> scity=Mountain View
Lines read so far: 30. Skipped: 0. Processed: 30====> Processing: 192.168.101.240 -> 3935802 -> dcity=Madrid
Lines read so far: 31. Skipped: 0. Processed: 31====> Processing: 72.14.247.104 -> 5181993 -> scity=Mountain View
Lines read so far: 32. Skipped: 0. Processed: 32====> Processing: 192.168.101.240 -> 2835048 -> dcity=(null)
Lines read so far: 33. Skipped: 0. Processed: 33====> Processing: 192.168.101.240 -> 4283580 -> dcity=(null)
Lines read so far: 34. Skipped: 0. Processed: 34====> Processing: 212.170.233.87 -> 4583520 -> scity=(null)
Lines read so far: 35. Skipped: 0. Processed: 35====> Processing: 192.168.101.240 -> 4441572 -> dcity=Madrid
Lines read so far: 36. Skipped: 0. Processed: 36====> Processing: 192.168.100.241 -> 686364 -> dcity=(null)
Lines read so far: 37. Skipped: 0. Processed: 37====> Processing: 192.168.101.240 -> 3908682 -> dcity=(null)
Lines read so far: 38. Skipped: 0. Processed: 38====> Processing: 89.202.149.42 -> 5095188 -> scity=(null)
Lines read so far: 39. Skipped: 0. Processed: 39====> Processing: 195.235.188.81 -> 4813050 -> scity=San Fernando
Lines read so far: 40. Skipped: 0. Processed: 40====> Processing:  ->  ->
Lines read so far: 41. Skipped: 0. Processed: 41====> Processing: 192.168.101.240 -> 3777882 -> dcity=(null)
Lines read so far: 42. Skipped: 0. Processed: 42====> Processing: 213.190.9.238 -> 4592037 -> scity=(null)
Lines read so far: 43. Skipped: 0. Processed: 43====> Processing: 86.109.103.232 -> 3803322 -> scity=(null)
Lines read so far: 44. Skipped: 0. Processed: 44====> Processing: 194.179.126.157 -> 4753638 -> scity=Arroyomolinos
Lines read so far: 45. Skipped: 0. Processed: 45====> Processing: 192.168.101.240 -> 3075432 -> dcity=(null)
Lines read so far: 46. Skipped: 0. Processed: 46====> Processing: 66.218.77.68 -> 3194928 -> scity=Sunnyvale
Lines read so far: 47. Skipped: 0. Processed: 47====> Processing: 72.233.5.202 -> 2990772 -> scity=Plano
Lines read so far: 48. Skipped: 0. Processed: 48====> Processing: 192.168.101.240 -> 2430942 -> dcity=Mountain View
Lines read so far: 49. Skipped: 0. Processed: 49====> Processing: 192.168.101.240 -> 2357316 -> dcity=San Diego
Lines read so far: 50. Skipped: 0. Processed: 50====> Processing: 84.122.86.45 -> 2181966 -> scity=San Fernando

All over, buster.

Ahora con neato, fdp, o cualquier herramienta Graphviz:

alfon@alfonubuntu:~$ fdp -Tpng -o final.png final.dot

El resultado (parte de el):

Relacionado:

• Argus. Auditando el tráfico de red. Parte 4. Generación de gráficas con AfterGlow.
• Argus. Auditando el tráfico de red. Parte 5. Auditoría de host remoto.
• Argus. Auditando el tráfico de red. Parte I
• Argus. Auditando el tráfico de red. Parte 2
• Argus. Auditando el tráfico de red. Parte 3. Generación de gráficas con ragraph.
• Visualización gráfica Nmap / Scapy Scan con Afterglow / Argus racluster. Clustering y gráficas fdp. Parte 1
• Argus. Auditando el tráfico de red. Parte 6. Argus y Geolocalización con GeoIP

========================================

Y hasta aquí por hoy. Hasta la próxima.

========================================

En esta ocasión vamos a ver una herramienta de visualización interactiva, en tiempo real, con una arquitectura cliente-servidor. Se trata de INAV (Interactive Network Active-Traffic Visualization).INAV (Interactive Network Active-Traffic Visualization). es una herramienta, como hemos comentado, del tipo cliente-servidor. El cliente desarrollado en Java y, por tanto, multiplataforma.

INAV nos muestra información del tráfico activo por nodos (host activos), la relación o conversación entre hosts, resolución DNS, rendimiento, etc.

Instalación de INAV.

Para el cliente no es necesario requisito alguno. Se trata de una aplicación en Java, por tanto multiplataforma. En este artículo ejecuraré INAV en un sistema Windows XP.

Lo descargamos (cliente) desde aquí: http://inav.scaparra.com/download/client/

Para el servidor es necesario:

• libpcap0.8
• libpcap0.8-dev
• g++

Requisitos que ya tendremos resuelto si hemos seguido otros artículos similares para instalar herramietnas de tráfico de red.

Voy a instalar el server, en este caso, en un sistema GNU/Linux Security Onion. Puede ser cualquiera, también he instalado el server en un Ubuntu Linux.

Vamos a ello:

alfon@alfonubuntu:~$ wget http://inav.scaparra.com/files/server/INAV-Server-0.3.7.tar.gz
--2011-06-15 18:43:21--  http://inav.scaparra.com/files/server/INAV-Server-0.3.7.tar.gz
Resolviendo inav.scaparra.com... 69.163.242.195
Conectando a inav.scaparra.com|69.163.242.195|:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 93012 (91K) [application/x-tar]
Guardando en: «INAV-Server-0.3.7.tar.gz»

100%[==============================================================>] 93.012      31,2K/s   en 2,9s

2011-06-15 18:43:24 (31,2 KB/s)-«INAV-Server-0.3.7.tar.gz» guardado [93012/93012]

alfon@alfonubuntu:~$ tar xzvf INAV-Server-0.3.7.tar.gz
INAV-Server-0.3.7/
INAV-Server-0.3.7/README.txt
INAV-Server-0.3.7/server/
INAV-Server-0.3.7/server/minorVersion.txt
INAV-Server-0.3.7/server/build.txt
INAV-Server-0.3.7/server/clientComm.cpp
INAV-Server-0.3.7/server/inputPlugin.hpp
INAV-Server-0.3.7/server/edge.hpp
INAV-Server-0.3.7/server/makefile
INAV-Server-0.3.7/server/pcapSniffer.hpp
INAV-Server-0.3.7/server/rectangle.cpp
INAV-Server-0.3.7/server/ethernet.cpp
INAV-Server-0.3.7/server/udp.cpp
INAV-Server-0.3.7/server/log.h
INAV-Server-0.3.7/server/constants.h
INAV-Server-0.3.7/server/data.hpp
INAV-Server-0.3.7/server/snifferData.cpp
INAV-Server-0.3.7/server/sniffer.h
INAV-Server-0.3.7/server/node.hpp
INAV-Server-0.3.7/server/bandwidthMonitor.cpp

fon@alfonubuntu:~/INAV-Server-0.3.7/server$ make
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o clientComm.o clientComm.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o clientCommData.o clientCommData.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o baseData.o baseData.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o snifferData.o snifferData.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o sniffer.o sniffer.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ethernet.o ethernet.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ip.o ip.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o tcp.o tcp.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o packet.o packet.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o filterData.o filterData.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o graphData.o graphData.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o bandwidthMonitor.o bandwidthMonitor.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/semaphore.o ../common/semaphore.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o icmp.o icmp.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o traceroute/tracerouteData.o traceroute/tracerouteData.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o traceroute/tracerouteThread.o traceroute/tracerouteThread.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/commandLineParser.o ../common/commandLineParser.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/xmlParser.o ../common/xmlParser.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o helper.o helper.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o udp.o udp.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/parseCommas.o ../common/parseCommas.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o debugThread.o debugThread.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/mutex.o ../common/mutex.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/threads.o ../common/threads.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o dataQueue.o dataQueue.cpp
g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o inavServer.o inavServer.cpp
g++ -lpthread -lpcap -o inavd clientComm.o clientCommData.o baseData.o snifferData.o sniffer.o ethernet.o ip.o tcp.o packet.o filterData.o graphData.o bandwidthMonitor.o ../common/semaphore.o icmp.o traceroute/tracerouteData.o traceroute/tracerouteThread.o ../common/commandLineParser.o ../common/xmlParser.o helper.o udp.o ../common/parseCommas.o debugThread.o ../common/mutex.o ../common/threads.o dataQueue.o inavServer.o
alfon@alfonubuntu:~/INAV-Server-0.3.7/server$

Como el server está instalado en un Security Onion, ahora hay que abrir el puerto 5000 para que el cliente se pueda establecer la comunicación:

iptables -A INPUT -p tcp –dport 5000 -j ACCEPT

Ejecutando INAV.

Vamos a ejecutar el servidor de la forma:

Ahora desde mi Windows XP o desde donde tenga el cliente ejecutamos el archivo java:

En la consola, del servidor aparecerán las conexiones, nodos, etc:

Visualizando la actividad de los hosts activos en el cliente.

Ya hemos ejecutado el archivo java y aparecerá una interface gráfica que, en unos segundos, comenzará a tener actividad de forma interactiva, aparfciendo los nodos, relaciones entre ellos, etc.

Eso sí, antes tendremos que indicar el la parte superior el host donde se encuentra el servidor y el puerto (por defecto el 5000).  Pulsamos en connect y

La información que muestra INAV es clara y tampoco necesita mayor explicación.

Se visualizarán solo los nodos o host que estén activos, cuando no lo estén desaparecerán de la zona de visualización de nodos.

Abajo vemos la relación entre uno de las puertas de enlace del laboratorio con otros host externos, el ancho de banda indicado por código de colores, puertos usados..:

Los host irán apareciendo y despareciendo, mostrando información, relaciones, ancho de banda, … todo en tiempo real.

INAV es capaz de gestionar grandes volúmenes de información y representación de nodos. Eso sí, necesitamos tener una buena “máquina”.

===

Y hasta aquí por hoy. Hasta la próxima.

En esta ocasión vamos a ver una herramienta para el análisis de flujos TCP. Se trata de Streams, una herramienta desarrollada por Tillmann Werner que procesa y analiza los streams TCP a partir de ficheros .pcap. Se basa en línea de comandos para el proceso, filtrado, etc datos de las sesiones.

Veremos brévemete su uso a través del análisis de un fichero .pcap.

Instalación de Streams.

Para la instalación yo he usado git porque mediante wget, etc tuve algún que otro problema.

git clone git://git.carnivore.it/streams.git
cd streams/
autoreconf -fv –install
./configure –with-libreadline-includes=/usr/include/readline/
make
make install

Uso básico de Streams.

nos situamos en /opt/streams/bin$  y

sudo ./streams

Tenemos lo siguiente:

alfon@alfonubuntu:/opt/streams/bin$ sudo ./streams

Ahora vamos a indicar el archivo .pcap a analizar. Para ello usamos el comando analyze:

> analyze /home/alfon/pcap/02032011.pcap

la respuesta:

file processed, 1328 streams (1154 non-empty and complete).

Podemos realizar un listado con list para ver todos y cada uno de los streams con la siguiente información:

1:       0.291104      18.640350  192.168.1.245:13266 > 192.168.1.11:4002 (20830 bytes)

• 1 número / identificación de la sesión
• 0.291104  marca de tiempo del comienzo
• 18.640350 marca tiempo final del stream
• 192.168.1.245:13266 IP origen y puerto
• 192.168.1.11:4002 IP destino y puerto
• (20830 bytes) bytes totales del stream

Usamos el comando filter para establecer o no el filtrado de tal forma que veamos o no todos los streams o que veamos los streams completos y no vacíos.

Ahora usamos bpf para establecer un filtro de este tipo:

> bpf host 192.168.1.11 and port 993

y hacemos un list:

Aplicando el filtro tenemos dos sesiones, 0 y 2. Vamos a verlas. Para ello vamos a hacer uso de un programa externo con el comando ext. Por ejemplo podenos usar hexdump (contenido hexadecimal) ó hd (hexadecimal y ASCII). Para ello:

> ext hexdump ó ext hd

y con el comando pipe pasamos la sesión que queramos a hexdump o hd:

Aplicamos de nuevo el comando bpf para dsactivar el filtro y aplicamos uno nuevo:

Otro ejemplo.

Voy a usar un fichero .pcap de los repositotrios Wireshark. Hacemos lo mismo. Abrimos el archivo y hacemos un list para ver las sesiones:

alfon@alfonubuntu:/opt/streams/bin$ sudo ./streams
_
_____ _____     ___| |_ _ __ ___  __ _ _ __ ___  ___
_____     |_____|_____|   / __| __| '__/ _ \/ _` | '_ ` _ \/ __|
|_____| _  |_____|_____|   \__ \ |_| | |  __/ (_| | | | | | \__ \  _   _ _
(_|_)____        (_)  |___/\__|_|  \___|\__,_|_| |_| |_|___/ (_) (_|_)
|_____|
version 0.1.0, Copyright (C) 2011 by Tillmann Werner

streams> analyze /home/alfon/pcap/smtp.pcap
file processed, 2 streams (2 non-empty and complete).
streams> list
0:       0.000000       7.235530  10.10.1.4:1470 > 74.53.140.153:25 (14705 bytes)
1:       0.346950       7.576953  74.53.140.153:25 > 10.10.1.4:1470 (538 bytes)
streams>

Se trata de una sesión SMTP. Se trata de un fichero .pcap pequeño pero podría ser que fuese un archivo mucho más grandes y no de solo dos sesiones. En el siguiente ejemplo vamos a usar el comando match para realizar búsquedas en los streams:

streams> analyze /home/alfon/031110.cap
file processed, 12928 streams (12155 non-empty and complete).
streams>

Este tiene 12928 sesiones. Vamos a usar match para buscar:

En este o cualquier otro caso, cuando tengamos iudentificado los datos que necesitemos, por ejemplo ficheros del tipo  (.pdf, .jpg, ewtc),  podemos salvar a un fichero binario. Lo haremos con los comandos outfile y dump para posteriormente abrirlo y analizarlo:

La secuencia sería:

streams> outfile /home/alfon/fichero.bin
streams> dump 3083
180808 bytes written to /home/alfon/fichero.bin
streams>

Teenemos otro comandos que es status que, en cualquier momento, nos informa de los filtros aplicados, expresiones bpf usadas o de búsquedas match, aplicación de filter, etc.

Con cualquier comando sin argumentos lo que hacemos es anular le efecto del comando para poder indicar otro valor

====

Hoy hasta aquí por hoy. Hasta la próxima.

En esta ocasión vamos a ver el uso de tcptrace en tiempo real o real-time, el módulo slice, módulo http y sus gráficas.

Ejecutando tcptrace en tiempo real.

La ejecución de tcptrace en tiempo real la realizaremos mediante pipes y ayudado por alguna herramienta que lo permita, en este caso tcpdump. Y lo haremos de la siguiente forma:

sudo tcpdump -ieth0 -w – | tcptrace -p -xrealtime stdin

• como reordaréis,  con la opción -p podemos visualizar el conetenido de los campos de las cabeceras IP/TCP. Con esta opción veremos información de todos los paquetes. Es sí, en tiempo real. No es necesaria esta opción.
• stdin es el manejador de archivos para entrada.

sudo tcpdump -ieth0 -w – | tcptrace -xrealtime stdin

El resultado:

El módulo slice.

Este módulo slice nos muestra, en un archivo slice.dat, las estádisticas más básicas del tráfico contenido en un .pcap o en tiempo real por intervalos de tiempo. Por defecto este intervalo está establecido en 15 segundos.  Con la opción -isegundos podemos establecer un intervalo distinto.

Por ejemplo. Vamos e ver está estádisticas a partir de un .pcap (gateway .pcap):

tcptrace -n -xslice gateway.pcap

• con -n desactivamos la resolución de nombres y así es todo más rápido para capturas muty grandes.

El ejecutar tcptrace con este módulo tenemos:

Vaya, parece que no hay nada nuevo. Es la salida típica de tcptrace con los flujos de tráfico,  su identificación, dirección de flujo, si la conexión está o no completada, etc.

Sin embargo, hay más; tcptrace ha creado un archivo denominado slice.dat. Ahí si están los datos estadísticos:

La información estadística mostrada es la siguiente:

• date intervalo de tiempo
• segs o número segmentos en el intervalo de tiempo date
• bytes o total de bytes en ese intervalo de tiempo
• rexsegs o segmentos retransimitidos
• rexbytes o bytes retransmitidos
• new o conexiones nuevas que se abren en ese intervalo de tiempo
• active o conexiones que siguen activas durante ese intervalo de tiempo (date).

El módulo http.

Para analizar los datos de tráfico referentes a HTTP. También extrae los archivos involucrados en dicho tráfico. Invocamos este módulo mediante la opción -xhttp.

Por cada cojexión detectada, tcptrace creará, mediante este módulo, un archivo xxxx_content.dat con el contenido del tráfico HTTP.

Vamos a ver un ejemplo:

tcptrace -zxy -xhttp -n -o1-3 casa.pcap

• como sé que el archivo .pcap contiene muchas conexiones, voy a filtrar y mostrar solo las 3 primeras -o1-3

La salida por terminal contiene dos partes:

• Datos estádísticos de conexión TCP
• Datos del modulo http referidos al protocolo HTTP.

Lo vemos:

Arriba estadísticas TCP para la primera conexión identificada como a2b. (repasad los primeros capítulos de la serie)

Un poco más abajo tendremos las estadísticas e información referida solo a HTTP. Información, como veréis, muy completa:

Pero además, el módulo http, ctreará una serie de archivos de contenido .dat con más información pro cada conexión identificada:

Por ejemplo, para la conexión identificada como e2f:

cat e2f_contents.dat


GET /reader/public/javascript/user/05987391129762782287/label/Nauscopio?n=2&callback=GRC_p(%7Bc%3A%22-%3A%22false%22%2Cn%3A%22false%22%Bnew%20GRC HTTP/1.1
Host: www.google.es
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: */*
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://seguridadyredes.nireblog.com/
Cookie: PREF=ID=a161d9a6a4d14239:FF=0:TM=1278970911:LM=1294571206:S=YDyC945yn3R2YN7o; NID=47=B0M7cpVHSBS4GCDpaHaCNld3v79-8twhdSMVCrHRy7jU9LSWgrOIRKCdZeasM5vSICKWCp8rDdXcIwoAoKrW9


¿ Solo eso ?.

No, hay más.  Además, el módulo http creará los archivos que ya hemos visto del tipo .xpl para la generación de gráficas. Por eso he puesto -zxy en tcptrace -zxy -xhttp -n -o1-3 casa.pcap.

En este caso se ha creado el archivo:

84.125.176.159_http.xpl
Vamos a usar Jplot para generar la gráfica:

java -jar jPlot.jar -t 84.125.176.159_http.xpl

El resultado:

Sobre TCPTRACE tenéis la siguiente información:

• Analizando capturas .pcap TCP con tcptrace. Generación de gráficas con Xplot. Parte 1
• Analizando capturas .pcap TCP con tcptrace. Generación de gráficas con Xplot. Parte 2
• Analizando capturas .pcap TCP con tcptrace. Filtrado y análisis de Conexiones.
• Analizando capturas .pcap TCP con tcptrace. Generación de gráficas con Xplot. Parte 3. Xtraffic.

===

Y hata aquí por hoy. Hasta la próxima.