Chuletillas (y XXXIX) – Instalar VirtualBox en Manjaro (u otro derivado de ArchLinux)

Josemaría | 8 de abril de 2014 | 1 comentario

chuleta Los derivados de ArchLinux (Manjaro, Chakra, etc.) suelen ser bastante más fáciles de manejar que la distribución matriz, pero aún así no es nada anormal que la instalación de ciertos paquetes sea ligeramente más dificultosa de lo que estamos acostumbrados en un Linux de escritorio y que requieran de nosotros alguna que otra intervención manual más allá de un simple pacman -S. Virtualbox es uno de estos casos y, aunque todas las posibles situaciones están perfectamente explicadas en esta página de la wiki de ArchLinux, vamos a dejar aquí una chuleta que debería de funcionar en la gran mayoría de los casos.

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

7 enlaces 7 (y LVII)

Josemaría | 7 de abril de 2014 | 1 comentario

enlaces rápidos

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: enlaces rápidos
Etiquetas:

Series, series y más series… (y II)

Josemaría | 4 de abril de 2014 | 1 comentario

icono televisiónSegunda entrega del “coleccionable” que empezamos por aquí dedicado a recomendar o a desaconsejar series para adictos al género o papás y mamás sin más de 45 minutos al día. Recordad la única norma: sólo valen series que lleven por el momento una única temporada. ¡Y empezamos!

Almost HumanAlmost Human. La pareja protagonista son un poli chulazo y bruto pero con buenos sentimientos y un remilgado y obsoleto androide que le han asignado como pareja. Así dicho no resulta demasiado atractivo, ya, pero los casos a los que se enfrentan suelen ser interesantes, el futuro que describen inquietante y al final la serie funciona. No he terminado aún la primera temporada pero por el momento no me aburro…

Under the DomeUnder the dome. Un buen día en un (aparentemente) aburrido y tranquilo pueblito de la america rural aparece una especie de burbuja transparente e infranqueable que lo rodea por completo y para la que nadie, ni dentro ni fuera de ella, parece tener explicación. A partir de ahí empezamos a ver que el pueblito no es tan aburrido como parece y que todos allí tiene un pasado. Algunos hasta media docena. Aburrida hasta límites insospechados, con unos personajes tan poco bien perfilados que casi resultan cómicos y una trama tan ridícula que al final ya te da igual de donde haya salido la maldita cúpula y si se mueren todos de lo que sea. Por increíble que parezca han aprobado una segunda temporada… Evitadla, please.

Orphan BlackOrphan Black. Una huérfana canalla y barriobajera se encuentra por casualidad en un metro de New York con la que parece ser su gemela justo en el momento en que se tira bajo las ruedas de un tren. Roba sus pertenencias, la suplanta, y descubre que se trata de una acomodada poli… y que hay bastantes más gemelas iguales a ellas dos. De lo más interesante que vi el año pasado, la verdad. Y si te das prisa aún estás a tiempo de pillar la segunda temporada (que empieza el próximo 19 de abril) desde el principio.

NashvilleNashville. Los personajes recuerdan bastantea a los de series míticas de los años 80 como Dallas o Dinastía y eso la hace divertida. La música, además, es bastante buena si te gusta el country y el bluegrass… Al final, en cualquier caso, decidí suscribirme a las listas de temas de Spotify (aquí y aquí) y abandonarla…

NOTA: La segunda temporada está ahora mismo a medias pero cuando yo la probé cumplía con la norma ¿eh?


The Michael J. Fox ShowThe Michael J. Fox Show.
Serie cancelada antes de terminar su primera temporada, así que no os hagáis mucha ilusión con ella. El título ya recuerda a series de otros tiempos, al estilo de el show de Bill Cosby y similares. Más moderna, claro y con un punto de irreverencia que huele a falsa a grandes distancias… pero aún así siento mucho que el retorno del señor Fox haya sido tan terriblemente malo. A la próxima.


Agents of SHIELDAgents of SHIELD.
Sin ser nada del otro mundo, ha mejorado bastante desde unos primeros capítulos ñoños que hacían temer algo enfocado a adolescentes parecido a Smallville o Arrow a… algo un poco menos ñoño :-P . Lo mejor: ese episodio donde un desertor asgardiano vive oculto como profesor en la Universidad de Sevilla (con exteriores reales rodados en esta ciudad). Doy fé de que si fuese real podría pasar totalmente inadvertido :-D

The BlacklistThe Blacklist. Predecible en casi todo, pero violenta y sin concesiones y eso (y poco más) hace que sea entretenida de seguir. Aún así, hay algo que funciona y me estoy tragando la primera temporada completita…


True DetectiveTrue Detective.
Se han dicho tantas cosas de esta serie (algunas tan extremadamente ridículas que la elevan casi a lo mejor que se ha hecho en toda la historia de la televisión) que yo paso de hacer juicios que luego me llueven piedras. Es buena y tiene personajes fabulosos, bien construidos y mejor interpretados. Sobra, quizás, un poco de misticismo cristiano y se agradecen las incontables referencias que hacen a toda la mitología creada por el círculo de Lovecraft y la recreación de esa América profunda irracionalmente religiosa que tanto morbo nos provoca a algunos. Hay que verla, si, pero sin volvernos locos ¿eh?

House of Cards BBC 1990House of Cards (1990). Si te está gustando la nueva versión de la serie de igual nombre producida por Netflix, merece la pena que le eches un vistazo a esta miniserie de cuatro episodios de la BBC en la que está inspirada. Es bastante más inocente y menos agresiva que su remake. También tiene un aire bastante más cómico a ratos y se nota mucho más viejúna como es lógico, pero la he disfrutado bastante.

Believe Believe. La serie va de una niña con poderes paranormales que está siendo perseguida por dos grupos diferentes: uno con contactos gubernamentales que la quiere para experimentar con ella con fines armamentísticos y otro que pretende protegerla de los primeros. A pesar de lo visto y simple del planteamiento, llegaba apadrinada por Alfonso Cuarón, así que parecía que había que darle una oportunidad… Y se la he dado, conste, pero apenas he podido resistir los tres primeros episodios de rigor. Es ñoña y boba hasta decir basta. Pasa de largo.

Resurrection Resurrection. Esta otra, sin embargo, venía precedida por la etiqueta de ser el nuevo Lost y eso era ya suficiente motivo para evitarla… y sin embargo he picado con los tres primeros capítulos y diría que más que Lost me parece un sucedáneo de Under the Dome. E igual de mala que ella. Vamos que me planto aquí y me trae sin cuidado para que y de donde vienen estos muertitos tan tristes…

Dracula Drácula.
Ni cuatro episodios he aguantado a este vampiro megalómano y empeñado en invertir en la invención de una especie de fuente energética inalámbrica. ¿Puede haber algo más ridículo que una criatura de la oscuridad que promueve la invención de una fuente de energía para proporcionar luz artificial? Pues así toda…

Cosmos 2014 Cosmos: A Space-Time Odyssey. No se si se puede considerarse como una serie (imagino que si, aunque sea una serie documental y no de ficción ¿verdad?), pero aún así la dejo por aquí por si no te has enterado de que se está emitiendo una nueva versión de los clásicos documentales que hicieron mundialmente popular a Carl Sagan en los años 80 y que merece la pena verlos.

SERIES DE ÚLTIMA HORA: The Red Road, una más de Montescos y Capuletos en una comunidad india estadounidense con líos de droga de por medio, y Soufthcliffe, una miniserie británica con muy buena pinta de la que se tan poco como aparece en su ficha de IMDB, son dos recomendaciones de última hora que aún no he podido empezar a ver. Ya os contaré en otra entrega…
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: culturales, televisión
Etiquetas: ,

Inspeccionando la cola de correos sin entregar en Postfix

Josemaría | 25 de marzo de 2014 | 5 comentarios

correo No suele ser habitual que postfix encole y/o retrase la entrega de correos electrónicos. Pero a veces ocurre. Por ejemplo por problemas de time-out con el servidor al que tiene que hacer la entrega. Si monitorizamos las colas de nuestro servidor (por ejemplo con munin) podemos observar cuando pasa y con que frecuencia:

Cola de mensajes retrasados (deferred) en postfix

Por defecto se reintenta la entrega de los correos cada 5 minutos y se descartan (generando un correo de advertencia al remitente) si no ha podido hacerse transcurridos cinco días del envío. Podemos variar estos valores introduciendo los siguientes parámetros en el fichero de configuración principal (/etc/postfix/main.cf):

queue_run_delay = 600
maximal_queue_lifetime = 1d

Existen más parámetros relacionados con esta directiva en este enlace del manual de postfix.

Podemos inspeccionar la cola de postfix para ver que mensajes no ha podido entregar y la causa de ello en cualquier momento usando los comandos mailq o postqueue -p (ambos son equivalentes y proporcionan la misma salida aunque mailq es un comando mucho más flexible y potente con más opciones. Consulta el manual ;-) )

Viendo el contenido de la cola de mensajes retrasados (deferred) en postfix

¿Ves el código alfanumérico de 10 caracteres con que empieza cada entrada de la cola? Es el identificador del mensaje que nos permite ver mucha más información acerca del mismo, su estado y su contenido usando el comando postcat -vq seguido de dicho identificador. Por ejemplo, para inspeccionar el primer mensaje de la cola de aquí arriba:

postcat -vq A3C3486137

También podemos decirle en cualquier momento a postfix que reprocese esos mensajes mediante los comandos postqueue -f o postfix flush. O podemos pedirle que reintente sólo uno de los mensajes de la cola usando el identificador que ya conocemos así:

postqueue -i A3C3486137

Por último, para eliminar todos los mensajes en espera de entrega que están en la cola podemos usar el siguiente comando:

postsuper -d ALL deferred

Ten en cuenta que, en este caso, los mensajes serán eliminados sin que el remitente reciba ningún tipo de notificación de que no ha podido realizarse la entrega.

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

Optimizar la velocidad de carga de WordPress (para tener contento a Google)

Josemaría | 20 de marzo de 2014 | 2 comentarios

icono de wordpress Desde hace ya algunos años, uno de los factores que Google valora a la hora de establecer el ranking de una web es la velocidad de carga de sus páginas. Este es el anuncio oficial que hicieron en el 2010 justificándo esta decisión y esta la página de información y recursos que proporcionan en la actualidad donde tenemos una herramienta que mide los tiempos de descarga de nuestra página y hace recomendaciones para mejorarlos

Existen multitud de buenos recursos en la web sobre este tema. A mi me gustaría destacar dos: las páginas de Exceptional Performance de Yahoo! (un clásico) y esta otra guía más reciente y mucho más centrada en satisfacer las exigencias de Google.

Yo, sinceramente, nunca me he preocupado mucho de estas cosas. Entendedme: me gusta que mis webs se carguen tan rápido como sea posible, pero no hasta el extremo de querer rebajar 100 milisegundos arañando tiempos de aquí y de allá. No obstante, hace unas semanas y más por “deporte” que por otra cosa me propuse jugar un poco con estas recomendaciones y pasé de una valoración de setenta y pocos puntos al 98/100 que veis bajo estas líneas. Os cuento como lo hice y os doy algunas recomendaciones por si os apetece jugar a lo mismo ;-)

Resultados obtenidos con Google Page Speed Insights

Lo primero que tienes que hacer es conocer bien como carga tu wordpress, ver como se distribuyen los tiempos y cuales son los principales cuellos de botella. En los enlaces anteriores ya hay referencias a algunas herramientas útiles para esto. Si queréis más, podéis probar con las siguientes:

Estas herramientas nos servirán, además, para verificar que lo estamos haciendo bien y que los cambios que hacemos no son contraproducentes.

El primer punto a vigilar es el tema y los plugins que usas en tu wordpress. Un tema limpio, sin errores y que no esté sobrecargado de estilos, imágenes y javascript mejora notablemente la velocidad de carga. Haz la prueba, si no, cambiando del tuyo a alguno de los más simples que WordPress trae por defecto. Idem con los plugins. Hay algunos que son verdaderos parásitos. Desactívalos todos, comprueba los tiempos que obtienes y, luego, ve activándolos uno a uno probando de nuevo para ver cuales son los más problemáticos. Valora si puedes vivir sin estos o busca sustituirlos por otros equivalentes pero más eficientes.

Piensa, además, que el contenido que incluyas también cuenta. Todos los objetos que incrustes (Youtube, Vimeo, etc.) van a ser valorados en la carga de tu página. En estos momentos, por ejemplo, la valoración que hace Google de mi portada baja del 98 que veis arriba a un 92 por culpa del objeto de Scribd que he incrustado un par de posts más abajo. Las imágenes también cuentan bastante. Usar miniaturas (thumbnails) que requieran de un click para verlas en alta calidad es una buena práctica. Si, como a mi, no te agrada, puedes usar alguna herramienta para optimizarlas antes de subirlas a tu servidor web. Mis favoritas son optipng y jpegoptim. Si, si, para Linux y en línea de comando. Si buscas otra cosa no se que haces por estas páginas ;-) Usa la opción --strip-all con jpegoptim.

Vamos ahora a cargar nuestro blog con una de las herramientas que hemos visto antes y a observar lo que ocurre. Por ejemplo usando Web Page Test:

Resultados obtenidos con Web Page Test

Como puedes ver, uno de los grandes devoradores de tiempo en las páginas de wordpress (y en general con todas las que usan PHP) es el llamado Time to First Byte o TTFB. Se trata del tiempo que transcurre entre que el servidor web recibe la petición de un cliente y el navegador de este recibe el primer byte y, básicamente, se consume sobre todo en procesar el código PHP. La mejor forma de reducirlo al máximo es usar alguna de las muchas cachés para wordpress que convierten tus páginas PHP a contenido estático. Yo uso W3TC habilitando sólo las opciones de caché de páginas y de objetos (para el resto de optimizaciones uso otros plugins) y sólo con esto podrás comprobar que los resultados mejoran sorprendentemente.

Resultados obtenidos con Web Page Test

Utilizar una caché para las consultas a la base de datos también ayuda un poco. W3TC incluye también esta característica, pero yo prefiero usar otro: DB Cache Reloaded Fix.

Incluye cabeceras de expiración para informar a los navegadores de por cuanto tiempo pueden cachear los contenidos estáticos de tu página (imágenes, css, etc.). Para ello lo primero que tienes que hacer es asegurarte que tu apache tiene activado el modulo mod_expires. Luego, en el fichero de definición del Virtual Host o, en su defecto, en el fichero .htaccess tienes que escribir las directivas correspondientes que pueden ser generales o específicas por tipo de archivo. En el anterior enlace a las páginas de apache tienes instrucciones de como hacerlo. Te copio aquí las mías:

ExpiresActive On
ExpiresByType image/gif "access plus 6 months"
ExpiresByType image/jpg "access plus 6 months"
ExpiresByType image/jpeg "access plus 6 months"
ExpiresByType image/png "access plus 6 months"
ExpiresByType image/x-icon "access plus 6 months"
ExpiresByType image/ico "access plus 6 months"
ExpiresByType application/javascript "now plus 1 month"
ExpiresByType application/x-javascript "now plus 1 month"
ExpiresByType text/javascript "now plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresDefault "access plus 1 month"

Optimiza y minimiza el tamaño de los archivos HTML, CSS y Javascript. De nuevo, si lo prefieres puedes activar estas características en el plugin de W3TC pero yo uso otro para esto: Autoptimize. El “truco” consiste en eliminar de estos ficheros cualquier espacio, salto de línea o comentario superfluo y combinarlos en un único archivo, de tal forma que reducimos el número de “requests” al servidor y el tamaño de las mismas.

Estos son los factores más generales a tener en cuenta, pero existen muchos otros particulares de cada caso que tendrás que estudiar usando las herramientas que te recomiendo por aquí y observando cuales son los cuellos de botella de tu instalación particular. Suerte con ello ;-)

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: google, wordpress
Etiquetas: , ,

7 enlaces 7 (y LVI)

Josemaría | 7 de marzo de 2014 | 1 comentario

enlaces rápidos

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: enlaces rápidos
Etiquetas:

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

Manual de HTML, CSS (y algo de Javascript)

Josemaría | 17 de febrero de 2014 | 6 comentarios

lenguajes Recopilación ordenada de apuntes de diferentes módulos (Lenguajes de marcas, Implementación de aplicaciones web, etc.) que, unidos, constituyen un completo manual de casi 130 páginas, válido tanto para quien quiera iniciarse en la realización de páginas web como para quien desee aprender algunos trucos avanzados (transpariencias, contorneos, menús, solapas, etc) o quiera empezar a manejar alguna de las nuevas características de HTML5 (canvas, geolocalización, etc.).

El manual se complementa con todos los ejemplos que se se citan en él y alguno más y que pueden descargarse integramente desde aquí.

Descargar “HTML & CSS”

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

El (complicado) mundo de los derechos en la era de Internet

Josemaría | 15 de febrero de 2014 | 2 comentarios

Opinión Ayer viernes almorzamos mientras que nos enterábamos que en el consejo de ministros se había aprobado el proyecto de la nueva ley de propiedad intelectual que, de seguir adelante, obligará a los buscadores y agregadores de noticias a pagar a los medios que enlazan. Como siempre, se ha armado un revuelto terrible entre opinadores, “gurús” y gente bien o mal intencionada que se deja llevar por los anteriores. Se acusa al gobierno de no entender como funciona Internet (lo cual es verdad) y volvemos a resucitar de nuevo los mismos tópicos enarbolados en defensa de “nuestros derechos” a prestarnos copias de material audiovisual a través de la red (derechos de los que, todo hay que decirlo, yo abuso bastante a menudo).

A mi me gustaría vivir en un mundo ideal y perfecto en el que todos tuviéramos derecho y acceso gratuito a lo indispensable. Cultura incluida. Pero ese mundo, por desgracia, no existe y mientras que lo inventamos (si llegamos a ello) tal vez merezca la pena tener en cuenta que defender la libertad implica también que un creador (o una empresa) es también libre de no querer regalar su trabajo. Y el hecho de que impedirlo sea difícil (o casi imposible) no lo hace menos injusto. ¿Que la medida perjudicará a los medios que recibirán menos visitas?¿Que realmente les sale rentable y se benefician de las visitas que reciben a través de los agregadores y buscadores? Bien, veámoslo y dejémoslos que se estrellen. También son libres de equivocarse ¿no?

No quiero que nadie me malinterprete con esto: yo soy un defensor a ultranza desde hace años de la cultura libre, pero no debería de ser algo que funcione por imposición. Quien no esté convencido, creo, no tiene porqué participar de ello.

ACTUALIZACIÓN: Nada que objetar, por otro lado, a la respuesta de María González, directora jurídica de Google España, en esta entrevista:

“Todos los editores y las páginas web en general pueden elegir estar en Google News o no, pueden establecer los protocolos de exclusión que son estándares en la industria, los ‘robots.txt’, y dar instrucciones a Google News para que Google News no les indexe. Nosotros nunca vamos a indexar noticias que el editor no quiera que se indexen. Es un tema voluntario. Si no quieres estar en Google News, no tienes por qué estar.”

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