| Artículos | 01 ABR 2007

Herramientas para test de intrusión

Tags: Histórico
Chema Alonso.
Durante dos meses hemos estado recorriendo el ciclo que comprende desde la recogida de la información que ofrece un sistema informático hasta cómo funciona el ciclo de bug, exploits, parche, scanner de vulnerabilidades. Como último paso, este mes nos centramos en las herramientas principales para la realización de un test de intrusión.

Los Escáneres de Vulnerabilidades
Este tipo de herramientas son la pieza principal cuando se va a realizar una auditoría de seguridad, tanto de caja blanca como de caja negra. Engloban el conjunto de acciones necesarias para identificar la direcciones IP activas, puertos y servicios ofrecidos, la identificación del sistema operativo, el nivel de actualizaciones de seguridad aplicadas e incluso la detección y explotación de las vulnerabilidades encontradas. Dentro de los múltiples escáneres de vulnerabilidades, nos encontramos con algunos más o menos amigables. Es decir, los hay que no ejecutan nunca la fase de intento de explotación de los fallos encontrados, y otros que los prueban como forma normal de trabajo. Esto puede llevar a que la realización de una auditoría con un escáner poco amigable pueda tumbar algún servicio o servidor.
Si estas herramientas realizan todas las fases del proceso, ¿esto quiere decir que todas las herramientas anteriores no son necesarias? No, las herramientas anteriores son mucho más específicas en su función y permiten realizar un escáner de vulnerabilidades completo.
Otra de las características de los escáneres de vulnerabilidades es que no son todos iguales; ni en la detección, ni en la evaluación de los riesgos, ni en la profundidad de los análisis, así que siempre es recomendable la utilización de, al menos, un par de ellos en un buen estudio.

Satán, Santa y Nessus
Aunque previamente habían aparecido muchos escáneres de una vulnerabilidad, quizá el primer escáner de vulnerabilidades completo que se creó fue el conocido como S.A.T.A.N. (Security Administrator Tool for Analyzing Networks). Su nombre creo mucha controversia, así que pronto apareció la versión SAINT (santa, Security Administrator’s Integrated Network Tool), que hoy en día se comercializa a través de www.saintcorporation.com.
El relevo de estos lo cogió Nessus, apareciendo en el año 1998, de la mano de Renaud Deraison, con la primera versión pública del producto. En su origen, y hasta el año 2005, todas las versiones han salido bajo la licencia GPL, pero a finales del año 2005 anunció que la versión 3 sería gratuita (no GPL). Las últimas versiones de Nessus se pueden obtener de la web www.nessus.org. pero pertenecen a la empresa Tenable Network Security, la empresa que Renaud creó en el año 2.002.
Nessus es una de las herramientas preferidas por todos a la hora de realizar un test de penetración en una red, debido a algunas características que repasamos a continuación:
- Actualización y funcionamiento mediante plug-ins: todos los escáneres de vulnerabilidades deben ofrecer un sistema de actualizaciones rápido para detectar las nuevas vulnerabilidades, que aparecen constantemente. En Nessus funciona mediante plug-ins. Bajo demanda podemos actualizar la base de datos de conocimiento antes de cada ejecución, para tener siempre actualizado el repositorio. Para hacer el sistema mucho más flexible en la creación de plug-ins, y para poder ser alimentado con conocimiento propio, podemos crear nuestros propios añadidos utilizando el lenguaje NASL (Nessus Attack Scripting Language).
- Arquitectura cliente/servidor: el sistema está diseñado para funcionar desde distintos clientes contra distintos objetivos. Así, Nessus corre como servicio en la máquina que deseemos, y puede ser utilizado desde cualquier cliente. Esta arquitectura es independiente de plataforma y permite instalar tanto los clientes como servidores en arquitecturas Microsoft y Unix/Linux. Esto va a permitir hacer esfuerzos económicos para tener un mejor servidor, cuya productividad mejorará el servicio a muchos clientes. Además, los objetivos pueden ser casi de cualquier tipo, ya que su base de conocimiento detecta vulnerabilidades en servidores, clientes y dispositivos de red corriendo Windows, Unix/Linux o MacOS.
- Políticas de auditoría: es importante que cualquier escáner de vulnerabilidades permita afinar la política a aplicar, poder elegir los servicios y las vulnerabilidades a auditar (no es lo mismo auditar un servidor de correo que un servidor FTP), que se integre además con los distintos protocolos de comunicaciones (algunos escáneres tienen problemas con los protocolos SSL) y que podamos decidir si queremos un escaneo amigable, o uno agresivo, es decir, que pruebe todo tipo de vulnerabilidades, aún asumiendo que podemos realizar una denegación de servicio (DoS) en algunos servicios o en el sistema. Para ello en Nesuss, cuando creamos o editamos una política, definiremos si queremos una segura o no, y después los plug-ins que queremos que pruebe en el proceso de auditoría.
Como Nesuss es el software utilizado por antonomasia, nos vamos a detener un poco más en su funcionalidad.

Realización de una auditoría con Tenable Nessus 3
Tras haber descargado, activado e instalado el producto, lo primero que tenemos que hacer es actualizar la base de datos de plug-ins. Si es la primera vez que lo arrancamos lo preguntará por sí mismo. En caso contrario, tenemos una herramienta para invocar la actualización en cualquier momento. Una vez configurado el servidor, elegimos la dirección IP y el puerto por el que va a escuchar el servicio de Nessus. Eventualmente, para conexiones remotas, deberíamos generar la lista de usuarios a los que se les permite la conexión con este servidor.
Una vez creados los usuarios, será necesario crear las políticas de auditoría ajustadas a nuestros entornos. Para ello arrancamos la herramienta de scanner de vulnerabilidad y seleccionamos la opción de Manage Policies para crear una nueva. Posteriormente tendremos dos opciones de configuración principal, en primer lugar deberemos seleccionar las opciones de configuración generales de la política. Esa lista se configurará en primera instancia especificando si se trata de una política segura o no. Si decidimos que la política sea segura, no se lanzará ningún plugin que pueda dañar el servicio. Además, es importante configurar en estas opciones las propiedades de las credenciales a utilizar, la carga que se va a realizar del servidor y las opciones especificas de rutas, ubicaciones y características que se conozcan del servidor, para poder afinar el uso de los plug-ins. Es aquí donde se nota la destreza de un buen auditor de seguridad.
La otra parte a afinar son directamente los plug-ins. Para ello, cuando creamos una política, deberemos elegir que es lo que queremos buscar, ya que no tiene sentido realizar búsqueda de fallos locales en Gentoo cuando estamos auditando en remoto un Windows Server 2003 R2. Para facilitar esta gestión, todos los plug-ins están agrupados en categorías, y podremos añadir o quitar categorías o directamente plug-ins. La ejecución de muchos de los plug-ins se realizará teniendo en cuenta las configuraciones definidas previamente en la política.
De todos y cada uno de los plug-ins que acompañan Nessus hay una ficha de info

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información