Monitorización orientada a host con OSSEC II

jue, 13 nov 2008 by Foron

En mi primer post sobre ossec he mostrado los pasos para hacer una instalación básica y completamente estándar de ossec. En este post vamos a ver lo que hay por debajo del software.

Ossec usa tres componentes: un detector de rootkits, una herramienta para revisar la integridad del sistema, y el analizador de logs. Todas ellas se configuran en el fichero ossec.conf.

Este fichero de configuración tiene una estructura muy clara, en formato xml, en el que se definen varios bloques.

En este post sólo voy a dar algunas ideas básicas sobre el formato con el que se definen las reglas que describen los eventos detectables en los logs.

Tanto el chequeo de integridad como el detector de rootkits se configuran de una forma muy similar, así que lo dejaré para que quien quiera se pelee con ello.

En ossec.conf se definen los logs que se quieren monitorizar dentro de secciones "localfile". Un ejemplo:

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

En este caso se dice que queremos vigilar auth.log, del tipo syslog. Existen varios formatos definidos, como apache o snort-full, por citar dos ejemplos. Syslog se usa en los casos en los que se loguea un único evento por linea. Sort-full, por poner otro ejemplo, está adaptado al tipo de log que deja snort cuando usa el formato de salida full.

Una vez definidos los formatos, empezamos a hablar de reglas. El primer paso es que ossec detecte qué tipo de entrada de log es. Para esto se usan los decoders (decoder.xml) Veamos un ejemplo.

  <decoder name="sshd">
  <program_name>^sshd</program_name>
  </decoder>

Este decoder "se activa" cuando la entrada de log es generada por el programa sshd (sshd[5493] en el siguiente ejemplo):

  Feb  3 19:22:33 server sshd[5493]: Accepted publickey for prueba from 192.168.10.2 port 50560 ssh2

Pero, a pesar de la importancia de esta sencilla regla (después veremos por qué), necesitamos extender el decoder para que sea útil.

  <decoder name="ssh-failed">
  <parent>sshd</parent>
  <prematch>^Failed \S+ </prematch>
    <regex offset="after_prematch">^for (\S+) from (\S+) port \d+ \w+$</regex>
    <order>user, srcip</order>
  </decoder>

Gracias a la primera y simple regla "sshd" nos aseguramos que ossec sólo va a analizar la entrada de log contra esta segunda regla, mucho más compleja, si dicho log está relacionado con ssh. Esto es una gran mejora en el rendimiento del sistema.

Sin entrar en explicaciones detalladas, esta regla se cumple con este tipo de log:

  Jul 26 22:06:10 server sshd[3727]: Failed password for prueba from 192.168.10.2 port 50519 ssh2

Y además crea dos "variables"; una con el usuario que ha intentado conectarse y otra con la IP origen.

Teniendo estos datos ya podemos empezar con las reglas "de verdad". Veamos algo del fichero sshd_rules.xml

  <rule id="5700" level="0" noalert="1">
    <decoded_as>sshd</decoded_as>
    <description>SSHD messages grouped.</description>
  </rule>

  <rule id="5716" level="5">
    <if_sid>5700</if_sid>
    <match>^Failed|^error: PAM: Authentication</match>
    <description>SSHD authentication failed.</description>
    <group>authentication_failed,</group>
  </rule>

De manera similar a los decoders, se define una primera regla básica para ssh, que ayudará a ossec en no tener que analizar reglas de apache (por ejmplo) en logs de ssh.

La segunda regla (5716) generará una alerta de nivel 5 cuando haya un intento de login erroneo. Pero también se pueden crear reglas compuestas que activarán alertas de mayor nivel si hay x intentos fallidos desde una misma IP

  <rule id="5720" level="10" frequency="6">
    <if_matched_sid>5716</if_matched_sid>
    <same_source_ip />
    <description>Multiple SSHD authentication failures.</description>
    <group>authentication_failures,</group>
  </rule>

Gracias al formato xml es muy sencillo añadir nuevas reglas. También se pueden enviar correos con las alertas a cuentas de correo diferentes en base, por ejemplo, al agente que ha generado la alerta o al nivel de la misma.

En el tercer y último post de la serie vamos a integrar ossec con psad.

read more

Inspección de tráfico con tcpdump y tcpflow

sáb, 08 nov 2008 by Foron

Antes de seguir con el segundo post sobre ossec, voy a dar un par de pistas sobre cómo ver el tráfico que pasa por una sesión tcp. Esto sí que es todo un mundo, así que me limito, como casi siempre, a dar cuatro detalles para que quien quiera se haga una idea de lo que se puede hacer y siga investigando.

Por supuesto, el que se pueda "espiar" lo que se está trasmitiendo no significa que debamos (ni podamos) hacerlo, al menos si no queremos tener problemas legales.

Vamos a empezar por lo básico. Necesitamos capturar tráfico para poderlo analizar después con cierta tranquilidad. Para esto usamos el conocido tcpdump, aunque podemos usar otros, como por ejemplo, snort.

  tcpdump -n -i eth1 -s 1515 -U -w /tmp/captura.pcap '(tcp port 20) or (tcp port 21) or (tcp port 25)'
  tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 1515 bytes

Para saber lo que hacen los parámetros nada mejor que el manual :-)

Dejamos esta terminal abierta y con el comando en ejecución. Vamos a ir analizando lo que se vuelca en captura.pcap en otra terminal.

Primera prueba.

Desde otra máquina vamos a hacer un telnet al puerto 25 y a mandar un correo.

  telnet 192.168.10.1 25
  Trying 192.168.10.1...
  Connected to 192.168.10.1.
  Escape character is '^]'.
  220 smtp.example.com ESMTP Postfix
  helo prueba.example.com
  250 smtp.example.com
  rset
  250 2.0.0 Ok
  helo prueba.example.com
  250 smtp.example.com
  mail from: prueba@example.com
  250 2.1.0 Ok
  rcpt to: prueba1@example.com
  250 2.1.5 Ok
  data
  354 End data with .
  Subject: Titulo del correo
  Este texto se ve en la captura
  .
  250 2.0.0 Ok: queued as 1F7426C420
  quit
  221 2.0.0 Bye
  Connection closed by foreign host.

Nuestro volcado tiene datos.... vamos a ver que tiene usando tcpflow.

  # tcpflow -r captura.pcap -c port 25
  192.168.010.001.00025-192.168.010.002.41403: 220 smtp.example.com ESMTP Postfix
  192.168.010.002.41403-192.168.010.001.00025: helo prueba.example.com
  192.168.010.001.00025-192.168.010.002.41403: 250 smtp.example.com
  192.168.010.002.41403-192.168.010.001.00025: rset
  192.168.010.001.00025-192.168.010.002.41403: 250 2.0.0 Ok
  192.168.010.002.41403-192.168.010.001.00025: helo prueba.example.com
  192.168.010.001.00025-192.168.010.002.41403: 250 smtp.example.com
  192.168.010.002.41403-192.168.010.001.00025: mail from: prueba@example.com
  192.168.010.001.00025-192.168.010.002.41403: 250 2.1.0 Ok
  192.168.010.002.41403-192.168.010.001.00025: rcpt to: prueba1@example.com
  192.168.010.001.00025-192.168.010.002.41403: 250 2.1.5 Ok
  192.168.010.002.41403-192.168.010.001.00025: data
  192.168.010.001.00025-192.168.010.002.41403: 354 End data with .
  192.168.010.002.41403-192.168.010.001.00025: Subject: Titulo del correo
  192.168.010.002.41403-192.168.010.001.00025: Este texto se ve en la captura
  192.168.010.002.41403-192.168.010.001.00025: .
  192.168.010.001.00025-192.168.010.002.41403: 250 2.0.0 Ok: queued as 1F7426C420
  192.168.010.002.41403-192.168.010.001.00025: quit
  192.168.010.001.00025-192.168.010.002.41403: 221 2.0.0 Bye

Sorpresa, tcpflow ha generado, en esta caso por salida estándar (-c), todo lo que ha sido capturado en el puerto 25.

Segunda prueba.

Bien, vamos con algo un poco diferente, pero igual de fácil (recordad que esto no son más que ideas)

Ahora vamos a suponer que he programado un rootkit que se llama exploit, y que lo voy a subir por ftp a la máquina que estamos monitorizando.

  ftp 192.168.10.1
  Connected to 192.168.10.1.
  220 Este es un servidor privado. Por favor cierre la sesion inmediatamente.
  Name (192.168.10.1:prueba):
  331 Please specify the password.
  Password:
  230 Login successful.
  Remote system type is UNIX.
  Using binary mode to transfer files.
  ftp> put exploit
  local: exploit remote: exploit
  200 PORT command successful. Consider using PASV.
  150 Ok to send data.
  226 File receive OK.
  101992 bytes sent in 0.00 secs (29433.1 kB/s)
  ftp> quit
  221 Goodbye.

Muy bien, ahora veamos lo que tenemos, empezando por el puerto 21, y después por el 20.

  # tcpflow -r captura.pcap -c port 21
  192.168.010.001.00021-192.168.010.002.50427: 220 Este es un servidor privado. Por favor cierre la sesion inmediatamente.
  192.168.010.002.50427-192.168.010.001.00021: USER prueba
  192.168.010.001.00021-192.168.010.002.50427: 331 Please specify the password.
  192.168.010.002.50427-192.168.010.001.00021: PASS secreto
  192.168.010.001.00021-192.168.010.002.50427: 230 Login successful.
  192.168.010.002.50427-192.168.010.001.00021: SYST
  192.168.010.001.00021-192.168.010.002.50427: 215 UNIX Type: L8
  192.168.010.002.50427-192.168.010.001.00021: TYPE I
  192.168.010.001.00021-192.168.010.002.50427: 200 Switching to Binary mode.
  192.168.010.002.50427-192.168.010.001.00021: PORT 192,168,10,2,205,32
  192.168.010.001.00021-192.168.010.002.50427: 200 PORT command successful. Consider using PASV.
  192.168.010.002.50427-192.168.010.001.00021: STOR exploit
  192.168.010.001.00021-192.168.010.002.50427: 150 Ok to send data.
  192.168.010.001.00021-192.168.010.002.50427: 226 File receive OK.
  192.168.010.002.50427-192.168.010.001.00021: QUIT
  192.168.010.001.00021-192.168.010.002.50427: 221 Goodbye.

Vamos a hacer ahora que tcpflow genere un fichero con el tráfico del puerto 20. Para esto quitamos el parámetro -c.

  # tcpflow -r captura.pcap  port 20
  # file 192.168.010.002.52512-192.168.010.001.00020
  192.168.010.002.52512-192.168.010.001.00020: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

Sorpresa, tenemos un fichero binario ..... con el exploit. Bueno, en realidad en una copia de /bin/ls, pero vale para el ejemplo

  # strings 192.168.010.002.52512-192.168.010.001.00020
  .......
  Usage: %s [OPTION]... [FILE]...
  List information about the FILEs (the current directory by default).
  Sort entries alphabetically if none of -cftuvSUX nor --sort.
  Mandatory arguments to long options are mandatory for short options too.
    -a, --all                  do not ignore entries starting with .
    -A, --almost-all           do not list implied . and ..
        --author               with -l, print the author of each file
    -b, --escape               print octal escapes for nongraphic characters
        --block-size=SIZE      use SIZE-byte blocks
  .......

¿Qué pasa en la realidad, cuando tenemos cientos o miles de sesiones de correo o ftp y queremos ver una concreta? Por un lado debemos guardar el tráfico que queremos investigar, claro, pero luego debemos saber qué sesiones se han establecido, a qué hora, cuánto tráfico ha pasado por ellas, entre que puertos, .... Para esto hay mucho software, pero un buen ejemplo es argus. A partir de aquí, podemos generar expresiones más elaboradas para usar en tcpflow (algo más que "port 20")

read more

Monitorización orientada a host con OSSEC I

sáb, 01 nov 2008 by Foron

En el mundo del software libre hay multitud de proyectos que, debido a su calidad, han terminado siendo comprados por empresas para ser usados como parte de sus soluciones comerciales. Dos ejemplos son sguil y ossec.

En la próxima serie de dos posts voy a comentar muy por encima lo principal de ossec.

Ossec es un proyecto relacionado con la seguridad informática, y particularmente con lo que se suele llamar HIDS. Dicho de otra forma, y simplificando mucho, se trata de una aplicación que monitoriza una máquina, y que detecta las anomalías que puedan producirse en el sistema. Para hacer esto usa sobre todo una herramienta para la detección de rootkits, otra para revisar la integridad de ficheros y ejecutables del sistema, y por último un potente sistema para analizar logs.

En cuanto a la arquitectura del sistema, usa básicamente un modelo de servidor/agentes, con lo que tendremos una máquina (servidor) encargada de recibir y actuar en base a la información que reciba de los agentes que, en definitiva, son las máquinas que están siendo monitorizadas. La forma de actuar del servidor es, por una parte, enviando noficaciones, y por otro lado, si así se configura, generando reglas firewall que se ejecutarán en los propios agentes.

Este primer post sólo va a describir la instalación de ossec. Dejamos para posts posteriores la configuración.

La instalación de ossec es muy sencilla. Es suficiente con ejecutar el típico install.sh del fichero de instalación que se puede descargar desde la web.

  sh install.sh

Una vez seleccionamos el idioma de instalación empieza el tema.

  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]:  /usr/local/ossec-1.6
       - Installation will be made at  /usr/local/ossec-1.6 .
  3- Configuring the OSSEC HIDS.
    3.1- Do you want e-mail notification? (y/n) [y]:
     - What's your e-mail address? zzz@yyyyyyy.net
     - We found your SMTP server as: mail.yyyyyyy.net.
     - Do you want to use it? (y/n) [y]:
     --- Using SMTP server:  mail.yyyyyyy.net.
    3.2- Do you want to run the integrity check daemon? (y/n) [y]:
     - Running syscheck (integrity check daemon).
    3.3- Do you want to run the rootkit detection engine? (y/n) [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]: n
       - Active response disabled.
    3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [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/vsftpd.log
      -- /var/log/mail.info
      -- /var/log/dpkg.log
      -- /var/log/snort/alert (snort-full file)
      -- /var/log/apache2/error.log (apache log)
      -- /var/log/apache2/access.log (apache log)

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

A partir de aquí empieza a compilar los distintos componenetes. He elegido una instalación para el servidor que recibirá los eventos, y he activado tanto la detección de rootkits como la revisión de integridad, pero he dejado sin activar la respuesta activa, que básicamente se trata de añadir entradas a hosts.deny y reglas de firewall.

El syslog remoto lo vamos a usar para recibir mensajes desde los agentes.

Por cierto, mientras escribía estas líneas el sistema se ha terminado de compilar:

  - System is Debian (Ubuntu or derivative).
  - Init script modified to start OSSEC HIDS during boot.
  - Configuration finished properly.
  - To start OSSEC HIDS:
                 /usr/local/ossec-1.6/bin/ossec-control start
  - To stop OSSEC HIDS:
                 /usr/local/ossec-1.6/bin/ossec-control stop
  - The configuration can be viewed or modified at /usr/local/ossec-1.6/etc/ossec.conf
      Thanks for using the OSSEC HIDS.
      If you have any question, suggestion or if you find any bug,
      contact us at contact@ossec.net or using our public maillist at
      ossec-list@ossec.net
      ( http://www.ossec.net/main/support/ ).
      More information can be found at http://www.ossec.net
  ---  Press ENTER to finish (maybe more information below). ---

A partir de aquí, por un lado tendremos que configurar ossec (ossec.conf), y después tendremos que ir añadiendo los agentes con la utilidad /usr/local/ossec-1.6/bin/manage_agents.

Vamos a arrancar el servidor y a añadir un par de agentes, uno en linux y otro en windows. Bueno, el agente windows no lo voy a documentar aquí. Tiene un instalador gráfico que se descarga desde la web, y los pasos son muy similares.

  /usr/local/ossec-1.6/bin/ossec-control start
  Starting OSSEC HIDS v1.6 (by Third Brigade, Inc.)...
  Started ossec-maild...
  Started ossec-execd...
  Started ossec-analysisd...
  Started ossec-logcollector...
  Started ossec-remoted...
  Started ossec-syscheckd...
  Started ossec-monitord...
  Completed.

  # ps aux | grep osse
  ossecm    5579  0.0  0.0   2076   528 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-maild
  ossec     5587  0.0  0.1   2664  1312 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-analysisd
  root      5591  0.0  0.0   1796   468 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-logcollector
  root      5603  2.5  0.0   1944   512 ?        D    17:45   0:04 /usr/local/ossec-1.6/bin/ossec-syscheckd
  ossec     5607  0.0  0.0   1980   480 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-monitord
  ossecm    5610  0.0  0.0   2076   300 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-maild

  # ./manage_agents
  ***********************************************
  * OSSEC HIDS v1.6 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: agente1
      * The IP Address of the new agent: 172.17.0.131
      * An ID for the new agent[001]:
  Agent information:
      ID:001
      Name:agente1
      IP Address:172.17.0.131
  Confirm adding it?(y/n): y
  Agent added.

  # ./manage_agents

  ***********************************************
  * OSSEC HIDS v1.6 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: agente1, IP: 172.17.0.131
  Provide the ID of the agent to extract the key (or '\q' to quit): 001
  Agent key information for '001' is:
  XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=

  ** Press ENTER to return to the main menu.

Y ya está. Ahora sólo queda instalar el agente en el servidor a monitorizar. La clave se usa para la comunicación agente/servidor.

  # ./install.sh
  ...
  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]: /usr/local/ossec-1.6
      - Installation will be made at  /usr/local/ossec-1.6 .
  3- Configuring the OSSEC HIDS.
    3.1- What's the IP Address of the OSSEC HIDS server?: 172.17.0.1
      - Adding Server IP 172.17.0.1
    3.2- Do you want to run the integrity check daemon? (y/n) [y]:
      - Running syscheck (integrity check daemon).
    3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
      - Running rootcheck (rootkit detection).
    3.4 - Do you want to enable active response? (y/n) [y]: n
      - Active response disabled.
    3.5- Setting the configuration to analyze the following logs:
      -- /var/log/messages
      -- /var/log/auth.log
      -- /var/log/syslog
      -- /var/log/mail.info
      -- /var/log/dpkg.log
    - 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 ---

Y ahora copiamos la clave pública que antes hemos sacado del servidor:

  ./bin/manage_agents

  ***********************************************
  * OSSEC HIDS v1.6 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): XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=
  Agent information:
     ID:001
     Name:agente1
     IP Address:172.17.0.131
  Confirm adding it?(y/n): y
  Added.
  ** Press ENTER to return to the main menu.

Arrancamos el agente... y ya está.

  /usr/local/ossec-1.6/bin/ossec-control start

Y no hay nada más que hacer para tener lo básico de ossec. Por supuesto, todo es muy configurable, y ampliable en base a lo que cada uno necesite.

Desde otra máquina, me intento conectar digamos que 10 veces usando ssh con usuarios invalidos..... sorpresa, recibo este correo.

  OSSEC HIDS Notification.
  2008 Sep 21 22:30:40

  Received From: (agente1) 172.17.0.131->/var/log/auth.log
  Rule: 5712 fired (level 10) -> "SSHD brute force trying to get access to the system."
  Portion of the log(s):

  Sep 21 19:06:32 fn131 sshd[5990]: Invalid user aaaaab from 172.17.0.2
  Sep 21 19:06:26 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
  Sep 21 19:06:23 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
  Sep 21 19:06:21 fn131 sshd[5986]: Failed none for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
  Sep 21 19:06:21 fn131 sshd[5986]: Invalid user aaaaa from 172.17.0.2
  Sep 21 19:06:09 fn131 sshd[5984]: Failed password for invalid user aaaah from 172.17.0.2 port 39009 ssh2
  Sep 21 19:06:06 fn131 sshd[5984]: Failed none for invalid user aaaah from 172.17.0.2 port 39009 ssh2

Algunos ejemplos con distintos tipos de eventos:

  OSSEC HIDS Notification.
  2008 Oct 09 21:29:03

  Received From: servidor->syscheck
  Rule: 550 fired (level 7) -> "Integrity checksum changed."
  Portion of the log(s):

  Integrity checksum changed for: '/etc/dovecot/dovecot.conf'
  Size changed from '45438' to '45460'
  Old md5sum was: 'bd5c81584dad9725045ec0e52eb0c15c'
  New md5sum is : '439061951cdeb975c21d37b4cc5f8649'
  Old sha1sum was: '8d7ade9a74b9e8ff4d6758c14bdb070ccb15b198'
  New sha1sum is : '8e7d34ba6328a1e5d38645972b369e700f7d05b2'
   --END OF NOTIFICATION

  OSSEC HIDS Notification.
  2008 Oct 07 18:29:00

  Received From: servidor->/var/log/dpkg.log
  Rule: 2902 fired (level 7) -> "New dpkg (Debian Package) installed."
  Portion of the log(s):

  2008-10-07 18:29:00 status installed unzip 5.52-12
   --END OF NOTIFICATION

  OSSEC HIDS Notification.
  2008 Oct 05 17:42:23

  Received From: agente1->/var/log/messages
  Rule: 5104 fired (level 8 ) -> "Interface entered in promiscuous(sniffing) mode."
  Portion of the log(s):

  Oct  5 17:42:21 nurn kernel: device lo entered promiscuous mode
   --END OF NOTIFICATION

En el próximo post veremos un poco sobre la configuración de todas estas reglas.

read more

Firewalls proactivos con psad II

dom, 07 sep 2008 by Foron

En el anterior post hemos visto lo más básico de psad. De hecho, he resumido alguna cosa tanto que los que ya conozcan el software pueden decir que no he sido todo lo riguroso que debiera. Un ejemplo, la parte relacionada con las variables IPT_AUTO_CHAINn. Mi objetivo, más que ser completamente riguroso, era dar una visión global del software.

En fin, dicho esto, vamos a ver alguna otra cosilla que se puede hacer con psad.

Recordemos el problema. Queremos poder añadir a nuestro firewall perimetral reglas que con el tiempo vayan expirando sin tener que estar encima. Queremos, además, que estas reglas se añadan en base a decisiones que tomen los servidores web o smtp en base a sus propios mecanismos, quitando al firewall perimetral la responsabilidad del análisis del tráfico del nivel de aplicación.

Hay varias formas de hacerlo. Lo más fácil es usar el propio comando psad. Por ejemplo:

  # psad -fw-block-ip 10.0.5.98
  [+] Writing 10.0.5.98 to socket; psad will add the IP
      within 5 seconds.

Es tan sencillo como esto. Veamos el resultado:

  # psad --fw-list
  [+] Listing chains from IPT_AUTO_CHAIN keywords...

  Chain PSAD_BLOCK (1 references)
   pkts bytes target     prot opt in     out     source               destination
       0     0 DROP       all  --  *      *       10.0.5.98            0.0.0.0/0

Para quitar esta IP es suficiente con esperar los 600 segundos configurados, o bien ejecutar:

  # psad --fw-rm-block-ip 10.0.5.98
  [+] Writing 10.0.5.98 to socket; psad will remove the IP
      within 5 seconds.

  # psad --fw-list
  [+] Listing chains from IPT_AUTO_CHAIN keywords...

  Chain PSAD_BLOCK (1 references)
   pkts bytes target     prot opt in     out     source               destination

A partir de aquí, seguro que a cada uno se le ocurren cinco formas de hacer que un servidor genere los comandos para que el firewall añada las reglas.

La forma en la que cada administrador gestiona lo que puede hacer con psad es particular de cada infraestructura, pero sin duda, una combinación de psad, fwsnort y otras técnicas como el port knocking añaden funcionalidades muy interesantes que en muchos casos ni siquera el software/hardware de pago ofrecen.

read more

Firewalls proactivos con psad

sáb, 06 sep 2008 by Foron

En este post voy a documentar un uso alternativo que se puede dar a psad, un interesante software pensado para la detección de escaneos de puertos, que fue creado como parte de bastille linux en el 1999.

El problema:

Tenemos un firewall que gestiona una red digamos que de servidores web y smtp, para los que evidentemente tenemos acceso libre por los puertos 25 y 80, pero que reciben multitud de ataques de todo tipo. Las propias aplicaciones tienen sus mecanismos de seguridad, pero al final siempre añadimos muchas de las IPs que generan los ataques en el firewall perimetral. Claro, al final tenemos cientos de IPs en los firewalls que somos incapaces de mantener, y que no hacen más que complicar su gestión. Para colmo, la mayoría de esas IP sólo lo intentan durante unos pocos minutos.

Una solución:

Queremos un sistema con el que podamos añadir IPs al firewall, y que expiren, si así lo decidimos, en un cierto plazo de tiempo. Vamos a utilizar psad para esto, que además, al mismo precio, nos sirve para detectar escaneos de puertos. En este primer post sobre todo escribiré sobre lo básico de psad, que en el próximo iremos adaptando al problema.

Vamos a ir instalando. Una opción es descargar el sofware y usar su propio instalador desde cipherdyne.org/psad/, pero en este caso voy a usar el software ya precompilado para Debian. Por cierto, más que recomendable dar una vuelta por cipherdyne.org y ver el software que hay disponible.

  aptitude install -R psad

No quiero que installe bastille, de ahí que use -R. Psad es una aplicación que en su mayoría está programada en perl, así que dependiendo de lo que cada uno tenga en su sistema instalará más o menos librerías.

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 syslog.conf:

  kern.info       |/var/lib/psad/psadfifo

Después de reiniciar syslog, ya está todo practicamente listo ....

Configuración:

Dependiendo de la forma de instalación y de la distribución que usemos, seguramente las rutas, nombres de pipes y alguna otra opción podrían ser diferentes, con lo que lo descrito aquí es más conceptual que algo con lo que se pueda hacer copy/paste.

Como psad es un software que sobre todo lee logs, es fundamental que nuestro firewall loguee lo que queremos tratar, que puede ser sólo lo del propio cortafuegos, o también lo que otras máquinas puedan enviarle. En definitiva, que aquí está la clave del invento.

Como referencia, hay que tener en cuenta que psad mira que en las líneas de logs que recibe existan las cadenas IN= y OUT=, con lo que asume que son de iptables. Esto nos será útil posteriormente.

Toda la configuración se hace en /etc/psad/psad.conf. En el directorio /etc/psad hay muchos otros ficheros, algunos los trataré en este post, pero otro no. Hay que tener en cuenta que psad es un software que hace más cosas que lo que voy a describir aquí.

La configuración es muy sencilla de leer y muy documentada, "se explica sola", así que sólo voy a comentar lo más útil para hacerse una idea.

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.

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               5;    ### Number of packets.
  DANGER_LEVEL2               15;
  DANGER_LEVEL3               150;
  DANGER_LEVEL4               1500;
  DANGER_LEVEL5               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

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       0;
  10.111.21.23    5   tcp/22;

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 sólo quedaría arrancar psad, con:

  /etc/init.d/psad start

Pruebas de funcionamiento:

Veamos lo que pasa cuando alguien nos hace un escaneo de puertos. Como nota, tengo un danger_level (DL) de 3 a partir del cual se añaden reglas de bloqueo.

  Sep  6 21:48:05  psad: src: 87.218.x.y signature match: "MISC MS Terminal Server communication attempt" (sid: 100077) tcp port: 3389
  Sep  6 21:48:05  psad: src: 87.218.x.y signature match: "MISC Microsoft PPTP communication attempt" (sid: 100082) tcp port: 1723
  Sep  6 21:48:05  psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [21-6347] flags: SYN tcp pkts: 130 DL: 2
  Sep  6 21:48:11  psad: src: 87.218.x.y signature match: "BACKDOOR DoomJuice file upload attempt" (sid: 2375) tcp port: 3141
  Sep  6 21:48:11  psad: src: 87.218.x.y signature match: "DOS Real Audio Server communication attempt" (sid: 100112) tcp port: 7070
  Sep  6 21:48:11  psad: src: 87.218.x.y signature match: "BACKDOOR Subseven DEFCON8 2.1 connection Attempt" (sid: 107) tcp port: 16959
  Sep  6 21:48:11  psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [2-32770] flags: SYN tcp pkts: 214 DL: 3
  Sep  6 21:48:11  psad: added iptables auto-block against 87.218.x.y for 600 seconds
  Sep  6 21:48:16  psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [104-13722] flags: SYN tcp pkts: 30 DL: 3

Donde 87.218.x.y es la IP origen del escaneo y 83.213.x.y el destino.

En el firewall:

  # iptables -L PSAD_BLOCK -n -t nat
  Chain PSAD_BLOCK (1 references)
  target     prot opt source               destination
  DROP       all  --  87.218.x.y       0.0.0.0/0

Y a los 600 segundos, se vacia.

  Sep  6 21:58:13 psad: removed iptables auto-block against 87.218.x.y
  # iptables -L PSAD_BLOCK -n -t nat
  Chain PSAD_BLOCK (1 references)
  target     prot opt source               destination

Lo que he hecho hasta ahora es lo básico de psad. En el próximo post seguiré con alguna otra cosilla interesante.

Para el que quiera buscar más información, nada como el libro linux firewalls. Un libro realmente excelente de una editorial que merece la pena.

read more