Proyecto Final de Curso: Sistema Detector de Intrusos. Administración de Sistemas Informáticos y Redes

Transcripción

1 Proyecto Final de Curso: Sistema Detector de Intrusos Administración de Sistemas Informáticos y Redes 20154/2015

2 Proyecto Final de Curso: Sistema Detector de Intrusos 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 Fichero de Configuración de OSSEC Inicio y Comprobación de funcionamiento NIDS Snort Barnyard Base de Datos Snort BASE Inicio Automático Conclusiones Bibliografía

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). 3

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í: 4

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. 5

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. 6

7 Ahora nos descargaremos los paquetes necesarios correspondientes a OSSEC y a la herramienta GeoIP. #wget #wget 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 tar.gz Seguidamente, accedemos a la carpeta que surge de la extracción #cd GeoIP 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 #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 7

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 8

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 (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 9

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> <!-- to specify GeoIP database file location --> <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> <!-- to add GeoIP info in alerts --> <use_geoip>yes</use_geoip> </alerts> Agregamos la sección database_output <database_output> <hostname> </hostname> <username>ossec</username> <password>ossec</password> <database>ossec</database> <type>mysql</type> 10

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 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: 11

12 define ('DB_USER_O', 'ossec'); define ('DB_PASSWORD_O', 'ossec'); define ('DB_HOST_O', ' '); 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 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. 12

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). 13

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. 14

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: 15

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: 16

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. 17

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. 18

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> < _notification>yes</ _notification> < _to>ossec@servidorossec.es</ _to> <smtp_server> </smtp_server> < _from>ossec@alertasossec</ _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: 19

20 <! Frequency that syscheck is executed default to every 22 hours > <! 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> </white_list> <white_list>^localhost.ossec$</white_list> <white_list> </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. 20

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 . <alerts> <log_alert_level>6</log_alert_level> < _alert_level>8</ _alert_level> </alerts> 21

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) Alert level 10 OSSEC HIDS Notification May 31 14:42:53 Received From: (mailserver) >/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= DST= 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 (020405B AA017340C ) May 31 09:42:53 mailserver kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth

23 MAC=ca:be:a0:93:57:90:00:a0:c5:44:49:8f:08:00 SRC= DST= 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 (020405B AA017340B ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) 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= DST= 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 (020405B AA ) END OF NOTIFICATION 23

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. 24

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 25

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 Descomprimimos, extraemos y nos movemos a la carpeta resultante: # tar -zxf libpcap tar.gz #cd libpcap Auto configuramos e Instalamos la Librería: #./configure --prefix=/usr #Make #make install Descargamos el paquete: # cd /usr/src && wget Descomprimimos, extraemos y nos movemos a la carpeta resultante: # tar -zxf libdnet-1.12.tgz 26

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 Descomprimimos, extraemos y nos movemos a la carpeta resultante: # tar -zxf daq tar.gz cd daq 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. 27

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 Ahora descargamos Snort: # wget 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 tar.gz && cd snort 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. 28

29 # cp /usr/src/snort /etc/*.conf* /usr/local/etc/snort # cp /usr/src/snort /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 /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 (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: ; 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. 29

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

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

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 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 32

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. 33

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. 34

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: 35

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 Tras descargarlo, lo descomprimimos y copiamos la carpeta generada en el sitio que hemos creado para base: # tar -zxf base tar.gz && cp -r base /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 : 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. 36

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: :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: 37

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: # Default-Stop: # 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 ;; 38

39 stop) do_stop ;; restart) do_stop do_start ;; *) echo "Usage: snort-barn {start stop restart}" >&2 exit 3 ;; esac exit 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. 39