Banner 1

Auditoría de seguridad en Windows Server 2012

0 comentarios

Llevar un control de la seguridad siempre es importante en cualquier entorno, especialmente en el empresarial. En máquinas Windows existe la auditoría de seguridad, una potente herramienta que permite mantener la seguridad en una empresa. Uno de sus principales objetivos consiste en comprobar el cumplimiento de las normas, aunque puede ser usada para una amplia variedad de situaciones, entre las que se pueden destacar; el análisis forense, monitorización de la actividad y resolución de problemas. A través de los registros que se generan, se podrían detectar comportamientos anómalos, accesos incorrectos o ilícitos a recursos de un entorno respaldado por la auditoría de seguridad.
clip_image002
Figura 1: Elementos de auditoría avanzada en Windows Server 2012
En el caso de Windows Server 2012, una de las principales novedades introducidas consiste en la creación de directivas de auditoría mediante el uso de expresiones. Esta nueva característica permite la implementación de directivas en entornos más complejos. Con el fin de que la creación de expresiones resulte más potente y sencilla, se ha trabajado para introducir información adicional en los eventos de acceso a datos.
A continuación se enumeran las nuevas características de auditoría de seguridad en Windows Server 2012 respecto a versiones anteriores de Windows.
Característica
Versiones anteriores de Windows
Windows Server 2012
Directivas de auditoría basadas en expresiones 
X
Auditoría de acceso a archivos
X
X
Auditoría de inicio de sesión de usuario mejorado
X
X
Auditoría de nuevos tipos de objeto protegibles 
X
Auditoría de dispositivos de almacenamiento extraíbles 
X
Tabla 1: Diferencias de auditoría de seguridad entre versiones de Windows Server
Otra novedad a destacar consiste en la posibilidad de auditar los accesos a dispositivos de almacenamiento extraíbles. En versiones anteriores de Windows, los administradores sólo tenían la posibilidad de limitar o denegar el uso de dispositivos de almacenamiento extraíble mediante las directivas destinadas a ello.
clip_image004
Figura 2: Auditoría de acceso a objeto (almacenamiento extraíble)
Se puede obtener más información sobre las novedades de auditoría de seguridad en Windows Server 2012 en Microsoft Technet.

FUENTE:

Envenenamiento DNS en Android: puede ser engañado a la hora de resolver dominios

0 comentarios

Roee Hay y Roi Saltzman del equipo IBM Application Security Research Group, han descubierto una vulnerabilidad en el sistema DNS de Android, que afecta a la versión 4.0.4 (Ice Cream Sandwich) y anteriores. Permite a un atacante hacer que un dominio resuelva hacia otra dirección.

La vulnerabilidad se debe a una implementación débil del sistema generador de números pseudo-aleatorios que se utilizan como identificador único de cada petición DNS. La debilidad de este sistema está ocasionada por el uso del identificador del proceso (PID) y la hora actual como semilla para generar los números aleatorios.

Sistema DNS

En el protocolo DNS (cuando trabaja sobre UDP) las peticiones DNS para resolver dominios se envían al servidor con un identificador único en los paquetes que conforman la petición. Así, a la hora de que el servidor responda, sabe a quién corresponde cada conversación.

Este identificador debe estar conformado por un valor aleatorio y el puerto UDP de destino. Para que un ataque de envenenamiento de DNS a este nivel funcione, un atacante podría enviar respuestas falsas al que intenta resolver (y hacerlo antes de que llegue la respuesta legítima del servidor real consultado).

En esta inundación de respuestas falsificaría la relación dominio-ip y podría engañar a la víctima. Tratándose de UDP (que no necesita confirmación de las dos partes como TCP) esto es posible. En cierta manera, lo que impide este ataque es precisamente ese código aleatorio que genera el cliente cuando quiere resolver. El atacante debe intentar predecir el próximo número aleatorio e inyectar respuestas que el sistema de resolución DNS no ha solicitado. Así puede engañarlo.

Si el identificador generado para cada consulta no es suficientemente aleatorio y llega a ser predicho de alguna manera, el atacante solo tiene que inundar al resolvedor de paquetes UDP con una pequeña cantidad de respuestas DNS. La que coincida será tomada en serio por el dispositivo que intenta resolver, haciéndole caso a los paquetes del atacante en vez de al servidor DNS legítimo consultado.

Si por el contrario el sistema de resolución realmente elige números aleatorios, las posibilidades del atacante son mínimas y necesitaría años para poder engañar al dispositivo. En el caso de Android, de los 32 bits posibles que pueden componer el identificador, se han visto que hasta 21 no eran realmente aleatorios, lo que facilita enormemente este ataque.

¿A qué se expone la víctima?

Este fallo podría permitir a un atacante predecir el identificador único y llevar a cabo un envenenamiento DNStradicional, enviando paquetes UDP a la víctima. En la demostración del vídeo, el ataque dura solo unos 10 minutos.

Una aplicación interesante que proponen los descubridores es la de incitar a la víctima a visitar una web del atacante. Esta, a través de JavaScript, comienza a "estimular" al sistema de resolución intentando resolver subdominios que no existen. El atacante además comienza a inyectar respuestas desde otro punto. El sistema de resolución se "confunde" y acaba creyendo que el dominio está en la IP que pertenece al atacante. Este configura el servidor web en esa IP para que robe todas las cookies de la víctima. El usuario acaba visitándola y así se podrá suplantar su usuario en cualquier página.

Han publicado un vídeo con una prueba de concepto como demostración de la vulnerabilidad, en la que se obtienen las cookies de un dominio.:


Por supuesto, para consumar totalmente estos ataques sobre páginas autenticadas con SSL, la víctima debería obviar las alertas del navegador.

La vulnerabilidad ha sido reportada y corregida por el del Android Security Team en la versión 4.1.1. En esta versión, para obtener números aleatorios se utiliza /dev/urandom que dispone de una entropía adecuada determinada por la actividad en la red.

Más información:

Weak randomness in Android’s DNS resolver (CVE-2012-2808)

Android DNS Poisoning: Randomness gone bad (CVE-2012-2808)

Android DNS Poisoning: Randomness gone bad (CVE-2012-2808)

Fuente:

OWASP Broken Web Applications Project VM v1.0

0 comentarios


Ayer, un post en el blog principal de OWASP anunciaba una nueva publicación del Broken Web Applications Project.

Este proyecto, que comenzó a mantenerse dentro de OWASP desde el 31 de Enero de 2010, consiste en la creación de una máquina virtual en la que se ejecutan un conjunto de aplicaciones que contienen vulnerabilidades, con el objetivo de practicar técnicas conocidas y relacionadas con la seguridad en aplicaciones web, tanto de forma manual, como para sacar el máximo partido a herramientas automáticas tanto de auditoría web como de código fuente. También nos permite ponernos "en el otro lado", defensa, para conocer el compartamiento de dichas aplicaciones en caso de que sean explotadas, probar firewalls de aplicaciones web (WAFs) o piezas de código fuente. 

Con esta recopilación nos ahorramos el tener que preparar un entorno o crear pruebas de conceptos o servicios vulnerables, así como evitar realizar ataques sobre entornos reales totalmente ajenos...

Dentro del conjunto de aplicaciones que se incluyen, se dividen en tres tipologías diferentes:
  • Aplicaciones de entrenamiento
Dentro de estas aplicaciones se incluyen aquellas que guían al usuario en la explotación satisfactoria de vulnerabilidades. Algunas de sobra conocidas por todos, se incluyen las siguientes:
    • OWASP WebGoat version 5.4+SVN (Java)
    • OWASP WebGoat.NET version 2012-07-05+GIT
    • OWASP ESAPI Java SwingSet Interactive version 1.0.1+SVN
    • Mutillidae version 2.2.3 (PHP)
    • Damn Vulnerable Web Application version 1.8+SVN (PHP)
    • Ghost (PHP)
  • Aplicaciones vulnerables "realistas"
Son como las de entrenamiento, pero en este caso las aplicaciones son más complejas y su comportamiento y funcionalidad pretende ser mucho más realista:
    • OWASP Vicnum version 1.5 (PHP/Perl)
    • Peruggia version 1.2 (PHP)
    • Google Gruyere version 2010-07-15 (Python)
    • Hackxor version 2011-04-06 (Java JSP)
    • WackoPicko version 2011-07-12+GIT (PHP)
    • BodgeIt version 1.3+SVN (Java JSP)
  • Versiones anticuadas de aplicaciones reales
Aquí se incluyen proyectos de aplicaciones web completamente reales y de uso extendido, cuyas versiones  o ramas tuvieron que requerir actualizaciones a causa de contener vulnerabilidades conocidas. Lo curioso de todo, es que, si bien pueden ya no estar mantenidas por los desarrolladores del proyecto, estas se pueden encontrar todavía.
    • WordPress 2.0.0 (PHP, released December 31, 2005) que incluye los plugins:
      • myGallery version 1.2
      • Spreadsheet for WordPress version 0.6
    • OrangeHRM version 2.4.2 (PHP, released May 7, 2009)
    • GetBoo version 1.04 (PHP, released April 7, 2008)
    • gtd-php version 0.7 (PHP, released September 30, 2006)
    • Yazd version 1.0 (Java, released February 20, 2002)
    • WebCalendar version 1.03 (PHP, released April 11, 2006)
    • Gallery2 version 2.1 (PHP, released March 23, 2006)
    • TikiWiki version 1.9.5 (PHP, released September 5, 2006)
    • Joomla version 1.5.15 (PHP, released November 4, 2009)
    • AWStats version 6.4 (build 1.814, Perl, released February 25,2005)
  • Aplicaciones creadas para probar herramientas
    • OWASP ZAP-WAVE version 0.2+SVN (Java JSP) - Prueba de OWASP ZAProxy
    • WAVSEP version 1.2 (Java JSP) - Aplicación utilizada para el benchmark de scanners de seguridad
    • WIVET version 3+SVN (Java JSP)
  • Páginas de pruebas o pequeñas aplicaciones
    • OWASP AppSensor Demo Application (Java)
Si bien en otras ocasiones ya hemos mencionado (por ejemplo, aquí y aquí) diferentes programas concretos o webs vulnerables a propósito sobre las que realizar pruebas, con este nuevo proyecto dispondremos de más variedad y como no, de un entorno mucho más controlado para que, como hemos mencionado antes, podamos actuar de una forma más defensiva.

El creador del proyecto, Chuck Willis, estará presentando esta "major version" en el Arsenal de la Black Hat USA que se está celebrando actualmente, y que comenzó ayer. Podéis seguir cualquier actualización del proyecto tanto en su twitter @owaspbwa, así como en la propia página del proyecto OWASP BWA y el repositorio en Google Code. La guía completa para el usuario se encuentra en esta página Wiki.

¡A practicar! ¡De forma legítima!

Fuentes:

Cómo diseñar una política de cortafuegos

0 comentarios
Aunque he de confesar que llevaba tiempo pensando en escribir un artículo con este título, ha sido a raíz de los comentarios que nuestros lectores dejaron en la encuesta que realizamos para conocer los intereses sobre los posts que os gustaría leer en SbD, lo que me ha impulsado a hacerlo ahora.

Muchas son las veces que me ha tocado analizar políticas de cortafuegos  de clientes con problemas, en los que he tardado más en hacerme un esquema mental de cómo es la topología de la red e imaginar en qué tienda ha comprado el criterio quien lo haya diseñado, que en dar realmente con el fallo de configuración.

Procesos tan vitales como aplicar una política de cortafuegos partiendo de una base ordenada, así como seguir unas buenas prácticas a la hora de hacer modificaciones, hacen que la política de seguridad sea más legible a la hora de entenderla, así como más eficiente en cuanto al procesamiento de las reglas.

Aquí van pues mis pasos y/o recomendaciones:
  • Suponemos que comenzamos partiendo de un dispositivo (o un clúster) que segmenta de forma correcta las redes que la organización desea separar. En este ejemplo, y como dicen los libros de matemáticas: "Sea un cortafuegos con cuatro redes diferentes: Una LAN, una DMZ de servicios públicos, una red DMZ de servicios privados (o accesibles sólo desde dentro) y la red de salida a Internet".
  • Un cortafuegos es, generalmente, un software implementado en un sistema operativo muy securizado y optimizado para tener un rendimiento óptimo en procesado y filtrado de paquetes, que interpreta las reglas que implementemos en modo Top-Down, es decir, por orden de definición. Si un paquete/conexión/sesión (dependiendo del cortafuegos) hace match con una regla, no se sigue procesando por las siguientes.
  • La regla 1 a definir en una política de cortafuegos que vamos a administrar de forma remota, es precisamente añadir una regla para permitirnos el acceso a los servicios de administración del propio cortafuegos, desde las direcciones IP de administración (sea SSH, HTTPS o el servicio cliente/servidor que corresponda). Ni sabéis la de veces que me habré autodenegado el servicio al aplicar una política de seguridad sin tener en cuenta esto, y la de paseos al CPD que me he pegado a modificar la política por consola o puerto serie.
  • Una vez definida la regla que permite la administración remota, habrá que crear la regla 2, que precisamente niega el acceso a los servicios de administración a TODAS las direcciones IP. Como las reglas se procesan de arriba a abajo, si la petición viene de una dirección IP permitida, entrará por la regla 1 y en caso contrario seguirá por la 2 hasta que haga "matching" en alguna. Si con estas dos reglas se abarca todas las posibles conexiones a la administración del equipo, siempre entrará por una de ellas. Esta regla es lo que se conoce como la "Stealth Rule"
  • A partir de aquí, para ser lo más eficiente posible, hay que pensar qué conviene más. Antiguamente, con dispositivos hardware limitados de recursos, había que tener en cuenta que los servicios más prioritarios a ofrecer (pensad en un servicio web o alguno en tiempo real o streaming), debían ir procesados al principio para dar una mejor satisfacción de usuario. Otra filosofía es poner al principio las reglas más utilizadas (tráfico web saliente o de correo, por ejemplo), dejando en últimos lugares aquellos servicios que se usan menos. En este caso, por estadística, un mayor porcentaje del tráfico se procesará antes. En dispositivos con una base de reglas a procesar "grande" o "muy grande" con mucho tráfico, el tener en cuenta este tipo de consideraciones, se nota en la carga del sistema. Actualmente, y dado los equipos hardware mastodontes de procesamiento que se utilizan, se nota menos. Un buen ejemplo lo tenéis en cómo, antiguamente, un programador se preocupaba de optimizar el número de variables a utilizar, así como la memoria a reservar en cada momento, dando lugar a verdaderas "joyas" con poco consumo de recursos. Ahora mismo, desde un Windows a un navegador se comen toneladas de memoria,…
  • Mi sugerencia es definir al principio las reglas para permitir los servicios prioritarios o, de negocio, de la organización. Lo más normal será dar acceso desde el Internet a las máquinas de la DMZ de servicios públicos. El orden a seguir es de mayor a menor prioridad, y de mayor a menor necesidad de "Tiempo Real". Por cada máquina (o grupo de máquinas) que dan un servicio habrá que crear una regla con los servicios a publicar. Yo sugeriría el siguiente orden (quitad aquellos servicios que la organización no ofrezca, claro está): HTTP/HTTPS, SSH, VNC, Terminal Server, FTP, VPN, SMTP. Nunca en la vida, a no ser que el cliente me obligara con una pistola en la cabeza, publicaría hacia Internet servicios de una organización como SSH, VNC y/o Terminal Server, pero en caso que se me requiera y, siempre y cuando se haga desde un número finito de direcciones IP, lo haría en ese orden para optimizar la experiencia del usuario que accede, al ser servicios interactivos.
  • Una vez se definen los accesos desde el exterior a la DMZ de servicios públicos, habrá que definir, al final de esa sección, una regla que prohiba el acceso desde Internet a cualquier servicio de dicha red. Es mejor prohibir accesos a la red completa, que comprenda todas las IPs de esa red, en vez de negar solo a las IPs de las máquinas existentes, de manera que si un día alguien sin avisar pincha una máquina nueva, queda correctamente filtrado.  
  • Si es necesario que desde la DMZ pública se acceda a servicios de la red DMZ privada (típico acceso a Sistema Gestor de Base de Datos, servidor de aplicaciones o accesos a servidor de correo con sus buzones desde un Mail Relay en la DMZ pública por ejemplo), será ahora cuando haya que crear dichos permisos. Importante es que se creen reglas específicas de máquinas origen de la DMZ pública a máquinas destino de la DMZ privada, exclusivamente a los servicios necesarios. Una vez terminada esa sección, habrá que definir una regla que prohiba acceso a cualquier servicio desde la red DMZ pública completa a la red DMZ privada también completa. Si nos compromenten una máquina en la DMZ pública, sólo podrán acceder a algunas máquinas a algunos servicios de la DMZ privada… no habiendo "barra libre". Habrá que tener en cuenta también qué servicios se permiten desde las redes DMZ privada y pública hacia Internet, hacia la LAN y desde la privada hacia la pública. Permitimos lo necesario explícitamente y negamos todo lo demás, evitando así, en la medida de lo posible canales de envío de shell inversas a través de servicios salientes innecesarios.
  • Las siguientes reglas a crear, por orden de importancia, serían las que permiten accesos desde la red interna LAN a la DMZ privada y a la red DMZ pública. Habrá que aplicar los mismos principios que antes, distinguiendo en este caso por redes origen (a no ser que el cortafuegos permita identificar a los usuarios de una forma más específica, no sólo por la IP origen, que en cualquier caso se puede cambiar para obtener mayores privilegios de acceso) para permitir lo justo y necesario a las DMZ, prohibiendo en una última regla todo lo demás a estas redes.
  • Finalmente habrá que definir las reglas de tráfico permitido desde la LAN hacia Internet. Al final de la sección, otra regla que prohiba todo lo no estrictamente permitido anteriormente.
  • Al final del todo, es típico y recomendable crear una regla llamada "Cleanup rule" o regla de limpieza que prohiba el tráfico desde Cualquier sitio hacia Cualquier sitio a Cualquier servicio. Es importante puesto que si hemos olvidado definir alguna de las reglas parciales de fitlrado entre redes, habrá tráfico que pase por aquí.
  • Hasta ahora, sólo he hablado de cómo definir reglas y qué permitir y qué negar. Sin embargo, me gustaría hacer un apunte a la hora de loggear o dejar un registro de aplicación de las reglas según el tráfico procesado. Los logs son sólo útiles si puedes leerlos y seguirlos. Si loggeamos TODO no habrá manera de monitorizar qué esta pasando en un momento dado, porque "los árboles no nos dejarán ver el bosque". Sin embargo, yo recomiendo loggear prácticamente todo lo que podamos que no sea absolutamente innecesario, como tráfico de broadcast, multicast, Netbios, DHCP, ARP, etc,.. que el firewall procese. Para ello, y si es un tráfico que entra por las reglas de prohibición de tráfico, recomiendo siempre crear una regla previa a esa, con las IPs de broadcast de la red o de broadcast genérico (255.255.255.255) en el destino, denegando el tráfico y marcando la casilla de NO Loggear el tráfico.
  • Si os dais cuenta, al principio del artículo he dicho cuál es la regla 1 a definir en el cortafuegos. Sin embargo, en la mayoría de los firewalls, existe un grupo de primeras reglas a procesar previa a la regla 1. Son las que se llaman reglas implícitas o "Regla 0", que suelen permitir o denegar "de fábrica" accesos a servicios de administración, o aquellos proporcionados por la propia máquina, como VPNs IPSEC/SSL/PPTP, DHCP, etc,...
  • Una parte muy importante en la definición de reglas es el rellenar el campo "Comentarios" que va al final de cada regla en casi todas las GUIs y que permite añadir una descripción para indicar qué hace concretamente dicha regla. Una vez más: documentación!
  • Una buena práctica después de definir una política de reglas es auditar desde las diferentes redes, los accesos hacia las demás, comprobando que la política está bien definida. Igualmente se aconseja monitorizar con especial dedicación los logs producidos, al menos al principio, corrigiendo en caso contrario la política si hemos dejado algo en el tintero.
Por cierto, que quiero agradecer desde aquí a Enrique Martín, mi buen amigo y ex-compañero de SGI,  que me enseñó las bases y me dió estas mismas guías cuando empecé a trabajar, implementando y posteriormente diseñando, políticas de seguridad en cortafuegos y otros dispositivos. 
 
Fuente: http://www.securitybydefault.com/2011/10/como-disenar-una-politica-de.html

Securizando un entorno de máquinas virtuales con Virtualbox

0 comentarios

La virtualización ha dejado de ser únicamente una moda, y, con los agravantes de los recortes por la crisis y la conciencia ecológica, se ha convertido en una forma de vida para todo tipo de organizaciones. Por esto, la seguridad ha tenido que reinventarse para poder adaptar conceptos como la correcta segmentación de redes, que anteriormente se hacía mediante diversas interfaces de red, VLANs y cables físicos conectados a una maraña de servidores, para definir políticas de acceso entre máquinas virtuales que corren en un mismo servidor físico.

Dentro de los sistemas de virtualización, hay una amplia elección profesional para elegir, por lo que las organizaciones que dispongan de recursos económicos para ello, pueden acudir a sus supermercado de productos de seguridad favorito, y hacerse con costosas licencias para crear entornos virtuales. En general, estas plataformas profesionales, permiten definir redes virtuales diferenciadas con políticas de seguridad que especifican el tráfico permitido entre ellas.

Como he dicho antes, para una organización más humilde o alguien que esté empezando una aventura empresarial (que las hay, incluso en España en 2012), la solución libre Virtualbox puede cubrir de sobra las necesidades de virtualización.  

Desde el prisma de un purista de la seguridad, tal cual explico en mi curso de Buenas Prácticas de Seguridad en Entornos Corporativos, el primer paso, para segmentar las redes que existirán en una organización, es identificar los diferentes servidores/servicios para decidir su distribución. Aquellos que necesiten tener una puerta por la que entre tráfico desde Internet, deberá ir en una DMZ de servicios públicos o frontend. La ubicación de los servidores que nutren estas aplicaciones públicas deben ir en una red diferente y protegida, o de backend. El tráfico a permitir entre todas estas redes habrá de ser el justo y necesario para evitar exposiciones de servicios/máquinas por error. Más o menos como se puede ver en el dibujo de abajo, y siguiendo los consejos que ya explicamos en "Cómo diseñar una política de cortafuegos"






"Bueno vale, después de la clase de pizarra que nos has soltado… cuéntanos esto del Virtualbox"

El problema de VirtualBox es que no dispone de una consola remota como tal, con la que gestionar las máquinas virtuales y con la que definir diferentes redes virtuales, así como asignar políticas de seguridad, por lo que habrá que inventarse algo por debajo, que supla esta carencia.

Partimos del caso de una organización pequeña en que disponemos de una máquina Linux, con recursos suficientes de RAM y disco duro, en la que instalaremos Virtualbox. Esta máquina dispone de conectividad a Internet (porque esté conectada al router ADSL o a una ONT de fibra óptica), y quizá conexión con una red LAN o wireless. Supongamos entonces que la máquina dispone únicamente de un par de interfaces físicos de red: uno conectado hacia Internet y otro hacia una red privada. 

Vamos a crear dos nuevas redes que permitan unir servidores de dos tipos: de frontend y de backend. Para ello, Linux provee de diferentes herramientas que permiten crear interfaces virtuales. En este caso vamos a definir dichos interfaces virtuales como tipo TAP [http://en.wikipedia.org/wiki/TUN/TAP]. 

Para ello, haremos, por cada red que queramos definir los siguientes pasos:

Data provided by Pastebin.com - Download Raw - See Original
  1. modprobe tun   #Cargaremos el driver "tun"
  2. tunctl -t tap0 #Creamos el interfaz tap0
  3. ifconfig tap0 192.168.5.1 netmask 255.255.255.0 up #Asignamos direccionamiento de red al interfaz y lo levantamos


Si necesitamos más interfaces virtuales, repetiremos las dos líneas "tunctl" e "ifconfig" con un nuevo intefaz virtual y el direccionamiento a asignar a sucesivos tap1, tap2, etc,…

Se supone que esto crea un interfaz de red virtual "persistente" asignado al uid 0 (si ejecutamos como root la orden, claro). Sin embargo, deberemos repetir los pasos de la definición de interfaces cada vez que arranque la máquina física. Para ello crearemos un script, en el /etc/rcX.d que corresponda, para que se definan los interfaces de red ANTES de que arranquen las máquinas virtuales. Es decir, no lo hagáis en el /etc/rc.local, que como sabréis, se ejecuta como último script de los de arranque.

Lo siguiente que tenemos que hacer es definir el interfaz de red de la máquina virtual que quedamos, como "Bridged Adapter" y seleccionaremos el interfaz "tap" que hayamos definido para esa red. 



Repetiremos este proceso para todas las máquinas virtuales según nuestras necesidades de pertenecer a la DMZ pública o a la privada. El direccionamiento de red a asignar a las máquinas virtuales de ambas redes, deberá pertenecer al mismo que tiene cada interfaz virtual TAP. En el caso del ejemplo, deberían pertenecer al rango 192.168.5.0/24. 

De esta manera, las máquinas de la DMZ pública, que ofrezcan servicios a Internet, quedarán en una DMZ virtual y las de backend en otra.

Viajando a la paranoia extrema

"Oye, ¿y si me comprometen una máquina, no podrían saltar a otra de la misma red?" Pues la respuesta es "puede". Si te comprometen una máquina virtual, las posibilidades son las mismas que en una red DMZ física, por lo que si la seguridad de cada una de las máquinas, a nivel individual, no ha sido tenido en cuenta convenientemente, podemos tener un problema mayor.

Para reforzar este posible caso, si queremos, podemos darle una vuelta de tuerca más, haciendo incluso que, la opción de máquinas virtuales sea más segura que la opción de redes físicas. Para ello, lo que haremos, en vez de definir un interfaz virtual por cada red, será crear un interfaz TAP por cada máquina virtual. Asignaremos desde el panel de Virtualbox el interfaz TAP, en modo bridge a cada máquina y utilizaremos subnetting para optimizar el espacio de direcciones IP.

Si antes usábamos una red con máscara 24 (255.255.255.0), ahora usaremos una máscara 30 (255.255.255.252). Los 30 bits de máscara nos permite 4 direcciones IP: la primera es la dirección de red, la última el broadcast de esa red y las otras dos son las "usables" para asignar a dos interfaces de red, creando una conexión Punto-a-Punto. Una será para la máquina virtual que montaremos en esa red, y otra para el interfaz tapX de la máquina física (que actuará de default gateway para la máquina virtual).

En el caso de 192.168.5.0/30 por ejemplo, tendríamos la 192.168.5.0 como dirección de red, la 192.168.5.3 como dirección de broadcast y la 192.168.5.1 y 192.168.5.2 como direcciones asignables. Si os liáis con el subnetting, podéis usar este enlace para el cálculo online de direcciones IP



Así, para acceder a otras máquinas, habrá que pasar sí o sí, a través del firewall… por lo que una política de seguridad estricta, asegurará, que si nos comprometen cualquiera de las máquinas virtuales, no será sencillo saltar a una "de las de al lado". Desde el punto de vista de la gestión de máquinas virtuales puede llegar a ser más lioso, pero como siempre, seguridad y usabilidad, se llevan mal. Este esquema es lo más parecido a implementar las Private VLAN que permite la electrónica de red Cisco.

Y ahora me diréis… ¿y si te comprometen la máquina física desde el propio acceso a Internet?  Pues lleváis razón. Quien tenga acceso a la máquina física puede acceder a los datos de todos los servidores contenidos en ella.

De vosotros dependerá securizar convenientemente esa máquina física, o incluso crear una máquina virtual nueva, que sea la que haga las labores de firewall, con un interfaz de red asignado (bridge) a cada una de las nuevas redes que hemos creado.

Así, la máquina física, si logramos que no tenga servicios de ningún tipo hacia el exterior, será un bastión muy difícil de vulnerar.
 
Fuente:
http://www.securitybydefault.com/2012/07/securizando-un-entorno-de-maquinas.html

Nuevas versiones Metasploit y SqlmapGui

0 comentarios
Aqui dejo las nuevas versiones de metasploit y sqlmapGui de las cuales ya se han trabajado en el blog.

sqlmapGUI v2.3.2



Metasploit v4.4



Saludos roboticos:

Fuentes:

http://www.n0where.net/2012/07/metasploit-v44.html
http://www.n0where.net/2012/07/sqlmapgui-v232.html

RedPhone

0 comentarios
Navegando entre mis Feeds encuentro esta aplicación la cual me parece interezante y digna de realizar pruebas.

An application that provides encrypted voice ca lls for Android.
    RedPhone is an application that enables encrypted voice communication between RedPhone users. RedPhone integrates with the system dialer to provide a frictionless call experience, but uses ZRTP to setup an encrypted VoIP channel for the actual call. RedPhone was designed specifically for mobile devices, using audio codecs and buffer algorithms tuned to the characteristics of mobile networks, and using push notifications to maximally preserve your device's battery life while still remaining responsive.
 
Fuentes:
https://github.com/WhisperSystems/RedPhone
http://www.n0where.net/2012/07/redphone.html

Reaver-wps: ataques de fuerza bruta contra WPS

0 comentarios
Hace un par de días, Stefan Viehbock publicó un whitepaper detallando los fallos en la implementación de Wi-Fi Protected Setup (WPS) que podrían permitir a un atacante realizar un ataque de fuerza bruta para probar todas las combinaciones de PIN posibles con el objetivo de obtener una contraseña WPA/WPA2 en cuestión de horas.
Los fallos de implementación residen en que:

1. la opción de Registro Externo no requiere ningún tipo de autenticación a parte de proveer el PIN correspondiente.

2. el router valida en PIN en dos partes: responde inmediatamente (mensaje EAP-NACK) si los 4 primeros dígitos del PIN son erróneos, y después hace lo propio con los 3 siguientes (el último dígito es un checksum). Esto reduce significativamente las posibles combinaciones: 10^4 (10,000) y 10^3 (1,000) respectivamente

Ahora que está vulnerabilidad se ha echo pública, Tactical Network Solutions LLC (TNS) ha decidido además publicar la herramienta open source Reaver (http://code.google.com/p/reaver-wps), una herramienta que han ido probando y perfeccionando desde hace casi un año.

Reaver realizará un ataque de fuerza bruta contra el AP, primero con la primera parte del PIN y luego con la segunda, realizando intentos para un espacio de claves de tan sólo 11,000 posibilidades.

El uso de esta herramienta nos proveerá por tanto la posibilidad de atacar fácilmente WPS, aspecto que nos ofrecerá claras ventajas respecto a la posibilidad de atacar directamente a WPA:

- Descifrar el PIN WPS es, obviamente, mucho más rápido.
- Una vez que tengamos el PIN WPS inmediatamente podemos recuperar la contraseña WPA, incluso si el propietario la cambia.
- Los puntos de acceso multifrecuencia (2.4/5GHz) se pueden configurar con varias claves WPA. Dado que el PIN WPS es el mismo en distintas frecuencias, el conocimiento del PIN permite a un atacante recuperar todas las claves WPA.

De momento, la única recomendación básica es desactivar WPS y activarlo sólo para cuando queramos añadir nuevos dispositivos...happy hacking!



Fuentes que pueden ayudar a ejecutar esta técnica que de seguro realizare paso a paso en estos dias:

http://www.hackplayers.com/2011/12/reaver-wps-ataques-de-fuerza-bruta.html
http://chikiteam.spanishforo.com/t246-tutorial-reaver-wpa-wifiway-34
http://hwagm.elhacker.net/manual-castellano-reaver/
http://www.ehacking.net/2012/01/reaver-wps-wpawpa2-cracking-tutorial.html
http://xora.org/2012-wpawpa2-cracking-con-reaver-tutorial/
http://www.hackthissite.org/
http://www.hackthissite.org/forums/viewtopic.php?f=24&t=8290&sid=9673d183148f463b4e9b6e523b565cae
http://www.hackthissite.org/forums/viewtopic.php?f=24&t=8235&sid=9673d183148f463b4e9b6e523b565cae

WAVSEP v1.2

0 comentarios

The Web Application Vulnerability Scanner Evaluation Project
 
Estas son algunas características:
 

Project WAVSEP currently includes the following test cases:

Vulnerabilities:
  • Path Traversal/LFI: 816 test cases, implemented in 816 jsp pages (GET & POST)
  • Remote File Inclusion (XSS via RFI): 108 test cases, implemented in 108 jsp pages (GET & POST)
  • Reflected XSS: 66 test cases, implemented in 64 jsp pages (GET & POST)
  • Error Based SQL Injection: 80 test cases, implemented in 76 jsp pages (GET & POST)
  • Blind SQL Injection: 46 test cases, implemented in 44 jsp pages (GET & POST)
  • Time Based SQL Injection: 10 test cases, implemented in 10 jsp pages (GET & POST)
  • Passive Information Disclosure/Session Vulnerabilities (inspired/imported from ZAP-WAVE): 3 test cases of erroneous information leakage, and 2 cases of improper authentication / information disclosure - implemented in 5 jsp pages
  • Experimental Tase Cases (inspired/imported from ZAP-WAVE): 9 additional RXSS test cases (anticsrf tokens, secret input vectors, tag signatures, etc), and 2 additional SQLi test cases (INSERT) - implemented in 11 jsp pages (GET & POST)
False Positives:
  • 7 different categories of false positive Reflected XSS vulnerabilities (GET & POST )
  • 10 different categories of false positive SQL Injection vulnerabilities (GET & POST)
  • 8 different categories of false positive path traversal/LFI vulnerabilities (GET & POST)
  • 6 different categories of false positive remote file inclusion vulnerabilities (GET & POST)
Additional Features:
  • A simple web interface for accessing the vulnerable pages
  • An auto-installer for the mysql database schema (/wavsep-install/install.jsp)
  • Sample detection & exploitation payloads for each and every test case
  • Database connection pool support, ensuring the consistency of scanning results 
Facil instalación:

Installation

(@) Use a JRE/JDK that was installed using an offline installation (the online installation caused unknown bugs for some users).
(1) Download & install Apache Tomcat 6.x
(2) Download & install MySQL Community Server 5.5.x (Remember to enable remote root access if not in the same station as wavsep, and to choose a root password that you remember).
(3) Copy the wavsep.war file into the tomcat webapps directory (Usually "C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps" - Windows 32/64 Installer)
(4) Restart the application server
(5) On WinXP, as long as you are using a high privileged user - you can skip this phase, on Win7, make sure you run the tomcat server with administrative privileges (right click on and execute),and on Ubuntu Linux, run the following commands:
sudo mkdir /var/lib/tomcat6/db
sudo chown tomcat6:tomcat6 /var/lib/tomcat6/db/
(6) Initiate the install script at: http://localhost:8080/wavsep/wavsep-install/install.jsp
(7) Provide the database host, port and root credentials to the installation script, in additional to customizable wavsep database user credentials.
(8) Access the application at: http://localhost:8080/wavsep/
 Estare probandola y comentare que tal su funcionamiento.


Saludos roboticos.

Fuentes:

https://code.google.com/p/wavsep/
http://www.n0where.net/2012/07/wavsep-v12.html

Suricata IDS/IPS 1.2.1 Extracción de ficheros de sesiones HTTP tráfico de red.

0 comentarios
Ya hemos visto en artículos anteriores como instalar, configurar, incluso añadir un sensor suricata a un SIEM Prelude. Esto lo hicimos con la versión 1.0.2 de Suricata.
En esta ocasión instalaremos y configuraremos la versión 1.2.1 de Suricata pero, además, añadiremos la funcionalidad de extracción de ficheros de sesiones HTTP.
Ya hemos hablado en varias ocasiones de la forma que tenemos de extraer ficheros de datos Binarios / Objetos HTTP a partir de una captura de tráfico de red, e incluso la forma de extraer fichero de impresión en red. También la forma de hacerlo con Tcpxtract, Justniffer, Assniffer, con Xplico, etc.
Al lio..

Instalación de Suricata 1.2.1

Yo ya tengo todos los prerequisitos e instalo directamente. Cualquier problema o para una primera instalación de suricata teneis más información sobre instalación y resolución de errores aquí: IDS / IPS Suricata. Instalación, configuración y puesta en marcha.
wget http://www.openinfosecfoundation.org/download/suricata-1.2.1.tar.gz
tar -xvzf suricata-1.2.1.tar.gz
cd suricata-1.2.1
./configure –enable-prelude
–enable-prelude por si usamos suricata como un sensor prelude que es mi caso.
Ahora, si no tememos las carpetas creadas por otra instalación anterior de suricata hacemos:
mkdir /var/log/suricata/
mkdir /etc/suricata
cp suricata.yaml /etc/suricata
cp classification.config /etc/suricata
make
sudo make install
cd /etc/suricata
Vamos a descargar las rules o reglas Emerging-Threats:
wget http://www.emergingthreats.net/rules/emerging.rules.tar.gz
tar xzvf emerging.rules.tar.gz

La extracción de ficheros de sesiones HTTP en suricata se realiza mediante reglas. Un ejemplo de estas reglas (files.rules) las descargaremos y ubicaremos en /etc/suricata/rules :
wget https://redmine.openinfosecfoundation.org/projects/suricata/repository/revisions/master/raw/rules/files.rules
Editamos files.rules y descomentamos las reglas que queramos usar.

Modificación de archivo de configuración suricata.yaml

Editamos /etc/suricata/suricata.yaml
Aunque no es necesario para la extracción de ficheros, yo he realizado la modificación siguiente:
  – pcap-log:
      enabled:  yes
      filename: log.pcap
Para la extracción de ficheros nos hará falta:
  – file:
      enabled: yes
      log-dir: files
      force-magic: no
log-dir files hará que los ficheros extraidos se depositen en /var/log/suricata/files
También en la sección stream:
stream:
  memcap: 32mb
  checksum_validation: no
  inline: no                  
  reassembly:
    memcap: 64mb
    depth:  
    toserver_chunk_size: 2560
    toclient_chunk_size: 2560
depth en 0, es decir, sin límite.
En cualquier caso también nos hará falta:
  • threshold-file: /etc/suricata/threshold.config
  • default-rule-path: /etc/suricata/rules/
  • classification-file: /etc/suricata/classification.config
  • reference-config-file: /etc/suricata/reference.config
En la sección libhtp:
libhtp:
   default-config:
     personality: IDS
     # Can be specified in kb, mb, gb.  Just a number indicates
     # it’s in bytes.
     request_body_limit: 0
     response-body-limit: 0
   server-config:
     – apache:
         address: [192.168.1.0/24, 127.0.0.0/8, "::1"]
         personality: Apache_2_2
         # Can be specified in kb, mb, gb.  Just a number indicates
         # it’s in bytes.
         request_body_limit: 0
         response-body-limit: 0
     – iis7:
         address:
           – 192.168.0.0/24
           – 192.168.10.0/24
         personality: IIS_7_0
         # Can be specified in kb, mb, gb.  Just a number indicates
         # it’s in bytes.
         request_body_limit: 0
         response-body-limit: 0
En la sección rule-files, que es donde se indican las rules a cargar, comentamos o descomentamos las reglas de nuestro interés y, además, añadimos la regla que anteriormente descargamos files.rules:
 - files.rules
Otras modificaciones pueden ser la ubicación de puertos de servicios que se encuentran con la indicación de puertos por defecto, nuestra HOME-NET, etc.
y listo.
Sobre algunas características de suricata ya escribí algo aquí: IDS / IPS Suricata. Entendiendo y configurando Suricata. Parte I

Extracción de ficheros con suricata.

Ya solo nos queda ejecutar suricata:
sudo suricata -c /etc/suricata/suricata.yaml -r ../pcap1/ids_2.pcap
Vemos la salida de información en consola:
Ejecutando Suricata 1.2.1 para extracción ficheros sesiones HTTPVamos a /var/log/suricata y vemos:
Logs de suricata 1.2.1 en /var/log/suricata y ficheros extraidos en files
Ya, en otro capítulo de Suricata IDS/IPS os hablé de los logs:
IDS / IPS Suricata. Instalación, configuración y puesta en marcha.
Dentro de la carpeta /var/log/suricata/files tendremos una serie de ficheros extraídos de la forma:
Suricata 1.2.1 fichers extraidos.
Tendríamos ficheros de texto, pfd, imágenes .js, etc ,etc ,etc,
Si editamos, por ejemplo, (estaría más a bajo del listado) file.9984.meta:
TIME:              12/07/2011-12:16:52.887378
PCAP PKT NUM:      869016
SRC IP:            195.xxx.152.xx
DST IP:            192.168.101.240
PROTO:             6
SRC PORT:          80
DST PORT:          36908
FILENAME:          /hphotos-xp-cpd4/381174_249112748_148457649_683242_1878105586_a.jpg
MAGIC:             JPEG image data, JFIF standard 1.02, comment: "*"
STATE:             CLOSED
SIZE:              10356
Tenemos información de la extracción respecto a origen, destino, puerto, etc. El archivo meta hace referencia, en este caso a file.9984.
En el explorador veríamos los ficheros:
suricata 1.2.1 extracción ficheros sesiones HTTP.

Relacionado con suricata IDS / IPS:

======
Y hasta aquí por hoy. Hasta lá próxima-

Fuente:https://seguridadyredes.wordpress.com/2012/02/01/suricata-idsips-1-2-1-extraccion-de-ficheros-de-sesiones-http-trafico-de-red/

Wireshark. Herramientas CLI. Datos estadísticos completos de todos nuestros ficheros cap/pcap a CSV / Excel.

0 comentarios
Ya vimos en su momento como obtener información de un determinado fichero pcap / cap con la herramietna CLI de Wireshark Capinfos.
capinfos a csv
En esta ocasión vamos a recopilar información estádistica de todos nuestros ficheros para volcarlo a . archivo .CSV y de este, por ejemplo, a una hoja Excel, LibreOfficce, etc.

En el anterior artículo sobre capinfos os conté:
“Respecto a la información idependiente que podemos sacar de cada fichero tenemos:
  • -t tipo. (porque puede leer varios tipos)
  • -E tipo de encapsulado
  • -c número de paquetes
  • -s tamaño archivo captura
  • -d tamaño archivo datos
  • -u duración captura
  • -a tiempo comienzo y -e final de captura
  • -S los dos datos de comienzo y final
  • Promedios
    • -y promedio datos (in bytes/sec)
    • -i promedio datos (in bits/sec)
    • -z promedio tamaño paquetes (in bytes)
    • -x promedio  paquetes (in packets/sec)
Para formatear los datos, tablas, etc, tenemos una serie de opciones. Las vemos con ejemplos:
Queremos crear una tabla con los datos de tipo, tipo encapsulado, número de paquetes de todos nuestros archivos. Usamos para ello -T para crear la tabla…..”
Pues bien ahora vamos a obtenr una serie de datos de todos nuestros ficheros pcap / cap y lo volcamos a .CSV:
capinfos -tcausx -T -m *.*cap > mis_capturas.csv
el resultado es:
capinfos a csv
una vez que tenemos el archivo .csv, importamos desde una hoja de cálculo:
capinfos a csv
Tendremos de esta forma una relación de todos nuestros ficheros de captura, tipos, fechas, estadísticas ,etc.
===
Hasta aquí por hoy. Hasta la próxima.

fuente:https://seguridadyredes.wordpress.com/2011/03/09/wireshark-herramientas-cli-datos-estadisticos-completos-de-todos-nuestros-ficheros-cappcap-a-csv-excel/

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

0 comentarios
Hemos visto muchas formas de representar el tráfico de red, alertas Snort, scan nmap, etc, de forma gráfica usando AfterGlow y Graphviz (dot, neato, circo, etc).
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:

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

Fuente:https://seguridadyredes.wordpress.com/2011/07/06/representacion-grafica-apache-access-log-con-apache2dot-y-graphviz/

Visualización interactiva de tráfico de red con INAV.

0 comentarios
Seguimos con la serie dedicada a Visualización gráfica de tráfico de red. En esta serie hemos visto InetVis , InetVis para detección de escan de puertos (representación tridimiensional de tráfico de red), NetGrok, Representación gráfica de tráfico de red con Argus Xplot /Jplot, Afterglow, TNV, etc, e icluso geolocalización con Snort / snoge, geolocalización con prelude correlator, Xplico, …

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:
01alfon@alfonubuntu:~$ wget http://inav.scaparra.com/files/server/INAV-Server-0.3.7.tar.gz
02--2011-06-15 18:43:21--  http://inav.scaparra.com/files/server/INAV-Server-0.3.7.tar.gz
03Resolviendo inav.scaparra.com... 69.163.242.195
04Conectando a inav.scaparra.com|69.163.242.195|:80... conectado.
05Petición HTTP enviada, esperando respuesta... 200 OK
06Longitud: 93012 (91K) [application/x-tar]
07Guardando en: «INAV-Server-0.3.7.tar.gz»
08 
09100%[==============================================================>] 93.012      31,2K/s   en 2,9s
10 
112011-06-15 18:43:24 (31,2 KB/s)-«INAV-Server-0.3.7.tar.gz» guardado [93012/93012]
12 
13alfon@alfonubuntu:~$ tar xzvf INAV-Server-0.3.7.tar.gz
14INAV-Server-0.3.7/
15INAV-Server-0.3.7/README.txt
16INAV-Server-0.3.7/server/
17INAV-Server-0.3.7/server/minorVersion.txt
18INAV-Server-0.3.7/server/build.txt
19INAV-Server-0.3.7/server/clientComm.cpp
20INAV-Server-0.3.7/server/inputPlugin.hpp
21INAV-Server-0.3.7/server/edge.hpp
22INAV-Server-0.3.7/server/makefile
23INAV-Server-0.3.7/server/pcapSniffer.hpp
24INAV-Server-0.3.7/server/rectangle.cpp
25INAV-Server-0.3.7/server/ethernet.cpp
26INAV-Server-0.3.7/server/udp.cpp
27INAV-Server-0.3.7/server/log.h
28INAV-Server-0.3.7/server/constants.h
29INAV-Server-0.3.7/server/data.hpp
30INAV-Server-0.3.7/server/snifferData.cpp
31INAV-Server-0.3.7/server/sniffer.h
32INAV-Server-0.3.7/server/node.hpp
33INAV-Server-0.3.7/server/bandwidthMonitor.cpp
34 
35fon@alfonubuntu:~/INAV-Server-0.3.7/server$ make
36g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o clientComm.o clientComm.cpp
37g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o clientCommData.o clientCommData.cpp
38g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o baseData.o baseData.cpp
39g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o snifferData.o snifferData.cpp
40g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o sniffer.o sniffer.cpp
41g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ethernet.o ethernet.cpp
42g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ip.o ip.cpp
43g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o tcp.o tcp.cpp
44g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o packet.o packet.cpp
45g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o filterData.o filterData.cpp
46g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o graphData.o graphData.cpp
47g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o bandwidthMonitor.o bandwidthMonitor.cpp
48g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/semaphore.o ../common/semaphore.cpp
49g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o icmp.o icmp.cpp
50g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o traceroute/tracerouteData.o traceroute/tracerouteData.cpp
51g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o traceroute/tracerouteThread.o traceroute/tracerouteThread.cpp
52g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/commandLineParser.o ../common/commandLineParser.cpp
53g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/xmlParser.o ../common/xmlParser.cpp
54g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o helper.o helper.cpp
55g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o udp.o udp.cpp
56g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/parseCommas.o ../common/parseCommas.cpp
57g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o debugThread.o debugThread.cpp
58g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/mutex.o ../common/mutex.cpp
59g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o ../common/threads.o ../common/threads.cpp
60g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o dataQueue.o dataQueue.cpp
61g++ -ggdb -g3 -D INAV_VERSION=\"0.3.7\"   -c -o inavServer.o inavServer.cpp
62g++ -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
63alfon@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.

fuente:https://seguridadyredes.wordpress.com/2011/06/16/visualizacion-interactiva-de-trafico-de-red-con-inav/
Powered by Bad Robot
Helped by Blackubay