Proyecto Final de Curso: Sistema Detector de...

Proyecto Final de Curso:

Sistema Detector de Intrusos

20154/2015

Administración de Sistemas Informáticos y Redes

Autor: Manuel Alberto González Dueñas

Proyecto Final de Curso: Sistema Detector de Intrusos


2


Contenido Defensa de la Iniciativa de Proyecto ............................................................................................. 3

¿Qué es un IDS?............................................................................................................................. 3

Introducción al Proceso de Instalación ......................................................................................... 4

HIDS OSSEC .................................................................................................................................... 6

Agentes OSSEC ............................................................................................................................ 12

Fichero de Configuración de OSSEC ............................................................................................ 19

Inicio y Comprobación de funcionamiento ................................................................................. 24

NIDS Snort ................................................................................................................................... 25

Barnyard ...................................................................................................................................... 31

Base de Datos Snort .................................................................................................................... 33

BASE ............................................................................................................................................ 35

Inicio Automático ........................................................................................................................ 37

Conclusiones ............................................................................................................................... 39

Bibliografía .................................................................................................................................. 40



3

Defensa de la Iniciativa de Proyecto

He decidido realizar este Proyecto porque, como he podido observar estos últimos años, los

proyectos realizados por otros compañeros suelen repetirse de un año a otro o por lo menos

suelen ser similares.

Como no me llamaba la atención ninguno de los que yo conocía de años anteriores, y

aprovechando que escasean los proyectos relacionados con la Seguridad Informática, el cual es

un campo que me llama bastante la atención, he decidido realizar uno orientado a ello.

He preguntado a mis compañeros que cursan este año el módulo de Seguridad y Alta

Disponibilidad, sobre qué temas están tratando y me ha llamado la atención la parte en la que

utilizaban el programa de tipo IDS llamado SNORT.

Yo no conocía este programa ya que el curso 2013/2014, cuando cursé dicho módulo no lo

utilizamos.

He investigado un poco sobre los IDS, utilidad, tipos y ámbitos de implementación.

Me ha parecido un tema bastante interesante y creo que sería un buen proyecto a realizar ya

que los IDS son una herramienta muy útil para un Administrador de Sistemas como seremos

nosotros en un futuro cercano, ya que nos facilita la detección de ataques e intrusiones en

nuestro sistema o incluso en la propia red de la empresa o entorno sobre el que trabajemos,

permitiéndonos tomar medidas preventivas.

Además también podremos analizar todo el tráfico de red, lo cual nos permitirá optimizarla

según las necesidades.

¿Qué es un IDS?

Un IDS o Sistema de Detección de Intrusos (Intrusion Detection System), es un programa que monitoriza la actividad del sistema, con la finalidad de detectar el acceso o accesos no autorizados a una máquina o una red. Se pueden diferenciar dos tipos de IDS:

HIDS – Host Intrusion Detection System: El cual actúa en la propia máquina donde se encuentra instalado, buscando constantemente cualquier signo de actividad sospechosa mediante un análisis continúo del sistema.

NIDS – Network Intrusion Detection System: El cual actúa a nivel de red, analizando el tráfico de esta en busca de cualquier tipo de actividad sospechosa. (Incluye el tráfico local).



4

Estos sistemas, tienen dos modos de actuación diferentes:

Modo Pasivo – También conocido como “Sistemas Pasivos”, se dedican a registrar en una base de datos cualquier actividad similar a una acción o acceso no autorizado.

Modo Activo – También conocido como “Sistema Reactivo”, se dedica a registrar en una base de datos y bloquear cualquier posible intrusión o acción no autorizada en el sistema.

Introducción al Proceso de Instalación

En este proyecto haremos uso de dos sistemas IDS diferentes.

Para el IDS de tipo HIDS, he utilizado el software OSSEC, ya que es un software Open Source y

es compatible tanto para Linux como para Windows.

Para el IDS de tipo NIDS, he utilizado el software SNORT, ya que está disponible bajo licencia GPL, es gratuito y funciona bajo plataformas Windows, GNU/Linux y Mac OS. Y es uno de los más usados. Para la parte del HIDS, que será la primera que expondré, utilizaré una máquina que hará de servidor y en la cual estará instalado OSSEC sobre Linux Debian. Debido a que OSSEC trabaja mediante el método Agente/Servidor, utilizaré otras dos máquinas que tendrán el papel de Agentes o “Clientes”. Una será Windows 7 y otra Linux Debian. La extructura prevista será algo tal que así:



5

En ambos clientes, instalaré OSSEC en modo Agente para que estos puedan enviar toda la información relativa a intrusiones y alertas al servidor, que es donde se almacenarán todas estas incidencias en forma de registros en una base de datos MySQL. Finalmente, instalaré una herramienta web que ayudará a visualizar las alertas y datos almacenados en la base de datos de una forma más clara y sencilla para el administrador. Para la parte del NIDS, utilizaré una máquina que hará de servidor, en la cual instalaré SNORT sobre Linux Debian. SNORT trabajará a nivel de red, por lo que no tiene unos equipos o agentes específicos que monitorizar, sino que monitorizará toda la red incluyéndose al mismo. Por lo tanto, y para que nos hagamos una idea de cómo podría ser la estructura, sería algo tal que así:

Una observación a tener en cuenta es que el propio SNORT podría actuar de cortafuegos, por lo que se podría sustituir el cortafuego del esquema por la máquina de SNORT si esta está debidamente configurada para realizar dicha función. Dicho caso no es el nuestro. La información monitorizada será almacenada en una base de datos MySQL y además incluiré una herramienta web para facilitarnos el análisis y visualización de los datos recogidos y almacenados en la base de datos. Y ahora, una vez aclarados y explicados los objetivos del proyecto, procederé, sin más dilación, a llevar a cabo la explicación paso a paso de la realización de este proyecto.



6

HIDS OSSEC

Como ya he explicado anteriormente, OSSEC es un IDS basado en Host. Su funcionamiento está basado en el análisis de logs o registros, comprobación de integridad, detección de rootkits, supervisión del registro de Windows, alertas en tiempo real y respuesta activa. A partir de la versión 2.6, OSSEC es compatible con bases de datos MySQL, y a partir de la 2.7 es posible obtener información GeoIP. Yo usaré la versión 2.8 con una base de datos MySQL y como añadido, intentaré instalar una herramienta que nos proporcione información sobre la Geolocalización de las IPs. Por último, instalaré una interfaz web para el análisis posterior de la información recogida en la base de datos. Esta interfaz llamada “AnaLogi” es muy intuitiva y clara a la hora de mostrar los datos. NOTA: En esta documentación tan solo mostraré capturas de aquellas pantallas, pasos o situaciones que crea más relevantes e importantes o para ayudar al entendimiento de algún paso más complejo de lo habitual. En primer lugar, instalaré todas las dependencias necesarias para el correcto funcionamiento del escenario que vamos a crear. Haciendo uso del siguiente comando, instalaremos los paquetes de mysql y sus librerías, un compilador de paquetes, el cual será necesario para la instalación de OSSEC y un instalador. “#aptitude install mysql-server libmysqlclient-dev gcc make” Durante el proceso de instalación, se nos requerirán ciertos datos para la correcta configuración de la base de datos tales como contraseñas para el usuario root o administrador de la base de datos. Los introduciremos a nuestra elección.



7

Ahora nos descargaremos los paquetes necesarios correspondientes a OSSEC y a la herramienta GeoIP.

“#wget http://www.ossec.net/files/ossec-hids-2.8.tar.gz”

“#wget http://www.maxmind.com/download/geoip/api/c/GeoIP-1.4.8.tar.gz”

NOTA: Si alguno de los comandos “wget” no funciona debido a que no encuentra la dirección de destino, podemos descargar dichos paquetes desde la web oficial.

Primero vamos a instalar el paquete GeoIP. Para ello primero extraemos el contenido del paquete descargado.

“tar xzvf GeoIP-1.4.8.tar.gz”

Seguidamente, accedemos a la carpeta que surge de la extracción

“#cd GeoIP-1.4.8”

Ejecutamos el siguiente comando para llevar a cabo la autoconfiguración del programa mediante el script de configuración que este trae.

“#./configure”

Por último, una vez configurado, procedemos a compilar e instalar con los siguientes comandos.

“#make” “#make install”

Descargamos también las base de datos que usará GeoIP

“#wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz”

“#wget ttp://geolite.maxmind.com/download/geoip/database/GeoLiteCityv6-beta/GeoLiteCityv6.dat.gz”

Y las descomprimimos.

“#gzip -d GeoLiteCity.dat.gz”

“#gzip -d GeoLiteCityv6.dat.gz”

http://www.ossec.net/files/ossec-hids-2.8.tar.gz

http://www.maxmind.com/download/geoip/api/c/GeoIP-1.4.8.tar.gz

http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz



8

Ahora procedemos a la instalación de OSSEC, empezando por descomprimir el paquete que nos bajamos al principio.

#tar xzvf ossec-hids-2.8.tar.gz

Seguidamente vamos a incorporar a mysql la estructura de necesaria para OSSEC:

Creamos la base de datos con el usuario root:

#mysql -u root -p

mysql> create database ossec;

mysql> grant INSERT,SELECT,UPDATE,CREATE,DELETE,EXECUTE on ossec.* to ossec@localhost;

mysql> set password for ossec@localhost=PASSWORD(‘ossec’);

mysql> flush privileges;

mysql> quit

Añadimos el esquema de tablas que trae OSSEC a la base de datos que acabamos de crear, utilizando el script de creación que incluye:

“# cd ossec-hids-2.8/src/os_dbd”

“# mysql -u root -p ossec < mysql.schema”

“cd..”

“cd..”

Ahora procederemos a instalar OSSEC ya estando en su carpeta de instalación.

Haciendo uso de los siguientes comandos, en especial con “make setgeoip” y “make setdb”, garantizamos que en la instalación quede compilado con las opciones correctas de acceso a la base de datos mysql y que pueda acceder a la información de la herramienta GeoIP y las bases de datos de la misma, las cuales descargamos anteriormente.

#cd src

#make setgeoip

#make setdb

#cd ..

#./install.sh



9

Una vez ejecutemos el último comando, comenzará el proceso de instalación de OSSEC, en el cuál se nos requerirán varios datos y se nos presentarán varias opciones a elegir, las cuales explicaré a continuación paso a paso.

Se ejecutará el script de instalación, que nos preguntará el idioma en el que deseamos instalar OSSEC.

Tendremos que introducir el código de idioma, que en nuestro caso es “es” que pertenece a “español”.

A continuación nos preguntará que tipo de instalación deseamos hacer, en nuestro caso vamos a hacer la instalación de servidor. Escribimos “servidor” y seguimos con la instalación.

La instalación de OSSEC en tipo servidor sólo se puede hacer en sistemas operativos GNU/Linux.

Nota: El modo local hace que el host se proteja a el mismo únicamente. La diferencia con el modo servidor es que el servidor puede gestionar todo el proceso de los agentes (clientes) centralizándolo y descargando los registros de actividad de las demás máquinas de las cuales recibe los logs y eventos de sistema.

Tras esto, la instalación configurará las variables de entorno del sistema que usará y te preguntará el directorio de instalación de OSSEC (y muestra uno por defecto “/var/ossec”) podemos introducir uno manualmente o dejar el que está por defecto. Ahora la instalación empezará a configurar el sistema OSSEC y nos hará algunas preguntas:

Si deseamos recibir notificaciones por email (para lo cual necesitaríamos usar un servidor de correo electrónico, puedes instalar uno en la misma máquina por ejemplo postfix)

Si queremos hacer uso del servidor de integridad del sistema. Es una parte importante del HIDS y es recomendable hacer uso del mismo, este demonio es el encargado de monitorizar y reportar cambios en los archivos de sistema.

Si queremos activar el sistema de detección de rootkits. Un rootkits es un malware con el objetivo de ganar privilegios en el sistema, por lo tanto deberíamos de activarla.

Si deseamos activar la respuesta activa del HIDS. Las respuestas activas nos permiten definir unas acciones que se ejecutarán de forma automática para evitar una posible intrusión o ataque tanto usando el /etc/host.deny o iptables (o ipfilter en caso de BSD o Solaris)

IPs a la lista blanca. La “lista blanca” es un archivo donde definimos unas IPs en las que “confiamos”, por defecto se agrega la puerta de enlace de la máquina, y te pregunta si deseas añadir alguna IP más a “lista blanca”.

Si deseas activar las alertas desde un syslog remoto

10

Una vez respondemos todo, el instalador compilará durante unos minutos, una vez compile nos dirá como iniciar y como parar OSSEC.

Para iniciar OSSEC, usaremos el siguiente comando: #/var/ossec/bin/ossec-control start Y para pararlo, usaremos el comando: #/var/ossec/bin/ossec-control stop El archivo de configuración de Ossec se encuentra en “/var/ossec/etc/ossec.conf”. Por último el instalador nos dice que para conectar un agente al servidor, debemos agregarlos (a los agentes) a el servidor, pudiendo hacerlo desde el programa “manage_agents” (/var/ossec/bin/manage_agents).

Ahora tenemos que copiar la base de datos de la herramienta “GeoIp” en el directorio “/etc” de OSSEC.

#cp GeoLiteCity*.dat /var/ossec/etc/

Una vez copiada la base de datos, empezamos a modificar el fichero de configuración de OSSEC para el acceso a la BD y a GeoIP.

#nano /var/ossec/etc/ossec.conf

En la sección global añadimos lo siguiente:

<global>  <geoip_db_path>/etc/GeoLiteCity.dat</geoip_db_path> <geoip6_db_path>/etc/GeoLiteCityv6.dat</geoip6_db_path> </global>

Y en la sección de alertas esto:

<alerts>  <use_geoip>yes</use_geoip> </alerts>

Agregamos la sección database_output

<database_output> <hostname>127.0.0.1</hostname> <username>ossec</username> <password>ossec</password> <database>ossec</database> <type>mysql</type>



11

</database_output>

Habilitamos el acceso a la base de datos de OSSEC:

# /var/ossec/bin/ossec-control enable database # /var/ossec/bin/ossec-control restart

Ahora que tenemos instalado y configurado el servidor OSSEC, procederemos a instalar la herramienta gráfica para el análisis de los datos.

Lo primero de todo es instalar los paquetes necesarios para el correcto funcionamiento de esta herramienta.

Apache2, ya que necesitamos un servidor web

Php5, lenguaje que usa la herramienta web.

Php5-mysql, para la comunicación entre la herramienta y la base de datos

Git, para poder obtener el código de la herramienta web de los repositorios de código “Git”.

#aptitude install apache2 php5 php5-mysql git

Nos movemos a la carpeta /var/www

# cd /var/www/

Descargamos AnaLogi haciendo uso de la utilidad “Git” con el siguiente comando:

#git clone https://github.com/ECSC/analogi.git

Asignamos como propietario el usuario “www-data” de apache del directorio Analogi:

#chown www-data:www-data analogi -R

Nos cambiamos al directorio de Analogi:

#cd /var/www/analogi

Renombramos el fichero db_ossec.php.new

# mv db_ossec.php.new db_ossec.php

Lo editamos para configurar la conexión a la base de datos OSSEC.

#nano db_ossec.php

Tenemos que modificar las siguientes líneas para que queden de la siguiente forma, pero con nuestros valores:



12

define ('DB_USER_O', 'ossec'); define ('DB_PASSWORD_O', 'ossec'); define ('DB_HOST_O', '127.0.0.1'); define ('DB_NAME_O', 'ossec');

Si lo deseamos podemos crear un virtual host para esta interface web, pero ya podemos acceder a la interface web mediante la dirección http://ip_servidor/analogi.

El paso siguiente sería agregar los diferentes agentes de OSSEC que deseamos y ya veríamos los cambios en la interface conforme vayan sucediendo eventos y alertas.

Agentes OSSEC

Instalar OSSEC en los equipos o máquinas que actuarán como agentes y que estarán

monitorizadas es muy fácil.

La base es la misma. Tendremos que ejecutar el mismo instalador que usamos en el servidor,

solo que cuando nos dé a elegir entre instalación en modo “Agente” o “Servidor”, esta vez

tenemos que elegir, obviamente, el modo “Agente”.

El resto de preguntas las contestamos de la misma forma que cuando instalamos el servidor

OSSEC.

En el caso de que uno de los agentes sea una máquina Windows, el proceso sería diferente.

Tendríamos que descargarnos el instalador de OSSEC para Windows, ejecutarlo y seguir el

asistente de instalación.

http://ip_servidor/analogi



13

Una vez tengamos OSSEC instalado en todos los equipos Agentes, tenemos que añadirlos,

sincronizarlos, agregarlos, conectarlos etc., como queramos llamarlo, al servidor OSSEC.

Esta conexión y por consiguiente, la transferencia de información entre los Agentes y el

Servidor, irá cifrada. Para ello necesitamos una clave. OSSEC nos da la posibilidad de generar la

clave automáticamente, para cada uno de los Agentes que estén conectados a él.

En la siguiente imagen podemos observar el Administrador de Agentes en el servidor OSSEC.

Antes de poder generar la clave, tenemos que añadir los Agentes al servidor para que este

pueda generar las claves a raíz de sus datos e IP.

Para ello pulsamos la opción (A).



14

Una vez elegida dicha opción, nos aparecerá la siguiente pantalla, donde tendremos que

introducir el Nombre, IP e ID del nuevo Agente. (El ID no es necesario que lo indiquemos, ya

que por defecto nos asigna el siguiente de la lista).

Una vez introducidos todos los datos, nos pedirá confirmación, como podemos comprobar en

la siguiente pantalla.



15

Aceptamos y ya tendremos el Agente agregado al servidor. Este proceso debemos llevarlo a

cabo para cada uno de los diferentes Agentes, tanto Windows como Linux.

Ahora ya podemos obtener las claves de los Agentes para añadirlas. Las claves no son más que

un juego de claves “Pública/Privada” que genera el servidor para poder realizar la conexión

con los agentes de forma cifrada y segura.

La clave que nosotros extraemos es la clave Pública que genera el servidor a raíz de su clave

privada. (Para cada agente genera un juego de llaves diferente).

Para obtener las claves, tan solo tendremos que elegir esta vez, la opción (E) del menú

principal del Administrador de Agentes en el servidor OSSEC.

Nos aparecerá la siguiente ventana, donde tendremos que indicar el ID del Agente del cual

queramos obtener su clave:



16

Una vez seleccionado el ID, aceptamos y nos mostrará la clave generada para que la copiemos.

Tan solo tendríamos luego que añadir dicha clave generada por el servidor al su respectivo

Agente y reiniciar ambas máquinas.

Para añadir la clave al Agente, tan solo nos vamos a la máquina Agente y ejecutamos el Administrador de Agentes.

Aquí solo nos mostrará dos opciones:



17

Seleccionamos la opción (I) y nos aparecerá la siguiente ventana:

En esta pantalla tendremos que pegar la clave obtenida anteriormente en el servidor. Una vez introducida, aceptamos y ya tenemos el cliente totalmente unido y sincronizado con el servidor.

En Agentes Windows, el proceso seria parecido, solo que a la hora de introducir dicha calve en el Agente, el proceso sería mucho más fácil y simple ya que contamos con interfaz gráfica.



18

En las siguientes imágenes lo podemos comprobar más detalladamente:

Solo debemos introducir la IP del servidor y la clave que el servidor nos generó para el Agente.

Ahora que ya tenemos todo lo relativo a OSSEC instalado, echaremos un vistazo rápido a la estructura de directorios. En la siguiente imagen podemos ver un diagrama de la misma con los directorios y ficheros más relevantes en la configuración y uso de OSSEC.



19

Fichero de Configuración de OSSEC

Ahora vamos a ver la estructura del fichero de configuración de OSSEC y explicaré un poco

algunas de sus secciones.

Como acabo de decir, este fichero se divide en diferentes secciones, en las cuales se realizan

las configuraciones de diferentes elementos y funciones.

La primera de ella es la parte de la “configuración global”. En ella podemos configurar el

servidor de correo (en el caso de que lo tengamos) y el envío de alertas mediante este a

nuestro correo.

Aquí podemos ver un poco el contenido de esta sección global de la configuración:

<code><global>

<email_notification>yes</email_notification>

<email_to>[email protected]</email_to>

<smtp_server>10.0.0.10</smtp_server>

<email_from>ossec@alertasossec</email_from>

</global>

</code>

La siguiente sección es la sección “rules”, donde podemos añadir o quitar reglas de OSSEC. Los ficheros que contienen las reglas de OSSEC se encuentran en el directorio “/var/ossec/rules” mostrado en la imagen de la estructura de directorios.

A continuación, un ejemplo del apartado “rules”:

<rules> <include>rules_config.xml</include> <include>pam_rules.xml</include> <include>sshd_rules.xml</include> … <include>asterisk_rules.xml</include> <include>ossec_rules.xml</include> <include>attack_rules.xml</include> <include>local_rules.xml</include> </rules>

La siguiente parte del archivo de configuración es la encargada de definir las opciones del sistema de integridad de archivos, donde se definen los directorios que se deben omitir o los que se deben de comprobar, cada que tiempo, etc (El tiempo se especifica en segundos).

Aquí podemos ver un ejemplo:



20

<!– Frequency that syscheck is executed – default to every 22 hours –> 79200 <!– Directories to check verifications) –> /etc,/usr/bin,/usr/sbin /bin,/sbin <!– Files/directories to ignore –> /etc/mtab /etc/mnttab … <!– Windows files to ignore –> C:\WINDOWS/System32/LogFiles C:\WINDOWS/Debug …

Como podemos observar, aparecen ficheros y directorios tanto de la máquina Linux como de la máquina Windows.

Ahora veremos cómo está configurado el sistema de detección de rootkits. En estos archivos de texto, se definen las normas para detectar rootkits, troyanos, etc.. :

<rootcheck> <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files> <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans> <system_audit>/var/ossec/etc/shared/system_audit_rcl.txt</system_audit> <system_audit>/var/ossec/etc/shared/cis_debian_linux_rcl.txt</system_audit> <system_audit>/var/ossec/etc/shared/cis_rhel_linux_rcl.txt</system_audit> <system_audit>/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt</system_audit> </rootcheck>

El siguiente apartado del fichero de configuración corresponde a los host de la lista blanca (los que definimos con la instalación. En nuestro caso sólo está nuestro propio host, dominio y puerta de enlace:

<global> <white_list>127.0.0.1</white_list> <white_list>^localhost.ossec$</white_list> <white_list>10.0.0.1</white_list> </global>

También podemos ver el apartado donde se definen que el syslog está activado:

<remote> <connection>syslog</connection> </remote>

Ahora vienen dos aparatados importantes. El apartado de los “script o comandos” que ejecutará la respuesta activa que habilitamos en la instalación y el apartado de configuración de la misma.



21

Este por ejemplo ejecuta el script host-deny.sh, y tiene un tiempo predefinido:

<command> <name>host-deny</name> <executable>host-deny.sh</executable> <expect>srcip</expect> <timeout_allowed>yes</timeout_allowed> </command>

Este es el apartado de configuración de la respuesta activa, (que usa los comandos que hemos visto en el apartado anterior) en este caso el script con la regla host-deny que se corresponde con el comando host-deny:

<!– Active Response Config –> <active-response> <!– This response is going to execute the host-deny - command for every event that fires a rule with - level (severity) >= 6. - The IP is going to be blocked for 600 seconds. –> <command>host-deny</command> <location>local</location> <level>6</level> <timeout>600</timeout> </active-response>

Por último, veremos la zona en la que se especifican los ficheros o archivos locales que se monitorizarán:

<!– Files to monitor (localfiles) –> <localfile> <log_format>syslog</log_format> <location>/var/log/messages</location> </localfile> <localfile> … </localfile>

OSSEC cuenta con una escala de niveles de alerta para clasificar por nivel de importancia cada una de las incidencias y alertas que se van produciendo.

En este apartado, podemos configurar a partir de qué nivel se generará una alerta y a partir de cual será necesario enviar una notificación por email.

<alerts> <log_alert_level>6</log_alert_level> <email_alert_level>8</email_alert_level> </alerts>



22

Y aquí podéis ver la lista con cada uno de los diferentes niveles de alerta y una pequeña descripción de cada uno:

Level 0: Ignorado, no se tomaron medidas. Se utiliza principalmente para evitar falsos positivos. Estos eventos se analizan antes que todos los demás y son eventos sin importancia para la seguridad. Level 2: Sistema de notificación de baja prioridad. Sistema de notificación de mensajes de estado o que no tienen ninguna importancia para la seguridad. Level 3: El éxito / eventos autorizados. Intentos exitosos de acceso, permitido en el firewall, etc Level 4: Sistema de errores de baja prioridad. Los errores relacionados con malas configuraciones o dispositivos no utilizados / aplicaciones. No tienen importancia para la seguridad y generalmente son causados por las instalaciones por defecto o pruebas de software. Level 5: Los errores generados por contraseñas perdidas, las acciones denegadas, etc. Level 6: Ataques de baja relevancia. Indican un gusano o un virus que no ofrecen ninguna amenaza para el sistema, tales como un gusano de Windows ataca a un servidor Linux. Level 9: Error de fuente no válida. Incluyen los intentos de inicio de sesión como un usuario desconocido o de una fuente no valida. El mensaje podría tener importancia para la seguridad, especialmente si se repite. También se incluyen los errores en relación con el administrador o root. Level 10: Múltiples errores generados por el usuario. Incluyen múltiples contraseñas incorrectas, varios intentos fallidos, etc Puede ser síntoma de un ataque, o podría ser simplemente que un usuario olvidó sus credenciales. Level 12: Alta importancia del evento. Incluyen mensajes de error o de advertencia del sistema, kernel, etc. Podría indicar un ataque contra una aplicación específica. Level 13: Errores inusuales (importancia alta).Los patrones comunes de ataque, como un intento de desbordamiento de búfer, uno más grande de mensaje syslog normal, o una cadena de URL más larga de lo normal. Level 14: Evento de alta seguridad e importancia. Por lo general el resultado de la correlación de las normas de ataque múltiple e indicativa de un ataque. Level 15: Ataque de éxito. Muy pequeña posibilidad de falsos positivos. La atención inmediata es necesaria.

Para terminar, os muestro como sería una notificación de alerta enviada por correo:

Asunto: OSSEC Notification – (mailserver) 10.0.0.10 – Alert level 10

OSSEC HIDS Notification. 2015 May 31 14:42:53

Received From: (mailserver) 10.0.0.10->/var/log/messages Rule: 4151 fired (level 10) -> “Multiple Firewall drop events from same source.” Portion of the log(s):

May 31 09:42:53 mailserver kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth101.0 MAC=ff:ff:ff:ff:ff:ff:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.71 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=44524 DF PROTO=TCP SPT=60274 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA017340C0000000001030302) May 31 09:42:53 mailserver kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth101.0



23

MAC=ca:be:a0:93:57:90:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.66 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=64585 DF PROTO=TCP SPT=60269 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA017340B0000000001030302) May 31 09:42:50 testserver kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth102.1 MAC=00:18:51:c8:67:78:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.68 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=63362 DF PROTO=TCP SPT=60271 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 testserver kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth102.1 MAC=ff:ff:ff:ff:ff:ff:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.71 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=44522 DF PROTO=TCP SPT=60274 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 testserver kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth102.1 MAC=00:18:51:c8:67:78:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.68 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=63362 DF PROTO=TCP SPT=60271 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 testserver kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth102.1 MAC=ff:ff:ff:ff:ff:ff:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.71 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=44522 DF PROTO=TCP SPT=60274 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 testserver1 kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth122.1 MAC=ff:ff:ff:ff:ff:ff:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.71 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=44522 DF PROTO=TCP SPT=60274 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 testserver1 kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth122.1 MAC=00:18:51:a61:8f:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.67 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=56871 DF PROTO=TCP SPT=60270 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 testserver1 kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth122.1 MAC=ff:ff:ff:ff:ff:ff:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.71 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=44522 DF PROTO=TCP SPT=60274 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 testserver1 kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth122.1 MAC=00:18:51:a61:8f:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.67 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=56871 DF PROTO=TCP SPT=60270 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 mailserver kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth101.0 MAC=ff:ff:ff:ff:ff:ff:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.71 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=44522 DF PROTO=TCP SPT=60274 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302) May 31 09:42:50 mailserver kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth101.0 MAC=ca:be:a0:93:57:90:00:a0:c5:44:49:8f:08:00 SRC=59.42.249.53 DST=200.55.146.66 LEN=60 TOS=0×00 PREC=0×00 TTL=47 ID=64583 DF PROTO=TCP SPT=60269 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA01728530000000001030302)

–END OF NOTIFICATION



24

Como podemos observar en la información de cabecera, se trata de una alerta por múltiples peticiones TCP desde un mismo origen, las cuales son rechazadas.

Inicio y Comprobación de funcionamiento

Una vez instalado, debemos iniciar los demonios de OSSEC en las máquinas (al reiniciar se inician automáticamente con ella).

También podemos iniciarlos manualmente con el siguiente comando:

“#/var/ossec/bin/ossec-control restart”

Vamos a probar el funcionamiento intentando hacer un ataque de un agente a otro mediante conexiones ssh inválidas. OSSEC lo detectará como un ataque de fuerza bruta (analizando las secuencias de ataque y comparándolas con las de su base de datos) y automáticamente tomará medidas.

En el caso de que tengamos instalado y configurado un servidor de correo, nos enviará un correo con la información de la alerta. (Dependiendo de cómo hayamos configurado el apartado de las alertas que vimos anteriormente, será más flexible o menos flexible a la hora de enviar alertas).

Desde el cliente Windows probaremos algo mucho más sencillo. Haremos un ping al servidor, al Agente Linux o a si mismo para que OSSEC lo monitoree y nos los muestre.

En la siguiente imagen, podemos comprobar como OSSEC ha registrado las dos pruebas anteriores y, tras almacenar las alertas en la base de datos, se nos muestra mediante la herramienta Analogi:

Quizás la imagen es un poco pequeña y no se vea con claridad, pero si nos fijamos se pueden observar las líneas de la gráfica y en la parte inferior una leyenda.



25

Ya hemos visto OSSEC y su funcionamiento como HIDS. Ahora es el turno del otro tipo de IDS, el cual ya comenté al principio de este documento.

Como NIDS utilizaré “Snort”, el cual trabajará junto a una base de datos MySql, al igual que con OSSEC y como herramienta gráfica utilizaré “BASE”, una herramienta un poco menos vistosa que “AnaLogi” y quizás más compleja de entender, pero la finalidad es mostrar diferentes recursos para el mismo propósito.

Sin más dilación, comencemos.

NIDS Snort

Snort es otro Sistema de detección de intrusos de tipo NIDS (trabaja en red a diferencia de OSSEC, que tiene un comportamiento más “interno”), por lo tanto trabaja escaneando y analizando los paquetes que circulan en la red, identifica posibles ataques según el comportamiento de los mismos y dispone de unas reglas de actualización diaria que hacen de él una herramienta importante en el mundo de la seguridad informática.

La manera más básica de instalar snort permite el almacenamiento de logs de sistema, pero voy a intentar guardar esos logs en una base de datos y verlos desde algún administrador web.

Para comenzar, instalaremos los pre-requisitos para que la instalación y funcionamiento de Snort se lleve a cabo satisfactoriamente.

En primer lugar, actualizaremos la lista de repositorios con el siguiente comando:

“#aptitude update”



26

Una vez actualizada la lista de paquetes, procedemos a instalar los paquetes necesarios para la

instalación y el correcto funcionamiento con el siguiente comando:

“# aptitude –y install apache2 apache2-doc autoconf automake bison ca-certificates

ethtool flex g++ gcc gcc-4.4 libapache2-mod-php5 libcrypt-ssleay-perl libmysqlclient-dev

libnet1 libnet1-dev libpcre3 libpcre3-dev libphp-adodb libssl-dev libtool libwww-perl make

mysql-client mysql-common mysql-server ntp php5-cli php5-gd php5-mysql php-pear

postfix sysstat usbmount”

Con el comando anterior, estaremos instalando:

Apache

Automake (herramienta para compilación e instalación de paquetes)

Gcc (compilador)

Php

Mysql

Postfix

Librerias y dependencias necesarias

Ahora vamos a instalar los pre-requisitos para instalar Snort. Son unas librerías necesarias para el funcionamiento de Snort a la hora de obtener paquetes de la red:

Descargamos el paquete: “# cd /usr/src & & wget http://www.tcpdump.org/release/libpcap-1.6.1.tar.gz “ Descomprimimos, extraemos y nos movemos a la carpeta resultante: “# tar -zxf libpcap-1.6.1.tar.gz “ “ # cd libpcap-1.6.1” Auto configuramos e Instalamos la Librería: “# ./configure --prefix=/usr “ “#Make” “#make install “ Descargamos el paquete: “# cd /usr/src & & wget http://libdnet.googlecode.com/files/libdnet-1.12.tgz” Descomprimimos, extraemos y nos movemos a la carpeta resultante: “# tar -zxf libdnet-1.12.tgz “

http://www.tcpdump.org/release/libpcap-1.6.1.tar.gz

http://libdnet.googlecode.com/files/libdnet-1.12.tgz



27

“ cd libdnet-1.12” Auto configuramos e Instalamos la Librería: “# ./configure --prefix=/usr --enable-shared” “make” “make install” Descargamos el paquete: “# cd /usr/src & & wget https://www.snort.org/downloads/snort/daq-2.0.2.tar.gz” Descomprimimos, extraemos y nos movemos a la carpeta resultante: “# tar -zxf daq-2.0.2.tar.gz” “cd daq-2.0.2 “” Auto configuramos e Instalamos la Librería: “# ./configure” “make” “make install” Actualizamos la ruta de las librerías compartidas: # echo >> /etc/ld.so.conf /usr/lib # echo >> /etc/ld.so.conf /usr/local/lib & & ldconfig

Una vez tengamos todos los pre-requisitos instalados, es el momento de pasar a la instalación y configuración de Snort.

https://www.snort.org/downloads/snort/daq-2.0.2.tar.gz



28

Haciendo uso del siguiente comando, nos descargamos el fichero de configuración de Snort sobre el que más a delante haremos algunos cambios: “# wget http://labs.snort.org/snort/2962/snort.conf” Ahora descargamos Snort: “# wget https://www.snort.org/downloads/snort/snort-2.9.6.2.tar.gz” NOTA: Si alguna descarga da error, podemos copiar el enlace y descargarlo manualmente y luego pasarlo a la máquina sobre la que estemos trabajando. Una vez descargado Snort, pasamos a descomprimirlo y seguidamente nos movemos al interior del directorio resultante de la descompresión. En este directorio se encuentran todos los ficheros necesarios para la compilación y posterior instalación de Snort. “# tar -zxf snort-2.9.6.2.tar.gz & & cd snort-2.9.6.2” Configuramos el paquete, lo compilamos y lo instalamos con el siguiente comando: “# ./configure --enable-sourcefire & & make & & make install “ A continuación, y una vez este Snort Instalado, tendremos que crear la siguiente estructura de directorios donde se almacenarán los “losg”, los ficheros de lista blanca y negra, las reglas etc: “# mkdir /usr/local/etc/Snort /usr/local/etc/snort/rules /var/log/Snort /var/log/barnyard2 usr/local/lib/snort_dynamicrules “ Ahora, crearemos los ficheros que Snort usará como lista blanca y lista negra para sus reglas:

“# touch /usr/local/etc/snort/rules/white_list.rules “ “# touch /usr/local/etc/snort/rules/black_list.rules” “# touch /usr/local/etc/snort/sid-msg.map” Ahora llega un paso muy importante. Tenemos que crear el usuario y el grupo “Snort” ya que solo dicho usuario y grupo podrá acceder a los ficheros y directorios de Snort. # groupadd snort & & useradd -g snort snort Una vez creados, teniendo en cuenta que el usuario Snort debe de pertenecer al grupo Snort, tenemos que modificar el usuario y grupo propietarios del directorio “/var/log/Snort” y “/var/log/barnyard2”, para que Snort pueda trabajar con los ficheros de “log” que contendrán: # chown snort:snort /var/log/snort /var/log/barnyard2 El siguiente paso es de vital importancia, ya que tenemos que copiar los ficheros con las siguientes extensiones a los directorios indicados para que podamos instalar “barnyard2”, el cual explicaré más adelante, cuando lleguemos a su instalación.

http://labs.snort.org/snort/2962/snort.conf

https://www.snort.org/downloads/snort/snort-2.9.6.2.tar.gz



29

# cp /usr/src/snort-2.9.6.2/etc/*.conf* /usr/local/etc/snort # cp /usr/src/snort-2.9.6.2/etc/*.map /usr/local/etc/snort # cp /usr/src/snort.conf /usr/local/etc/snort

Por último y antes de pasar a comprobar si todo funciona correctamente, tenemos que configurar algunos parámetros de Snort para que todo esté correcto y no tengamos ningún inconveniente.

Lo primero es configurar el fichero “Snort.conf”, fichero principal de configuración de Snort, donde tendremos que modificar las siguientes líneas:

Para modificarlo, hacemos uso del siguiente comando:

“# nano /usr/local/etc/snort/snort.conf “ “Line #45 - ipvar HOME_NET 10.0.0.0/24 Line #48 - ipvar EXTERNAL_NET !$HOME_NET Line #104 - var RULE_PATH ./rules Line #109 - var WHITE_LIST_PATH ./rules Line #110 - var BLACK_LIST_PATH ./rules Line #293 - max_gzip_mem 104857600 (esto hemos de añadirlo al final de la línea) Line #521 - output unified2: filename snort.log, limit 128 (esta línea tendremos que añadirla nosotros) “ Por último, tenemos que descomentar o borrar todas las líneas “include $RULE_PATH” excepto la referente al fichero “local.rules”, ya que lo que se pretende es que Snort solo utilice las reglas que nosotros especifiquemos en dicho fichero. Y ahora modificamos el fichero anterior, “local.rules”, con el siguiente comando: “# nano /usr/local/etc/snort/rules/local.rules” Y añadimos la siguiente línea o regla de Snort, la cual tan solo hará que se registren todos los paquetes ICMP que pasen por la red, es decir, los más comúnmente conocidos como “PING”. “alert icmp any any -> $HOME_NET any (msg:"ICMP test"; sid:10000001; rev:1;) “

Bien, pues ya está todo listo. Ahora solo queda hacer una prueba para ver si funciona todo. Para ello ejecutamos el siguiente comando:

“# /usr/local/bin/snort -A console -q -u snort -g snort -c /usr/local/etc/snort/snort.conf -i eth0” Con este comando lo que estamos haciendo es iniciar Snort e indicarle que escanee y monitorice toda la red desde la interfaz “eth0”.



30

Ahora si hacemos un ping desde cualquier máquina hacia cualquier máquina:



31

Siempre y cuando ambas se encuentren en la misma red que Snort, empezaremos a ver lo siguiente:

Snort captura todos los paquetes ICMP pertenecientes al ping que hemos realizado, en tiempo real. Todo esto se guarda en un fichero de log, pero nosotros lo que queremos es que se guarde en una base de datos para, posteriormente, poder analizarlo con facilidad.

Barnyard

En entornos en los que un IDS Snort tiene que procesar una gran cantidad de tráfico es muy

posible que su rendimiento se vea afectado y acabe descartando paquetes.

Esto es debido a que Snort no procesa el siguiente paquete hasta que no termina de escribir la

alerta en la base de datos. Este proceso de escritura es lento si hablamos de que es necesario

una conexión TCP y un insert en la base de datos por cada alerta.

Para estos casos se puede configurar Snort para que escriba las alertas en un fichero local en

lugar de hacerlo directamente en red.

En el paso anterior, cuando configurábamos el fichero “Snort.conf”, añadimos la línea “output

unified2: filename snort.log, limit 128”.



32

Con esta línea diremos a Snort que escriba las alertas en un fichero con nomenclatura base

“snort.log” con un tamaño máximo de 128MB cada uno.

Como veis se trata del formato “unified2”, un formato binario optimizado que permitirá a

nuestro querido "cerdito" generar alertas más rápidamente.

Pero si tenemos las alertas en un fichero local, ¿cómo las escribimos entonces en la base de

datos?

Para esta tarea tenemos “Barnyard2, un intérprete “open source” de los ficheros de salida en

formato “unified2.”

Una vez aclarado lo que es “Barnyard” y para lo que sirve, pasamos a instalarlo y configurarlo.

Lo primero de todo es descargarlo, para lo cual haremos uso del siguiente comando:

“# wget https://github.com/firnsy/barnyard2/archive/master.tar.gz” Una vez descargado lo descomprimimos y nos movemos al interior de la carpeta que se genera en la descompresión: “# tar -zxf master.tar.gz && cd barnyard2-* “ Con el siguiente comando, lo reconfiguramos, compilamos e instalamos con la configuración compatible con “mysql”, que será la base de datos que usaremos : “# autoreconf -fvi -I ./m4 & & ./configure --with-mysql --with-mysql-libraries=/usr/lib/i386-linux-gnu & & make & & make install” Movemos el fichero de configuración de Barnyard2 al directorio donde se encuentra instalado Snort: “# mv /usr/local/etc/barnyard2.conf /usr/local/etc/snort “

Y copiamos los esquemas de mysql al directorio de instalación:

“# cp schemas/create_mysql /usr/src” Por último, modificamos el fichero de configuración de barnyard2 que copiamos anteriormente al directorio de Snort, modificando las líneas indicadas a continuación y de la siguiente manera: “# nano /usr/local/etc/snort/barnyard2.conf” Line #27- “/usr/local/etc/snort/reference.config” Line #28 - “/usr/local/etc/snort/classification.config”

https://github.com/firnsy/barnyard2/archive/master.tar.gz



33

Line #29 - “/usr/local/etc/snort/gen-msg.map” Line #30 - “/usr/local/etc/snort/sid-msg.map” Line #227 - “output alert_fast” Al final del fichero, añadir la siguiente línea: “output database: log, mysql, user=snort password=<snort> dbname=snort host=localhost”

En esta línea le estamos indicando la base de datos y sus credenciales, que deberá de usar para introducir las alertas y para poder consultarlas posteriormente.

Base de Datos Snort

Ahora vamos a proceder a instalar y configurar la base de datos MySql, donde se almacenarán

los registros de las alertas de Snort gracias a Barnyard.

Para ello, lo primero que debemos de hacer es acceder a “mysql” con el usuario “root”:

“# mysql -u root –p” La contraseña del usuario “root” de mysql será la que asignamos en la instalación de mysql. Una vez dentro, ejecutamos las siguientes sentencias para crear la base de datos: “mysql> create database snort;” Una vez creada, tendremos que crear un usuario llamado “Snort” con privilegios de creación, inserción, lectura y actualización de la base de datos que acabamos de crear. Este usuario es al que hicimos referencia en el fichero de configuración de “barnyard2” en la línea donde especificamos el nombre y credenciales de la base de datos que estamos creando y configurando ahora. “mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;” Una vez creado el usuario, tenemos que asignarle una contraseña, para ello ejecutamos lo siguiente: “mysql> SET PASSWORD FOR snort@localhost=PASSWORD('snort');” Recordemos que la contraseña ha de ser la misma que la que especificamos en el fichero de configuración.



34

Ahora que ya tenemos creada la base de datos, usamos el siguiente comando para seleccionarla y empezar a trabajar con ella: “mysql> use snort;”

Una vez seleccionada, tendríamos que crear las tablas que Snort necesita, pero por suerte, Snort incluye un fichero que contiene un script con el esquema de tablas necesarias, el cuál usaremos para crearlas automáticamente: Para ello debemos de usar el siguiente comando: “mysql> source /usr/src/create_mysql” Una vez ejecutado, podemos ver si efectivamente se han creado las tablas con el siguiente comando: “mysql> show tables;” Por último, salimos de la base de datos y de mysql con la orden “exit”: “mysql> exit” Ahora, para comprobar si todo funciona correctamente y Barnyard hace bien su trabajo introduciendo datos en la base de datos, tenemos que iniciar Snort y Barnyard. Usaremos el siguiente comando: Para Snort: “# /usr/local/bin/snort -q -u snort -g snort -c /usr/local/etc/snort/snort.conf -i eth0 &” Para barnyard2: “# /usr/local/bin/barnyard2 -c /usr/local/etc/snort/barnyard2.conf -d /var/log/snort -f snort.log -w /usr/local/etc/snort/bylog.waldo –C /usr/local/etc/snort/classification.config & ” Una vez iniciados, debemos hacer un ping para comprobar si Barnyard recoge la información de los ficheros de log de Snort y la almacena en la base de datos. Para ver si la almacena, podemos usar el siguiente comando: “# mysql -uroot -p -D snort -e "select count(*) from event" “ Con él, nos aparecerá el número de registros del a tabla eventos. Si no hay ninguno es porque

algo falla, quizás las credenciales de la base de datos sería lo más probable.



35

Si todo ha ido bien, debería mostrar el número de registros igual al número de paquetes ICMP

detectados.

Por último, tan solo nos quedaría configurar apache para instalar la herramienta web BASE, la cual nos ayudará en el análisis de la información.

BASE

Lo primero que haremos es configurar apache para que BASE funcione correctamente.

Crearemos un nuevo sitio donde instalar BASE, para ello debemos copiar y habilitar un sitio por

defecto con el siguiente comando:

“# cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled” Modificamos el fichero “php.ini” para que la línea 452 quede de la siguiente forma: “# nano /etc/php5/apache2/php.ini” “Line #452 – error_reporting = E_ALL & ~E_NOTICE “ Habilitamos el módulo ssl, para que el sitio use una conexión segura: “# a2enmod ssl” Por último ejecutamos estas dos líneas y reiniciamos apache:



36

“# pear config-set preferred_state alpha & & pear channel-update pear.php.net” “# pear install --alldeps Image_Color2 Image_Canvas Image_Graph” “# /etc/init.d/apache2 restart” Con esto ya tenemos listo apache para su correcto funcionamiento con BASE. Ahora procedemos a instalarlo. Descargamos BASE con el siguiente comando: # wget http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.5/base-1.4.5.tar.gz Tras descargarlo, lo descomprimimos y copiamos la carpeta generada en el sitio que hemos creado para base: “# tar -zxf base-1.4.5.tar.gz & & cp -r base-1.4.5 /var/www/base” Asignamos los permisos al sitio: “# chmod 777 /var/www/base” Estos permisos son solo momentáneos, una vez esté todo funcionando tendremos que asignar unos permisos menos permisivos. Ahora abrimos el navegador e introducimos la IP de la máquina seguida de “/base”: https://10.0.0.128/base Nos aparecerá el asistente de instalación en el que iremos indicando las siguientes opciones: Clicamos en continuar y elegimos el idioma. Como no está el español, yo he seleccionado inglés. Nos pedirá una ruta para adodb. Introducimos la siguiente: “Path to adodb: /usr/share/php/adodb” Pulsamos en continuar y nos pedirá los siguientes datos, lo cuales tenemos que dejarlos tal y como indico: “Database Name: snort Database Host: localhost Database Port: dejar en blanco Database User Name: snort Database Password: snort” Los valores que hemos introducido son los que se corresponden con la base de datos para Snort y sus credenciales.

http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.5/base-1.4.5.tar.gz

https://10.0.0.128/base



37

Clicamos en crear base de datos. Por último solo nos queda logarnos en BASE y podremos ver las alertas generadas por los paquetes ICMP anteriores. Si pulsamos en una de ellas nos mostrará lo siguiente: “Snort Alert [1:10000001:0] “ Y con esto ya tenemos todo listo.

Aquí podemos ver una imagen de BASE, donde podemos observar que el apartado de los

paquetes ICMP posee el 100% de actividad, ya que por ahora son las únicas alertas que ha

generado Snort.

Inicio Automático

Por último y antes de pasar a las conclusiones de este proyecto, voy a hacer que tanto Snort

como Barnyard se auto inicien cada vez que la máquina se inicie, ya que se supone que estos

dos servicios deben estar funcionando continuamente.

Para ello tan solo debemos crear el siguiente fichero:



38

“# nano /etc/init.d/snortbarn”

Y copiar en su interior el siguiente script:

#! /bin/sh # ### BEGIN INIT INFO # Provides: snortbarn # Required-Start: $remote_fs $syslog mysql # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: Start Snort and Barnyard ### END INIT INFO . /lib/init/vars.sh . /lib/lsb/init-functions mysqld_get_param() { /usr/sbin/mysqld --print-defaults | tr " " "\n" | grep -- "--$1" | tail -n 1 | cut -d= -f2 } do_start() { log_daemon_msg "Starting Snort and Barnyard" " " # Make sure mysql has finished starting ps_alive=0 while [ $ps_alive -lt 1 ]; do pidfile=`mysqld_get_param pid-file` if [ -f "$pidfile" ] & & ps `cat $pidfile` >/dev/null 2>&1; then ps_alive=1; fi sleep 1 done /sbin/ifconfig eth1 up /usr/local/bin/snort -q -u snort -g snort -c /usr/local/etc/snort/snort.conf -i eth1 & /usr/local/bin/barnyard2 -q -c /usr/local/etc/snort/barnyard2.conf -d /var/log/snort -f snort.log -w /usr/local/etc/snort/bylog.waldo -C /usr/local/etc/snort/classification.config 2> /dev/null & log_end_msg 0 return 0 } do_stop() { log_daemon_msg "Stopping Snort and Barnyard" " " kill $(pidof snort) 2> /dev/null kill $(pidof barnyard2) 2> /dev/null log_end_msg 0 return 0 } case "$1" in start) do_start ;;



39

stop) do_stop ;; restart) do_stop do_start ;; *) echo "Usage: snort-barn {start|stop|restart}" >&2 exit 3 ;; esac exit 0 ------------------------------------------------------------------------------------------

Una vez copiado, hacemos ejecutable al fichero con el siguiente comando:

“# chmod +x /etc/init.d/snortbarn” Y creamos un enlace simbólico para que se auto inicie: “# insserv -f -v snortbarn”

Y ahora sí, ya tenemos todo terminado.

Os dejo con las conclusiones que he sacado de este proyecto.

Conclusiones

Creo que es un proyecto muy completo e interesante y el cuál nunca se ha realizado

anteriormente por otros alumnos del centro según tengo entendido. Además se tocaría un

campo muy diferente al del resto de proyectos que se vienen realizando habitualmente, como

es la Seguridad Informática.

En cuanto al desarrollo, con OSSEC apenas he encontrado problemas aunque es verdad que

hay muy poca información sobre dicha herramienta.

Con Snort si que he tenido muchos más problemas en todos los sentidos: base de datos,

instalación, configuración de BASE, comunicación con Barnyard… etc.

Esto, en parte, se debe a que aunque hay mucha más información, ya que es una herramienta

muy usada actualmente, pero la gran mayoría está desfasada o es para versiones más

antiguas.



40

Aun así, el tema sobre el que se basa mi proyecto me ha parecido muy interesante de estudiar,

investigar y descubrir, ya que es muy útil hoy en día teniendo en cuenta la moda actual de

atacar sitios y servidores para recabar información o simplemente por diversión.

Ahora ya puedo decir que sé lo que es un IDS, para que sirve y las cosas que hace, así como soy

consciente de que también hay muchas otras funciones que me quedan por aprender.

Para finalizar, recomiendo el uso de estos sistemas, siempre y cuando sea necesario un cierto

nivel de seguridad, ya que aparte de protegernos, nos brindan mucha información sobre lo que

pasa en la red, de la cual podemos aprender mucho.

Sin más dilación, me despido con un cordial saludo, espero que os haya parecido un tema y un

proyecto interesante.

Un saludo, Manuel Alberto González Dueñas.

Bibliografía

https://web.notablepdf.com/web/viewer.html?source=sharedfile&document_identifier=MXG

ePfFV0m50muSJjaEC1esvKlJ3QXn0JRia3/sJm+o&file=https://d2tkmshiozsr4v.cloudfront.net/d

ocuments/files/004/313/842/original/d9568735bfe20ebc825d141d606df8584fb6cdaf/open-

uri20150408-3-1qp4w2o%3F1428503952

http://desdelocalhost.blogspot.de/2012/10/ossec-hids-deteccion-de-intrusos-en.html

https://seguridadyredes.wordpress.com/2007/12/28/sistemas-de-deteccion-de-intrusos-y-

snort-i/

https://web.notablepdf.com/web/viewer.html?source=sharedfile&document_identifier=MXGePfFV0m50muSJjaEC1esvKlJ3QXn0JRia3/sJm+o&file=https://d2tkmshiozsr4v.cloudfront.net/documents/files/004/313/842/original/d9568735bfe20ebc825d141d606df8584fb6cdaf/open-uri20150408-3-1qp4w2o%3F1428503952




http://desdelocalhost.blogspot.de/2012/10/ossec-hids-deteccion-de-intrusos-en.html

https://seguridadyredes.wordpress.com/2007/12/28/sistemas-de-deteccion-de-intrusos-y-snort-i/

https://seguridadyredes.wordpress.com/2007/12/28/sistemas-de-deteccion-de-intrusos-y-snort-i/

Proyecto Final de Curso: Sistema Detector de...

Documents

Transcript of Proyecto Final de Curso: Sistema Detector de...