28 de noviembre de 2011

BackTrack 5: Escaneando con OpenVAS y Greenbone Security

Siguiendo con las entradas sobre la configuración de OpenVAS y la introducción a Greenbone Security, vamos a realizar un escaneo de vulnerabilidades de una máquina virtual utilizando el motor de OpenVAS y Greenbone como cliente gráfico. Podemos encontrar más información sobre la arquitectura de Greenbone en el siguiente enlace, hay que tener en cuenta que se trata de una empresa privada que desarrolla sus propias soluciones de seguridad.

Preparando el sistema

En primer lugar actulizamos la lista de NVTs con el comando openvas-nvt-sync


Luego recargamos la base de datos del gestor (OpenVAS Manager) con el comando openvasmd --rebuild. Recordar que cada vez que actualicemos la lista de test, deberemos lanzar el comando anterior para que el gestor cuente con todas las novedades.


Lanzamos el escaner (OpenVAS Scanner) con el comando openvassd y dejamos que carge los plugins. Comentar sobre este paso que no tarda lo mismo que la primera vez (~ 30min) que ejecutamos el escaner aunque el equipo acabe de ser encendido o reiniciado.


Lanzamos el gestor (OpenVAS Manager) y el administrador (OpenVAS Administrator) con los comandos openvasmd y openvasad, ambos en localhost y en los puertos 9390 y 9393 respectivamente.


Lanzamos el demonio de Greenbone Security Assistant con el comando gsad --http-only --listen=127.0.0.1 -p 9392. Como se puede observar, lanzamos el comando para http (también es posible ejecutarlo bajo SSL) en localhost y en el puerto 9392.


Ejecutamos un navegador y apuntamos a locahost en el puerto 9392 para conectarnos a Greenbonse Security Assistant.


Greenbone Security Assistant

Una vez logueados, crearemos un destino (Target) donde lanzar las pruebas, puede ser un nombre de dominio, un rango o una dirección IP.

Pasamos a crear una nueva tarea con New Task donde elegiremos un nombre, un perfíl de escaneo (Scan Config) y un destino (Scan Targets).


Una vez creada, aparecerá la nueva tarea en el apartado Tasks donde podremos ver más detalles antes de ejecutarla.





Una vez arrancada, el primer estado de la tarea será Requested (Solicitada). Podemos ir actualizando la página para ver el proceso de escaneo y los resultados que va obteniendo.


Una vez finalizada, cambiará a estado Done.


Entrando en la tarea podemos ver un resumen con los datos y los reportes realizados.


Entrando en un reporte vemos más detalles sobre los fallos encontrados y podremos filtrar los resultados y ver sólo los que nos interesen. Igualmente podremos exportarlo a los formatos soportados por el sistema.


No he sido capaz de exportar ningún reporte a PDF, a través de Firefox aparece el siguiente error.


Greenbone Security Desktop

Igualmente nos podemos conectar al demonio de Greenbone a través del escritorio de la misma compañia Greenbone Security Desktop. Lanzamos el comando gsd para ejecutar la aplicación.


Nos logueamos al gestor (OpenVAS Manager), localhost:9390, con algún usuario del sistema. Se puede observar en la captura que el sitema ejecuta la versión 2.0 de OMP (OpenVAS Management Protocol).


En primer lugar nos encontramos los reportes del usuario junto con unos gráficos de los mismos.


Podemos también ver en detalle los reportes realizados al igual que los resultados.


También podemos exportar los reportes. Nuevamente, al exportar a PDF e intentar abrir el documento recibo el error.



Podemos también crear nuevas tareas, targets, temporizadores, etc. a través de las pestañas situadas en la parte inferior de la aplicación.



Con esta entrada finaliza, de momento, la serie BackTrack 5 y los posts relacionados con OpenVAS y los diferentes clientes gráficos que tenemos a nuestra disposición. Espero que sea educativo y entretenido para todos los lectores.

Un saludo, Brixton Cat.

25 de noviembre de 2011

BackTrack 5: Introducción a Greenbone Security


Dado que tengo pendiente escribir la entrada sobre la utilización de Greenbone Security como cliente gráfico para utilizar el OpenVAS que configuramos entradas atrás, me ha parecido más util (mientras terminaba de realizarse el escaneo jeje) realizar una introducción con las opciones más reseñables del mismo.

Task

En este apartado, correspondiente a la pantalla de incicio de la aplicación, nos encontramos las distintas tareas (escaneos) que tenemos creados en el sistema, estén o no ejecutándose. Desde el mismo podemos ver la evolución de las tareas, ejecutarlas, crear una nueva, etc.


New Task

Poco tiene que decir este apartado... Será necesario darle un nombre y utilizar un target que deberá estar creado anteriormente, localhost se crea por defecto.


Scan Configs

Son los distintos perfiles que hay creados para escanear los host. Desde aquí podemos crear nuestras propias configuraciones de escaneo dando un nombre y seleccionando si queremos un perfil vacio o completo sobre el que trabajar.

 

Targets

En este apartado creamos los distintos hosts destino sobre los que realizaremos los escaneos. Estos deben ser creados antes de la tarea y una vez creada ésta, no se podrán eliminar hasta haberla borrado previamente.

Es necesario especificar un nombre, una dirección/rango IP o un nombre de host así como un rango de puertos conocidos (por defecto todos con default).


Credentials

En caso que conozcamos un usuario y contraseña válido del sistema podremos usarlos en los servicios SSH y SMB de los targets.


Escalators

En este apartado podemos configurar varios métodos con los que notificar las tareas del sistema a partir de su estado, en base a una condición como el resultado y enviarlos por SNMP, E-mail, etc.


Schedules

Otra opción más que interesante son los temporizadores con los que programar nuestros escaneos y que estos se realicen sin necesidad de nuestra intervención.


Report Formats

Aquí podemos ver y añadir los distintos formatos con los que exportar los reportes: PDF, HTML, CSV, TXT, etc.


Slaves

En caso que tengamos otros gestores (OpenVAS Manager) corriendo en la red, podemos crear esclavos en los que controlar la ejecución de tareas desde un gestor maestro y recibir la información.


Administration

Para poder ver el contenido de estos apartados, deberemos loguearnos con algún usuario administrador; como el creado durante la configuración del sistema.


Users

En este apartado podemos ver y crear usuarios, su rol y las restricciones, eliminarlos, etc.


NVT Feed Management

Desde aquí podremos actualizar la lista de test con los que analizar las vulnerabilidades para contar con todas las novedades de la aplicación.


Scanner Settings

Como su propio nombre indica, en este apartado podemos ver la configuración que está ejecutando el escaner (OpenVAS Scanner), en este caso desde el archivo de configuración /usr/local/etc/openvas/openvassd.conf.


Podeis encontrar más información sobre las funcionalidades y las opciones del sistema en las novedades o en la documentación oficial del proyecto a través de los libros:

- OpenVAS Compendium (En)
- OpenVAS Kompackt (De)

En breve realizaré una entrada explicando el proceso de creación y realización de escaneos así como veremos brevemente un reporte con algunos fallos para el ejemplo.

Un saludo, Brixton Cat.

20 de noviembre de 2011

Cluster Web Alta Disponibilidad: Configuración de recursos

Tengo pendiente hace algún tiempo terminar la serie Cluster Web Alta Disponibilidad y aprovechando que tengo algunas capturas hechas voy a intentar terminarlo lo antes posible y centrarme en otra cosa... Siempre hay que entretenerse con algo xD.

Arrancamos crm en modo interactivo y entramos en el modo configure, para evitar errores y avisos durante la instalación deshabilitamos las propiedades stonith y qourum con los comandos:

property stonith-enable=false
property no-quorum-policy=ignore


Dirección IP

Creamos el recurso con nombre ClusterIP para la dirección IP donde se atenderán las peticiones de la página Web que contendrá el cluster.

Utilizamos el comando primitive ClusterIP ocf:heartbeat:IPaddr2 params ip=192.168.1.250 cidr_netmask=32 clusterip_hash=sourceip op monitor interval=30s. Y confirmamos y aplicamos cambios con commit.


primitive. Para crear recuros.
ClusterIP. Nombre para el recurso.
ocf:heartbeat:IPaddr2. Tipo de recurso para la dirección IP.
params. Parametros del recurso.
ip=192.168.1.250. Dirección IP en decimal que utilizará el cluster.
cidr_netmask=32. Máscara de red en formato CIRD.
clusterip_hash=sourceip.
op monitor. Opción monitor.
interval=30s. Con un intervalo de 30s.

Ahora pasamos a realizar algunas pruebas, primero nos conectamos a la IP del cluster a través del navegador.


Si desactivamos el nodo principal sobre el que está corriendo el recurso y recargamos el navegador podemos ver el cambio.


Servidor Web

Ahora creamos el recurso (WebSite) para el servidor Web con el comando:

primitive WebSite ocf:heartbeat:apache params configfile=/etc/apache2/apache2.conf op monitor interval=1min meta target-role=Started


ocf:heartbeat:apache. Recurso para el servidor Web Apache.
configfile=/etc/apache2/apache2.conf. Archivo de configuración del servidor Web.
meta. Metainformación del recurso.
target-role=Started. Activamos el arranque por defecto.

Aparecen unos warnings sobre los tiempos de arranque y parada del servicio pero seguimos adelante y confirmamos con commit. Podemos observar que el cluster coloca inicialmente los recursos en diferentes nodos para evitar sobrecargar los equipos pero luego lo modificaremos a nuestro antojo.



Si apuntamos el navegador a la IP servidor principal (192.168.1.248) sobre el que está corriendo el recurso ClusterIP, la conexión es reiniciada.


Si apuntamos a la IP del nodo secundario (192.168.1.249) sobre el que corre el recurso del servidor Web (WebSite), la conexión si es aceptada.


Si apuntamos a la IP compartida del cluster (192.168.1.250) nuevamente nos reinicia la conexión dado que el servidor no está corriendo en dicho equipo.


Colocation

Como comentaba anteriormente, el cluster distribuye los recursos entre los nodos para evitar sobrecargar los equipos. Pero es más recomendable aprovecharnos de todas las opciones que incluye crm para ordenar y colocar los distintos recursos del cluster.

Utilizamos el siguiente comando:

colocation Web_on_IP inf: WebSite ClusterIP


colocation. Opción para colocar recursos, grupos, etc.
Web_on_IP. Nombre para identificarlo.
inf:. Palabra clave que obliga a los siguientes recursos.
WebSite ClusterIP. El recurso WebSite estará junto a ClusterIP.

Y lo podemos comprobar con crm_mon.


Ahora cuando apuntamos a la IP del nodo maestro (192.168.1.248) al igual que a la IP del cluster (192.168.1.250) nos responde correctamente.


Y si apuntamos a la IP del esclavo (192.168.1.249) nos reinicia la conexión.


Pruebas finales

Vamos a tumbar el servidor principal donde están corriendo los recursos ClusterIP y WebSite con el comando crm node standby y a través de crm_mon comprobamos que estos son transferidos al servidor secundario; podemos observar que éste es el único que está online y el principal en modo standby.

Si apuntamos a la IP del cluster (192.168.1.250) nos responde correctamente y podemos observar que se trata del nodo secundario.


Si apuntamos a la IP del nodo principal (192.168.1.248) nos reinicia la conexión.


Y si apuntamos a la IP del nodo secundario (192.168.1.249) el cual está ejecutando los recursos del cluster, nuevamente responde correctamente.


En próximas entradas instalaremos y configuraremos DRBD para crear un RAID1 con el que replicar los datos de la página Web.

Un saludo, Brixton Cat.