Evita que tus correos sean marcados como spam usando registros PTR, SPF y DKIM

Josemaría | 3 de marzo de 2014 | 3 comentarios

correoInstalar y configurar un servidor de correo es algo relativamente sencillo y un tema que hemos tratado en alguna ocasión por aquí. También hemos hablado de la forma de reducir el spam que entra en nuestros buzones implementando un sistema de Greylisting. De lo que no hemos hablado aún es de las formas que tenemos de evitar que nuestros correos legítimos acaben abandonados en la carpeta de correo no deseado del destinatario. Algo que cada vez es más frecuente si tienes tu propio servidor de correo personal o de empresa y escribes habitualmente a buzones de los grandes proveedores (Gmail, Hotmail y Yahoo, por ejemplo) que hace tiempo se declararon en guerra abierta contra el spam.

Las técnicas de control de spam usadas más frecuentemente pasan por contrastar la autenticidad del remitente a través de algún tipo de comprobación contra el dominio de procedencia del correo electrónico. Lo que se persigue es que si recibo un correo procedente de una cuenta de determinado dominio, el propietario de dicho dominio debería de tener correctamente identificadas cuales son las máquinas autorizadas para enviar correo en su nombre. Recuerda que lo habitual (e indispensable) es identificar las máquinas receptoras del correo (mediante registros MX), pero muchos administradores aún continúan sin identificar de forma alguna a las emisoras a pesar de que tenemos varias opciones para hacerlo. Veamoslas.

Para ilustrar nuestro ejemplo supondremos que tenemos un servidor de correo que actúa como único emisor autorizado y que también funciona como receptor del correo. Su nombre es estafeta.micorreo.net y su IP la 145.255.98.239. Nuestro servidor es un VPS contratado a una empresa de hosting, que es la que nos proporciona la IP, usará postfix sobre una máquina con Debian 7, estará perfectamente configurado y atenderá a dos dominios diferentes (ya hemos hablado también aquí de como hacerlo) llamados midominio.com y midominio.net

La existencia de un registro PTR de resolución inversa para la IP de la máquina que entrega el correo es una de las primeras cosas que valorará de forma positiva un filtro antispam. El problema que vamos a encontrar con esto es que, habitualmente, no podremos crearlo nosotros mismos. Si la IP fija que usa nuestro servidor nos la ha proporcionado nuestro ISP tendremos que pedírle a ellos que creen este registro para nosotros. Si nuestro servidor de correo está alojado en una empresa de hosting se lo solicitaremos a ellos o, tal vez, nos proporcionarán algún mecanismo para que lo hagamos nosotros mismos a través de su panel de configuración. Si tienes la posibilidad de configurarla por ti mismo en un servidor BIND nuestros buenos amigos de systemadmin te dicen aquí como debes de hacerlo, así que no pierdo más el tiempo en ello ;-) .

Para nuestro ejemplo, pediríamos a la empresa de hosting que nos aloja el servidor (yo así lo hice a Gigas, mi empresa actual de hosting que de de alta un registro de resolución inverso para la IP 145.255.98.239 que se resuelva como estafeta.micorreo.net

Para comprobar si lo han hecho correctamente puedes usar nslookup:

nslookup -query=PTR 145.255.98.239

Los registros SPF (Sender Policy Framework o Marco Normativo de Remitentes) constituyen uno de los métodos más comunes y fáciles de implementar para identificar a las máquinas de nuestro dominio autorizadas para enviar correo electrónico. El método es tan sencillo como dar de alta un nuevo registro en la zona de tu dominio donde identifiques a los servidores que autorizas para enviar correo. Originalmente se usaba un registro TXT pero posteriormente se amplió la funcionalidad de las bases de datos DNS añadiendo un nuevo tipo de registros denominado SPF. Hoy en día es recomendable usar ambos métodos por si acaso el servidor que realiza la validación busca aún el tipo de registros antiguo.

La sintaxis de definición de un registro SPF tiene muchas alternativas y puede variar según nuestras necesidades. En esta entrada tienes la especificación completa muy bien explicada y con todo lujo de detalles. Para nuestro ejemplo (un único servidor de correo tanto para envío como para recepción y que coincide con el que aparece en el registro MX) puedes usar los siguientes registros:

@ IN MX 10 estafeta.micorreo.net.

@ IN TXT "v=spf1 mx ip4:145.255.98.239 ~all"
@ IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"

Puesto que el correo de ambos dominios es gestionado por el mismo servidor debemos repetir esos mismos registros exactamente iguales en las bases de datos de ambas zonas. Y, por supuesto, hacer un reload del servidor bind9 después de hacer los cambios.

Tenemos muchas formas de hacer pruebas si hemos configurado correctamente nuestros resgistros SPF. Una de ellas es usar alguno de los muchos tests online disponibles por ahí. Mis favoritos son estos:

Otra opción es enviar un correo a una cuenta de los grandes proveedores (GMail, Outlook o Yahoo, por ejemplo, comprueban la validez de los registros SPF para valorar si un correo es marcado como SPAM) y observar lo que pone en la cabecera del correo que recibe el destinatario. Ten en cuenta que la validación que hace cada uno de ellos es ligeramente diferente. Por ejemplo, si retiras la partícula ip4 de los registros anteriores Gmail y Yahoo seguirán validando correctamente pero Outlook dejará de hacerlo.

Si, por ejemplo, enviamos un correo a Gmail y no hemos definido aún registros SPF, Google insertará en la cabecera del correo una marca como esta definiéndolo como neutral. Eso quiere decir que no puede determinar si el correo es válido o es spam.

Received-SPF: neutral (google.com: 145.255.98.239 is neither permitted nor denied by best guess record for domain of josemaria@midominio.com) client-ip=145.255.98.239;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 145.255.98.239 is neither permitted nor denied by best guess record for domain of josemaria@midominio.com) smtp.mail=josemaria@midominio.com

Por el contrario, cuando contemos con unos registros SPF correctos la valoración que Google hará constar anunciará que el correo es correcto (pass):

Received-SPF: pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) client-ip=145.255.98.239;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@midominio.com

Si Google recibe un correo de un dominio que usa registros SPF pero el servidor emisor del mismo no está autorizado en estos registros lo marcará como fail o softfail. En el caso de los registros que he puesto como ejemplo lo hará como softfail gracias a la partícula ~all que he especificado (consulta la página de sintaxis que he referenciado antes para entender las diferencias entre ambos).

NOTA: Microsoft propuso hace años una variante de los SPF que denominó Sender ID y que decía corregir alguna de las carencias del protocolo original, pero su empecinamiento en mantener ciertas patentes sobre el mismo impideron que se popularizara su uso. Aquí tienes más información acerca de sus diferencias. Hoy en día lo normal es que si un servidor realiza una comprobación del Sender ID la de por buena si se encuentra un SPF correcto.

El tercer tipo de registros que veremos son los DKIM (DomainKeys Identified Mail), un sistema de identificación que usa firmas realizadas con criptografía de clave pública. El método en el que se basa también es sencillo de entender. Nuestro servidor de correo firmará todos sus mensajes salientes mediante su clave privada y esta firma se incluirá en la cabecera del mensaje en una sección llamada “DKIM-Signature”.

La clave pública deberá de estar disponible para que quien lo quiera pueda realizar la verificación de la firma. Esto se hace en un registro TXT de nuestro DNS. La implementación de este sistema en nuestros servidores es, sin embargo, bastante más complicada ya que necesitamos generar previamente la pareja de claves, configurar nuestro servidor de correo para que realice la firma de los mensajes y, por último, insertar la clave pública en el registro TXT correspondiente de nuestra zona DNS… Vamos a ver como hacerlo.

En primer lugar instalamos los paquetes necesarios:

apt-get install opendkim opendkim-tools

A continuación creamos un directorio para las claves y archivos de configuración. Podemos, por ejemplo, hacerlo en el directorio /etc. En el crearemos un subdirectorio por cada dominio de correo que usamos y tres ficheros adicionales que luego explicaremos como rellenar:

mkdir /etc/opendkim
mkdir /etc/opendkim/midominio.com
mkdir /etc/opendkim/midominio.net
touch KeyTable
touch SigningTable
touch TrustedHosts

Vamos ahora a generar las parejas de claves necesarias para que DKIM funcione. Entramos en el directorio que hemos creado para el primer dominio y ejecutamos lo siguiente:

cd /etc/opendkim/midominio.com
opendkim-genkey -s mail -d midominio.com

El parametro detrás de la -s es el llamado “selector” y el que va detrás de la -d el dominio para el que generas las claves. La instrucción anterior nos generará un par de ficheros: uno llamado mail.private con la clave privada y otro denominado mail.txt que incluye el registro que, con ligeras modificaciones, tendremos que incluir en nuestra zona DNS y que contiene la clave pública. Fíjate en el contenido en bruto de este fichero:

mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB" ; ----- DKIM key mail for midominio.com

Y ahora mira lo que yo he incluido en mi DNS:

_domainkey.midominio.com. IN TXT "o=~; r=josemaria@midominio.com"

mail._domainkey.midominio.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB" ; ----- DKIM key mail for midominio.com

Como ves, he incluido un primer registro TXT denominado _domainkey.midominio.com. (mail es el selector usado al generar la clave y midominio.com. el dominio) cuyo contenido es la política que usaremos (puedes consultar aquí que significa). El segundo registro es el contenido íntegro del fichero mail.txt al que simplemente le he añadido el dominio correspondiente al final del primer campo.

Esta primera parte ya está lista. Ahora tienes que hacer un reload de las zonas de tu servidor DNS (service bind9 reload) y, por último, podrías probar si tienes correctamente configurado estos registros con esta herramienta.

Tenemos aún que dotar de contenido a los tres ficheros que hemos creado inicialmente en el directorio /etc/opendkim. Los dos primeros sirven para seleccionar la clave privada que se usará para la firma en función del correo del remitente.

El fichero KeyTable contendrá una línea por cada pareja de claves que hemos creado. La sintaxis de cada una de estas líneas con arreglo a como hemos realizado el proceso hasta ahora sería así:

keyid dominio:selector:path_a_la_clave_privada

Nosotros usaremos como keyid el mismo nombre de dominio, así que en nuestro ejemplo quedará así:

midominio.com midominio.com:mail:/etc/opendkim/midominio.com/mail.private
midominio.net midominio.net:mail:/etc/opendkim/midominio.net/mail.private

El fichero SigningTable identifica los correos con los keyid del fichero anterior y, por tanto, con la clave privada usada para la firma. La sintaxis de cada línea es esta:

expresion_para_identificar_el_correo keyid

Y en nuestro ejemplo:

*@midominio.com midominio.com
*@midominio.net midominio.net

El último de ellos, TrustedHosts, debería de incluir a los servidores autorizados para usar opendkim. Nosotros tenemos sólo uno pero especificaremos todas sus posibles direcciones y/o identificaciones para evitar problemas:

127.0.0.1
145.255.98.239
invernalia.unlugarenelmundo.es

Muy importante: debemos de asegurarnos que el usuario opendkim y sólo él tiene acceso a estos directorios

chown opendkim:opendkim /etc/opendkim/* -R
chmod go-rwx /etc/opendkim/* -R

Configuramos ahora /etc/opendkim.conf incluyendo o modificando las siguientes líneas (échale un vistazo con detenimiento porque alguna podría aparecer con otros valores distintos a los que aquí ponemos):

Syslog yes
SyslogSuccess yes
LogWhy yes
UMask 002
OversignHeaders From

KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

SignatureAlgorithm rsa-sha256
AutoRestart yes
UserID opendkim:opendkim
Socket inet:8891@localhost

Canonicalization relaxed/simple
Mode s

En el fichero /etc/postfix/main.cf incluimos las siguientes líneas para instruir a postfix de lo que queremos hacer:

#OpenDKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
#smtpd_milters = inet:8891@localhost
non_smtpd_milters = inet:localhost:8891

Por último, reiniciamos los dos servicios en los que hemos hecho cambios:

service opendkim restart
service postfix restart

Puedes comprobar que tu servidor está firmando los mensajes salientes simplemente mirando en la cabecera de los mensajes que hayas enviado (ojo, no vale con mirar esto en la carpeta de enviados de tu cliente de correo: tienes que mirarlo en el buzón de alguién a quién hayas enviado un mensaje ;-) ). Deberías de encontrar una sección como esta:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=midominio.com;
	s=mail; t=1393841181;
	bh=WOdEGJCY/0JhPY8jx68CyFKNQxxdoD1qEPM2Bike+fA=;
	h=Date:From:Reply-To:To:Subject:From;
	b=dtHZW0UMlXcKt6c8IY6DS1IVclv7KZTo6IIK0+r/yLWdKet/G9jkvSxmp7MhTeL9t
	 p5Jh87PMKJD0GuRWIJAKx/QLSVAhf9/scXbR7GH9dRPipwxM4lRzaWwxgyCFfKafca
	 SnBJ81jsaKpQgB8sUi2CY4YWt0Y0Vdy7CKCDbpxA=

Además, también puedes mirar los logs de tu servidor postfix (en /var/log/mail.log):

Mar  3 06:22:05 estafeta opendkim[2738]: 4DA1D14206A: DKIM-Signature header added (s=mail, d=midominio.com)

Para saber que la configuración a la que has llegado es correcta, puedes envíar un correo a gmail y comprobar en la cabecera del mensaje recibido que la autenticación a través de DKIM es correcta:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@midominio.com;
       dkim=pass header.i=@midominio.com

Como con los SPF, te recomiendo que pruebes también con Yahoo, Outlook y otros proveedores para asegurarte de que has llegado a una configuración correcta.

También te pueden resultar útiles las herramientas de DKIM Core para generación o verificación de tus claves.

NOTA: Al igual que ocurría en el caso de los SPF, DKIM también tiene un hermano bastardo llamado DomainKeys que fue impulsado por yahoo! pero que ya nadie más usa… salvo ellos. Si miras en las cabeceras de un correo enviado a yahoo podrás ver que con la configuración que hemos visto aquí valida DKIM como pass y DomainKeys como neutral:

Authentication-Results: mta1040.mail.bf1.yahoo.com  from=midominio.com; domainkeys=neutral (no sig);  from=midominio.com; dkim=pass (ok)

Finalmente, tenemos un mecanismo para realizar una comprobación global de los mecanismos de identificación que nuestro correo es capaz de pasar que consiste en enviar un mail a la dirección check-auth@verifier.port25.com. Como respuesta recibiremos un resumen con los tests de autenticación que pasamos y los que no:

From: auth-results@verifier.port25.com
To: josemaria@midominio.com
Subject: Authentication Report
Message-Id: <1393852132-602016@verifier.port25.com>
Precedence: junk (auto_reply)
In-Reply-To: <53147EDC.1060808@midominio.com>

This message is an automatic response from Port25's authentication verifier
service at verifier.port25.com.  The service allows email senders to perform
a simple check of various sender authentication mechanisms.  It is provided
free of charge, in the hope that it is useful to the email community.  While
it is not officially supported, we welcome any feedback you may have at
<verifier-feedback@port25.com>.

Thank you for using the verifier,

The Port25 Solutions, Inc. team

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
Sender-ID check:    pass
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  estafeta.micorreo.net
Source IP:      145.255.98.239
mail-from:      josemaria@midominio.com

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass 
ID(s) verified: smtp.mailfrom=josemaria@midominio.com
DNS record(s):
    midominio.com. 86400 IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"
    midominio.com. 86400 IN MX 10 estafeta.micorreo.net.
    estafeta.micorreo.net. 14400 IN A 145.255.98.239

----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result:         neutral (message not signed)
ID(s) verified: header.From=josemaria@midominio.com
DNS record(s):

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: josemaria@midominio.com)
ID(s) verified: header.d=midominio.com
Canonicalized Headers:
    date:Mon,'20'03'20'Mar'20'2014'20'14:08:44'20'+0100'0D''0A'
    from:=?UTF-8?B?Sm9zw6kgTWFyw61hIE1vcmFsZXMgVsOhenF1ZXo=?='20'<josemaria@midominio.com>'0D''0A'
    reply-to:josemaria@midominio.com'0D''0A'
    to:josemaria.morales@gmail.com,'20'jmmoralesv@outlook.com,'20'jmmoralesv@yahoo.com,'20'check-auth@verifier.port25.com'0D''0A'
    subject:prueba'20'desde'20'morales-vazquez'20'a'20'dkim'0D''0A'
    dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=midominio.com;'20's=mail;'20't=1393852124;'20'bh=bTRBPsyNE9vY+br0wyWV6XaM4bHp8xfOlCzTWRPryRY=;'20'h=Date:From:Reply-To:To:Subject:From;'20'b=

Canonicalized Body:
    xxxx'0D''0A'
    '0D''0A'
    --'20''0D''0A'
    --'20'Jos'C3''A9''20'Mar'C3''AD'a'20'Morales'20'['20'josemaria@midominio.com'20']'0D''0A'
    ------------'20'Blog:'20'['20'http://blog.unlugarenelmundo.es/'20']'0D''0A'
    ------------'20'Perfil:'20''20'['20'http://cv.morales-vazquez.es/'20']'0D''0A'
    

DNS record(s):
    mail._domainkey.midominio.com. 86400 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB"

Public key used for verification: mail._domainkey.midominio.com (1024 bits)

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

----------------------------------------------------------
Sender-ID check details:
----------------------------------------------------------
Result:         pass 
ID(s) verified: header.From=josemaria@midominio.com
DNS record(s):
    midominio.com. 86400 IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"
    midominio.com. 86400 IN MX 10 estafeta.micorreo.net.
    estafeta.micorreo.net. 14400 IN A 145.255.98.239

----------------------------------------------------------
SpamAssassin check details:
----------------------------------------------------------
SpamAssassin v3.3.1 (2010-03-16)

Result:         ham  (-2.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
                            domain
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Políticas de contraseñas y control de acceso en Debian

Josemaría | 8 de febrero de 2014 | 8 comentarios

seguridad Existe un falso tópico por ahí que viene a decir, de una u otra forma, que Linux es más seguro que Windows. Para nada. Es cierto que, normalmente, el usuario medio de Linux está más comprometido con la seguridad, abundan más los usuarios expertos y menos los usuarios domésticos y que existe una mayor variedad de posibilidades y herramientas para hacer seguros nuestros sistemas. También que al existir un volumen menor de equipos con Linux no es objetivo prioritario de los creadores de virus. Pero “recién salido de la caja” y en manos de un usuario torpe y/o despreocupado, un Linux es, por regla general, tan poco seguro como cualquier Windows. De veras.

Veamoslo, por ejemplo, desde el punto de vista de la política de usuarios y contraseñas, uno de los aspectos que mas se critica en los Windows de escritorio. Una Debian 7.3 (la última en el momento de escribir esto) te permite poner cualquier contraseña para el root y la cuenta inicial que se crean de forma obligatoria durante la instalación. Y cuando digo cualquiera, digo cualquiera y sin ningún tipo de advertencia. ¡Hasta una de un sólo carácter o el maldito 123456 (que hace años que ya ni siquiera en Hotmail está permitida aunque sigue siendo una de las passwords más usadas)! Además, el único tipo de protección ante ataques de diccionario y/o fuerza bruta es un retraso de tres segundos entre cada intento de login fallido. No, no parece un planteamiento muy seguro a priori ¿Verdad? Bueno, por lo menos no nos permite dejar las cuentas sin contraseña. Algo es algo…

NOTA: Si durante la instalación dejamos la password del usuario root en blanco nos lo permitirá pero en ese caso, afortunadamente, lo que hará sera deshabilitar la cuenta de root y conceder privilegios a través de sudo a la cuenta del primer usuario que… igualmente, podremos inicializar con cualquier contraseña sin ningún tipo de advertencia. ¡Ay!

La parte positiva del asunto es que con un poquito de trabajo por nuestra parte este esquema puede mejorar sustancialmente. Para ello, lo primero es conocer como funciona la autenticación de usuarios en Linux. Vamos a ello.

Antes que nada vamos a ubicar algunos de los ficheros importantes en este asunto. En el directorio /etc se encuentran los ficheros passwd y shadow que guardan, respectivamente, las cuentas de usuario y los “hashes” de las contraseñas. Además, repartido entre ellos, existe mucha información relacionada con el proceso de autenticación: si el usuario puede hacer login interactivo o no, el bash que usará, información de caducidad de la cuenta, etc. Veamos una línea típica de cada uno de estos ficheros y hagamos una disección de su contenido.

Empezamos por el fichero passwd. Cada línea se corresponde con un usuario y consta de siete campos en los que el separador es el signo “:”. Por ejemplo así:

josemaria:x:1001:1001:Jose Maria Morales,,,:/home/josemaria:/bin/bash

El significado de cada uno de los campos es este:

1Nombre que el usuario utilizará en el login
2Tradicionalmente aquí se encontraba la hash del password. Ahora, una x simboliza que la hash de la password se encuentra en el fichero shadow. Un * o un ! indican que la cuenta está desactivada. Por el contrario, si eliminamos la x (o cualquier otra cosa) de este campo, el sistema nos dejará entrar sin necesidad de contraseña pero sólo a través de una conexión "in situ" frente a la máquina mientras que las conexiones remotas no se permitiran.
3UID del usuario
4GID del grupo primario del usuario
5Infomación personal del usuario. Los diferentes campos están separados por comas.
6Directorio home del usuario
7Path absoluto al shell por defecto que usará cuando realice una conexión interactiva. Se suele poner /bin/false cuando no queremos permitir una conexión interactiva.

Aquí ya podemos hacer la primera “personalización” relativa a la seguridad. Si queremos que un usuario no pueda hacer una conexión interactiva con el sistema basta con que pongamos un * o un ! en el campo 2 o un shell inexistente en el campo 7 (por convención suele ponerse /bin/false). La diferencia entre usar uno u otro método es que el segundo permitirá que, aún así, esa cuenta de usuario pueda seguir usándose para otro tipo de servicios (correo, por ejemplo) mientras que si usamos el primero la cuenta quedará totalmente inutilizable para ningún servicio.

Vayamos ahora con el fichero shadow. Primero un ejemplo. Como podemos ver, en este caso tenemos 8 campos:

josemaria:$6$F3PRa1Vu$fXK1ZYXex67wi5XdbnTokhWle416I87oAtgs0ynFdhn.c6IBqrvGhmnCUC.Ue2AbLJtn9C9ZH.3pgNfSeneTF0:15675:0:99999:7:::
1Nombre que el usuario utilizará en el login
2Se trata de un campo compuesto que contiene información del algoritmo que usará el sistema para calcular el hash, la salt que aplicaremos a la password antes de calcular este y el hash resultante. Cada uno de estos tres subcampos se separan por el símbolo $. En el ejemplo de aquí arriba el 6 del primer campo indica que usaremos SHA512 (la opción por defecto en las Debian actuales), la salt es F3PRa1Vu y el resto después del último símbolo $ es la hash ya calculada al resultado de concatenar la salt con el password. Un 5 en el primer campo indica que usaremos SHA256, un 4 SHA1, un 3 NT Hash, un 2 blowfish y un 1 MD5. Un * o un ! en este campo también indican que la cuenta está deshabilitada.
3Fecha del último día en que se cambió la password indicada, como es habitual, mediante el número de días transcurridos desde el 1 de Enero de 1970
4Número mínimo de días requeridos entre cambios de contraseñas. Un 0 indica que se puede cambiar tan a menudo como se quiera.
5Número máximo de días para obligar a un cambio de contraseña. Por defecto 99999. O sea, casi 274 años. O sea, nunca.
6Número de días antes de que el password expire en que se mostrará un aviso al usuario indicando que debe de cambiarla. Por defecto 7 días
7Número de días del periodo de gracia después de que el password expire transcurridos los cuales la cuenta será deshabilitada. En blanco por defecto (no habrá periodo de gracia).
8Fecha (indicada también mediante el número de días transcurridos desde el 1 de enero de 1970) en que la cuenta será deshabilitada. En blanco por defecto (la cuenta nunca expira).

La expiración de passwords y de cuentas de los parámetros que hemos visto se puede manejar de dos formas: editando directamente la información del fichero shadow o con el comando chage. Por ejemplo, el siguiente comando fija en 30 días la validez máxima de una contraseña para el usuario josemaria y en 2 el mínimo número de días que deben de transcurrir entre cambios:

chage -M 30 -m 2 josemaria

Otros parámetros interesantes son -d y -E para establecer la fecha del último cambio de contraseña y la de caducidad de la misma respectivamente (en formato YYYY-MM-DD), -I para establecer los días de gracia antes de desactivar la cuenta, o -W para establecer el número de días antes de la fecha de caducidad para emitir una advertencia.

También podemos cambiar todos estos datos de forma interactiva:

comando chage en forma interactiva

O listar los valores establecidos para una cuenta usando el argumento -l:

chage -l josemaria

Pero ¿Dónde se establecen estos valores por defecto para que se tengan en cuenta a la hora de crear nuevos usuarios y no tener que modificarlos uno a uno? En el fichero /etc/login.defs podemos editar los siguientes parámetros que sirven, respectivamente, para ajustar el número máximo y mínimo de días de validez de una password y la antelación a que caduque con que recibiremos una advertencia:

PASS_MAX_DAYS   60
PASS_MIN_DAYS   2
PASS_WARN_AGE   5

En el fichero /etc/default/useradd ajustamos los días de gracia en que las cuentas permarecerán activas después de caducar las contraseñas y la fecha global de expiración de las mismas:

INACTIVE=2
EXPIRE=

Un -1 en el primer campo indica que la cuenta se deshabilitará tan pronto como caduque la contraseña. Si el segundo campo está en blanco indica que la cuenta no tendrá una fecha predeterminada de expiración.

Pero la verdadera potencia en el sistema de identificación de Linux reside en la gran variedad y flexibilidad que tenemos a la hora de usar métodos que refuerzan el sistema clásico de autenticación o nos proporcionan alternativas al mismo mediante módulos adicionales. Estos módulos residen en el directorio /lib/i386-linux-gnu/security/ y se configuran a través de los ficheros que tenemos en /etc/pam.d. En este enlace podemos ver todos los disponibles en una Debian 7 estable, aun los no instalados por defecto. Empecemos por ver dos de los que vienen instalados “de serie”. pam_faildelay y pam_tally nos permiten, a través del fichero /etc/pam.d/login, controlar el retraso entre varios intentos de login fallidos y la configuración de bloqueo de cuentas después de sucesivos intentos erroneos con los siguientes parámetros:

auth optional pam_faildelay.so delay=5000000
auth required pam_tally.so deny=5 unlock_time=7200

En la primera línea el retraso entre logins fallidos se especifica en microsegundos (5000000, o sea, 5 segundos). En la segunda línea decimos que tras cinco intentos de login fallido la cuenta se bloqueará durante 7200 segundos (2 horas). En una instalación limpia y por defecto la primera línea aparece configurada a 3 segundos y la segunda no aparece, es decir, la cuenta no se bloquea nunca.

El control manual de las cuentas bloqueadas o intentos fallidos de login puede llevarse mediante dos utilidades: pam_tally o faillog.

pam_tally y faillog para control de cuentas bloqueadas e intentos fallidos de login

Podemos, además, consultar los datos relativos a una única cuenta de usuario con cualquiera de estos dos comandos:

pam_tally --user josemaria
faillog -u josemaria

Desbloquear manualmente una cuenta o hacer un reset a los intentos fallidos de la misma así:

pam_tally --user josemaria --reset=0
faillog -r -u josemaria 

O modificar el número máximo de intentos fallidos así:

faillog -m 3
NOTA: Los bloqueos tras sucesivos intentos fallidos se pueden controlar también con utilidades externas como denyhost (de la que hablamos aquí hace años) o fail2ban que añaden muchas otras funcionalidades.

El tipo de contraseñas permitidas y alguna otra característica asociada a las mismas se configura en el fichero /etc/pam.d/common-password. La configuración por defecto usa el módulo pam_unix y se define mediante esta línea:

password [success=1 default=ignore] pam_unix.so obscure sha512

El argumento obscure realiza una mínima comprobación de la complejidad de la contraseña: si esta es demasiado simple o una modificación fácilmente reproducible a partir de la anterior, mientras que sha512 define el algoritmo que se usará para guardar el hash en el fichero shadow. Otros argumentos interesantes que podemos añadir son remember, que dicta el número de contraseñas que son memorizadas por el sistema para que el usuario no las repita o minlen que fija la longitud mínima de la contraseña. Por ejemplo, para recordar las 12 contraseñas anteriores y fijar una longitud mínima de 10 caracteres modificaríamos la línea anterior así:

password [success=1 default=ignore] pam_unix.so obscure remember=12 minlen=10 sha512

El módulo pam_cracklib, que no viene instalado por defecto, nos permite una configuración mucho más flexible. Lo instalamos así:

apt-get install libpam-cracklib

Y, tras hacerlo, se nos añadirá automáticamente la siguiente línea en el fichero /etc/pam.d/common-password justo encima de la que define la forma de funcionar del módulo pam_unix:

password requisite pam_cracklib.so retry=3 minlen=8 difok=3

pam_cracklib es mucho más restrictivo que pam_unix a la hora de permitir contraseñas puesto que, además de las comprobaciones de complejidad, contrasta la password elegida por el usuario con las de un diccionario que instala en el directorio /var/cache/cracklib. Además, en su configuración por defecto que acabamos de ver exige una longitud mínima de 8 caracteres de los cuales, al menos, tres no debería de estar presentes en la password anterior (argumento difok). Otros argumentos interesantes son reject_username (rechaza contraseñas que contengan de alguna forma el nombre de usuario escrito normal o invertido) o maxrepeat=n (rechaza contraseñas con más de n caracteres iguales seguidos).

Particularmente flexible es el método que nos permite definir el tipo de caracteres que exigiremos a la contraseña. pam_cracklib considera que existen cuatro grupos de caracteres: letras mayúsculas, letras minúsculas, cifras y signos de puntuación. La forma más sencilla es definir el mínimo número de estos tipos que deberían de estar presentes en cada contraseña con el argumento minclass=n, donde n es un número entre 1 y 4.

Contamos, además, con los argumentos lcredit, ucredit, dcredit y ocredit que representan, respectivamente, a las letras minúsculas, las mayúsculas, los dígitos y los signos de puntuación, los cuatro grupos de caracteres a considerar. Cuando aparecen con valores negativos indican el mínimo número de caracteres de ese grupo con que debería de contar nuestra password. Por ejemplo, minlen= 8 ucredit=-1 lcredit=-1 dcredit=-1 indica que la contraseña debería de tener al menos una mayúscula, una minúscula y un dígito y contar con 8 caractéres mínimos de longitud. Cuando se utilizan con valores positivos, sin embargo, validan nuestra contraseña según un sistema de créditos donde minlen indicaría el número de “puntos” mínimo que validaría una contraseña como correcta. La contraseña sumaría un punto por cada carácter de longitud y los puntos correspondientes a las clases de caracteres que incluya. Pongamos, por ejemplo, que hemos establecido los argumentos minlen= 13 ucredit=1 ocredit=2 dcredit=2. La contraseña tristr4s suma diez puntos (ocho por longitud y dos más por contener un dígito) y no sería valida, mientras que Tristr4s! sumaría 14 (nueve por longitud, una por tener mayúsculas, dos por tener un dígito y otros dos por tener un signo de puntuación) y si sería permitida.

En las páginas del manual de cada uno de estos módulos puedes encontrar algunos otros argumentos interesantes.

IMPORTANTE: La mayor parte de estas restricciones se tendrán en cuenta sólo en el caso de que sea el propio usuario quien realice su cambio de contraseña. Si es el usuario root quien la establece inicialmente o la cambia se le permitirá saltarse a la torera la gran mayoría de estas normas, a veces sin siquiera una advertencia.
ACTUALIZACIÓN: En Security by Default publican esta semana esta entrada con información mucho más técnica sobre los módulos de autenticación PAM donde, además, los analizan como posible punto para comprometer a un sistema.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Backups y recuperación de datos en PYMEs

Josemaría | 16 de diciembre de 2013 | Comentar
Una buena ración de estadísticas para preocuparse un poco…
especiales Según un reciente estudio realizado entre SMBs (“Small and Medium Business”, el nombre que reciben nuestras PYMES en el mundo anglosajón) de Estados Unidos, Francia, Alemania y Reino Unido por una importante empresa del sector de la virtualización, el 85% de los interrogados tenían problemas con el coste de sus soluciones de backup, el 83% con la capacidad o el espacio de almacenamiento requerido por las mismas y el 80% con la complejidad técnica necesaria para su uso.

El estudio no tiene desperdicio y hay muchas otras cifras interesantes en él. A veces, cuentan, recuperar un simple correo electrónico borrado puede llevar hasta 12 horas, el 17% de las recuperaciones de datos que se realizan presentan algún tipo de problema o error y hasta el 55% de las empresas está considerando cambiar sus métodos de backup para el año que entra.

No conozco ningún estudio similar en nuestro país, pero lo que he visto en las PYMEs (y también en alguna gran empresa) en las que he tenido algo que ver en los últimos años es similar a lo que se cuenta aquí. O, incluso, peor. Lo que me sigue sorprendiendo es la desidia a implementar soluciones robustas en este terreno cuando todos sabemos que los discos duros fallan (¡y mucho!), pero sobre todo que las personas cometemos errores y, más a menudo de lo que nos gustaría, borramos archivos por error. O de forma malintencionada. Mirad, si no, lo que ha ocurrido en la UGT hace bien poco ;-)

De lo segundo es bastante difícil conseguir datos fiables, pero de lo primero hay suficientes números como para echarse a temblar. El tiempo de vida medio de un disco duro en un entorno empresarial se estima en entre tres y cinco años. Los estudios realizados por Google dicen que a partir del segundo año la probabilidad anualizada de error en un disco se dispara al 8% y se mantiene entre este valor y el 10% en los tres años siguientes. Los estudios de ExtremeTech indican un porcentaje menor de errores en el segundo año pero los disparan a cerca del 12% a partir del tercero. Y ¿son más fiables los nuevos discos SSD? Es difícil comparar una tecnología con poco más de cinco años con otra de más de 50, pero los pocos estudios que se han hecho por el momento indican que el incremento en la fiabilidad de esta tecnología es escaso o inexistente.

Las técnicas de backup y de recuperación de datos son, hoy en día, inexcusables en un entorno informático y, si me apuran, en el personal. Cualquier empresa que se precie debería de tomarse ambas cosas muy en serio y asegurarse de que usa mecanismos acordes a lo que trata de proteger. Porque luego lamentarse es gratis, pero no sirve ya de nada.

Referencias:

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

RAID por software en Debian 7 con mdadm

Josemaría | 23 de octubre de 2013 | 2 comentarios

hard disk Para el que no lo sepa, un RAID en informática no es una carrera de aventuras sino un disco duro lógico creado a partir de la union de dos o más discos duros físicos con objeto (por lo general aunque no siempre) de proporcionar tolerancia a fallos. Las siglas vienen de Redundant Array of Inexpensive Disks y hace referencia a que, en su día, constituían una alternativa para proporcionar un almacenamiento seguro usando discos baratos en lugar de unos mucho más caros (por lo general SCSI). Ahí está la wikipedia para quién quiera aprender un poquito más ;-)

El método más seguro de usar esta tecnología es mediante hardware dedicado. Eso que quede claro. Pero cuando no queremos o no podemos gastarnos el dinero que esto requiere tenemos la alternativa de implementarlo mediante software. En Linux tenemos para ello mdadm, una herramienta en línea de comando muy sencilla de usar si entendemos los conceptos básicos de lo que estamos haciendo.

La instalación en una Debian es así de sencilla:

apt-get install mdadm

El script de configuración posterior a la instalación sólo nos planteará dos cuestiones. Leelas atentamente (como siempre… ;-) ). En la primera se nos pregunta si el sistema de ficheros raíz de nuestro Linux estará en un RAID con objeto de iniciarlo antes de la secuencia de arranque. En este ejemplo le diremos que no puesto que sólo usaremos RAID para los discos de datos, así que responderemos con none como se nos indica en el mensaje siguiente:

Instalación de mdadm en Debian Linux
En la segunda pregunta se nos interroga acerca de si queremos que los discos RAID que vamos a crear se inicialicen de forma automática durante cada inicio de la máquina o si preferimos hacerlo nosotros manualmente. Contestaremos que queremos que lo haga de forma automática.

Instalación de mdadm en Debian Linux
Una vez instalado mdadm ya podemos crear nuestro RAID. En el ejemplo que vamos a ver crearemos un RAID5 con tres discos de 500GB. El comando lsblk es muy cómodo para ver que asignación de nombres le ha hecho nuestro sistema a estos dispositivos:

Comprobando la asignación de nombres de dispositivos a nuestros discos duros con lsblk
El comando básico para crear un RAID es este:

mdadm --create dispositivo-md --level=x --raid-devices=z dispositivos-sd

O en formato abreviado:

mdadm --create dispositivo-md -l x -n z dispositivos-sd

Donde x es el nivel de RAID (admite los básicos 0, 1, 4, 5, 6, 10 y alguno más) y z el número de discos que formarán el array. El dispositivo-md será el nombre de dispositivo que recibirá el nuevo disco lógico (y que debería de estar en el directorio /dev y, por convención, llamarse md seguido de un número, por ejemplo /dev/md0) y los dispositivos-sd serían los discos físicos que forman el array separados por espacios (por ejemplo /dev/sdb /dev/sdc). Podemos añadir también la opción --verbose para obtener información más detallada del proceso de creación y los posibles fallos. Veamos un par de ejemplos:

Para crear un RAID0 con los tres discos indicados:

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc

Para crear un mirror (RAID1) con los discos indicados:

mdadm --create /dev/md0 -l 1 -n 2 /dev/sdb /dev/sdc

La creación admite, aparte de estas, otras opciones avanzadas que puedes consultar en el manual que se ha instalado con él (man mdadm). Y vamos ya a seguir con nuestro ejemplo. Para crear el RAID5 que necesitamos ejecutamos lo siguiente:

mdadm --create --verbose /dev/md0 --level=5 -n 3 /dev/sdb /dev/sdc /dev/sdd

Si todo ha salido bien se nos mostrarán algunos mensajes informativos y el comando finalizará indicando que el disco md0 ha sido inicializado y arrancado. Podemos comprobar el estado de nuevo con lsblk o con more /proc/mdstat
Comprobando el estado de un RAID5 recién creado con mdadm

Para poder utilizar nuestro disco debemos aún formatearlo y montarlo en nuestro sistema de ficheros. Vamos a formatearlo como ext4 y a montarlo en un directorio que se llame datos dentro del subdirectorio /mnt:

mke2fs -t ext4 /dev/md0
mkdir /mnt/datos
mount /dev/md0 /mnt/datos

Si usamos ahora, por ejemplo, el comando df (df -k /mnt/datos) para ver el espacio de la partición y el porcentaje de uso veremos que, efectivamente, disponemos de cerca de 1TB correspondiente al tamaño del RAID5 con tres discos de 500GB que hemos montado.

Nos falta aún algo más. Durante la instalación le hemos dicho a mdadm que inicie de forma automática todos los arrays, pero eso no significa que los monte en el sistema de ficheros. Si queremos que lo haga automáticamente en cada arranque y en el mismo directorio donde lo acabamos de hacer de forma manual, tendremos que añadir una línea como la siguiente al fichero /etc/fstab:

/dev/md0  /mnt/datos  ext4  defaults  0  1

Vamos a echarle ahora un vistazo a diversos comandos de gestión y monitorización. Si queremos detener el volumen usamos el argumento --stop. No olvides desmontarlo antes para evitar que haya pérdida de datos:

umount /dev/md0
mdadm --stop /dev/md0

Luego, para volver a arrancarlo de forma manual:

mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Y si habíamos incluido la línea que indicamos antes en el fichero fstab para volver a montar el disco en nuestro sistema de ficheros basta con hacer esto:

mount /dev/m0 /mnt/datos

Para ver información de todos los arrays que tenemos en funcionamiento en la máquina usamos el argumento --detail:

mdadm --detail --verbose --scan

Información de los RAID en una máquina con mdadm

Sólo tenemos uno, claro. Para ver información en detalle del mismo:

mdadm --detail --verbose /dev/md0

Información en detalle de un RAID con mdadm

O también podemos usar el argumento --examine para ver información y el estado de cualquier a de los discos que forman nuestro array:
Información en detalle de uno de los discos de un RAID con mdadm

Vamos a simular ahora la rotura de uno de los discos. Para ello apagamos la máquina bruscamente y desconectamos uno de los tres discos del RAID. Podemos hacer fácilmente esta prueba tanto en una máquina real (¡que no esté en producción!) como en una virtual. Tras arrancar de nuevo nuestro RAID habrá perdido la tolerancia a fallos. No obstante, si hemos creado o copiado datos en el directorio /mnt/datos veremos que estos siguen siendo perfectamente accesibles.

OJO: Si el RAID no estaba aún totalmente inicializado (hemos usado discos muy grandes y no ha pasado suficiente tiempo desde su creación o desde la última vez que se recuperó de un fallo) el volumen no arrancará correctamente. Es por tanto muy importante no comenzar a usarlo hasta que no se ha inicializado completamente y extremar las precauciones después del fallo de algún disco hasta que volvemos a recuperar la tolerancia a fallos. Si miramos el pantallazo de aquí arriba en el que aparece la salida de ejecutar more /proc/mdstat vemos que allí aparece una barra de progreso donde se indica el estado de creación o reconstrucción del RAID. Mientras que esa barra no llegue al 100% y desaparezca mejor que no tengas ningún problema ;-)

Para recuperar la tolerancia a fallos debemos de añadir un disco nuevo. Lo hacemos y una vez arrancada de nuevo la máquina ejecutamos lo siguiente para añadir el disco /dev/sdc a nuestro RAID en sustitución del que hemos simulado que se ha roto:

mdadm /dev/md0 --add /dev/sdc

El RAID se reconstruirá sólo de forma automática pero dependiendo del tamaño y del volumen de datos podrá tardar más o menos tiempo. Observa de vez en cuando la salida de more /proc/mdstat para estar al tanto.

OJO: Después de perder un disco los nombres de los dispositivos pueden haber “bailado”. Es muy importante que comprobemos antes (con lsblk, por ejemplo) cuales son los que siguen formando parte del array y cual el nuevo que queremos añadir.

Si lo que queremos es añadir al RAID un nuevo disco para que sea usado como hot spare basta con sumarlo a un RAID ya creado y funcional con el mismo comando que usamos antes para añadir un disco a un RAID estropeado:

mdadm /dev/md0 --add /dev/sde

Si lo que queremos es añadir el disco para agrandar el tamaño del RAID y no para que sea usado como hot spare tendríamos que usar los siguientes comandos:

mdadm /dev/md0 --add /dev/sde
mdadm --grow /dev/md0 –raid-devices=4

En el fichero /proc/mdstat podemos ver el proceso como siempre:
Haciendo crecer nuestro RAID añadiendo un nuevo disco

Lo que no nos va a resolvernos mdadm es hacer que la partición que habíamos creado en el disco y sobre la que estábamos trabajando crezca. Eso es tarea nuestra:

umount /dev/md0
e2fsck -f /dev/md0
resize2fs /dev/md0
mount /dev/md0 /mnt/datos

Y el resultado:
Extendiendo la partición de un RAID al que hemos añadido un nuevo disco

NOTA: Como se puede observar, durante este último proceso de crecimiento del RAID hemos trabajado con cuatro discos (tres originalmente) de 1GB cada uno en lugar de los de 500GB que hemos usado en el resto del tutorial. Quería que se apreciara el cambio de tamaño del volumen y la resincronización de discos tan grandes habría supuesto tener que esperar muchas horas para poder visualizar el proceso completo.

Si lo que queremos es eliminar uno de los discos del RAID (para reemplazarlo por otro, por ejemplo) tenemos antes que marcarlo como fail. Luego lo eliminamos:

mdadm /dev/md0 --fail /dev/sdd
mdadm /dev/md0 --remove /dev/sdd

Y si quisiéramos eliminar el RAID usamos este comando:

mdadm --remove /dev/md0

mdadm tiene también un argumento llamado --monitor que le permite generar alertas cuando ocurre alguna incidencia en el RAID. Por defecto en una Debian el monitor se arranca como un daemon que graba las incidencias en el fichero de logs de la máquina (/var/log/syslog) de esta forma:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog

Si, además, quisiéramos que nos enviara dichas incidencias a nuestra cuenta de correo deberíamos de añadir la opción --mail:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog --mail josemaria@uponday.net
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Greylisting en Postfix y Debian 7

Josemaría | 27 de septiembre de 2013 | 2 comentarios

correoNadie se acuerda de Santa Bárbara hasta que truena, que dice el refrán. Yo tenía pendiente configurar un sistema de Greylisting (listas grises) en mi servidor de correo pero no lo he visto como urgente e inmediato hasta el aumento inusitado de actividad de los bots de spam de los últimos días.

El Greylisting es, hoy por hoy, uno de los métodos más efectivos a la hora de controlar el spam y su funcionamiento es sencillo y fácil de entender. Cuando un servidor de correo recibe un mensaje anota en una lista tres datos que lo identifican (la IP desde donde viene, el correo del remitente y el del receptor) y a continuación lo rechaza indicando al emisor que lo intente de nuevo más tarde. Esto se hace con un código 45x:

-> MAIL FROM: <sender@somedomain.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <recipient@otherdomain.com>
<- 451 4.7.1 Please try again later

Si el mensaje ha sido enviado por un servidor SMTP legítimo reconocerá el mensaje de rechazo y en un tiempo predefinido (típicamente de 300 segundos) reenviará de nuevo el correo que, en este caso, será aceptado por el servidor del destinatario. Un bot preparado para enviar spam no realizará el segundo envío. De esta forma, si el correo no es spam llegará al destinatario con 5 minutos de retraso. Salvo este detalle el emisor no se enterará de nada (todo el trabajo se hace entre los servidores de correo sin que los clientes intervengan). Si el receptor abre la cabecera del mensaje recibido verá una línea parecida a esta:

X-Greylist: delayed 300 seconds by postgrey-1.34 at invernalia; Thu, 19 Sep 2013 16:30:33 CEST

El sistema de control del spam mediante Greylisting fue originalmente ideado por Evan Harris en este whitepaper de 2003. El señor Harris mantiene, además, una lista de implementaciones de su método para diversos servidores de correo. Si quieres más información conceptual sobre esta técnica, esta página y la entrada correspondiente de la wikipedia también tienen información interesante.

Si ya tienes una Debian con un servidor de correo postfix funcionando la implementación en perl del Greylisting es muy, muy fácil de poner en marcha. Basta con instalar el paquete postgrey y añadir check_policy_service inet:127.0.0.1:10023 en la lista de restricciones del fichero main.cf de configuración de postfix en el directorio /etc/postfix:

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023

Por supuesto, una vez hechas ambas cosas debemos de reiniciar el servicio postfix. La instalación nos ha creado un nuevo servicio llamado postgrey que arranca como daemon y escucha en el puerto 10023 y que responde a los argumentos habituales: start, stop, restart, reload, force-reload y status. En el directorio /etc/postgrey tenemos dos ficheros denominados whitelist_clients y whitelist_recipients donde, respectivamente, se pueden especificar las direcciones de ciertos servidores smtp o direcciones de correo que no se someteran al procedimiento de rechazo temporal de los mensajes y que se aceptaran al primer intento. Tenemos, además, un fichero donde se encuentra la configuración principal del servicio llamado /etc/default/postgrey que veremos más adelante.

Si observamos ahora el log de nuestro postfix (/var/log/mail.log) podemos estudiar el funcionamiento y si este es correcto. Cuando recibimos cualquier correo (salvo uno ya identificado como válido en las whitelist) será inmediatamente registrado y rechazado:

Al cabo de cinco minutos si el correo es legítimo el servidor remitente volverá a intentarlo y ahora el correo si será aceptado:

Puede que el servidor emisor se impaciente y antes de que transcurran esos cinco minutos vuelva a intentarlo. En ese caso el correo volverá a ser rechazado:

Como puedes observar en los mensajes del log, aparte de la razón del rechazo el servidor enviará una dirección web personalizada donde se informa detalladamente de lo que está ocurriendo:

mensaje de información de postgrey en castellano

Postgrey crea, además, una base de datos en el directorio /var/lib/postgrey donde guarda información acerca de los mensajes recibidos. Después de aceptar cinco mensajes de un servidor, este será automáticamente incluido en una whitelist de tal forma que, a partir de este momento, ya no se le volverá a exigir el trámite de los reintentos. Podemos consultar en cualquier momento los servidores de esta lista ejecutando el siguiente script:

perl /usr/share/doc/postgrey/postgrey_clients_dump

Y una ejecución de ejemplo:

Servidores incluidos en la whitelist de greylist

Tenemos aún pendiente ver el fichero de configuración principal: /etc/default/postgrey. En el podemos modificar, por ejemplo, el texto que aparecerá en el mensaje de rechazo:

POSTGREY_TEXT="Si tu sevidor funciona como debiera debería de intentar enviarme de nuevo el mensaje en 5 minutillos de nada"

También podemos enviar al demonio cualquiera de los argumentos que tenemos disponibles para modificar su funcionamiento (ver man postgrey) mediante el parámetro POSTGREY_OPTS. Por ejemplo, en la siguiente línea se dice al demonio que escuche en el puerto 60000, subimos el retraso para aceptar el mensaje a 600 segundos y le indicamos que incluya las direcciones de los clientes en la whitelist después de aceptarles 3 envíos:

POSTGREY_OPTS="--inet=60000 --delay=600 --auto-whitelist-clients=3"

Para terminar, si quieres comprobar la configuración de tu servidor de correo electrónico para ver si es vulnerable de alguna forma y puede ser usado como un Open Relay, si el correo saliente que envía puede verse bloqueado de alguna forma, etc. existen muchas herramientas en línea pero las más cómodas y completas, a mi juicio, son las de mxtoolbox y el test de allaboutspam.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalación y primeros pasos con ntop 5 en Debian 6

Josemaría | 25 de marzo de 2013 | 6 comentarios

ntop es la herramienta más popular y completa para monitorizar el tráfico de una red cuando nos interesa, no sólo conocer la magnitud del mismo sino su procedencia y características. Colocado en un punto estratégico de nuestra red nos sirve para detectar cualquier tipo de anomalía en la misma. Si lo instalamos en un servidor nos sirve para auditar el tipo de tráfico que este emite y recibe de forma gráfica y muy didáctica.

Como ocurre en algunas ocasiones la versión en la paquetería de debian (4.0.33 en la estable y 4.99.3 en testing y unstable) va bastante por detrás de la del producto (5.0.1) así que si te apetece jugar con lo último lo mejor es bajarte los fuentes y compilarlos en tu máquina. Pero ya sabes que, en este caso, tendrás que preocuparte de posibles actualizaciones de forma manual. ntop, en particular, no parece tener ningún aviso automático de la aparición de nuevas versiones. Vamos a ello.

Antes que nada, instalamos los paquetes necesarios para realizar la instalación, las dependencias y alguna otra cosa necesaria:

apt-get install build-essential libtool automake autoconf libpcap-dev libgdbm-dev rrdtool librrd-dev libssl-dev python-dev libgeoip-dev graphviz subversion python-pip

A continuación nos descargamos de aquí la última versión estable de ntop, la copiamos en, por ejemplo, el directorio /tmp de nuestra máquina y la descomprimimimos:

wget -c http://sourceforge.net/projects/ntop/files/ntop/Stable/ntop-5.0.1.tar.gz
tar xvfz ntop-5.0.1.tar.gz

Ahora entramos al directorio donde se han descomprimido los fuentes (ntop-5.0.1 en este caso) y generamos los binarios.

cd ntop-5.0.1/
./autogen.sh
make
make install
ldconfig

Y listo. Sólo nos quedan unos cuantos retoques. Los datos que ntop capture una vez esté en funcionamiento se guardarán en /usr/local/var/ntop. El daemon de ntop se ejecuta con el usuario nobody, así que debemos de hacerlo propietario de dicho directorio para que pueda escribir libremente en él:

chown -R nobody /usr/local/var/ntop

El binario de ntop ya está listo para ejecutarse y se encuentra en el directorio /usr/local/bin. Si escribes ntop -help tendrás una detallada lista de posibles opciones. Las mías son estas:

/usr/local/bin/ntop -i eth0 -w 3001 -L -d

De esta forma ntop monitorizará todo el tráfico enviado y recibido por el interfaz de red eth0 de nuestra máquina, el interface web de ntop escuchará peticiones en el puerto 3001 (por defecto lo haría en el 3000), guardará los mensajes de log en el syslog de la máquina (/var/log/syslog) y se ejecutará como daemon o servicio en segundo plano.

En la primera ejecución nos pedirá que introduzcamos la contraseña para el usuario admin necesaria para entrar a ciertas páginas restringidas del programa. Muy pocas, la verdad, pero luego veremos como solucionar esto.

ACTUALIZACIÓN: Las últimas compilaciones llevan por defecto la contraseña admin para el usuario admin

Para acceder a ntop ya sólo tenemos que ir a nuestro navegador y escribir lo siguiente sustituyendo ip-de-la-maquina por la dirección o nombre correcto donde hemos hecho la instalación y cambiando el puerto por el adecuado si lo hemos modificado en la orden de inicio anterior:

http://ip-de-la-maquina:3001

Pantalla principal de ntop (Traffic Summary)

Para proteger el acceso a cualquier página de ntop (imprescindible sobre todo si es visible desde Internet) debemos de entrar en el menú superior (Admin -> Configure -> Protect URLs) y añadir una regla con un asterisco ‘*’ al limitado grupo de usuarios que deseemos (o al usuario admin si es una instalación de uso particular).
Protegiendo el acceso a ntop

Ahora ya sólo nos quedan unos pequeños ajustes para disponer de algunos gráficos y diagramas adicionales que, por defecto, no vienen configurados. El plugin Round-Robin Database debería de estar activado para disponer de los gráficos de Network Load generales o por protocolo.
Gráficos de carga por protocolo en ntop con rrd activado

Para ello, además de activar el plugin (Plugins -> Round-Robin Database -> Activate), deberíamos de comprobar que en la pantalla de Preferencias (Admin -> Configure -> Preferences) la cadena rrd.rrdPath apunta a un directorio donde el usuario nobody tenga permisos de escritura (típicamente /usr/local/var/ntop/rrd), que en la configuración del plugin (Plugins -> Round-Robin Database -> Configure) las dos cadenas del bloque RRD Files Path apuntan al mismo directorio y que en el bloque Data to Dump de esta misma pantalla tenemos seleccionada, al menos, la opción de Interfaces. Si seleccionamos todas las opciones tendremos muchos más datos de captura pero a costa de cargar más la ejecución y el espacio ocupado por las capturas. Mucho cuidado con el espacio en disco, que podemos necesitar fácilmente 2 Gigas por día en un servidor con un tráfico corrientito.
Configurando rrd en ntop

Para ver los mapas por regiones tenemos que instalar las plantillas Mako para python. Como al principio de todo hemos instalado el paquete python-pip nos basta con salir a línea de comandos y ejecutar lo siguiente:

pip install Mako

Graficos geográficos con Mako y ntop

Por último, aunque hemos instalado graphviz y Dot es uno de sus elementos integrantes, nos hace falta añadir un path en las Preferencias (Admin -> Configure -> Preferences) para disponer de los Mapas de Tráfico de Red Locales. Entramos en ellas y, al final de la tabla, añadimos la cadena dot.path con el valor /usr/bin/dot. Pulsamos Add, confirmamos y listo.
Gráficos de tráfico de red local en ntop

ntop tiene muchas otras gráficas y páginas de información útil e interesante además de estas que he mostrado y cuyo único motivo para aparecer aquí es que necesitan de algún retoque extra en la configuración para poder usarlas, así que lo mejor es que las explores una a una. La documentación para interpretarlas es escasa, todo hay que decirlo, pero últimamente se están poniendo las pilas en este sentido y han prometido, por fin, un manual de usuario en breve.

Y ya sólo nos queda un pequeño detalle para concluir. Si quieres que ntop se ejecute de forma automática como servicio cada vez que hagas un reinicio de la máquina donde la tienes instalada sólo tienes que crear un fichero .sh (por ejemplo ntop.sh) con la línea de ejecución que has usado antes para ponerlo en marcha, crear un enlace al mismo en el directorio init.d y ejecutar lo siguiente:

ln -s /opt/Scripts/ntop.sh /etc/init.d/ntop
update-rc.d ntop defaults 99
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalando OpenVAS 4 en Ubuntu 11.04

Josemaría | 12 de junio de 2011 | 2 comentarios

herramientas Hace poco contamos por aquí como instalar la última versión de OpenVAS en Fédora. Si prefieres trabajar con Ubuntu o una distribución derivada puedes seguir lo que se cuenta en ese mismo post salvo en algunos pequeños detalles:

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalando OpenVAS 4 beta en Fedora 14

Josemaría | 18 de marzo de 2011 | 1 comentario

herramientas OpenVAS es un scanner de vulnerabilidades de red de código abierto creado a partir de un fork de la versión 2 de Nessus que se convirtió en código propietario en su versión 3, allá por el año 2005. Si queremos instalar la última versión de OpenVAS, la 4, disponible en fase beta desde diciembre de 2010, tenemos que hacerlo manualmente. Existen indicaciones de como hacerlo para diferentes distribuciones en esta dirección pero, a mi parecer, son difíciles de seguir para quién no está bien familiarizado con la arquitectura que usa esta herramienta, he detectado algunos errores y no explican, por ejemplo, algo tan básico como la forma de realizar una instalación distribuida cliente-servidor que es uno de los puntos fuertes de la herramienta. Así que vamos allá.

ACTUALIZACIÓN: Desde el día 17 de marzo la versión 4 es ya definitiva (ya es casualidad que lo tuviera escrito desde una semana antes y que no mirara la lista de correo hasta días después ¿eh?). El procedimiento de instalación aquí descrito sigue siendo válido y si lo has seguido usando los repositorios se te habrán actualizado los últimos cambios de forma automática.

Para disponer de los paquetes necesarios podemos hacer dos cosas, descargarlos manualmente (de esta dirección si usas arquitectura de 64 bits o de esta otra si usas arquitectura i386) e instalarlos con rpm (o yum con la opción --localinstall) o, mucho más recomendable, añadir un nuevo repositorio a tu máquina para recibir las futuras actualizaciones. En este segundo caso debes de crear un nuevo archivo .repo (por ejemplo openvas.repo) en tu directorio /etc/yum.repos.d y copiar en él lo siguiente (o bajártelo diréctamente desde aquí):

[security_OpenVAS_STABLE_v4]
name=security:OpenVAS:STABLE:v4 (Fedora_14)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/Fedora_14/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/Fedora_14/repodata/repomd.xml.key
enabled=1

Lo siguiente que tenemos que hacer es decidir que instalar. Cómo decíamos antes, OpenVas tiene una estructura cliente servidor de forma que la parte del programa que realiza el escaneo propiamente dicho puede instalarse en una máquina diferente a aquella desde la que se lanza y monitoriza el análisis o, incluso, distribuirlo entre varias para aliviar la carga. Tenemos, así, la posibilidad de instalar servidores en diferentes puntos estratégicos de nuestra red y usar siempre el cliente desde nuestro ordenador de trabajo. Existe una detallada descripción de la arquitectura que se usa en esta dirección pero si no te interesa meterte en tantos detalles, échale al menos un vistazo a esta imagen para comprender lo que sigue:
Arquitectura de OpenVAS

El servidor de OpenVAS está formado por tres módulos (scanner, manager y administrator) y disponemos de tres posibles clientes para explotarlos: uno en línea de comando (openvas CLI), otro con una aplicación clásica de escritorio que usa las librerías qt4 (greenbone security desktop o gsd) y una tercera posibilidad que es acceder directamente a través de un navegador usando, para ello, el módulo denominado greenbone security assistant.

Y vamos a instalar. Si queremos hacer una instalación completa (cliente y servidor) en la misma máquina y estamos usando el repositorio que hemos puesto anteriormente, tenemos que instalar (recordad, como usuario root) los siguientes paquetes:

sudo yum install sqlite nmap libopenvas4 libmicrohttpd10  openvas-scanner openvas-manager openvas-administrator  greenbone-security-assistant gsd openvas-cli

Si lo que queremos es hacer una instalación sólo con la parte de servidor y, además, tener la posibilidad de conectarnos usando un navegador como cliente, instalaríamos lo siguiente:

sudo yum install sqlite nmap libopenvas4 libmicrohttpd10  openvas-scanner openvas-manager openvas-administrator  greenbone-security-assistant

Si queremos instalar sólo el cliente en línea de comandos:

sudo yum install libopenvas4 openvas-cli

Y, por último, si sólo quisieramos instalar la aplicación cliente de escritorio:

sudo yum install libopenvas4 gsd

Instalación completada. Ahora hay que poner esto en marcha. Si hemos realizado una instalación distribuida (servidor en una máquina y cliente en otra) lo primero que tenemos que hacer es unos cambios en la configuración del servidor ya que este, por defecto, arranca los servicios usado el parámetro --listen=127.0.0.1 de forma que no admite conexiones que no vengan de la propia máquina. Para corregir esto procedemos de la siguiente forma:

Si lo que queremos es poder conectarnos al servidor a través de un navegador web desde otra máquina, debemos de editar el fichero /etc/sysconfig/greenbone-security-assistant y localizar las siguientes líneas:

GSA_ADDRESS=127.0.0.1
...
ADMINISTRATOR_ADDRESS=127.0.0.1
...
MANAGER_ADDRESS=127.0.0.1

En el fichero original no aparecen todas así una debajo de otra ¿eh? ;-) Bien, pues lo único que tenemos que hacer es sustituir el 127.0.0.1 por la ip real de la máquina que actúa como servidor.

Si lo que queremos es usar el cliente de escritorio gsd desde otra máquina, el fichero que debemos de editar es /etc/sysconfig/openvas-manager. Localizamos ahora la siguiente línea y hacemos la misma operación que hemos descrito antes:

MANAGER_ADDRESS=127.0.0.1

¿Continuamos? Lo siguiente (aún en el servidor) sería añadir un primer usuario con privilegio de administrador (cualquiera de los clientes nos pedirá autenticación antes de darnos acceso). El siguiente comando nos creará un usuario llamado josemaria y nos pedirá de forma interactiva la contraseña para este:

sudo openvasad -c add_user -n josemaria -r Admin

A continuación generamos los certificados que también usaremos en la autenticación:

sudo openvas-mkcert -q
sudo openvas-mkcert-client -n om -i

Y ya casi estamos. Para quién no lo conozca, un programa como este que analiza vulnerabilidades se parece en algunos aspectos a un antivirus: alguien tiene que actualizar de forma permanente que nuevas vulnerabilidades existen y de que forma reconocerlas. Al igual que actualizamos las “firmas” de nuestro antivirus necesitamos actualizar estos patrones de reconocimiento que en OpenVAS reciben el nombre de NVT’s Es por lo tanto necesaria una sincronización periódica. El siguiente script podría servirnos para ello. Además de la sincronización realiza la activación de servicios en el orden correcto de forma que deberíamos de usarlo antes de la primera conexión y después de cada reinicio de la máquina con el servidor:

sudo openvas-nvt-sync
sudo service openvas-manager stop
sudo service openvas-scanner stop
sudo openvassd
sudo openvasmd --migrate
sudo openvasmd --rebuild
sudo service openvas-administrator stop
sudo service openvas-manager stop
sudo service openvas-scanner restart
sudo service openvas-manager start
sudo service openvas-administrator start
sudo /etc/init.d/greenbone-security-assistant restart

Y con esto está todo. Si queremos asegurarnos o posteriormente cuando lancemos un cliente tenemos algún problema, existe un pequeño script que podemos descargar desde aquí y que, ejecutado con privilegios de root, nos permite verificar si nuestra instalación está correcta o, por el contrario, nos alertaría acerca de que es lo que nos falta. Si lo ejecutamos con el parámetro --server obviaría en esta comprobación todo lo referente a la instalación del cliente.

Ahora ya podemos empezar a auditar la red. El cliente de escritorio no crea entrada en ningún menú, así que lo tenemos que ejecutar a mano (pulsando Alt+F2 o directamente desde un terminal) con el comando gsd. En las siguientes ilustraciones se ve la pantalla de conexión y la principal del programa

Login con GSD, el cliente de escritorio de OpenVAS
Pantalla principal de GSD, el cliente de escritorio de OpenVAS

Si preferimos usar el cliente web (mucho más ligero, la verdad) “apuntamos” con nuestro navegador al puerto 9392 de la máquina donde hemos instalado el servidor usando protocolo seguro https (por ejemplo https://192.168.1.217:9392 o https://localhost:9392 en caso de que lo tengamos todo en la misma máquina). A continuación tienes también los pantallazos de la ventana de login y la principal del cliente:

Login con GSA, el cliente web de OpenVAS
Pantalla principal de GSA, el cliente web de OpenVAS

ACTUALIZACIÓN: En systenadmin nos cuentan como instalarlo en una Cent.OS además de algunas notas útiles sobre el escalado de eventos y la sobreescritura de alertas para evitar falsos positivos recurrentes.

ACTUALIZACIÓN (y II): y si prefieres instalarlo en Ubuntu échale un vistazo a estas notas adicionales.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Intypedia, una enciclopedia visual de la Seguridad

Josemaría | 30 de septiembre de 2010 | Comentar

seguridad Se acaba de presentar al público Intypedia, una enciclopedia visual de la Seguridad. Se trata de un proyecto de Criptored que ofrecerá vídeos educativos sobre esta materia.

Por el momento sólo hay dos entradas: un vídeo introductorio y una primera entrega (incrustada aquí abajo) sobre la historia de la criptografía y su desarrollo en Europa, pero en las próximas entradas contará con nombres como Arturo Ribagorda de la Universidad Carlos III o Gonzalo Álvarez Marañón del CSIC (¿recordais el Criptonomicón?)


Las entregas se acompañan de ejercicios (propuestos y resueltos) lo cual facilita muchísimo el uso de este material en la enseñanza. En el correo de presentación en Una al Día reproducen una nota de prensa con mucha más información sobre este proyecto.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Autenticación en Apache (y II): digest y con mySQL

Josemaría | 18 de marzo de 2010 | 3 comentarios

apache Continuamos hoy con otros dos métodos de autenticación en Apache. El primero que vamos a ver recupera los problemas de gestión de usuarios y contraseñas pero soluciona el problema de la transferencia de contraseñas en claro sin necesidad de usar SSL. Consiste en usar la autenticación mediante digest. El procedimiento, como veréis, es muy similar al visto el otro día con la autenticación básica pero cambiando algunas de las directivas y usando la utilidad htdigest en lugar de htpassword para crear el fichero de contraseñas. El módulo de autenticación necesario suele venir con Apache pero no habilitado por defecto. Para activarlo usamos la utilidad a2enmod y, a continuación reiniciamos el servidor Apache:

$ sudo a2enmod auth_digest
$ sudo /etc/init.d/apache2 restart

Luego incluimos una sección como esta en el fichero de configuración de nuestro Virtual Host:

<Directory "/var/www/miweb/privado">
     Order deny,allow
     AuthType Digest
     AuthName "dominio"
     AuthUserFile "/etc/claves/digest.txt"
     <Limit GET POST>
          Require valid-user
     </Limit>
</Directory>

Como vemos, es muy similar a la configuración necesaria en la autenticación básica. Sólo dos notas: el fichero donde se dejan las contraseñas se indicaba con la directiva AuthDigestFile hasta la versión 2.2 de apache. Ahora, como veis en el ejemplo, es AuthUserFile. Y dos: la directiva AuthName que en la autenticación básica se usaba para mostrar un mensaje en la ventana que pide el usuario y contraseña, ahora se usa también para identificar un nombre de dominio (realm) que debe de coincidir con el que aparezca después en el fichero de contraseñas. Dicho esto, vamos a generar dicho fichero con la utilidad htdigest:

# htdigest -c /etc/claves/digest.txt dominio josemaria
Adding password for josemaria in realm dominio.
New password:
Re-type new password:

Al igual que ocurría con htpassword, la opción -c (create) sólo debemos de usarla al crear el fichero con el primer usuario. Luego añadiremos los restantes usuarios prescindiendo de ella. A continuación vemos el fichero que se genera después de añadir un segundo usuario:

josemaria:dominio:8d6af4e11e38ee8b51bb775895e11e0f
gemma:dominio:dbd98f4294e2a49f62a486ec070b9b8c

El último método que vamos a ver usa una base de datos de mySQL como repositorio de contraseñas. Esto nos permitirá preparar de forma fácil unas páginas para gestionarlas por personal no experto o, incluso, permitir al propio usuario final que haga cambios por si mismo, crear algún método de recuperación automático por email, etc. Esto, combinado con un cifrado SSL, nos proporciona un método cómodo, flexible y suficientemente seguro para la mayoría de los casos. Lo primero que debemos de hacer es instalar el módulo que nos proporciona este modelo de autenticación, activarlo y reiniciar nuestro apache:

$ sudo apt-get install libapache2-mod-auth-mysql
$ sudo a2enmod auth_mysql
$ sudo /etc/init.d/apache2 restart

A continuación necesitamos crear una base de datos adecuada en el servidor mysql. Los únicos campos imprescindibles son los dos correspondientes al usuario y contraseña, tal y como se muestran en la siguiente imagen. El resto, a nuestro gusto y dependiendo de si planeamos hacer alguna página para gestionarlos y las funcionalidades que queremos que tenga (nombre completo, dirección de email, etc.)

base de datos para autenticación con Apache

Necesitaremos, además, un usuario de mySQL con acceso a estas tablas para que Apache pueda usarlo. Con concederle privilegios de lectura (SELECT) nos basta:

usuario para la autenticación

Añadimos un par de registros a nuestra base de datos para hacer pruebas:
usuarios para las pruebas de acceso

Y, por último, editamos la sección correspondiente en la configuración de nuestro Virtual Host y pedimos a apache que haga un reload de la misma:

<Directory "/var/www/miweb/privado">
     AuthType Basic
     AuthName "Zona Privada"
     AuthBasicAuthoritative Off
     AuthMYSQL on
     AuthMySQL_Authoritative on
     Auth_MySQL_Host localhost
     AuthMySQL_DB httpdauthmysql
     AuthMySQL_Password_Table usuarios
     Auth_MySQL_User apacheauth
     Auth_MySQL_Password 4pache3Sql
     AuthMySQL_Username_Field login
     AuthMySQL_Password_Field pwd
     AuthMySQL_Empty_Passwords off
     AuthMySQL_Encryption_Types Plaintext
     Require valid-user
</Directory>

El significado de los campos a personalizar para nuestra configuración es fácilmente distinguible:

El campo Auth_MySQL_Encryption_Types, por último, nos permite definir la forma en que la contraseña se guarda en nuestra base de datos y admite múltiples formas. Tal y como está en el ejemplo anterior, indicamos que la contraseña se guardará en texto plano. Si queremos hacerlo un poco más serio y no guardar la contraseña así podríamos, por ejemplo, almacenar un hash de la misma. Existen diversos métodos para esto, pero lo más sencillo es variar el valor de este campo por lo siguiente:

AuthMySQL_Encryption_Types Crypt

Esto nos permitirá usar las mismas firmas generadas por la utilidad htpasswd que vimos aquí o, en general, las creadas a partir de la llamada a la función crypt(). Copiamos el hash al campo pwd de la base de datos antes generada, volvemos a hacer un reload a nuestro apache y listo.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes