Entonces me planteé la pregunta de como podía asegurarme de que el próximo “inquilino” del servidor viejo no pudiera recuperar ninguno de mis ficheros. Ya conocía las utilidades wipe o shred pero me faltaba encontrar una forma de poder ejecutarlas borrando todo el disco duro. Por suerte, los servidores dedicados de OVH disponen del “modo rescate” que arranca una mini-distribución por red en nuestro servidor a la que nos podremos conectar por SSH tras recibir el correo con la contraseña de root y que, afortunadamente, dispone de shred.

Así que, los pasos para devolver el servidor de forma segura serían:

1. En el manager de OVH vamos a la sección ‘Servicios’ y vamos a ‘Netboot’
2. De los netboot disponibles seleccionaremos ‘rescue-pro‘
3. Ahora reiniciaremos el servidor para que arranque la distribución de rescate. Una vez haya arrancado, recibiremos un mail con la contraseña del usuario root.
4. Ya sólo nos queda conectarnos por SSH al servidor usando la contraseña recibida y ejecutar 

   root@rescue:~# nohup shred -fvz /dev/sda&

Ese comando sobrescribirá todo el disco duro 25 veces (valor por defecto) con varios patrones y finalmente lo sobrescribirá con ceros para, según la página de man, ocultar el hecho de que se ha ejecutado. Dependiendo del tamaño del disco, el borrado seguro puede tardar bastantes horas, incluso días. Por eso aconsejo ejecutarlo con nohup y ponerlo en background. Así podremos desconectarnos y el proceso seguirá ejecutándose. Siempre podremos verificar el progreso leyendo el fichero nohup.out.

Una vez haya terminado, reiniciamos el servidor y ya estará listo para regresar a manos del proveedor sin que debamos temer por nuestros datos.

Pero hoy, tras actualizar a la versión 2.8.1, por casualidad he lanzado un grep en un directorio que no tocaba y he descubierto el fichero wp-admin/includes/class-wp-filesystem-ssh2.php. Resulta que WordPress también puede usar SSH para realizar esas actualizaciones. Normalmente esa opción no aparece por que no disponemos de todo el software necesario para que funcione, pero es bastante sencillo conseguirlo. Veamos como hacerlo en una Debian:

$ sudo aptitude install libssh2-1 libssh2-1-dev php5-dev
$ sudo pecl install -f ssh2
$ sudo vi /etc/php5/conf.d/ssh2.ini
    extension=ssh2.so
$ sudo /etc/init.d/apache2 restart

Una vez tenemos instalada la extensión ssh2.so de PHP, podemos desinstalar los paquetes de desarrollo que instalamos en el primer paso.

$ sudo aptitude remove libssh2-1 libssh2-1-dev php5-dev

Listo, ya podemos actualizar los plugins desde la comodidad de nuestro navegador sin necesidad de tener un servidor FTP o FTPS. Seguramente también se puede usar para actualizar el propio WordPress, aunque no lo puedo confirmar ya que yo lo actualizo usando subversión.

Como se puede ver es bastante sencillo. De todas formas, os dejo un screencast que he hecho sobre la instalación (inaugurando mi cuenta de YouTube).

Voy a dar por sentado que tenemos un Postfix instalado y configurado para que use el Amavis para las funciones de anti-virus y anti-spam. Si no es así, te recomiendo que leas el excelente artículo de Jaume Sabater.

El primer problema lo tenemos si el mismo servidor está actuando como MX y como servidor SMTP para nuestros usuarios: Amavis firmaría tanto los correos de nuestros usuarios como los que le llegan en su función de MX, y no es lo que queremos. Por tanto, lo primero es separar esas dos funciones (MX y submission) en el Postfix añadiendo las siguientes líneas en /etc/postfix/master.cf (seguramente ya haya algo parecido pero comentado)

1
2
3
4
5

submission inet n       -       n       -       -       smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o content_filter=smtp-amavis:[127.0.0.1]:10026

Con estas líneas estamos indicándole al Postfix que también escuche por el puerto de submission (587/tcp), que por ese puerto sólo acepte correo de conexiones autentificadas y cifradas por TLS, y que debe enviar los correos recibidos al Amavis usando el puerto 10026 (mientras que el resto se seguirá enviando por el puerto 10024). Con esto conseguiremos que Amavis distinga y trate de forma diferente los correos de los usuarios.

Lo siguiente es hacer que Amavis también escuche por el puerto 10026 y hacer que firme los correos que le lleguen por ese puerto. Lo haremos añadiendo al fichero /etc/amavis/conf.d/50-user:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$inet_socket_port = [10024, 10026];
 
$interface_policy{'10026'} = 'AUTH';
 
$policy_bank{'AUTH'}   = {           # Authenticated clients
os_fingerprint_method   => undef, # don't fingerprint authenticated clients
bypass_spam_checks_maps => [1],   # don't spam check authenticated clients
originating => 1,
#
# force MTA to convert mail to 7-bit before DKIM signing
# to avoid later conversions which could destroy signature:
smtpd_discard_ehlo_keywords => ['8BITMIME'],
};
 
$enable_dkim_signing = 1;
dkim_key('llull.net', 'personal', '/etc/dkim/llull.net.key.pem');

En la última línea le indicamos que para el dominio ‘llull.net‘ y el selector ‘personal‘ debe firmar los correos con la clave privada contenida en el fichero /etc/dkim/llull.net.key.pem. Para generar ese fichero ejecutaremos como root el comando

server:~# amavisd-new genrsa /etc/dkim/llull.net.key.pem
Private RSA key successfully written to file "/etc/dkim/llull.net.key.pem" (1024 bits, PEM format)

Ya sólo falta obtener y configurar en nuestro servidor DNS la clave pública y para ello disponemos de otro comando:

server:~# amavisd-new showkeys
personal._domainkey.llull.net.  3600 TXT (
"v=DKIM1; p="
"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoTaWXxsXpNi100Flp7fIKJSlZ"
"ptMP4aCCZjUFgT7TsWokWQJhnGUNnxexEqqPtCDbCUAvEg3iieMRrKwZoHAUDqCf"
"fvW9dcYR7+NdnaxAXCBpOh8Wg5GFJeIid9Gsx3ByBObBQnRGSMOxdBRBO4VXwGb2"
"hKAIOiBMPxaFghdDZQIDAQAB")

Y ya sólo falta añadir la salida del anterior comando a la zona de nuestro dominio en el servidor DNS. La salida está en formato Bind por lo que si usamos ese servidor DNS no tendremos más que añadir  ese texto en el fichero correspondiente.

Acordaos de reiniciar el Postfix, Amavis y Bind para que apliquen las nuevas configuraciones. Para comprobar que todo está funcionando correctamente, podemos enviar un correo a uno de los reflectores existentes.

Ahora ya no tenéis escusa para que vuestro servidor de correo no firme los correos salientes. Si os surge alguna duda, usad los comentarios. Aunque creo que me he acordado de todo, han pasado algunos meses desde que lo configuré y es posible que haya pasado algo por alto.

Artículo basado en la documentación oficial de Amavis.

De todas las reglas, las más sencillas de corregir son:

• Add Expires headers
• Compress components with gzip
• Configure entity tags (ETags)

Otras reglas pueden suponer reescribir parte de la aplicación pero para solventar estas tres basta con añadir algunas líneas al final del .htaccess del directorio raíz de nuestra web. Hay que tener en cuenta que los modulos necesarios deben estar instalados y la configuración del servidor nos debe permitir establecer esta configuración (directiva AllowOverride)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Add Expires Header
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>
 
# Compress CSS files
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml application/rss+xml application/atom_xml
AddOutputFilterByType DEFLATE text/css application/javascript
</IfModule>
 
# ETag only use file time and size, but no inode
FileETag MTime Size

En las líneas 2 a 9 configuramos que las imágenes, hojas de estilo y javascripts tengan una fecha de expiración de una semana a partir del momento en que se ha visitado la página web. Esto significa que el navegador del usuario usará la copia local (fichero cacheado) durante una semana. Este comportamiento puede suponer un problema si tenemos ficheros de estos tipos que vamos modificando sin cambiarle el nombre (p.e. un banner) ya que los navegadores de algunos de los usuarios mantendran las versiones antiguas.

Desde la 12 a la 15 configuramos la compresión de las páginas HTML, feeds (text/xml, application/rss+xml y application/atom_xml), hojas de estilo y javascripts. De esta forma conseguimos ahorrar tráfico (importante si estamos en un hosting con limitaciones de tráfico)  y que el tiempo de transmisión sea menor.

Finalmente, en la última línea configuramos los ETags generados por el propio servidor Apache para los ficheros estáticos. Por defecto, Apache tiene en cuenta tres aspector para generar el ETag: el inodo, fecha de modificación y tamaño. Pero se recomienda no usar el inodo para generarlo ya que si nuestra web empieza a ser conocida y tenemos que distribuir la carga entre varios servidores, es muy poco probable que un fichero tenga el mismo inodo en todos los servidores de la granja. Entonces, el ETag variaría en funcion del servidor que lo generara por lo que no se sacaría provecho a esta cabecera. Para resolverlo, configuramos el Apache para que genere el ETag sólo considerando la fecha de modificación y el tamaño del fichero.

Con esta simple configuración yo conseguí pasar de una puntuación de 74 a 89.

A medida que pueda escribiré algún post más sobre optimización web y como resolverlo en el caso concreto de un blog que usa WordPress.

Icono de Aleph en el iPod Touch

Desde la versión 1.1.3 del sistema operativo del iPhone, puedes añadir enlaces a tus webs favoritas a la pantalla de inicio. Por defecto, el dispositivo crea una miniatura de esa web, pero es tan pequeña que no sirve para identificarla. Por suerte, ese icono se puede personalizar como podéis ver en la captura de pantalla.

Según podemos leer en la documentación de Apple, es tan simple como crear una imagen en formato PNG de 57×57 pixeles (sí, a mi también me parece un tamaño un poco extraño) y colocarlo en la raíz de nuestra web con el nombre  apple-touch-icon.png. El dispositivo  se encargará de redondear las esquinas y darle ese efecto glossy. Pero si nuestra imagen ya tiene algún tipo de efecto de brillo (como me ocurre a mi) queda demasiado sobrecargado: demasiado brillo. Para que el iPhone no añada ese efecto glossy a la imagen manteniendo las esquinas redondeadas, basta con renombrarlo a apple-touch-icon-precomposed.png, como se indica en otra parte de la documentación.

En lugar de usar los nombres por defecto, también podemos dar una referencia a la imagen que queremos que se use como icono añadiendo en la cabecera del documento HTML uno de los siguientes tags dependiendo de si quieremos o no que se aplique el efecto glossy a la imagen:

  <link rel="aple-touch-icon" href="/customIcon.png"/>
  <link rel="apple-touch-icon-precomposed" href="/customIcon.png"/>

Lo que no acabo de entender muy bien son los motivos que puede tener Apple para no usar el favicon (eng) que los navegadores ya usan, entre otras cosas, para asignar un icono al enlace  cuando lo guardamos en nuestros bookmarks. Ya se que normalmente el favicon es de 16×16 píxeles por lo que resulta algo pequeña para la interfaz del iPhone y escalándola quedarían horribles. Pero el formato ICO soporta que en el mismo fichero puedas tener varios tamaños de la imagen. Bastaría con que el iPhone usara la más grande disponible y si ninguna tiene el tamaño mínimo requerido que hiciera lo de la miniatura de la web. Ahora mismo no se me ocurre ningún motivo técnico para tener que usar otra imagen diferente para un fin similar.

DKIM recuerda bastante al Sender Policy Framework, o SPF, cuya finalidad es que los servidores puedan verificar que el servidor que les está entregando un correo está autorizado a hacerlo. Es decir, si el servidor mx.example.org está intentando entregar un correo con remitente user@example.com a mi servidor, este usará SPF para verificar si mx.example.org está autorizado a gestionar el correo de ese dominio. La idea es buena pero, por la forma en que se hace, tiene problemas cuando hay redirecciones o forwards. Para más información, podéis leer la introducción a SPF del proyecto OpenSPF o el artículo de la Wikipedia [en inglés].

Quería introducir un poco SPF para poder compararlo con DKIM ya que ambos tienen finalidades similares y usan el sistema de DNS para publicar la información necesaria. Pero así como SPF publica en DNS qué servidores pueden o no enviar correo de un dominio, DKIM publica una clave pública que se usará para verificar que el correo se originó desde un servidor legítimo, evitando el problema de los forwards. Pero nos estamos avanzando un poco…

¿Cómo funciona?

Simplificando bastante: a la hora de enviar, el remitente firma el mensaje y añade esa firma al correo. Entonces, cualquiera de los servidores por los que pasa el correo, puede comprobar su autenticidad verificando la firma. Aunque cualquiera de los servidores puede, la comprobación normalmente se realiza en el servidor destinatario.

Profundizando algo más, DKIM se basa en sistemas muy usados y conocidos como son la criptografía asimétrica, las funciones de hash y, como ya habíamos anticipado, DNS. Para entender mejor su funcionamiento, vemos la infraestructura que hay que configurar para que pueda funcionar:

1. El administrador del dominio de correo debe generar un par de claves asímetricas.
2. Seguidamente, configurará la clave privada en sus servidores de correo, que la usaran para firmar los mensajes.
3. Finalmente, publica la clave pública como un registro TXT en la zona DNS de su dominio para que los servidores que quieran comprobar la autenticidad de los correos puedan obtenerla.

Ahora ya podemos ver el proceso con más detalle: el servidor remitente calcula el hash del correo teniendo en cuenta el cuerpo y algunas cabeceras, y cifra ese hash con la clave privada generando la firma que se añade al correo. Cuando un servidor quiera verificarlo, como necesitará la clave pública para hacerlo, consultará al sistema DNS para obtenerla y poder realizar la comprobación. Si el correo se originara desde un servidor ilegítimo, como no tendría la clave privada adecuada, la comprobación de la firma fallaría poniendo en evidencia al servidor como posible spammer o phisher.

Como la comprobación no se basa en quién nos está entregando el mensaje sino en quién lo originó, este esquema no sufre de los problemas de SPF con los forwards. Sin embargo, al estar basado en firma digital, tiene problemas con las modificaciones que pueda sufrir el correo durante su transmisión. Por ejemplo, si se añade un disclaimer después de que se haya firmado, la verificación fallará.

Para más información sobre DKIM os remito su web, donde encontrareis multitud de documentación, y, como nó, a la Wikipedia.

Como referencias, decir que tanto Yahoo! como Gmail son dos grandes ejemplos de ISPs que usan DKIM en sus servidores.

DKIM en SpamAssassin

Finalmente, veamos como podemos configurar SpamAssassin para sacar provecho de este sistema. Estoy dando por supuesto que usamos Debian Etch y que ya tenéis el MTA (Postfix o similar) y el SpamAssassin instalados y configurados. Sólo mostraré la configuración a realizar para que se empiecen a comprobar las firmas de DKIM. Desgraciadamente, la versión que viene con Etch no es del todo adecuada por lo que deberemos añadir el repositorio de backports a nuestro source.list. Una vez añadido, actualizaremos la lista de paquetes e instalaremos libmail-dkim-perl, con todas sus dependencias, desde backports:

  server:~# aptitude update
  server:~# aptitude -t etch-backports install libmail-dkim-perl

Ahora sólo falta habilitar el plugin Mail::SpamAssassin::Plugin::DKIM descomentando la correspondiente línea en el fichero /etc/spamassassin/v312.pre. Recordad reiniciar spamd, amavisd-new o el content-filter que uséis para que se aplique la nueva configuración.

Como ejemplo, veamos las cabeceras de un correo enviado desde gmail:

X-Spam-Status: No, score=-0.124 required=4.5 tests=[AWL=-0.185,
	BAYES_20=-0.74, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001,
	DNS_FROM_SECURITYSAGE=0.001, HTML_MESSAGE=0.001, P0F_Unknown=0.8,
	SPF_PASS=-0.001]
...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:mime-version:content-type;
        bh=JvMz4j1uNftb2YwcCYFAjZF73T5HtaC0paeyk3KqFao=;
        b=s2/id2fqmQMef9gWIvn6jhs09lz9nnyOrwepQtQQdzd6Bj8iB/7b2G3PN+bLcOW0k1
         kTs7ew+y8P1rROBlA+T8CpsYirWL0gSp6YZidyhN2SHJVg9ZXQ7oWq6czAcqs/y3871n
         l4Wnm53EqPPNn4Tqos6ruDghAfyJ/deBxFY3Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=U6s9wCp2Q5U7DC0WcQGJ6S6hNwTNmPUiklMd0RtMgB+pJzvP8T/NaqT43Q4QyaukPz
         ig4b3S0/QF3B6uOctVvYQE9YAlgbilx+QxthVzhtc9xvyfePgF63RoebvK28hNlL5VUn
         +0cdEBbEOqkPzo1d1j5XaDGDUV6W/0xHRZb2o=
Received: by 10.210.65.2 with SMTP id n2mr4808273eba.65.1224441206376;
        Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Received: by 10.210.113.2 with HTTP; Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Message-ID: <57e22bd310j416695a2d215d0810191133h6297c2b8a@mail.gmail.com>
Date: Sun, 19 Oct 2008 20:33:26 +0200
From: "Gmail user" <user@gmail.com>
To: user@example.com
Subject: DKIM test
MIME-Version: 1.0
Content-Type: multipart/alternative;

Como podéis ver, con la puntuación que le dá SpamAssassin por defecto no mejoramos la discriminación de spam: +0.001 por venir firmado que se compensa con -0.001 porque la firma es correcta. En la lista de correo de spamassassin-users podemos encontrar algunas sugerencias (y sus actualizaciones).

Conclusiones

DomainKeys Identified Mail es otro sistema pensado para verificar el origen del correo que, como el resto de alternativas, tiene sus ventajas e inconvenientes. Y hemos dado unas pinceladas sobre como se puede usar para ayudar a nuestro sistema anti-spam. En un futuro post, explicaré como configurar nuestro Postfix y Bind para que nuestro correo use DKIM.

Yo, personalmente, pienso que más que intentar parchear el protocolo SMTP, debería tomarse la decisión de hacer “borron y cuenta nueva” y diseñar un nuevo protocolo de transmisión de correo teniendo en cuenta todo lo aprendido hasta ahora y especialmente pensado para no permitir el spam.

Servidor SMTP

Como ya he comentado, lo que queremos es proteger el MTA de ataques de fuerza bruta: si alguien consiguiera averiguar unas credenciales correctas podría usar nuestro servidor para hacer relay. Dentro del paquete de fail2ban en Debian tenemos casí toda la configuración que nos hace falta. De hecho, se define el filtro sasl, pero la expresión regular no es del todo correcta. Para solucionarlo, crearemos el fichero /etc/fail2ban/filter.d/sasl.local (tal y como se recomienda en /usr/share/doc/fail2ban/README.Debian.gz<(code>) con el siguiente contenido.

[Definition]
failregex = : warning: .*+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed

Es la misma línea que en sasl.conf pero con ligeras modificaciones, como la eliminación de la marca de final de línea ($) en la expresión regular.

Activaremos la regla sasl modificando/creando el fichero /etc/fail2ban/jail.local:

[sasl]
enabled  = true

Para que se aplique la nueva regla, debemos recargar la configuración:

 server:~# fail2ban-client reload
 <pueden salir unos warnings>

 server:~# fail2ban-client status
 Status
 |- Number of jail:      2
 `- Jail list:           sasl, ssh

Si alguno de los comandos da un error de “Could not find server“, es que el servidor de fail2ban no está arrancado.

Servidores POP3 e IMAP

Por coherencia, si protegemos el servidor SMTP debemos hacer lo propio con los servidores de POP3 e IMAP. Si no, como los tres servicios comparten la base de datos de usuarios, podrían usar uno de los servicios desprotegidos para averiguar la contraseña por fuerza bruta. Como los mensajes de error de autenticación no indican el servicio que ha usado el usuario para conectarse, vamos a tratar los servidores POP3 e IMAP en conjunto. Esto es, al detectarse errores de autanticación se bloquearan todos los servicios.

Para realizar esta configuración, empezaremos creando el filtro en /etc/fail2ban/filter.d/cyrus.local con el siguiente contenido:

[Definition]
failregex = : badlogin: .*\[<HOST>\] (?:plaintext|LOGIN|(?:CRAM|DIGEST)-MD5|NTLM) .*SASL\(-13\): authentication failure
ignoreregex =

Y acabamos añadiendo las reglas necesarias al final del fichero /etc/fail2ban/jail.local:

[pop3]
enabled  = true
port     = pop3
filter   = cyrus
logpath  = /var/log/mail.log

[pop3s]
enabled  = true
port     = pop3s
filter   = cyrus
logpath  = /var/log/mail.log

[imap2]
enabled  = true
port     = imap2
filter   = cyrus
logpath  = /var/log/mail.log

[imaps]
enabled  = true
port     = imaps
filter   = cyrus
logpath  = /var/log/mail.log

Debemos definir una regla por puerto porque la versión 0.7.5 de fail2ban (la que tenemos en Etch) no soporta que se indique más de un puerto por regla. Versiones más recientes, como la versión 0.8, parece que si lo soportan (Si alguien lo comprueba, que me lo comente.  Gracias).

Como siempre, recargad la configuración y comprobad que se estén usando las reglas recién definidas.

Conclusiones

Fail2Ban es una gran medida disuasoria y con estas configuraciones conseguimos frenar en gran medida los ataques de fuerza bruta contra los servicios autenticados de correo: con la configuración por defecto, el servidor no aceptará conexiones de ese cliente durante diez minutos tras tres intentos fallidos.

Aunque la seguridad es necesaria, suele ser incómoda. Pensad en el usuario que intenta configurar su Outlook Expres en casa pero se le ha olvidado la contraseña (como si la hubiera recordado durante más de diez segundos… cuanto daño ha hecho la opción “Recordar contraseña”…) y tras varios intentos os llama. Como el servidor le ha bloqueado el acceso por un tiempo, aunque le podáis dar la contraseña correcta, deberá esperar. Dependiendo de como sean vuestros usuarios, es posible que debáis jugar un poco con los parámetros bantime y maxretry.

Como véis, no resulta muy complicado dotar de algo más de seguridad a nuestros servidores si conocemos las herramientas adecuadas y como usarlas.

Como se puede sobreentender de su nombre, los sistemas de One-Time-Password son sistemas de autenticación en los que cada contraseña se utiliza una única vez. Esto nos puede resultar útil en el caso de que debamos hacer login en situaciones comprometidas: usando un protocolo con el que las credenciales viajan en claro (sin cifrar) por la red, desde un equipo del que no podemos asegurar su integridad (que no tenga keyloggers instalados, por ejemplo), etc.

Aunque existen tres formas de implementar sistemas OTP, desde un punto de vista práctico existen dos tipos:

• Basados en secuencia: cada vez que usamos una contraseña esta deja de ser válida y el sistema nos pedirá la siguiente en el proximo login. Mientras no hagamos login, el sistema nos seguirá pidiendo la misma.
• Basados en relojes sincronizados: la contraseña va cambiando con el tiempo, se use o no. El principal requisito de estos sistemas es que el servidor y el generador de la contraseña deben estar sincronizados en el tiempo.

El sistema que os presento es OPIE, que está basado en secuencia, es una implementación de S/Key. Si elegí este fué por sencillez de implementación ya que todo el software necesario esta disponible desde los repositorios oficiales de Debian. Pero le he encontrado dos “problemas”: la página del proyecto no funciona (al menos mientras estoy escribiendo este post) y que no hay desarrollos nuevos desde 1998.

Las contraseñas de OPIE son independientes de las del sistema operativo, cosa necesaria ya que sino de poco nos serviría si a partir de la contraseña de OPIE se pudiera averiguar la del sistema operativo. Para funcionar, OPIE se basa en tres datos: un número de secuencia, una semilla y una passphrase (donde reside la fortaleza del sistema frente a ataques de fuerza bruta).

La forma que tiene de generar la contraseña de un sólo uso es concatenando la semilla y la passphrase, y aplicando la función de hash MD5 tantas veces como le indique el número de secuencia. El resultado se convierte en seis palabras inglesas. Todo este cálculo se realiza desde el cliente. La passphrase nunca se almacena en el servidor.

Para poder validar la contraseña, el servidor necesita almacenar la última contraseña que se usó y el número de secuencia y semilla para podérselo indicar al usuario al hacer login (para los curiosos, esta información se almacena en /etc/opiekeys, que es un fichero que sólo puede leer el usuario root). El sistema dará por buena la contraseña si el MD5 de la contraseña proporcionada por el usuario coincide con la contraseña que tenía almacenada. Una vez se ha verificado la contraseña el número de secuencia se decrementa y cuando este llega a 1 es necesario reinicializar el contador con una nueva semilla (si no, las contraseñas se repetirían) Como el MD5 es una función unidireccional, es imposible encontrar la nueva contraseña a partir de la anterior.

Instalación y configuración

Cómo siempre, empezaremos instalando el software necesario. En este caso deberemos instalar paquetes tanto en el servidor como en un equipo de confianza que nos hará de cliente. Para distinguir los comandos que debemos ejecutar en uno u otro equipo, usare los prompts server:~# y client:~# para el servidor y el cliente respectivamente.

  server:~# aptitude install libpam-opie opie-server opie-client
  client:~# aptitude install opie-client

Una vez instalado el software, cada usuario que quiera usar este sistema de autenticación debe inicializarlo. Hay dos formas de hacerlo, en una se supone que el acceso que tenemos al servidor es seguro y en la otra esta suposición no es necesaria. Si estamos implementando este sistema significa que la seguridad nos preocupa (algunos dirían que somos paranoicos ) y por eso sólo explicaré el segundo método, que no es mucho más complicado y si es más seguro. En este proceso hay que ejecutar comandos tanto en el servidor como en el equipo de confianza (cliente). Supongamos que el usuario username quisiera inicializarlo:

• Debería empezar por usar opiepasswd en el servidor.

  username@server:~$ opiepasswd
  Adding username:
  You need the response from an OTP generator.
  New secret pass phrase:
          otp-md5 499 se4569
          Response:

• En este momento vamos a un terminal del cliente (máquina de confianza) y ejecutamos opiekey pasándole como parámetros los valores del número de secuencia y semilla que aparecen al lado de otp-md5. Cuando nos lo pida, le introduciremos la passphrase que queremos configurar. Recordad que cuanto más complicada sea la passphrase, mejor.

  client:~$ opiekey 499 se4569
  Using the MD5 algorithm to compute response.
  Reminder: Don't use opiekey from telnet or dial-in sessions.
  Enter secret pass phrase: <introducimos la passphrase>
  WOOL ARTY FUM SNUG WARN WICK

• Volvemos a la consola que tenemos en el servidor y pegamos la última línea que obtuvimos con  opiekey en el cliente. Lo remarcado en cursiva es lo que ya teníamos en pantalla.

  username@server:~$ opiepasswd
  Adding username:
  You need the response from an OTP generator.
  New secret pass phrase:
          otp-md5 499 se4569
          Response: WOOL ARTY FUM SNUG WARN WICK
  
  ID username OTP key is 499 se4569
  WOOL ARTY FUM SNUG WARN WICK

Con esto, el usuario username dispone de 499 contraseñas de un sólo uso.

Para hacer que el sistema empiece a usar OPIE como sistema de autenticación debemos indicárselo al PAM. La forma más sencilla es sobreescribir el fichero /etc/pam.d/common-auth con el que podemos encontrar en /usr/share/doc/libpam-opie/examples/pam.d/common-auth (recomiendo hacer una copia de seguridad del antiguo) en el que se indica que el primer método de autenticación seguirá siendo la contraseña del sistema operativo pero si este fallá se usará OPIE:

server:~$ cat /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
auth    sufficient      pam_unix.so
auth    sufficient      pam_opie.so
auth    required        pam_deny.so

Si lo hacemos de esta forma, cualquier servicio que autentique por PAM se podrá beneficiar del sistema de One Time Password: ssh, su, etc. De nada serviría poder usar OTP para hacer login desde un equipo del que no nos fiamos y luego tecleamos la clave de root en la misma máquina. En el caso de usarlo también para obtener permisos de administrador, aconsejo usar sudo antes que su por la sencilla razón que para usar el primero se pide la contraseña del usuario que pide los privilegios (que ya está usando OTP) mientras que el segundo pide la contraseña de root.

En el caso de SSH debemos realizar una pequeña comprobación en la configuración del servidor de sshd (fichero /etc/ssh/sshd_config): el parámetro ChallengeResponseAuthentication debe estar a yes. Si no estuviera así, el sistema no le indicaría al usuario el número de secuencia y semilla al intentar hacer login.

Ejemplo de uso

Ya lo tenemos todo listo. Veamos un ejemplo de conexión SSH usando OPIE:

• Desde la máquina de dudosa seguridad nos conectamos como normalmente:

  unsecure:~$ ssh username@example.com
  Password:

• El sistema nos pide la contraseña como siempre, ya que así lo hemos configurado en las PAM. Pero como no nos fiamos de la seguridad de esa máquina no introducimos la contraseña:

  unsecure:~$ ssh username@example.com
  Password: <enter>
  otp-md5 498 se4569 ext, Response:

• Como la autenticación por contraseña a fallado, ha entrado en acción OPIE que nos indica el siguiente número de secuencia (498) y la semilla (se4569). Desde un equipo de confianza usamos opiekey para obtener el OTP, pasándole el secuencial y la semilla:

  secure:~$ opiekey 498 se4569
  Using the MD5 algorithm to compute response.
  Reminder: Don't use opiekey from telnet or dial-in sessions.
  Enter secret pass phrase: <introducimos la passphrase que usamos al configurarlo>
  GWYN OAF HIRE ALOE CASK CERN

• Una vez tenemos la contraseña, se la indicamos al servidor y si todo ha ido bien, ya estamos dentro (lo remarcado en cursiva es lo que ya teníamos en pantalla):

  unsecure:~$ ssh username@example.com
  Password:
  otp-md5 498 se4569 ext, Response: <introducimos la contraseña generada (no se ve)>
  Last login: Mon Apr  9 10:01:18 2008 from 192.168.0.10
  username@server:~$

• Si nos intentamos conectar de nuevo, veremos como el número de secuencia se ha decrementado:

  unsecure:~$ ssh username@example.com
  Password: <enter>
  otp-md5 497 se4569 ext, Response:

Generadores de claves

Me imagino que os deberéis estar preguntando que ventaja tiene este sistema si de todas formas necesitas un equipo de confianza para generar la contraseña. Es decir, ¿si tengo un portátil para ejecutar opiekey, por que no lo uso para conectarme directamente desde él? Entre otros motivos se me ocurre que ese portátil no pueda tener conexión a Internet porque, por política de seguridad, la red en la que estás no permita que equipos externos tengan acceso al exterior. Pero yo nunca he dicho que necesitemos un PC para generar la contraseña. Existen, como mínimo, dos alternativas:

Podemos imprimir una lista de contraseñas y llevarlas bien cerca de nosotros. Para hacerlo, en el cliente de confianza ejecutaremos:

client:~$ opiekey -n 5 499 se4569
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <introducimos la passphrase que usamos al configurarlo>
495: CRAB YEAR MAO JAG BEAD KUDO
496: CLOD REED BOND COMA DELL HEFT
497: ERIC WEE WISE TOLD NINA DIVE
498: GWYN OAF HIRE ALOE CASK CERN
499: WOOL ARTY FUM SNUG WARN WICK

Donde en la opción -n se le indica el número de contraseñas que queremos que nos imprima y el 499 es el número de secuencia más alto que queremos que aparezca en la lista.

Y si no queremos llevar las contraseñas por escrito, podemos usar nuestro móvil o PDA para calcular la contraseña instalando el equivalente al opiekey. Para hacerlo necesitaremos que el dispositivo pueda ejecutar código Java. Yo he encontrado tres aplicaciones GPL: j2me-otp, otp-j2me (sí, no son muy originales con los nombres) y otpgen. No voy a explicar como se instalan, ya que depende mucho del móvil que tengáis.

De los tres, el que más me gusta es el tercero pues es más cómodo: te permite definir cuentas en las que mantiene el seed y el número de secuencia, que se va decrementando a medida que obtienes contraseñas. Además estoy seguro de que no hace cosas raras ya que lo he auditado (lo que os dará igual si no os fiáis de mí ) y al que he hecho dos pequeñas aportaciones: el número de secuencia sólo se decrementa cuando aceptamos la contraseña que nos ha proporcionado y he añadido una opción de configuración para que se muestren o no asteriscos al escribir la passphrase.

A pesar de haber mandado el parche al desarrollador, la verdad es que me animé tanto con esta aplicación que he terminado reescribiéndola casi por completo y podéis ver el resultado en la página del proyecto.

Mantenimiento

Como a medida que vamos usando contraseñas el número de secuencia va decrementando, debemos reinicializarlo cuando este se acerque a uno. Para hacerlo usaremos las mismas herramientas que usamos para inicializarlo (opiekey y opiepasswd) y el proceso es casi el mismo. La única diferencia es que en esta ocasión opiepasswd nos solicitará la actual contraseña antes de solicitarnos la nueva:

username@server:~$ opiepasswd
Updating username:
You need the response from an OTP generator.
Old secret pass phrase:
        otp-md5 495 se4569 ext
        Response: CRAB YEAR MAO JAG BEAD KUDO <contraseña actual obtenida con opiekey>
New secret pass phrase:
        otp-md5 499 se1984
        Response: NINA TOLD ALIA LAKE LARK THIS <contraseña nueva obtenida con opiekey>

ID username OTP key is 499 se1984
NINA TOLD ALIA LAKE LARK THIS

Es muy importante no repetir nunca la misma semilla, si mantenemos la passphrase, ya que las contraseñas se calculan a partir de estos dos datos y si en alguna ocasión repitiéramos, las contraseñas que se generarían serían repetidas y ya no serían de un sólo uso.

Seguridad del sistema

Las contraseñas de este sistema son generadas mediante algoritmos de hashing, por lo que empezaremos estudiando la seguridad o robustez del sistema a partir de estos algoritmos y en concreto de la dificultad de averiguar el texto a partir del resultado de la función. Por la forma en que se generan las contraseñas, significa revisar lo dificultad de averiguar la siguiente contraseña a partir de la actual. Aunque en 1996 se descubrió una vulnerabilidad en el algoritmo MD5, que es el que usa OPIE, esta vulnerabilidad no afecta al aspecto que nos preocupa. (para los curiosos, dicha vulnerabilidad es un problema de colisiones: resulta más o menos fácil encontrar dos textos que den el mismo resultado, pero esto no significa que, dado un resultado, se pueda calcular un texto que lo genere). Por lo tanto, no debemos preocuparnos en este aspecto. La robustez del sistema dependerá de la robustez de las contraseñas generadas, que es el siguiente punto a considerar.

OPIE genera contraseñas de 64 bits de longitud a partir de los 128 bits resultantes del MD5 haciendo una XOR entre los 64 primeros bits y los 64 últimos. Consideraremos que los 64 bits son aleatorios ya que se calculan mediante funciones de hashing. Eso significa que estas contraseñas tienen una robustez de 64 bits. Para poder comparar, según la Wikipedia, una contraseña de la misma longitud (ocho carácteres) generada por un usuario tiene la robustez equivalente de entre 18 y 30 bits. Por lo tanto, en este aspecto es mejor que las contraseñas que usamos habitualmente: distributed.net necesitó 4 años, 9 meses y 23 días para romper una clave de 64 bits mientras que, también según la Wikipedia, sólo se necesitarían 16 minutos para averiguar una contraseña creara por un usuario.

Por lo tanto, parece que el sistema es seguro. Si véis algun error en mi razonamiento, por favor, indicádmelo mediante los comentarios.

Por otro lado, ya que estamos hablando de seguridad y si habéis llegado hasta aquí posiblemente signifique que os interesa poderos conectar por SSH a un servidor vuestro desde una red potencialmente insegura, dejadme que os dé un consejo: llevad con vosotros, y a buen recaudo, el figerprint de la clave de vuestro servidor y verificad que coincida con el que se os indica al iniciar la conexión por primera vez. De esta manera os aseguraréis que no estáis siendo sujetos de un ataque man-in-the-middle. Puede que muchos de vosotros ya lo estéis haciendo, pero seguro que hay otros muchos que no.

Conclusiones

Aunque el post es bastante largo (a veces pienso que me enrollo demasiado) este sistema es bastante sencillo de implementar, la seguridad que ofrece es adecuada y, si lo configuráis como os he indicado, no tiene impacto en el día a día ya que podéis usar vuestras contraseñas de siempre cuando trabajáis desde entornos seguros, pero dispondréis de esta alternativa en casos donde la seguridad no esté tan clara. Además, ¿sabéis la cara que pone la gente cuando usas el móvil para calcular una contraseña al intentar hacer login en un sistema?

Si tenéis algo que decir sobre el post o si encontráis alguna burrada (cosa posible ya que dada la longitud del post lo he escrito en varias tandas), no dudéis en usar los comentarios.

Fail2ban es un servicio que vigila una serie de ficheros de log y cuando detecta intentos fallidos bloquea la dirección IPdesde la que se han realizado añadiendo una regla de iptables.

Para instalarlo, en Debian basta con un "aptitude install fail2ban". La configuración por defecto trae activada la protección de SSH y a parte de bloquear la IP infractora envía un correo a root. A parte de la protección de SSH, trae configuraciones para apache, postfix, qmail, vsftpd, etc. y soporte para otros sistemas de firewall a parte de iptables.

Fail2ban no nos asegura una protección total, es sólo una medida más para ponérselo más difícil a los que intentan entrar de forma no autorizada en nuestro servidor, principalmente contra script-kiddies.

En este post os voy a explicar una técnica para luchar contra el spam que he descubierto recientemente y como configurarlo.

Introducción

Esta técnica antispam sólo es útil si se implementa a nivel de servidor de correo, y se fundamenta en dos pilares:

1. Como se puede suponer del título del post, uno de los pilares es la detección de la versión del sistema operativo del servidor remoto que está intentando entregar un correo a una de las direcciones que alojamos.
2. El otro pilar es el hecho de que nadie en su sano juicio instalaría un servidor de correo sobre un Windows XP, ya que está destinado a estaciones de trabajo y no a servidores. Pero incluso así, la gran mayoría de spam proviene de Windows XP, que seguramente tendrán instalado un virus que los convierte en relayers.

Es decir, si somos capaces de determinar que correos entrantes nos los está enviando un Windows XP, lo podremos usar para diferenciar mejor el correo legítimo del spam.

Descripción técnica

El núcleo de esta técnica lo forman amavis, spamassassin y p0f. Seguramente el único que no os debe sonar es p0f y me imagino que la mayoría ya conoceréis el amavis, sistema de filtrado de correo, y el spamassassin, el sistema antispam por excelencia. p0f es un sistema de O.S. fingerprining pasivo. Básicamente es un sniffer que es capaz de identificar la versión del sistema operativo a partir de los paquetes TCP/IP que vé. Es decir, es similar a la opción -O del nmap, pero de forma pasiva.

La idéa es que cuando amavis vaya a filtrar un nuevo correo entrante, consulte de alguna manera al p0f para saber la versión del sistema operativo de la máquina remota y el spamassassin pueda tener en cuenta esa información para determinar si el correo es spam o no.

Instalación y configuración

Los prerequisitos son tener un servidor de correo que use amavisd-new y spamassassin. No voy a explicar como se instalan y configuran ya que depende del MTA que uséis y existen muchos how-tos (como este de Jaume Sabater [copia en Bulma]). En cuanto a la distribución, me centraré en una Debian que es lo que tengo por mano.

Instalación de P0F

Lo primero es instalar el p0f: aptitude install p0f (o apt-get install p0f, me da igual )

Para la comunicación entre p0f y amavis, usaremos un programilla en perl que viene dentro del paquete de amavisd-new: p0f-analyzer (que se instala en /usr/sbin). Este programa espera recibir los datos del p0f por su entrada estandar y abre un puerto por el que el amavis le hace las consultas. Por defecto, p0f-analyzer escucha en todas las interfaces del servidor aunque implementa unas ACLs muy simples por las que sólo contesta a peticiones que le lleguen del localhost (127.0.0.1). Como a mi no me gusta tener servicios internos escuchando en todas las interfaces, cambie la línea 79 de


  bind(S, sockaddr_in($port,INADDR_ANY)) or die "bind: $!";

a

  bind(S, sockaddr_in($port,INADDR_LOOPBACK)) or die "bind: $!";

Las ACLs se controlan mediante el array @inet_acl que se define en la línea 70.

Si ejecutas /usr/sbin/p0f-analyzer sin parámetros, te da un ejemplo de uso que es el que yo utilicé:

  /usr/sbin/p0f -l 'tcp dst port 25' 2>&1 | /usr/sbin/p0f-analyzer.pl 2345

De esta manera, el p0f identificará las conexiones destinadas al puerto 25/tcp y el p0f-analyzer abre el puerto 2345 para recibir las consultas del amavis. Primera parte resuelta.

Configuración de amavis

El siguiente paso es configurar el amavis para que consulte al p0f-analyzer. Para ello debemos usar el parámetro de configuración $os_fingerprint_method. En el caso de Debian, modifiqué el fichero /etc/amavis/conf.d/50-user e incluí las dos líneas siguientes:

  $os_fingerprint_method = 'p0f:127.0.0.1:2345';
  $policy_bank{'MYNETS'}{os_fingerprint_method} = undef;

En la primera línea le indicamos donde puede consultar al p0f-analyzer y en la segunda que no use el p0f-analyzer para las máquinas de la red interna.

Finalmente reiniciamos el amavisd-new. Si hemos realizado los cambios en la configuración de forma correcta, en /var/log/mail.log deberíamos encontrar la línea que nos indica que ha activado la opción de OS_Fingerprinting:

  Oct  3 12:23:14 server amavis[29216]: OS_Fingerprint code  loaded

Ahora ya sólo falta que el spamassassin use la información que nos proporciona p0f.

Configuración de spamassassin

La forma que tiene el amavis para pasar la información que ha recibido del p0f al spamassassin es añadiendo la cabecera X-Amavis-OS-Fingerprint al correo. Esta cabecera no se añade al correo que recibirá el usuario, sólo se usa internamente entre el amavis y el spamassassin.

Como a mi me interesaba que todos los usuarios se beneficiaran de esta nueva técnica, modifiqué el fichero /etc/spamassassin/local.cf para que incluyera la siguiente configuración:

  #   Set score for different client OS
  #   Needs p0f-analyzer up and running
  header P0F_WindowsXP X-Amavis-OS-Fingerprint =~ /^Windows XP/
  header P0F_Windows   X-Amavis-OS-Fingerprint =~ /^Windows(?! XP)/
  header P0F_Unknown   X-Amavis-OS-Fingerprint =~ /^UNKNOWN/
  header P0F_Unix      X-Amavis-OS-Fingerprint =~ /^Linux|((Free|Open|Net)BSD)|Solaris|HP-UX|Tru64/

  score  P0F_WindowsXP 3.5
  score  P0F_Windows   1.7
  score  P0F_Unknown   0.8
  score  P0F_Unix     -0.5

Definimos cinco tests y les damos puntuaciones. Las puntuaciones de los tests no son aleatorias, me basé en las que se indican aquí pero las modifiqué un poco a mi gusto. Con estas puntuaciones le estamos indicando al spamassassin que es muy probable que los correos que le lleguen desde máquinas Windows XP sean spam, ya que le damos una puntuación de 3.5, mientras que los que le lleguen desde Unixes tienen una menor probabilidad de serlo y por eso le damos una puntuación de -0.5.

Para que se empiecen a aplicar los nuevos tests, si estamos ejecutando el spamassassin en modo daemon (spamd) deberemos reiniciarlo y si se ejecuta de forma interna al amavis, deberemos reiniciar este último.

A partir de ahora, el spamassassin debería tener en cuenta el sistema operativo de la maquina remota para puntuar los correos. Si tenéis configurado el amavis para que incluya en las cabeceras los tests del spamassassin, podéis buscarlo allí. Por ejemplo:

X-Spam-Status: Yes, score=9.25 required=4.5 tests=[BAYES_99=3.5,
    HTML_MESSAGE=0.001, P0F_Unix=-0.5, RCVD_IN_BL_SPAMCOP_NET=1.96,
    URIBL_AB_SURBL=1.86, URIBL_BLACK=1.955, URIBL_SC_SURBL=0.474]

Conclusión

La técnica de O.S. fingerprinting no es la panacea en la lucha contra el spam, pero es un complemento al resto de tests, un aspecto más que nuestro sistema antispam puede tener en cuenta para clasificar mejor los mensajes. Y por el trabajo que lleva configurarlo, creo que merece la pena.