Nueva característica para Oinkmaster

Para el que no lo tenga presente, Oinkmaster es un muy útil script en perl que nos permite mantener las reglas de snort actualizadas. Oinkmaster permite customizar la forma en que las reglas se actualizan, posibilitando que el administrador elija si hay reglas que no desea tocar, si hay reglas que desea modificar y varias cosas más.

El script es relativamente simple, descarga el paquete de reglas desde la página de snort (un tar.gz) a un directorio temporal, lo descomprime y luego, dependiendo de lo especificado en el archivo oinkmaster.conf, copia dichas reglas al directorio de reglas de snort. Si las reglas nuevas cambian con respecto a las que teníamos, copia las nuevas al directorio. Lo bueno es que en oinkmaster.conf podemos definir que si nosotros desactivamos una regla, cuando actualice la mantenga desactivada, además podemos aplicar reglas de modificación, y saltear archivos completos de reglas (es decir para que no los pise con reglas nuevas). Realmente un lujo. Pueden leer más en su web oficial (http://oinkmaster.sourceforge.net/). Próximamente estaré publicando un artículo bastante completo sobre configuración de snort que incluye al oinkmaster.

Una necesidad que surgió durante la desactivación de alertas de Snort es poder agregar rangos de SIDs (id de reglas) para deshabilitar. En el script original, si deshabilitamos las reglas cuyos sid son 2, 3, 4, y 5, tendremos que agregar a oinkmaster.conf la opción "disablesid 2,3,4,5". Con estos numeritos no es tan problemático, pero con los SID kilométricos de algunas reglas, si deseamos desactivar varios SIDs sucesivos, es una molestia tener que escribir uno por uno.
Por ello modifiqué el script perl para poder agregar opciones del estilo "disablesid 2-5" en oinkmaster.conf y así poder deshabilitar varias reglas sin necesidad de escribir todos los SIDs. Ya que estaba, también modifiqué el script para que acepte rangos en la opción localsid (SID de reglas que no debe tocar), y enablesid (SID de reglas que debe activar).

A partir de las modificaciones (nada del otro mundo, cabe destacar), cree un diff que permite parchar el script original, el cual pueden descargar aquí.

Para aplicar el patch simplemente copien el código en un archivo oinkmaster.patch, guardenlo en el directorio donde tienen el script original (suele llamarse oinkmaster.pl u oinkmaster) y parados en dicho directorio, ejecuten lo siguiente:

# patch < oinkmaster.patch

Envié estas modificaciones al autor original (Andreas Östling), el cual me contestó varias semanas después, diciéndome que las modificaciones le parecían muy interesantes y que iba a tratar de incorporarlas, aunque ya no tiene tiempo para trabajar en Oinkmaster, así que no sabía cuándo iba a poder hacerlo.

En fin, espero que les resulte útil como a mi!

Configurar NTP en GNU/Linux

Si tenemos una red de mediana a grande, probablemente tengamos configurado algún servidor NTP (sobre todo si están en un entorno Windows Active Directory).
NTP o Network Time Protocol, es un protolo que nos permite sincronizar la hora entre las distintas máquinas. Hay distintas formas de calcular la hora. Por un lado los servidores NTP pueden estar sincronizados con uno (o varios) servidor/es UTC (Coordinated Universal Time). Por otro lado, si no contamos con acceso a esos servidores, podemos sincronizar los servidores NTP entre sí.
Elegir una u otra opción dependerá del administrador de red, pero supera la explicación que intento dar. Simplemente me limitaré a explicar como configurar una máquina como cliente de un/os servidor/es NTP. La explicación está basada en el artículo NTP Server and Client Configuration in debian (http://www.debianadmin.com/ntp-server-and-client-configuration-in-debian.html).

Para ello primero instalamos el paquete ntp, lo cual en debian y derivados se traduce a:

# apt-get install ntp

y luego configuramos el archivo /etc/ntp.conf. Ahora, o bien podemos dejar los servidores NTP de debian, o bien colocar los de nuestra red. Si deseamos utilizar los de nuestra red, comentamos las líneas con los servers debian y agregamos nuestros servervidores NTP. Suponiendo que los servidores NTP son 192.168.1.56, 192.168.1.57, agreguemos estas líneas a ntp.conf:

server 192.168.1.56
server 192.168.1.57

Como el paquete que instalamos también funciona de servidor NTP, si no queremos que otros se sincronicen con nuestro reloj, debemos restringir el acceso. El paquete NTP nos permite realizar esta restricción con el comando restrict. restrict sin otro parámetro que el servidor, le da a dicho servidor el mayor acceso (modificar configuraciones, consultar, etc). En nuestra modalidad cliente, él único servidor que tendrá este permiso es localhost (alias, nosotros mismos):

restrict 127.0.0.1

Si no queremos que los otros servidores tengan demasiado acceso, podemos restringirlos para que no modifiquen la configuración en tiempo real y que no puedan consultar nuestro servidor NTP:

restrict default notrust nomodify nopeer

Eso es todo en cuanto a configuración. Simplemente reiniciamos el demonio ntp:

# /etc/init.d/ntp restart

y realizamos una consulta para saber si está funcionando correctamente:

# ntpq -p
# ntpdc -p

Simple no?

Otra forma de sincronizar nuestro reloj con el de un servidor NTP es utilizar la aplicación ntpclient, con el servidor NTP como parámetro:

# ntpclient 192.168.1.56

Claro que esta sincronización se ejecuta cuando ejecutamos el comando, mientras que utilizando ntpd el sistema se sincroniza sólo cada un cierto intervalo de tiempo.

Activar HTTPS en Apache + Forzar SSL

Una tarea que repito una y otra vez al instalar un servidor Apache, es la configuración para activar HTTPS. Los pasos son bastante simples, pero es necesario algún que otro truco. Por ello, me pareció interesante describir el procedimiento.
Además les comentaré cómo forzar al servidor a que siempre utilice HTTPS, y que no envíe nada a través de HTTP.
La configuración que describiré a continuación está pensada para una distribución debian o basada en ésta, aunque los pasos no deberían cambiar mucho en otras distros.

Para configurar HTTPS, primero deben crear un certificado SSL. Hace poco más de un año escribí una guía completa, describiendo los certificados y cómo crear uno utilizando openssl. La pueden acceder aquí.

Una vez que tenemos el certificado, debemos actualizar apache para que escuche en el puerto 443 y decirle donde están los certificados. Las distros basadas en debian suelen traer el archivo /etc/apache2/sites-available/default-ssl, en el cual se encuentra una configuración default del VirtualHost necesario para utilizar HTTPS. Podemos utilizar este archivo como base para nuestra configuración. Simplemente deben copiar el archivo de sites-available a sites-enabled:

cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/

o bien, utilizar el comando a2ensite, que se encarga de habilitar Virtual Hosts definidos en sites-available:

a2ensite default-ssl

El siguiente paso me costó un par de horas de trabajo. El paso en sí es muy simple, pero encontrar el error me llevó bastante tiempo.
Luego de configurar el servidor para que funcione con ssl (incluyendo los pasos que describo luego), me encontré con que apache arrojaba el error "ssl_error_rx_record_too_long". Me costó un buen tiempo descubrir el problema, aunque la solución la tuve desde el principio en la página stackoverflow.
El error se debe a que en la configuración del VirtualHost default (/etc/apache2/sites-enabled/000-default) se especifica que apache debe utilizar esa configuración para todas las direcciones DNS y para todos los ports. Por ello, cuando accedemos a través de HTTPS (port 443), apache se encuentra con una configuración que no presenta SSL, y envía una respuesta HTTP común, cuando en realidad el browser del cliente está esperando una conexión SSL.
En fin, el error se soluciona cambiando la línea:

<VirtualHost *>

por

<VirtualHost *:80>

en el archivo /etc/apache2/sites-enabled/000-default. Ahora apache sabe que esta configuración es sólo para el port 80.

Una vez realizado el paso anterior, debemos modificar algunas líneas en el archivo sites-enabled/default-ssl para que funcione SSL. Por un lado necesitamos cambiar los paths al certificado y la clave del certificado. Dirijanse a la parte del archivo que empieza con "SSL Engine Switch" y asegúrense de que la línea "SSLEngine on" se encuentre descomentada. Luego modifiquen las líneas:

SSLCertificateKeyFile /path/clave.key
SSLCertificateFile /path/certificad.crt

y coloquen el path correspondiente. La primera especifica la ubicación de la clave, y la segunda la ubicación del certificado.


Configurado SSL correctamente, forzaremos al cliente a utilizar HTTPS en lugar de HTTP. Es decir, si el usuario olvida poner https en la dirección, forzaremos a que el server igualmente utilice https a través de una redirección.
Para forzar la redirección, agregaremos algunas líneas al archivo /etc/apache2/sites-enabled/000-default. Vayan a la parte donde se configura el directorio base, y dejenlo de la siguiente forma:

<Directory /var/www/>
...
...
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Directory>

Las líneas que agregamos realizan un if. Si no se está utilizando HTTPS (RewriteCond %{HTTPS} off), entonces redirigir a la misma dirección pero utilizando HTTPS (RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}). Estas reglas las obtuve de Apache: Redirect http to https Apache secure connection – force HTTPS Connections.

Eso es todo, ya tenemos habilitado SSL en Apache, y establecimos que siempre se utilice HTTPS =)

Links: sniffing con tcpdump

Hace mucho tiempo que no publico links, en parte porque me gusta publicarlos cuando tengo varios que traten un mismo tema.
En esta ocasión les traigo links sobre la herramienta de sniffing tcpdump.
Si bien Wireshark sigue siendo mi herramienta favorita a la hora de sniffear, esta es bastante pesada y requiere de una interfaz gráfica, algo que no siempre tenemos. tcpdump tiene la misma potencia que wireshark, con la diferencia que esta última es liviana y corre desde la consola.
Es obvio que desde la consola es más difícil visualizar lo que deseamos, pero gracias a la cantidad de filtros que trae, y dado que podemos guardar lo sniffeado en un archivo para luego parsearlo con otras herramientas, es una herramienta extremadamente útil.
Si bien el nombre es TCPdump, permite filtrar contenidos de otros protocolos como arp, ip, udp, etc, es decir, no se limita a TCP.
La salida es en modo texto y podemos ver el contenido del payload en hexa y en ascii.

Sin más introducción, les dejo los links:

tcpdump for Dummies. El nombre lo dice todo. Describe de forma simple el funcionamiento de tcpdump y llega a mostrar varios filtros útiles, realmente muy bueno para empezar.

Understanding tcpdump. Tutorial bastante más avanzado que el anterior donde muestran distintas salidas, filtrado de distintos protocolos, filtrado por flags TCP, y mucho más, realmente muy bueno.

TCPDUMP (manpage). No podía faltar el completísimo manual oficial de tcpdump. En éste se muestran todas las opciones, los formatos de salida, y ejemplos. Seguramente la referencia más completa al uso de tcpdump.

Spy on the Spyware with tcpdump. Interesante tutorial enfocado a detectar spyware, pero muy general, mostrando varios ejemplos de filtros.

Espero que les sea de utilidad. El sniffing por consola puede parecer bastante rústico, pero es muy útil si aplicamos los filtros correctos. tcpdump es una excelente opción.