You are on page 1of 37

Manual de HIDS OSSEC y Port Scan Detector PSAD Grupo de Software Libre Cienfuegos

Los sistemas de detección de intrusos (IDS) son una herramienta muy útil para los administradores porque mediante ellos podemos detectar los ataques en nuestra red. Primero que todo explicaremos que cosa es un HIDS. HIDS es un IDS basado es hosts. En primer lugar, detección de intrusos es el proceso o las técnicas utilizadas para detectar ataques a una red específica del sistema o aplicación. La mayoría de las herramientas de detección de intrusos no son sólo para detectar los ataques, sino también el mal uso de software, la política de violaciones y otras formas de actividades inapropiadas. Un IDS basados en host realiza detección de intrusos dentro de los sistemas que desea proteger. Algunas de estas herramientas analizan los registros, la detección de spyware que otros, mientras que otros realizan la detección de virus. Análisis de seguridad del registro es el proceso o las técnicas utilizadas para detectar ataques a una red específica del sistema, o la aplicación utilizando los registros como la principal fuente de información. Análisis de los registros de seguridad también se puede llamar LID (S) – basado en un registro de detección de intrusiones. Los registros pueden ser cualquier cosa, desde los registros del firewall, registros del servidor web, registros de sistema, eventos de IDS o los registros de eventos de Windows. Del análisis del registro también se utiliza para detectar uso indebido de software, la política de violaciones y otras formas de actividades inapropiadas. LIDS (basado en el registro de sistemas de detección de intrusiones) es un término extravagante para las herramientas que realizan análisis del registro de seguridad (especificado arriba). Su objetivo es detectar el mal uso (o ataques), utilizando los registros como la principal fuente de información. No es un sustituto de NIDS (Network IDS basado) o cualquier otra solución de seguridad, sino una adición a los mismos. Comparación HIDS vs NIDS Los sistemas de detección de intrusiones basados en host (HIDS) se definen generalmente como aplicaciones que se ejecutan en sistemas específicos y que monitorizan archivos de registro locales, actividad en la red y otros elementos útiles para la detección de comportamientos hostiles. La ventaja de los HIDS es que cuentan con un acceso más profundo al sistema y relacionan entre sí los eventos locales fácilmente (por ejemplo, un error en una aplicación web seguido de un nuevo usuario añadido al sistema). La desventaja, que se ha de instalar el software en cada una de las máquinas que se desea proteger y se han de administrar muchos puntos finales. Los sistemas de detección de intrusiones por red (NIDS) suelen constar de uno o más sensores de red ubicados en puntos de paso obligado (como los cortafuegos), o enganchados a switches configurados para redirigir al sensor todo el tráfico. La ventaja de los NIDS es que es posible cubrir con ellos grandes porciones de una red con una cantidad mínima de sensores. La desventaja es que los ataques internos pueden pasarnos desapercibidos cuando no atraviesan las partes monitorizadas de la red, privándonos de la oportunidad de analizar los sistemas en mayor profundidad. Que es OSSEC? OSSEC es un Open Source basada en host Sistema de Detección de Intrusiones. Realiza análisis de logs, comprobación de la integridad, la supervisión del registro de Windows, detección de rootkits, alertas en tiempo real y respuesta activa. Comprobar la integridad de archivos Cada archivo en un sistema operativo genera una huella digital única, también conocido como hash criptográfica. Esta huella digital se genera en función del nombre y el contenido del archivo. Un HIDS pueden controlar los archivos importantes para detectar cambios en la huella digital cuando alguien, o algo así, modifica el contenido del archivo o reemplaza el archivo con una versión completamente diferente del archivo.

Control de registro El registro del sistema es un listado de directorios de todo el hardware y la configuración de software, sistema operativo configuraciones, y los usuarios, grupos y preferencias en un sistema Microsoft Windows. Los cambios realizados por los usuarios y los administradores del sistema se registran en las llaves(KEY) del sistema de registro para que los cambios se guardan cuando el usuario cierra la sesión o el sistema se reinicia. El registro también le permite ver cómo el núcleo del sistema interactúa con el hardware y software. Un HIDS pueden ver para que estos cambios importantes en las llaves del registro para asegurarse de que un usuario o una aplicación no instale una nueva o modifique un programa existente con mala intención. Por ejemplo, una utilidad de administración de contraseñas puede ser reemplazado con un ejecutable modificado y la clave de registro cambiada para que apunte a la copia maliciosa. Detección de rootkits Un rootkit es un programa desarrollado para hacerse con el control encubierto sobre un sistema operativo al tiempo que se oculta e interactúa con el sistema en el que está instalado. Un rootkit instalado puede ocultar servicios, procesos, puertos, archivos, directorios y claves del registro del resto de la operación sistema y del usuario. Respuesta Activa

Respuesta activa le permite ejecutar automáticamente comandos o las respuestas cuando se produce concede evento o serie de eventos que representan determinado riesgo para el sistema. Antes de seguir con el OSSEC veremos la configuración de Iptables Primero que nada vamos a tratar el tema de iptables para que el mismo registre los eventos DROP en los logs del sistema. Esto lo haremos en cada uno de los servidores que vamos a monitorear con el OSSEC y el PSAD. Esta sería una plantilla a seguir en un script de arranque de iptables: #!/bin/bash IPTAB=”/sbin/iptables” iptables -F iptables -X iptables -Z #iptables -t nat -F iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP #Reglas localhost iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A FORWARD -i lo -o -eth1 -j ACCEPT

############INPUT######################## iptables -A INPUT -m state –state INVALID -j LOG –log-prefix “DROP INVALID ” –logip-options –log-tcp-options iptables -A INPUT -m state –state INVALID -j DROP iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT ### anti-spoofing rules (Te va a marcar el paquete como SPOOFING cuando no pertenezca a tu subred) iptables -A INPUT -i eth0 ! -s 192.168.10.0/24 -j LOG –log-prefix “SPOOFED PKT ” iptables -A INPUT -i eth0 ! -s 192.168.10.0/24 -j DROP #Reglas ACCEPT en el INPUT #Aquí van las reglas que vas a poner en el input ### default INPUT LOG rule (Esto es la marca DROP en el /var/log/message.) Debe ir al final de las reglas input iptables -A INPUT ! -i lo -j LOG –log-prefix “DROP ” –log-ip-options –log-tcp-options ############# Reglas NAT ############################# #Reglas NAT las que tengas ################## Reglas FORWARD ################### ### state tracking rules iptables -A FORWARD -m state –state INVALID -j LOG –log-prefix “DROP INVALID ” – log-ip-options –log-tcp-options iptables -A FORWARD -m state –state INVALID -j DROP iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT ### anti-spoofing rules (Te va a marcar el paquete como SPOOFING cuando no pertenezca a tu subred) iptables -A FORWARD -i eth0 ! -s 192.168.10.0/24 -j LOG –log-prefix “SPOOFED PKT ” iptables -A FORWARD -i eth0 ! -s 192.168.10.0/24 -j DROP #Reglas ACCEPT en forward #Aquí van tus reglas forward ### default log rule (Esto es la marca DROP en el /var/log/message.) Debe ir al final de las reglas FORWARD iptables -A FORWARD ! -i lo -j LOG –log-prefix “DROP ” –log-ip-options –log-tcpoptions ############Reglas OUTPUT############################# #Logs output ### state tracking rules iptables -A OUTPUT -m state –state INVALID -j LOG –log-prefix “DROP INVALID ” – log-ip-options –log-tcp-options iptables -A OUTPUT -m state –state INVALID -j DROP

iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT #Reglas OUTPUT # Tus reglas OUTPUT ### default log rule (Esto es la marca DROP en el /var/log/message.) Debe ir al final de las reglas OUTPUT iptables -A OUTPUT ! -o lo -j LOG –log-prefix “DROP ” –log-ip-options –log-tcp-options iptables -A INPUT -j LOG iptables -A FORWARD -j LOG iptables -A INPUT -j LOG La regla abajo descrita se ubica al final de las reglas input por la razón de que todo lo que no machee con las reglas anteriores las marque en registro de sistema como un evento DROP y así sucede con las reglas forward y output. iptables -A INPUT ! -i lo -j LOG --log-prefix "DROP " --logip-options --log-tcp-options Ejemplo de log generado: #tail -f /var/log/messages Jan 30 11:56:15 test kernel: DROP IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth122.1 MAC=00:18:51:a6:d1:8f:00:a0:c5:44:49:8f:08:00 SRC=200.55.186.42 DST=200.55.146.67 LEN=1500 TOS=0×00 PREC=0×00 TTL=60 ID=25343 DF PROTO=TCP SPT=80 DPT=51450 WINDOW=1716 RES=0×00 ACK URGP=0 OPT (0101080A3387BA7C3E8AA8E2) Jan 30 11:57:46 testserver1 kernel: DROP INVALID IN=eth1 OUT= PHYSIN=eth1 PHYSOUT=veth122.1 MAC=00:18:51:a6:d1:8f:00:a0:c5:44:49:8f:08:00 SRC=200.55.186.42 DST=200.55.146.67 LEN=741 TOS=0×00 PREC=0×00 TTL=60 ID=21073 DF PROTO=TCP SPT=80 DPT=51482 WINDOW=1766 RES=0×00 ACK PSH FIN URGP=0 OPT (0101080A33892CC43E8C524B) Ya que después tenemos todos nuestros servidores o PC de trabajo bien configurados nuestros iptables es que procederemos con la instalación y configuración del OSSEC. Instalación de OSSEC Existen varias formas desplegar un sistema OSSEC veremos ahora los diferentes tipos de escenarios: • Instalación local: Usada para proteger un solo host. • Instalación de agente: Se utiliza para asegurar y proteger varios host, mientras que estos informan a un servidor OSSEC central. • Instalación del servidor: Se utiliza para agregar información de los agentes desplegados OSSEC y recopilar eventos syslog. En nuestro caso vamos a usar una instalación de un servidor OSSEC y en los equipos que queremos proteger instalaremos los agentes de OSSEC. Un ejemplo gráfico podría ser este:

Ahora explicaremos la instalación del servidor OSSEC: Primero descargaremos de la pagina de OSSEC la instalación del mismo: #cd /usr/src #wget -t0 -c http://www.ossec.net/files/ossec-hids-2.6.tar.gz #wget -t0 -c http://www.ossec.net/files/ossec-hids2.6_checksum.txt Ahora chequearemos la integridad del fichero descargador #md5sum -c ossec-hids-2.6_checksum.txt Ahora para poder compilar el instalador e instalarlo debemos instalar lo necesario para hacerlo: #apt-get install build-essential Descompactamos el archivo descargado # gunzip -c ossec-hids-2.6.tar.gz | tar -xf # cd ossec-hids-2.6 Ahora correremos el install # ./install.sh ** Para instalação em português, escolha [br]. ** [cn]. ** Fur eine deutsche Installation wohlen Sie [de]. ** For installation in English, choose [en]. ** Para instalar en Español , eliga [es]. ** Pour une installation en français, choisissez [fr]. ** Per l’installazione in Italiano, scegli [it]. ** [jp].

** Aby instalowa w jzyku Polskim, wybierz [pl]. ** no yстaнoBкe нa pyсскoM ,BBeДитe [ru]. ** Za instalaciju na srpskom, izaberi [sr]. ** Türkçe kurulum için seçin [tr]. (en/br/cn/de/es/fr/it/jp/pl/ru/sr/tr) [en]: es OSSEC HIDS v2.6 Installation Script – http://www.ossec.net You are about to start the installation process of the OSSEC HIDS. You must have a C compiler pre-installed in your system. If you have any questions or comments, please send an e-mail to dcid@ossec.net (or daniel.cid@gmail.com). - System: Linux earth 2.6.20-16-generic - User: root - Host: earth – Press ENTER to continue or Ctrl-C to abort. – 1- What kind of installation do you want (server, agent, local or help)? server - Server installation chosen. 2- Setting up the installation environment. - Choose where to install the OSSEC HIDS [/var/ossec]: /var/ossec - Installation will be made at /var/ossec . 3- Configuring the OSSEC HIDS. 3.1- Do you want e-mail notification? (y/n) [y]: y - What’s your e-mail address? root@localhost - We found your SMTP server as: 192.168.10.15 (Este es el servidor de correo de la red) - Do you want to use it? (y/n) [y]: y –— Using SMTP server: 192.168.10.15 3.2- Do you want to run the integrity check daemon? (y/n) [y]: y - Running syscheck (integrity check daemon). 3.3- Do you want to run the rootkit detection engine? (y/n) [y]: y - Running rootcheck (rootkit detection). 3.4- Active response allows you to execute a specific command based on the events received. For example, you can block an IP address or disable access for a specific user. More information at: http://www.ossec.net/en/manual.html#active-response - Do you want to enable active response? (y/n) [y]: y - Active response enabled. - By default, we can enable the host-deny and the firewall-drop responses. The first one will add a host to the /etc/hosts.deny and the second one will block the host on iptables (if linux) or on ipfilter (if Solaris, FreeBSD or NetBSD). - They can be used to stop SSHD brute force scans, portscans and some other forms of attacks. You can also add them to block on snort events, for example. - Do you want to enable the firewall-drop response? (y/n) [y]: y

- firewall-drop enabled (local) for levels >= 6 - Default white list for the active response: - 192.168.10.28 - Do you want to add more IPs to the white list? (y/n)? [n]: n 3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [y]: y - Remote syslog enabled. 3.6- Setting the configuration to analyze the following logs: – /var/log/messages – /var/log/auth.log – /var/log/syslog – /var/log/mail.info - If you want to monitor any other file, just change the ossec.conf and add a new localfile entry. Any questions about the configuration can be answered by visiting us online at http://www.ossec.net . –— Press ENTER to continue —– Al presionar enter el proceso de instalación se encargará de compilar el ossec terminando el proceso de instalación. Lo siguiente sería ya arrancar el servicio. #/var/ossec/bin/ossec-control start Nota: Si su sistema es debian squeze debemos tener en cuenta que el servicio ossec no tendrá el encabezado necesario para arrancar cuando el sistema lo hace. Para solucionar esto debemos agregar el encabezado a /etc/init.d/ossec de manera siguiente: #nano /etc/init.d/ossec al pricipio del archivo agregamos lo siguiente: ### BEGIN INIT INFO # Provides: ossec # Required-Start: # Should-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: ossec # Description: Start ossec ### END INIT INFO Guardamos los cambios y hacemos lo siguiente: update-rc.d ossec defaults Importante: Antes de pasar a la creación de agentes, recuerde que el servidor OSSEC HIDS necesita recibir la comunicación de los agentes por el puerto 1514 y 514. Usted debe asegurarse de que firewall o filtrado de paquetes en la máquina servidor permite este tráfico. Cada sistema operativo y la distribución de software proporciona una manera de hacer esto. Usted debe habilitar el tráfico UDP entrante en los puertos 1514 y 514 de las subredes donde los agentes se instalan. La regla de firewall debe mantener el estado de conexión, ya que el agente espera las respuestas del servidor. Aunque para

mi solo fue necesario establecer la conexiones entrantes para el puerto 1514 UDP. Lo haríamos de la manera siguiente en el script de iptables en las reglas input. En el servidor OSSEC: #OSSEC iptables -A INPUT -i eth0 -s 192.168.100.0/24 -p udp --dport 1514 -j ACCEPT En el agente: En las reglas INPUT #OSSEC iptables -A INPUT -i eth0 -s 192.168.10.20/32 -p udp --dport 1514 -m state --state NEW -j ACCEPT En las Reglas OUTPUT #Acceso a OSSEC iptables -A OUTPUT -o eth0 -p udp -d 192.168.10.20/32 --dport 1514 -m state --state NEW -j ACCEPT Ahora procederemos a instalar los agentes del OSSEC. Este procedimiento lo haríamos en cada uno de los sistemas que deseamos controlar con el HIDS. En cada uno de los servidores a controlar haríamos lo siguiente: #apt-get install build-essential #/install.sh ** Para instalação em português, escolha [br]. ** [cn]. ** Fur eine deutsche Installation wohlen Sie [de]. ** For installation in English, choose [en]. ** Para instalar en Español , eliga [es]. ** Pour une installation en français, choisissez [fr]. ** Per l’installazione in Italiano, scegli [it]. ** [jp]. ** Aby instalowa w jzyku Polskim, wybierz [pl]. ** no yстaнoBкe нa pyсскoM ,BBeДитe [ru]. ** Za instalaciju na srpskom, izaberi [sr]. ** Türkçe kurulum için seçin [tr]. (en/br/cn/de/es/fr/it/jp/pl/ru/sr/tr) [en]: es OSSEC HIDS v2.6 Installation Script – http://www.ossec.net You are about to start the installation process of the OSSEC HIDS. You must have a C compiler pre-installed in your system. If you have any questions or comments, please send an e-mail to dcid@ossec.net (or daniel.cid@gmail.com). - System: Linux earth 2.6.20-16-generic - User: root

- Host: earth – Press ENTER to continue or Ctrl-C to abort. – 1- What kind of installation do you want (server, agent, local or help)? agent - Agent(client) installation chosen. 2- Setting up the installation environment. - Choose where to install the OSSEC HIDS [/var/ossec]: /opt/ossec - Installation will be made at /opt/ossec . 3- Configuring the OSSEC HIDS. 3.1- What’s the IP Address of the OSSEC HIDS server?: 192.168.10.20 (IP del servidor OSSEC) - Adding Server IP 192.168.65.20 3.2- Do you want to run the integrity check daemon? (y/n) [y]: y - Running syscheck (integrity check daemon). 3.3- Do you want to run the rootkit detection engine? (y/n) [y]: y - Running rootcheck (rootkit detection). On the agent installation, notice that the only options for active response are enable or disable. Enabling active response on an agent allows the server to initiate responses that are executed on this agent. We recommend enabling for all agents. 3.4 – Do you want to enable active response? (y/n) [y]: y 3.5- Setting the configuration to analyze the following logs: – /var/log/messages – /var/log/authlog – /var/log/secure – /var/log/xferlog – /var/log/maillog - If you want to monitor any other file, just change the ossec.conf and add a new localfile entry. Any questions about the configuration can be answered by visiting us online at http://www.ossec.net . –— Press ENTER to continue —– Al presionar enter el proceso de instalación se encargará de compilar el ossec terminando el proceso de instalación. Lo siguiente sería ya arrancar el servicio. #/var/ossec/bin/ossec-control start Nota: Si su sistema es debian squeze debemos tener en cuenta que el servicio ossec no tendrá el encabezado necesario para arrancar cuando el sistema lo hace. Para solucionar esto debemos agregar el encabezado a /etc/init.d/ossec de manera siguiente: #nano /etc/init.d/ossec al pricipio del archivo agregamos lo siguiente: ### BEGIN INIT INFO # Provides: ossec # Required-Start: # Should-Start: # Required-Stop: # Default-Start: 2 3 4 5

# Default-Stop: 0 1 6 # Short-Description: ossec # Description: Start ossec ### END INIT INFO Guardamos los cambios y hacemos lo siguiente: update-rc.d ossec defaults Ahora procederemos a agregar los agentes en el servidor y como vincular los mismo al servidor En el servidor: # /var/ossec/bin/manage_agents **************************************** * OSSEC HIDS v1.4 Agent manager. * * The following options are available: * **************************************** (A)dd an agent (A). (E)xtract key for an agent (E). (L)ist already added agents (L). (R)emove an agent (R). (Q)uit. Choose your action: A,E,L,R or Q: A - Adding a new agent (use ‘\q’ to return to the main menu). Please provide the following: * A name for the new agent: mars * The IP Address of the new agent: 192.168.10.25 * An ID for the new agent[001]: 001 Agent information: ID:001 Name:mars IP Address:192.168.10.25 Confirm adding it?(y/n): y Agent added. Ahora extraemos la llave para asignarsela a el agente. **************************************** * OSSEC HIDS v1.3 Agent manager. * * The following options are available: * **************************************** (A)dd an agent (A). (E)xtract key for an agent (E). (L)ist already added agents (L). (R)emove an agent (R). (Q)uit. Choose your action: A,E,L,R or Q: e

Available agents: ID: 001, Name: mars, IP: 192.168.10.25 Provide the ID of the agent to extract the key (or ‘\q’ to quit): 001 Agent key information for ‘001’ is: MDAxIG1hcnMgMTkyLjE2OC42NS40MCBmY2UzMjM4OTc1ODgzYTU4ZWM3YTRkY WJiZTJmMjQ2Y2ViODhmMzlmYjE3MmI4OGUzMTE0MDczMzVhYjk2OTRh ** Press ENTER to return to the main menu. Copiamos la llave anterior. En el agente OSSEC (Servidor que vamos a controlar) hacemos lo siguiente: # /var/ossec/bin/manage_agents **************************************** * OSSEC HIDS v1.3 Agent manager. * * The following options are available: * **************************************** (I)mport key from the server (I). (Q)uit. Choose your action: I or Q: i * Provide the Key generated by the server. * The best approach is to cut and paste it. *** OBS: Do not include spaces or new lines. Paste it here (or ‘\q’ to quit): Aquí pegamos la llave MDAxIG1hcnMgMTkyLjE2OC42NS40MCBmY2UzMjM4OTc1ODgzYTU4ZWM3YTRkY WJiZTJmMjQ2Y2ViODhmMzlmYjE3MmI4OGUzMTE0MDczMzVhYjk2OTRh Agent information: ID:001 Name:mars IP Address:192.168.10.25 Confirm adding it?(y/n): y Added. ** Press ENTER to return to the main menu. **************************************** * OSSEC HIDS v1.3 Agent manager. * * The following options are available: * **************************************** (I)mport key from the server (I). (Q)uit. Choose your action: I or Q: q Ahora tanto en el servidor como en el agente reiniciamos el servicio de OSSEC. #/var/ossec/bin/ossec-control restart.

Ahora veremos la estructura de directorios del OSSEC en el servidor que cuenta con varios directorios. ■ /var/ossec/bin — Directorio Contiene los binarios usados por HIDS OSSEC. ■ /var/ossec/etc — Directorio Contine los ficcheros de configuración necesarios para OSSEC. ■ ossec.conf — El principal fichero de configuracion del OSSEC. ■ internal_options.conf — Fichero de configuracion con opciones opcionales. ■ decoders.xml — Un fichero que contiene los decofificadores de los logs. ■/var/ossec/logs — Directorio que contine los logs del OSSEC HIDS. ■ alerts/alerts.log — OSSEC HIDS logs de alerta. ■ ossec.log — Registros (logs) de OSSEC HIDS (error, warn, info, y otros). ■ active-responses.log — Registros de las respuestas activas de OSSEC HIDS. ■/var/ossec/queue — Directorio que contiene los ficheros de colas de OSSEC HIDS. ■ agent-info — Directorio que contiene la información específica de los agentes (sistema operativo, venrsion de OSSEC HIDS, y otras). ■ syscheck — Directorio que contiene el chequeo integridad con un fichero de registro por cada agente declarado. ■ rootcheck — Directorio que contiene la informaccion de rootkit y las politicas de monitoreo por cada agente. ■ rids — Directorio que contiene los IDs de los mensajes de los agentes. ■ /var/ossec/rules — Directorio que contiene todas las reglas para OSSEC HIDS. ■ /var/ossec/stats — Directorio que contiene la información estadistica tales como numero de registros de logs por segundo, y otras Veremos el fichero de configuración de OSSEC. El archivo de configuración (/var/ossec/etc/ossec.conf) se organiza en varias partes. La primera parte, la parte global, es la que define el servidor de correo y la configuración del mismo (si usamos). Podríamos activar la notificación por email configurando esos campos: <code><global> <email_notification>yes</email_notification> <email_to>ossec@midominio.cu</email_to> <smtp_server>192.168.10.28</smtp_server> <email_from>ossecm@servidorhids</email_from> </global> </code>

A continuación podemos ver las reglas que usa ossec, quitar o añadirlas, estás reglas se encuentran en /var/ossec/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 de omitir o los que se deben de comprobar, cada que tiempo (definido en segundos).. <!– 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 … A continuación podremos ver cómo está configurado el sistema de detección de rootkits, esos archivos de texto definen normas para poder 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 tramo del archivo de configuración corresponde a los host de la lista blanca (los definimos con la instalación, en nuestro caso en la lista blanca sólo está nuestro propio host, dominio y puerta de enlace: <global> <white_list>127.0.0.1</white_list> <white_list>^localhost.localdomain$</white_list>

<white_list>192.168.10.1</white_list> </global> También podemos ver algúnos tramos que definen que el syslog esta activado: <remote> <connection>syslog</connection> </remote> Algunos scripts que son la base de la respuesta activa(para el host.deny, iptables..) Este por ejemplo ejecuta el script host-deny.sh, y tiene un tiempo predefinido (al tiempo la entrada del host deny es borrada, eso se define en la configuración de respuesta activa): <command> <name>host-deny</name> <executable>host-deny.sh</executable> <expect>srcip</expect> <timeout_allowed>yes</timeout_allowed> </command> La configuración de respuesta activa (que usa los comandos que hemos visto) en este caso el 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> La auto respuesta Host-deny corre el script host-deny.sh de acuerdo al nivel (level) ,en este caso mayores o iguales a 6, se encarga de agregar el host al fichero /etc/hosts.deny en el equipo víctima de cualquier evento. Ejemplo de que agrega en el fichero: ALL:192.168.10.7 Ahora podemos ver que archivos se monitorizán localmente: <!– Files to monitor (localfiles) –> <localfile> <log_format>syslog</log_format> <location>/var/log/messages</location> </localfile> …

Por defecto para el tratamiento del firewall existe un script firewall-drop que agrega al firewall reglas drop en input y forward en caso que ocurra una respuesta activa en la observancia de los log de los agentes. Por defecto viene en ossec el active response para en caso nivel de la alerta sea mayor que 6 y viene declarado así: <active-response> <!– Firewall Drop response. Block the IP for - 600 seconds on the firewall (iptables, - ipfilter, etc). –> <command>firewall-drop</command> <location>local</location> <level>6</level> <timeout>600</timeout> </active-response> Pero en nuestro caso la sustituiremos mas adelante cuando usemos psad. Ahora veremos que quieren decir cada uno de los niveles que establece ossec: Level 0: Ignorado, no se tomaron medidas. Se utiliza principalmente para evitar falsos positivos. Estas reglas se analizan antes de 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: El usuario los errores generados por contraseñas perdidas, las acciones denegado, etc. Estos mensajes no tienen de seguridad pertinentes. 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 atacar a un servidor Linux. También se incluyen con frecuencia provocado IDS eventos y sucesos comunes de error. Level 9: error de la 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: error 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 que la normal. Level 14: evento de alta seguridad de 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. Ya en el proceso de terminada la instalacion de cada uno de los agentes veremos ya muestras de algunos resultados en nuestro correo que recibira las alertas de de todos los niveles. Si queremos solo

recibir solo las que en una medida u otra comprometan el sistema pordemos configurar eso en el fichero de configuracion de OSSEC: <alerts> <log_alert_level>6</log_alert_level> <email_alert_level>8</email_alert_level> </alerts> Aquí solo generaran alertas a partir del nivel 6 y se enviarán los mensajes de correo con las alertas por encima de 8 que son las que tienen mayor relevancia. Ahora les expongo una de las alertas de mensaje con nivel de alerta 10: Asunto: OSSEC Notification – (mailserver) 192.168.10.28 – Alert level 10 OSSEC HIDS Notification. 2012 Jan 31 14:42:53 Received From: (mailserver) 192.168.10.28->/var/log/messages Rule: 4151 fired (level 10) -> “Multiple Firewall drop events from same source.” Portion of the log(s): Jan 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) Jan 31 09:42:53 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=64585 DF PROTO=TCP SPT=60269 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080AA017340B0000000001030302) Jan 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) Jan 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) Jan 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) Jan 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) Jan 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) Jan 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) Jan 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) Jan 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) Jan 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) Jan 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 Instalación de la interface Web de OSSEC en el servidor OSSEC La interfaz web de usuario de OSSEC permite realizar peticiones específicas, aunque por desgracia no permite la configuración de los servidores o de los agentes (para eso hay que recurrir a la línea de comandos). Además, la WebGUI de OSSEC permite conocer el estado del servidor y de los agentes de un vistazo. #cd /usr/src #wget http://www.ossec.net/files/ui/ossec-wui-0.3.tar.gz #wget http://www.ossec.net/files/ui/ossec-wui-0.3checksum.txt #wget http://www.ossec.net/files/ui/ossec-wui-0.3.tar.gz.sig Ahora que tenemos los archivos, debemos verificar que los archivos no han sido alterados o dañado durante la descarga, ejecute los siguientes comandos:

#md5 ossec-wui-0.3.tar.gz MD5 (ossec-wui-0.3.tar.gz) = 45abaaf0e460ad38caa6932b69511cd7 #sha1 ossec-wui-0.3.tar.gz SHA1 (ossec-wui-0.3.tar.gz) = 70198da3932f597d3b5632dc4d87637922bd8ad8 #gpg --verify ossec-wui-0.3.tar.gz.sig ossec-wui-0.3.tar.gz gpg: Signature made Tue Mar 27 23:51:15 2007 ADT using RSA key ID 6B30327E gpg: Good signature from “Daniel B. Cid (Ossec development) ” Primary key fingerprint: 86C6 D33B C52E 19BF DDAE 57EB 4E57 14E2 6B30 327E Si falla algunos de estos chequeos recomendamos que vuelva a descargar los tres ficheros y repita el proceso. Ahora descomprimimos el fichero y comenzamos el proceso de instalación de la interface web: #tar -zxvf ossec-wui-0.3.tar.gz #mv ossec-wui* /var/www/ossec-wui #cd /var/www/ossec-wui/ #./setup.sh Setting up ossec ui... Username: admin New password: Re-type new password: Adding password for user admin Setup completed successfully. #usermod -G ossec www #chmod 770 tmp/ #chgrp www tmp/ #/etc/init.d/apache2 restart Lo que resta es abrir la página en la dirección del servidor http://192.168.10.20/ossec-wui/ Y ya veremos la página web del servidor ossec con los agentes que ya hemos incorporados y los eventos que estan transcurriendo además de opciones de busqueda , etc..:

Ya visto todo esto veremos PSAD Introducción a PSAD Port Scan Attack Detector (psad) es un grupo de tres demonios ligeros para el sistema escritos en Perl y C que están diseñados para trabajar con el sistema de cortafuegos Linux iptables para detectar los port scans y otros tráficos sospechosos. Psad hace uso de los registros de actividad de iptables para detectar, alertar y opcionalmente bloquear los port scan u otros tráficos sospechosos. Para TCP scans psad analiza las banderas TCP para determinar el tipo de scan (syn, fin, xmas, etc.) y para determinar las opciones de línea de comando correspondientes que pudieran usarse para que nmap genere tal scan. Además psad hace uso de muchas firmas TCP, UDP e ICMP contenidas en el sistema de detección de intrusos Snort (vea http://www.snort.org/) para detectar tráfico sospechoso tales como probes para puertas traseras comunes, herramientas DDoS, identificación de OS, y más. Por omisión psad también suministra alertas para las reglas snort que sean detectadas directamente por iptables a través del uso de un juego de reglas generadas por fwsnort (http://www.cipherdyne.org/fwsnort/). Esto habilita psad para que envie alertas para los ataques de capa de aplicación. psad tiene un conjunto altamente configurables de umbrales de peligro (con valores por omisión razonables) que le permiten al administrador definir qué constituye un port scan u otro tráfico sospechoso. Las alertas por email enviadas por psad incluyen la ip origen del scanning, la cantidad de paquetes enviados a cada puerto, cualquier firma TCP, UDP o ICMP que hayan sido identificadas (e.g. “NMAP XMAS scan”), el rango de puertos bajo scan, el nivel de peligro (de 1 a 5), información dns reversa e información whois. Psad también hace uso de varios campos de encabezados asociados a paquetes TCP SYN para pasivamente identificar el sistema operativo remoto (de una forma similar a p0f finger printer) desde se origina el scan. Esto requiere el uso del argumento –log-tcp-options en las reglas de registro de actividad de iptables, si esta opción no se usa, psad intenta entonces la identificación de sistema operativo con el método de uso de longitud de paquete, TTL y valores TOS, IP ID; y tamaños de ventana TCP. Psad se usa por medio de la configuración de syslog para que escriba los mensajes de kernel.info al pipe con nombre /var/lib/psad/psadfifo y luego todos los mensajes de dicho pipe. De esta forma se le suministra a psad un flujo de datos puro que exclusivamente contiene paquetes que el cortafuegos ha decidido no le son adecuados para que entren a su red. Psad consiste de tres demonios: psad, kmsgsd, y psadwatchd. Psad es responsable de procesar todos los paquetes que han sido registrados por el cortafuegos y de aplicar la lógica de firmas para determinar qué tipo de scan ha sido desplegado contra la máquina o contra la red. kmsgsd lee todos los mensajes que han sido escritos en el tubo (pipe) /var/lib/psad/psadfifo y escribe cualquier mensaje que haga coincidencia de acuerda a una expresión regular particular (o string) en /var/log/psad/fwdata. psadwatchd es un software de perro guardián que reiniciará a cualquiera de los otros dos demonios en caso de que mueran por cualquier razón. No es nuestro objetivo por ahora implementar fwsnort por trataremos en otra entrega agregarle esta funcionalidad al psad que es muy interesante. Ahora pondremos gráficamente un esquema general aproximado de ejemplo el cual explicaremos:

Nuestra idea es protegernos tanto de ataques internos en la red local y externos desde internet en este caso como verán el psad estará en cada uno de los servidores así como todos tendrán el agente de OSSEC y cada uno de ellos con iptables configurado como explicamos al inicio de este manual cuando tratamos iptables. Instalación de Psad Primero descargaremos la ultima versión que esta en el sitio http://cipherdyne.org/psad #cd /usr/src #wget http://cipherdyne.org/psad/download/psad-2.1.7.tar.bz2 #tar xfj psad-2.0.8.tar.bz2 Instalamos las dependencias: #aptitude install libcarp-clan-perl libdate-calc-perl libiptables-chainmgr-perl libiptables-parse-perl libnetworkipv4addr-perl libunix-syslog-perl libbit-vector-perl gcc #cd psad-2.1.7 #./install.pl El script install.pl le pedirá varias piezas de entrada, incluyendo una dirección de correo electrónico que alerta de correo electrónico será enviado, el tipo de demonio syslog se están ejecutando en el sistema (syslogd, syslog-ng, o metalog), si solo PSAD analizará sólo los mensajes de log de iptables que contienen un registro específico o prefijo, y si desea enviar los datos de registro en el IDS DShield distribuida. Usted puede introducir manualmente la información o utilizar los valores predeterminados (presionando ENTER) y pronto tendrá una instalación de funcionando de psad. Una instalación por defecto de psad lee los datos que a través de syslog se pasan a la tubería /var/lib/psad/psadfifo (un pipe de los de toda la vida), con lo que lo primero es hacer que kern.info se mande a dicho pipe, con algo tan sencillo como añadir a rsyslog.conf. Lo editamos y al final del mismo ponemos lo siguiente: kern.info |/var/lib/psad/psadfifo Nota: Claro que esto debe ir tabulado Ahora reiniciamos rsyslog. #/etc/init.d/rsyslog restart Nota: Si su sistema es debian squeze debemos tener en cuenta que el servicio ossec no tendrá el

encabezado necesario para arrancar cuando el sistema lo hace. Para solucionar esto debemos agregar el encabezado a /etc/init.d/ossec de manera siguiente: #nano /etc/init.d/psad al pricipio del archivo agregamos lo siguiente: ### BEGIN INIT INFO # Provides: pasd # Required-Start: # Should-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: psad # Description: Start psad ### END INIT INFO Guardamos los cambios y hacemos lo siguiente: update-rc.d pasad defaults Ahora antes de arrancar definitivamente PSAD veremos como las opciones del fichero de configuración que tocamos en nuestro caso. Editamos el fichero de configuración que esta en /etc/psad Las dos siguiente opción se define a quien se le va a enviar el correo de alerta según el nivel de peligro así como los bloqueos añadidos a iptables y los desbloqueos ### Supports multiple email addresses (as a comma separated ### list). EMAIL_ADDRESSES psad@mpcfg.co.cu; Esta opción define el nombre del host en cuestion en el cual esta corriendo el PSAD. ### Machine hostname HOSTNAME nautilus.mpcfg.co.cu; Las dos siguientes variables definen las redes locales y las que no lo son, muy al estilo snort. HOME_NET 192.168.10.0/24, 172.16.0.0/16; # un ejemplo EXTERNAL_NET any; Estas redes se definen porque psad usa las reglas de snort para detectar tráfico sospechoso, aunque las usa en cierta medida de forma diferente. Por ejemplo, para psad todo el tráfico que loguea está destinado a lo que para snort sería HOME_NET. La siguiente variable se define que palabra buscará en los logs de iptables generados por iptables con la opncion –log-prefix, en nuestro caso DROP. FW_MSG_SEARCH DROP; Anteriormente explicábamos ese tema en la plantilla de iptables declarándolo tanto para las reglas input, output y forward, este es un ejemplo para las reglas INPUT para cuando no coincida con nada de

las reglas anteriores declaradas, registrarlo en los logs de iptables con prefijo DROP: ### default INPUT LOG rule iptables -A INPUT ! -i lo -j LOG --log-prefix "DROP " --logip-options --log-tcp-options PSAD se encargará de analizar el mensaje DROP en los logs de iptables y determinar así sus acciones. Esta variable indica que puertos se van a ignorar en el análisis de los logs de iptables. Esto se debe definir bien para evitar falsos positivos en la red. IGNORE_PORTS tcp/25; Las siguientes variables definen los niveles de peligro. Desde el punto de vista de escaneo de puertos, estos niveles definen el número de paquetes recibidos. Desde el punto de vista de otro tipo de actividad maliciosa, estos niveles se definen según el tipo de ataque o si la IP origen es conocida por anteriores bloqueos. DANGER_LEVEL1 DANGER_LEVEL2 DANGER_LEVEL3 DANGER_LEVEL4 DANGER_LEVEL5 5; ### Number of packets. 15; 150; 1500; 10000;

Con la siguiente línea hacemos que Psad no sea sólo algo pasivo, sino que añada reglas a nuestro firewall. ENABLE_AUTO_IDS Y; Digamos que queremos bloquear IPs a partir del nivel 3: AUTO_IDS_DANGER_LEVEL 3; Y que queremos que los bloqueos duren 600 segundos AUTO_BLOCK_TIMEOUT 600; Por supuesto, usamos iptables: IPTABLES_BLOCK_METHOD Y; La siguiente variable define la/s cadenas en las que queremos que se añadan reglas de bloqueo. Su sintaxis es: Target,Direction,Table,From_chain,Jump_rule_position,To_chain,Rule_position. Por ejemplo: IPT_AUTO_CHAIN1 DROP, src, nat, PREROUTING, 1, PSAD_BLOCK, 1; Lo más interesante aqui es que DROPeamos con reglas añadidas a la tabla nat y la cadena PSAD_BLOCK. Se pueden añadir IPT_AUTO_CHAINn reglas. No hace falta decir que debemos haber creado anteriormente la cadena PSAD_BLOCK Con esta opción que ejemplificamos podemos decirle al PSAD que niveles de peligro informará vía correo.

### Only send email alert if danger level >= to this value. EMAIL_ALERT_DANGER_LEVEL 3; Psad puede incluso ejecutar scripts externos. La IP origen se pasa a estos scripts en la variable SRCIP. ENABLE_EXT_SCRIPT_EXEC N; Hay muchas opciones a configurar. Como he dicho antes aquí no hay más que unas cuantas para dar una idea de lo que se puede hacer. Otro fichero interesante es el /etc/psad/auto_dl, en el que podemos configurar listas blancas y negras de IPs. Por ejemplo: 127.0.0.1 10.111.21.23 5 tcp/22; 0;

Con estas dos reglas permitimos todo lo que venga desde 127.0.0.1 y damos un danger_level de 5 a todo lo que venga de 10.111.21.23 y sea tráfico ssh. Otro fichero interesante es /etc/psad/signatures, que incluye unas 200 firmas de snort, pero ligeramente modificadas para poder pasar información a psad. Por ejemplo: alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING undefined code"; icode:>0; itype:8; classtype:misc-activity; sid:365; psad_id:100195; psad_dl:2;) Es una definición de regla relacionada con icmp, y que tiene un identificador en psad de 100195 y que asigna un danger_level de 2. Ahora habiendo explicado cada una de las opciones mas importantes del fichero de configuración del PSAD podemos proceder a arrancar el mismo /etc/init.d/psad start Vincular OSSEC con PSAD Primero vamos a crear un script que ejecute el psad desde OSSEC como respuesta activa y el mismo se guarda en /var/ossec/active-response/bin/. En este manual lo llamaremos psad.sh. #cd /var/ossec/active-response/bin/ #touch psad.sh #chmod 755 psad.sh #chown root:ossec psad.sh Ahora editamos el fichero creado #nano psad.sh y dentro de el añadimos lo siguiente: #!/bin/bash # Añade una regla de psad usando la IP origen. También pasamos el usuario, pero no lo vamos a usar. # Entrada: user, srcip

# Salida: Nada. Ejecuta una regla psad ACTION=$1 USER=$2 IP=$3 # Agregando ip a las reglas del frirewal if [ "x${ACTION}" = "xadd" ]; then psad -fw-block-ip $IP exit 0 fi # Eliminando ip de las reglas del firewall if [ "x${ACTION}" = "xdelete" ]; then psad –fw-rm-block-ip $IP exit 0 fi Ahora en el fichero de configuración del ossec en /var/ossec/etc editamos el fichero ossec.conf para en la sección de comando declarar el comando psad.sh #nano /var/ossec/etc/ossec.conf y en la sección de comandos añadimos lo siguiente: <command> <name>psad</name> <executable>psad.sh</executable> <expect>user,srcip</expect> </command> Por defecto ossec tiene un script de firewall que viene declarado así en la respuesta activa del mismo <active-response> <!-- Firewall Drop response. Block the IP for - 600 seconds on the firewall (iptables, - ipfilter, etc). --> <command>firewall-drop</command> <location>local</location> <level>6</level> <timeout>600</timeout> </active-response> Ahora configuraremos la respuesta activa de ossec con el comando declarado para psad eliminando o modificando el que el trae por defecto: <active-response> <disabled>no</disabled> <command>psad</command> <location>local</location>

<level>6</level> <timeout>600</timeout> </active-response> Ahora podemos reniciciar el servicio de ossec para que tome los cambios de la configuración #/var/ossec/bin/ossec-control restart Lo siguiente sería copiar el script de psad el que llamamos psad.sh para cada agente en /var/ossec/active-response/bin/ con los mismos permisos y dueños del archivo y reiniciar el ossec en cada uno de los agentes después de haberlo hecho. Hasta aquí hemos visto el HIDS OSSEC y el Port Scan Attack Detector (PSAD) y como integrarlos de tal forma que nuestros servidores estén protegidos ante cualquier ataque sea cual sea. Ejemplos de ataques: Primero vamos a ver ataques se scaneos de puertos usando NMAP Scan TCP connect #nmap -sT -n 192.168.10.14 -max-rtt-timeout 500 Aquí estamos haciendo un escaneo tipo TPC al servidor con IP 192.168.10.14 y en los logs de iptables de ese servidor reporta algo así: Feb 1 13:56:53 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2461 DF PROTO=TCP SPT=54335 DPT=299 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A494C9D200000000001030302) Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2461 DF PROTO=TCP SPT=54335 DPT=299 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2461 DF PROTO=TCP SPT=54335 DPT=299 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23432 DF PROTO=TCP SPT=59887 DPT=1479 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A494C9D200000000001030302)

Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23432 DF PROTO=TCP SPT=59887 DPT=1479 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23432 DF PROTO=TCP SPT=59887 DPT=1479 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=37748 DF PROTO=TCP SPT=45653 DPT=594 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A494C9D200000000001030302) Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=37748 DF PROTO=TCP SPT=45653 DPT=594 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=37748 DF PROTO=TCP SPT=45653 DPT=594 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=55906 DF PROTO=TCP SPT=53026 DPT=49 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A494C9D200000000001030302) Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=55906 DF PROTO=TCP SPT=53026 DPT=49 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00

TTL=64 ID=55906 DF PROTO=TCP SPT=53026 DPT=49 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48035 DF PROTO=TCP SPT=42803 DPT=556 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A494C9D200000000001030302) Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48035 DF PROTO=TCP SPT=42803 DPT=556 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi kernel: IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:19:d1:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48035 DF PROTO=TCP SPT=42803 DPT=556 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 1 13:56:53 glpi psad: added iptables auto-block against 192.168.10.24 for 600 seconds Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "MISC xfs communication attempt" (sid: 1987) tcp port: 7100 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "MISC HP Web JetAdmin communication attempt" (sid: 100084) tcp port: 8000 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "DOS arkiea backup communication attempt" (sid: 282) tcp port: 617 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "P2P Fastrack kazaa/morpheus communication attempt" (sid: 1383) tcp port: 1214 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "MISC VNC communication attempt" (sid: 100202) tcp port: 5900 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "MISC MS Terminal Server communication attempt" (sid: 100077) tcp port: 3389 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "DOS iParty DOS attempt" (sid: 1605) tcp port: 6004 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "RPC portmap listing TCP 32771" (sid: 599) tcp port: 32771 Feb 1 13:56:59 glpi psad: src: 192.168.10.24 signature match: "P2P napster communication attempt" (sid: 100090) tcp port: 8888 Feb 1 13:56:59 glpi psad: scan detected: 192.168.10.24 -> 192.168.10.14 tcp: [9-61440] flags: SYN tcp pkts: 694 DL: 5

El psad actuará aquí de manera independiente a ossec porque es su función de detectar escaneo de puertos entonces la orden de ejecutar el script de ossec psad.sh no llegará a ejecutase porque ya psad como servicio se encargó cerrar al atacante. El psad se encarga de enviar el mensaje de correo electrónico indicando el nivel de peligro en que catalogó el escaneo de puertos y otros datos que vimos dentro de las características de PSAD al inicio. Para el ejemplo anterior este fue el contenido del mensaje: Asunto:[psad-alert glpi.mpcfg.co.cu ] DL5 src: prox1.mpcfg.co.cu dst: glpi.mpcfg.co.cu =-=-=-=-=-=-=-=-=-=-=-= Wed Feb 1 13:56:53 2012 =-=-=-=-=-=-=-=-=-=-=-= Danger level: [5] (out of 5) Scanned TCP ports: [21-22370: 22 packets] TCP flags: [SYN: 22 packets, Nmap: -sT or -sS] iptables chain: INPUT, 15 packets iptables chain: INPUT (prefix “DROP”), 7 packets Source: 192.168.10.24 DNS: prox1.mpcfg.co.cu OS guess: SunOS:4.1::SunOS 4.1.x Linux:2.5::Linux 2.5 (sometimes 2.4) Destination: 192.168.10.14 DNS: glpi.mpcfg.co.cu Overall scan start: Thu Jan 12 10:06:39 2012 Total email alerts: 19 Complete TCP range: [1-65301] Syslog hostname: glpi Global stats: chain: interface: TCP: UDP: ICMP: INPUT eth0 17050 0 0 [+] TCP scan signatures: “SCAN FIN” dst port: 478 (no server bound to local port) flags: FIN sid: 621 chain: INPUT packets: 106 classtype: attempted-recon reference: (arachnids) http://www.whitehats.com/info/IDS27 “MISC Microsoft PPTP communication attempt” dst port: 1723 (no server bound to local port) flags: SYN

psad_id: 100082 (derived from: 2126 2044) chain: INPUT packets: 3 classtype: attempted-admin reference: (bugtraq) http://www.securityfocus.com/bid/5807 reference: (cve) http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-1214 [+] Whois Information (source IP): # # Query terms are ambiguous. The query is assumed to be: # “n 192.168.10.24″ # # Use “?” to get help. # # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=192.168.100.24? showDetails=true&showARIN=false&ext=netref2 # NetRange: 192.168.0.0 – 192.168.255.255 CIDR: 192.168.0.0/16 OriginAS: NetName: PRIVATE-ADDRESS-CBLK-RFC1918-IANA-RESERVED NetHandle: NET-192-168-0-0-1 Parent: NET-192-0-0-0-0 NetType: IANA Special Use Comment: This block is used as private address space. Comment: Traffic from these addresses does not come from IANA. Comment: IANA has simply reserved these numbers in its database Comment: and does not use or operate them. We are not the source Comment: of activity you may see on logs or in e-mail records. Comment: Please refer to http://www.iana.org/abuse/ Comment: Comment: Addresses from this block can be used by Comment: anyone without any need to coordinate with Comment: IANA or an Internet registry. Addresses from Comment: this block are used in multiple, separately Comment: operated networks. Comment: Comment: This block was assigned by the IETF in the Comment: Best Current Practice document, RFC 1918 Comment: which can be found at: Comment: Comment: http://www.rfc-editor.org/rfc/rfc1918.txt RegDate: 1994-03-15 Updated: 2011-04-12 Ref: http://whois.arin.net/rest/net/NET-192-168-0-0-1

OrgName: Internet Assigned Numbers Authority OrgId: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US RegDate: Updated: 2004-02-24 Ref: http://whois.arin.net/rest/org/IANA OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName: Internet Corporation for Assigned Names and Number OrgAbusePhone: +1-310-301-5820 OrgAbuseEmail: abuse@iana.org OrgAbuseRef: http://whois.arin.net/rest/poc/IANA-IP-ARIN OrgTechHandle: IANA-IP-ARIN OrgTechName: Internet Corporation for Assigned Names and Number OrgTechPhone: +1-310-301-5820 OrgTechEmail: abuse@iana.org OrgTechRef: http://whois.arin.net/rest/poc/IANA-IP-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # =-=-=-=-=-=-=-=-=-=-=-= Wed Feb 1 13:56:53 2012 =-=-=-=-=-=-=-=-=-=-=-= Y también se recibe otro mensaje diciendo en el asunto solamente [psad-status glpi.mpcfg.co.cu ] added iptables auto-block against 192.168.10.24 for 600 seconds. Quiere decir que el psad agrego esa IP a las reglas del firewall por un intervalo de 600 segundos como fue definido en la configuración de PSAD. Podemos comprobar esto en la la víctima y corriendo lo siguiente: # psad --List \[+] Listing chains from IPT_AUTO_CHAIN keywords... Chain PSAD_BLOCK_INPUT (1 references) pkts bytes target prot opt in out source destination 1338 80280 DROP all — * * 192.168.10.24 0.0.0.0/0 Chain PSAD_BLOCK_OUTPUT (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all — * * 0.0.0.0/0 192.168.10.24 Chain PSAD_BLOCK_FORWARD (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all — * * 0.0.0.0/0 192.168.10.24

0 0 DROP all — * * 192.168.10.24 0.0.0.0/0 Al transcurrir los 600 seg el PSAD elimina de las reglas del firewall la ip atacante y envía un mensaje informándolo. Ossec también detecta esto y como el está también a la escucha de los logs del sistema incluyendo /var/log/messages, el mismo detecta múltiples DROP con el siguiente mensaje Multiple Firewall drop events from same source. Se recibe también de manera detallada en un mensaje de correo electrónico: Asunto: OSSEC Notification - (glpi) 192.168.10.14 - Alert level 10 Received From: (glpi) 192.168.10.14->/var/log/messages Rule: 4151 fired (level 10) -> “Multiple Firewall drop events from same source.” Portion of the log(s): Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=26130 DF PROTO=TCP SPT=54611 DPT=53 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=42406 DF PROTO=TCP SPT=58566 DPT=256 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=50286 DF PROTO=TCP SPT=40919 DPT=3389 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=9307 DF PROTO=TCP SPT=33613 DPT=812 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=20363 DF PROTO=TCP SPT=41470 DPT=143 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=26227 DF PROTO=TCP SPT=37225 DPT=1392 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=21708 DF PROTO=TCP SPT=33539 DPT=5190 WINDOW=5840 RES=0×00 SYN URGP=0 OPT

(020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=4846 DF PROTO=TCP SPT=34860 DPT=409 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=24558 DF PROTO=TCP SPT=33055 DPT=422 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=35215 DF PROTO=TCP SPT=58065 DPT=108 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:52 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=42811 DF PROTO=TCP SPT=57643 DPT=901 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C97430000000001030302) Feb 1 13:56:50 glpi kernel: DROP IN=eth0 OUT= PHYSIN=eth1 PHYSOUT=veth124.0 MAC=36:46:4c:a1:b1:5a:00:191:93:b4:81:08:00 SRC=192.168.10.24 DST=192.168.10.14 LEN=60 TOS=0×00 PREC=0×00 TTL=64 ID=34336 DF PROTO=TCP SPT=49521 DPT=846 WINDOW=5840 RES=0×00 SYN URGP=0 OPT (020405B40402080A494C92F70000000001030302) –END OF NOTIFICATION Scan TCP SYN or Half-Open #nmap -n 192.168.10.14 --max-rtt-timeout 500 Este escaneo tendría el mismo efecto que el anterior seria cerrado el atacante. TCP FIN, XMAS, and NULL Scans #nmap -sF -n 192.168.10.14 --max-rtt-timeout 5 Este escaneo tendría el mismo efecto que el anterior sería cerrando el atacante, la única diferencia es que ossec no lo detecta porque los mensajes de los logs de iptables son DROP INVALID ya que esos los marcamos y los bloqueamos en el script de iptables como paquetes en el estado INVALID y el ossec solo entiende de DROP, aunque podríamos crear la regla en ossec pero eso sería en otro momento para este tipo de prefijo de log de iptables: iptables -A INPUT -m state --state INVALID -j LOG --logprefix "DROP INVALID " --log-ip-options --log-tcp-options iptables -A INPUT -m state --state INVALID -j DROP El mensaje de psad en los logs seria así: Feb 1 14:57:17 glpi psad: added iptables auto-block against

192.168.10.24 for 600 seconds Feb 1 14:57:26 glpi psad: src: 192.168.10.24 signature match: "SCAN FIN" (sid: 621) tcp port: 655 Feb 1 14:57:26 glpi psad: scan detected: 192.168.10.24 -> 192.168.100.14 tcp: [1-65301] flags: FIN tcp pkts: 3416 DL: 5 Por último Scan UDP #nmap -sU -n 192.168.10.14 --max-rtt-timeout 500 Este escaneo tendría el mismo efecto que el anterior sería cerrando el atacante. Los logs de psad serían: Feb 1 15:08:41 glpi psad: added iptables auto-block against 192.168.10.24 for 600 seconds Feb 1 15:08:47 glpi psad: scan detected: 192.168.100.24 -> 192.168.100.14 udp: [84-32786] udp pkts: 150 DL: 5 Ataque de fuerza bruta por ssh Ahora veremos un ataque de fuerza bruta por ssh y aquí el ossec si intervendrá mandando a ejecutar el script de psad desde el ya que psad no es capaz de detectar este tipo de ataque. Voy a escoger el paquete Medusa, aunque existen otros como Hydra. En aras de ganar tiempo y por lo sencillo del mismo medusa fue mi opción. En el equipo atacante montamos medusa: #aptitude install medusa Ahora creamos un pequeño diccionario de password: #nano password.txt y agregamos dentro de el una lista de password posibles (aquí pongo una pocas para lograr el objetivo que es que el ossec se encargue de el y ejecute el script de psad) 1 12 123 1234 12345 123456 1234567 12345678 123456789 admin password root sysadmin system toor

Ahora corremos medusa para realizar el ataque: #medusa -h 192.168.10.14 -u root -P password.txt -M ssh Medusa v2.0 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks The default build of Libssh2 is to use OpenSSL for crypto. Several Linux distributions (e.g. Debian, Ubuntu) build it to use Libgcrypt. Unfortunately, the implementation within Libssh2 of libgcrypt appears to be broken and is not thread safe. If you run multiple concurrent Medusa SSH connections, you are likely to experience segmentation faults. Please help Libssh2 fix this issue or encourage your distro to use the default Libssh2 build options. ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 1 (1 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 12 (2 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 123 (3 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 1234 (4 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 12345 (5 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 123456 (6 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 1234567 (7 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 12345678 (8 of 15 complete) ACCOUNT CHECK: [ssh] Host: 192.168.10.14 (1 of 1, 0 complete) User: root (1 of 1, 0 complete) Password: 123456789 (9 of 15 complete) Como vemos llegó a hacer 9 intentos de inicio de sesión por ssh con el usuario root y deja de hacerlo eso quiere decir que ya se tomaron acciones por parte de la víctima. OSSEC detecta el ataque mandándote un correo o bien por la interface web se puede ver: OSSEC HIDS Notification. 2012 Feb 01 21:55:15 Received From: (glpi) 192.168.10.14->/var/log/auth.log Rule: 5720 fired (level 10) -> “Multiple SSHD authentication failures.” Portion of the log(s): Feb 1 16:55:14 glpi sshd[25670]: Failed password for root from 192.168.10.7 port 34247 ssh2 Feb 1 16:55:12 glpi sshd[25670]: Failed password for root from 192.168.10.7 port 34247 ssh2 Feb 1 16:55:06 glpi sshd[24404]: Failed password for root from 192.168.10.7 port 34243 ssh2

Feb 1 16:55:04 glpi sshd[24404]: Failed password for root from 192.168.10.7 port 34243 ssh2 Feb 1 16:55:02 glpi sshd[24404]: Failed password for root from 192.168.10.7 port 34243 ssh2 Feb 1 16:54:55 glpi sshd[24401]: Failed password for root from 192.168.10.7 port 34240 ssh2 Feb 1 16:54:53 glpi sshd[24401]: Failed password for root from 192.168.10.7 port 34240 ssh2 Feb 1 16:54:51 glpi sshd[24401]: Failed password for root from 192.168.10.7 port 34240 ssh2 –END OF NOTIFICATION OSSEC HIDS Notification. 2012 Feb 01 21:55:17 Received From: (glpi) 192.168.10.14->/var/log/auth.log Rule: 2502 fired (level 10) -> “User missed the password more than one time” Portion of the log(s): Feb 1 16:55:16 glpi sshd[25670]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.10.7 user=root –END OF NOTIFICATION El ossec ordena al agente a ejecutar el script psad.sh. En los logs de psad veremos como se bloquea el atacante: Feb 1 17:01:17 glpi psad: added iptables auto-block against 192.168.10.7 for 600 seconds Podemos comprobar esto de la siguiente manera # psad --List \[+] Listing chains from IPT_AUTO_CHAIN keywords... Chain PSAD_BLOCK_INPUT (1 references) pkts bytes target prot opt in out source destination 1338 80280 DROP all — * * 192.168.10.7 0.0.0.0/0 Chain PSAD_BLOCK_OUTPUT (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all — * * 0.0.0.0/0 192.168.10.7 Chain PSAD_BLOCK_FORWARD (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all — * * 0.0.0.0/0 192.168.10.7 0 0 DROP all — * * 192.168.10.24 0.0.0.0/0

Hasta aquí llega nuestra exposición aunque ha sido corriendo y espero que entiendan, cualquier duda me contactan por el chat o correo. Este trabajo nos llevó casi un mes, primero el estudio del tema, después las pruebas que hicimos y por ultimo preparar cada uno de los servidores para que todo esto funcionase bien.