Lección 2: Montando un HIDS con OSSEC
div style="position:relative;height:0;padding-bottom:56.25%">
Ejercicio: Preparar el entorno para el resto de actividades
En esta lección se configurará OSSEC como servidor/agente, la forma recomendada cuando se desean proteger varias máquinas. En este caso, el papel de servidor lo realizará base, los agentes (las máquinas a proteger) serán dmza e inta, y los atacantes serán exta (ataques externos) e intf (ataques internos, es decir, desde la red corporativa). Por tanto, para realizar las actividades será necesario arrancar las máquinas UML siguientes: fw, exta, dmza, inta e intf.
Se recomienda, además, restaurar la copia de seguridad inicial que viene con NETinVM ("uml_machines_2016-04-01_14-19_initial.tgz") para evitar que los cambios realizados en otras actividades del curso puedan interferir con el trabajo a realizar en esta lección.
Aviso
Al restaurar una copia de seguridad se elimina el estado actual de las UML. Por lo tanto, se recomienda realizar una copia de seguridad antes.
Acciones a realizar:
- Realizar, si no se ha hecho antes, una copia del estado actual y etiquetarlo adecuadamente renombrando el fichero resultante.
- Restaurar la copia de seguridad inicial.
- Editar el guión "uml_run_my_uml.sh" para que solamente se ejecuten las máquinas indicadas.
- Lanzar las máquinas UML usando el icono "Run my UMLs".
- Comprobar que efectivamente se han puesto en marcha las máquinas esperadas.
Además, para que base pueda desempeñar su papel de estación de trabajo del analista deberá ser capaz de recibir los mensajes de los agentes. Para ello sería necesario abrir el puerto 1514 de UDP. Sin embargo, puesto que las interfaces tap0, tap1 y tap2 que conectan a base con las máquinas UML forman parte de la red interna del cortafuegos de openSUSE, no será necesario realizar ningún cambio en la configuración del cortafuegos de base.
También será necesario que el analista pueda leer los correos electrónicos que genere OSSEC. Puesto que los correos los genera el servidor, bastará con que cualquier usuario del sistema pueda enviar correos al resto de los usuarios del sistema. Ésta es la configuración por defecto de base, así que lo único que será necesario es configurar un cliente de correo. Aunque pueden usarse otros clientes, a continuación se describe cómo configurar el cliente gráfico kmail.
Acciones recomendadas:
- Arrancar KMail por primera vez y rellenar la información solicitada por el asistente:
- Primera pantalla:
- "Full Name": User 1
- "E-mail address": user1@base.example.net
- No poner contraseña
- Desmarcar "Find provider settings on the Internet"
- Seleccionar "Next"
- Segunda pantalla:
- Seleccionar como "Account type": MailBox
- Seleccionar "Next"
- Tercera pantalla:
- Introducir como "URL": /var/mail/user1
- Seleccionar "Next"
- Cuarta pantalla y última:
- Seleccionar "Finish"
- Primera pantalla:
- Comprobar la configuración:
- Como usuario no privilegidado, en una terminal de base, ejecutar la orden:
date | mail -s "Prueba" user1@localhost - Comprobar que llega un correo a kmail con asunto "Prueba" y con contenido la fecha y la hora del momento en que se haya ejecutado la orden anterior. (Puede ser necesario presionar en "Next", en la barra de herramientas de KMail, para que se muestren los mensajes).
- Como usuario no privilegidado, en una terminal de base, ejecutar la orden:
- Arrancar KMail por primera vez y rellenar la información solicitada por el asistente:
---------------------------------------------------------------------------------------------
Ejercicio: Instalación de OSSEC en modo servidor/agentes
Obtención del programa OSSEC
Lo primero es obtener una copia del programa, disponible a través de su página web: http://www.ossec.net. El enlace directo a la página de descargas es: http://www.ossec.net/?page_id=19. Una vez en la página se debe seleccionar la versión "Server/Agent 2.8.3 – Linux/BSD" y su suma de comprobación (Checksum).
Acción a realizar: descargar el programa OSSEC (versión 2.8.3) y su suma de comprobación.
(Si todo ha ido bien, deben haber dos ficheros en la carpeta "Downloads" del directorio inicial de user1 en base, "ossec-hids-2.8.3.tar.gz" y "ossec-hids-2.8.3-checksum.txt").
Comprobación de la integridad del programa
Los hashes MD5 y SHA1 de "ossec-hids-2.8.3.tar.gz" están incluidos en el fichero "ossec-hids-2.8.3-checksum.txt". Para comprobar que "ossec-hids-2.8.3.tar.gz" no ha sufrido cambios durante la descarga, ambos hashes deben coincidir con los que se generen a partir del fichero descargado con los algoritmos MD5 y SHA1. La forma de generar los hashes sería:
md5sum ossec-hids-2.8.3.tar.gz
sha1sum ossec-hids-2.8.3.tar.gz
Acción a realizar: comprobar la integridad del programa descargado.
Instalación y configuración de OSSEC en el servidor
Este apartado debe realizarse como administrador del sistema (root) en base, por lo que lo primero es lanzar una terminal y, en ella, convertirse en administrador. (El resto de acciones de este apartado deberán realizarse en esta terminal).
Acción a realizar: convertirse en administrador en una terminal (sugerencia: usar "su -").
Lo siguiente es extraer el programa, compilarlo, configurarlo e instalarlo. La extracción se puede hacer de la forma habitual ("tar zxf /home/user1/Downloads/ossec-hids-2.8.3.tar.gz"), mientras que el resto de pasos se realizan ejecutando el fichero "install.sh" de la carpeta "ossec-hids-2.8.3" recién creada. Por ejemplo, ejecutando "sh ossec-hids-2.8.3/install.sh".
Durante la ejecución del programa de instalación, se debe seleccionar la instalación en modo servidor, utilizando las opciones por defecto; eso sí, teniendo cuidado de proporcionar una dirección de correo válida para recibir las notificaciones (usar "user1@localhost") y definiendo 127.0.0.1 como IP del servidor SMTP.
Acción a realizar: configurar e instalar OSSEC en modo servidor en base.
Finalmente, queda por poner en marcha el servidor de OSSEC. Para ello, tal y como sugiere el mismo programa, basta con ejectutar la orden "/var/ossec/bin/ossec-control start". Si todo funciona correctamente, dicha orden nos informará de que se han puesto en marcha diferentes módulos y, al final, que el arranque se ha completado. La puesta en marcha de un servidor genera una alerta de nivel 3 que debería traducirse en un correo electrónico recibido por "user1@localhost".
Acción a realizar: poner en marcha el servidor OSSEC en base y comprobar que se recibe el correo electrónico de notificación correspondiente.
Instalación y configuración de OSSEC en los agentes
La instalación en modo agente requiere acceso al programa OSSEC (fichero "ossec-hids-2.8.3.tar.gz"). La forma más sencilla de compartirlo entre base y los agentes es copiar dicho fichero al directorio "/home/user1/uml/mntdirs/tmp", al que los agentes (máquinas UML en este ejercicio) tienen acceso como el directorio local "/mnt/tmp".
Acción a realizar: como usuario normal, en base, copiar el fichero "ossec-hids-2.8.3.tar.gz" en la carpeta "/home/user1/uml/mntdirs/tmp".
El resto de este apartado debe realizarse como administrador del sistema (root) en cada uno de los agentes. A modo de ejemplo, se indica a continuación cómo realizar la instalación y configuración en inta, proceso que habrá que repetir posteriormente en dmza.
Acción a realizar: usando la terminal correspondiente, entrar como usuario root en inta.
Lo siguiente es extraer el programa, compilarlo, configurarlo e instalarlo. La extracción se puede hacer de la forma habitual ("tar zxf /mnt/tmp/ossec-hids-2.8.3.tar.gz"), mientras que el resto de pasos se realizan ejecutando el fichero "install.sh" de la carpeta "ossec-hids-2.8.3" recién creada. Por ejemplo, ejecutando "sh ossec-hids-2.8.3/install.sh".
Durante la ejecución del programa de instalación, se debe seleccionar la instalación en modo agente, proporcionando la dirección IP del servidor (10.5.2.1 en el caso de inta, en el caso de dmza será 10.5.1.1).
Acción a realizar: configurar e instalar OSSEC en modo agente en inta.
La comunicación entre el servidor y los agentes es cifrada y autentificada. Por este motivo, para cada agente es necesario crear una clave de autentificación en el servidor, exportarla, e importarla en el cliente.
A continuación se describe el mecanismo para inta. (Este mismo mecanismo debe ser repetido posteriormente para dmza teniendo cuidado de usar el identificador, nombre y dirección IP adecuados).
- Dar de alta a inta en el servidor. Para ello es necesario:
- Ejecutar la orden "/var/ossec/bin/manage_agents" como root en base, que es donde está el servidor.
- Seleccionar 'A' (añadir un agente).
- Proporcionar la información para inta: Nombre: inta, Dirección IP: 10.5.2.10, ID 001. (Tras revisar los datos introducidos, confirmar que se desea añadir el agente).
- Generar y exportar una clave de autenticación para inta. Para ello, dentro del mismo programa del paso anterior:
- Seleccionar 'E' (extraer una clave para un agente).
- Introducir el ID de inta (habitualmente 001).
- Copiar la clave al portapapeles.
- Seleccionar 'Q' (salir del programa).
- Relanzar el servidor OSSEC en base para que tenga en cuenta al nuevo agente. Para ello basta con ejecutar la orden "/var/ossec/bin/ossec-control restart".
- Importar la clave en el agente (inta, en este caso). Para ello, en la terminal de inta en la que se tiene abierta la sesión como administrador:
- Ejecutar el programa "/var/ossec/bin/manage_agents".
- Seleccionar 'I' (importar clave del servidor).
- Pegar la clave copiada en el paso anterior.
- Revisar la información y confirmar.
- Seleccionar 'Q' (salir del programa).
Acción a realizar: registrar a inta como agente en el servidor (base), generar una clave para inta e importarla en inta, siguiendo el mecanismo descrito.
En este punto, el agente inta está preparado para poderse conectar con el servidor base y comenzar a funcionar como agente del IDS, enviando las alertas al servidor. Por tanto, solamente queda poner en marcha OSSEC en inta. Como en el caso del servidor, es suficiente con ejecutar "/var/ossec/bin/ossec-control start". La puesta en marcha de un agente también genera una notificación que se debe traducir en un mensaje de correo electrónico dirigido a "user1@localhost".
Acción a realizar: poner en marcha el servidor OSSEC en inta y comprobar que se recibe el correo electrónico de notificación correspondiente.
A continuación, será necesario repetir el proceso de configuración como agente OSSEC en dmza, para completar el escenario de estar protegiendo una red de ordenadores. Es necesario tener en cuenta que la dirección IP de dmza es 10.5.1.10, que pertenece a la red DMZ y que, en esa red, el servidor base tiene la IP 10.5.1.1.
Acción a realizar: configurar dmza como agente OSSEC, comprobando que finalmente se recibe el correo electrónico de confirmación de que el nuevo agente se ha conectado al servidor.
Comprobación final de la instalación
Finalmente, para comprobar que la configuración es correcta (o para depurar los posibles problemas), se puede usar la orden "/var/ossec/bin/agent_control -l" (debe ser ejecutada como root en base). La opción "-l" solicita un listado de los agentes disponibles (registrados con el servidor). A continuación se muestra un ejemplo de sistema correctamente configurado (con base, inta y dmza registrados como agentes):
base:~ # /var/ossec/bin/agent_control -l OSSEC HIDS agent_control. List of available agents: ID: 000, Name: base (server), IP: 127.0.0.1, Active/Local ID: 001, Name: inta, IP: 10.5.2.10, Active ID: 002, Name: dmza, IP: 10.5.1.10, Active List of agentless devices: base:~ #
Acción a realizar: comprobar el listado de agentes disponibles.
Limpiando datos temporales de las UML
Para dar por finalizado el ejercicio, conviene limpiar todos los datos temporales generados durante la instalación de OSSEC en las UML. Así, las copias de seguridad serán más reducidas. Para ello, lo único que hay que hacer es borrar el directorio "ossec-hids-2.8.3" de inta y de dmza.
Acción a realizar: borrar los datos temporales en inta y dmza.
Ejercicio: realizando una copia de seguridad
En las actividades siguientes se modificará el estado de las UML con acciones como instalar programas o simular diferentes tipos de ataques. Puesto que en este punto se dispone de una instalación limpia de los agentes, se recomienda realizar una copia de seguridad.
Antes de hacerla, es conveniente recordar que:
- Se debe haber borrado el directorio "ossec-hids-2.8.3" en inta y dmza.
- Se deben parar las máquinas.
Acciones a realizar: realizar una copia de seguridad del estado de las UML. (En caso de duda, se recomienda revisar el apartado sobre copias de seguridad).
La copia de seguridad debería tener unos 25 MiB, aproximadamente.
Una vez realizada la copia, solamente queda volver a arrancar las máquinas (con el icono "Run my UMLs") y comprobar que los agentes vuelven a registrarse correctamente con el servidor.
Acciones a realizar: arrancar las UML con "Run my UMLs" y comprobar que los agentes vuelven a conectarse con el servidor.
Ejercicio: Primeras alertas con OSSEC
Para mostrar el funcionamiento de OSSEC, en esta actividad se realizarán acciones habituales que pueden generar alertas, y se aprenderá a valorar si deben ser consideradas, o no, como un intento de intrusión.
Ejemplo 1: Acceso físico de un usuario
Una de las cosas que genera una alerta es el hecho de que un usuario inicie una sesión directamente en la consola del sistema. Para comprobarlo, basta con ir a una de las terminales de las máquinas protegidas (inta y dmza) y conectarse como uno de los usuarios disponibles (user1 y root).
Este simple hecho genera una alerta, pero lógicamente no necesariamente supone una intrusión (o intento de intrusión), ya que la alerta se genera incluso aunque se introduzca la contraseña correctamente a la primera. Por este motivo, a la alerta se le asigna un nivel 3 (successful/authorized events), y no se notifica por correo electrónico.
La forma de ver todas las alertas que recibe el servidor es consultar el fichero "/var/ossec/logs/alerts/alerts.log" de base. Una forma cómoda de supervisar las modificaciones que se van produciendo es usar la orden "tail" con la opción "-f".
Acciones a realizar:
- En una terminal de base, como root, comenzar a supervisar las alertas que recibe el servidor OSSEC.
- En una terminal de inta, iniciar sesión en el sistema como usario root.
- Identificar la alerta, tratando de interpretar la información que proporciona.
Ejemplo 2: Instalación de un programa nuevo
Otra acción que genera una alerta es instalar paquetes de software en un sistema. En este caso, esta actividad, aunque no supone necesariamente que haya una intrusión, sí es un evento significativo que debe ser comprobado cada vez que produzca. Dicho de otro modo, es deseable que el sistema nos avise cada vez que se instalen nuevos programas. Por este motivo, el nivel asignado a esta alerta es el 7, y se genera un aviso por correo electrónico (en la configuración por defecto de OSSEC).
Acciones a realizar:
- En una terminal de base, como root, comenzar a supervisar las alertas que recibe el servidor OSSEC.
- (Si no se tiene abierta). En una terminal de inta, iniciar sesión en el sistema como usario root.
- (Si se ha iniciado). Identificar la alerta para no confundirla con las siguientes.
- Instalar el programa "screen" en inta mediante la orden "apt-get install screen".
- Identificar las alertas, tratando de interpretar la información que proporcionan y correlacionarla con los mensajes de "apt-get".
- Comprobar que se recibe el correo electrónico correspondiente a las alertas recién generadas.
---------------------------------------------------------------------------------------
Ejercicio: Probando la respuesta activa
En este ejercicio se realizarán acciones para provocar la respuesta activa de OSSEC, identificando los cambios que realiza en el sistema.
Ejemplo 1: Ataque de fuerza bruta mediante SSH
Una forma de provocar la respuesta activa de SSH es tratar de adivinar nombres de usuarios y contraseñas en una máquina usando prueba y error (fuerza bruta). Las medidas de respuesta activa de OSSEC se pueden consultar ejecutando la orden "/var/ossec/bin/agent_control -L" como root en el servidor (base). Por defecto, OSSEC modifica la configuración de tcpwrappers (fichero "/etc/hosts.deny") y de IPTABLES.
Acciones a realizar:
- Desde intf, simular un ataque de fuerza bruta a inta. Para ello, probar a conectarse como los usuarios uno, dos, tres..., hasta que no sea posible seguir probando.
- En base, comprobar que se han recibido las alertas y la notificación por correo electrónico.
- En inta, comprobar que se han añadido reglas de IPTABLES que bloquean el acceso desde intf.
- En inta, comprobar que se ha añadido a intf al fichero "/etc/hosts.deny" para evitar el acceso a cualquier servicio desde dicho nodo.
Ejemplo 2: Tratar de adivinar nombres de ficheros o directorios en un servidor web
Otro ejemplo consiste en intentar descargar información no enlazada desde un servidor web, nuevamente usando prueba y error. Para ello, una utilidad muy conveniente es el programa wget, que permite descargar contenido desde la línea de órdenes y automatizarlo mediante un sencillo guión de una línea:
for x in $(seq 1000); do wget www.example.net/foo/$x; done
Para simular un ataque de este tipo, se usará una máquina externa, en este caso exta, que simulará ser un nodo cualquiera de Internet. El ataque se lanzará sobre el servidor web de NETinVM (ww.example.net, que es un alias de dmza).
Acciones a realizar:
- Desde exta, simular el ataque descrito sobre www.example.net (dmza). Para ello, usar el guión anterior.
- En base, comprobar que se han recibido las alertas y la notificación por correo electrónico.
- En dmza, comprobar que se han añadido reglas de IPTABLES que bloquean el acceso desde exta.
- En dmza, comprobar que se ha añadido a exta al fichero "/etc/hosts.deny" para evitar el acceso a cualquier servicio desde dicho nodo.
Francisco Javier Cervigon Ruckauer
No hay comentarios:
Publicar un comentario