Ya he tenido que hacerlo en tres instalaciones: una en mi lugar de trabajo, otra en mis servidores personales y otra en los de una amiga.
Etiqueta: Debian
Empaquetando Java de Oracle para Debian
Algo que la gente de Debian ya tiene resuelto en cierta medida y que anoto aquí para futuras referencias.
apt-dater: actualizaciones múltiples …
… con todo lo que eso conlleva.
Certificados Let’s Encrypt en más de un servidor …
… vaya problema tonto con el que no contaba.
Probando conversores de texto a HTML …
… en Debian, ya que estoy pensando en crear una impresora virtual para obtener versiones HTML de los listados de la empresa.
mydevtools: un pequeño paquete con herramientas …
… valiosas para escribir otros programas y crear paquetes Debian ya puestos.
Servidor de correo electrónico en Debian
Aunque el servidor no vaya a gestionar buzones de correo electrónico considero que es valioso que sea capaz de enviar y recibir mensajes sin necesitar una pasarela con sus credenciales.
Esto es especialmente cierto ya que suelo centralizar la cuenta del administrador para todas mis máquinas en una cuenta externa, y me gusta que no tengan problemas a la hora de enviarme avisos. Es un rollo tener que consultar varios buzones locales para saber qué ha ocurrido.
Así pues, quiero que cada máquina pueda enviar correo al exterior y necesito reducir las posibilidades de que le ignoren (marcándolo como spam) o directamente le denieguen el acceso.
Para ello el servidor tiene que cumplir una serie de requisitos:
- Registros MX apuntando al nombre completo del servidor.
- Dirección IP apuntando a nombre completo del servidor (resolución inversa).
- SPF activo en el registro DNS (también importante si se emplean Google Apps).
- DKIM activo en el servidor de correo (exim) y en el DNS.
- DMARK rematando ambos mecanismo ya que presentan algún fleco por el que podrían ser inutilizados.
Steve Kemp tiene varios artículos al respecto. Como resumen podemos afirmar que todos requieren cambios en el DNS y la implicación del servicio de correo.
SPF
Ya hay excelentes explicaciones de cómo funciona el invento así que no me voy a extender en ello. Si escribo ésto es para anotar detalles técnicos a los que tendré que recurrir una y otra vez en el futuro.
- Crear un registro de texto en el DNS de mi dominio indicando qué máquinas están autorizadas a enviar correo desde él.
- Indicar al servidor de correo (exim4) que emplee la verificación SPF cuando reciba correo.
En este dominio el registro SPF queda así:
v=spf1 mx a ip4:46.101.91.82/32 -all
donde indico que sólo los servidores definidos en el registro MX pueden enviar correo en su nombre, concretamente señalo la dirección IP, e indico que los correos tienen que rechazarse si no cumplen alguna de éstas condiciones (-all). Se puede consultar la síntaxis aquí.
Una vez tengamos la definición es recomendable crear dos registro en el DNS del dominio: uno de tipo SPF y otro de tipo TXT. Por lo visto no todos los clientes consultan el primero y es algo que no cuesta.
Respecto a exim4 sólo tenemos que preocuparnos de la recepción del correo y para ello vamos a indicar que emplee SPF
- Asegurarnos de tener instalada la versión exim4-daemon-heavy.
- Instalar el paquete spf-tools-perl.
- Activar la comprobación vía CHECK_RCPT_SPF=true en el archivo /etc/exim4/conf/main/00_local_macros y reiniciar.
Si el registro SPF hubiese contenido una política de fallo blando (~all)los mensajes recibidos serían aceptados pero se incluiría un aviso en forma de cabecera especial
Received-SPF: softfail client-ip=...
que podría ser utilizada por posteriores filtros de spam. En este caso concreto prefiero que dichos correos sean rechazados durante la conexión (parámetro -all) como el fragmento de conexión que muestro a continuación:
MAIL FROM:<root@esferas.org> 250 OK RCPT TO:<root@esferas.org> ** 550-[SPF] 79.148.243.240 is not allowed to send mail from esferas.org. Please ** 550 see http://www.openspf.org/Why?scope=mfrom;identity=root@esferas.org;ip=79.148.243.240
DKIM
Este mecanismo consiste en emplear un par de claves criptográficas, una pública y otra privada, y publicar la primera, la pública, en el registro DNS. El servidor de correo firmará con la clave privada los mensajes salientes y el receptor del mismo podrá, tras consultar el registro DNS correspondiente, verificar la autenticidad del mismo.
Los pasos a seguir son los siguientes:
- Crear un par de claves criptográficas empleando openssh. La única precaución a tomar es la longitud de la clave. Proveedores como gandi.net no admiten más de 1024 bits.
- Elegir una palabra clave como selector dado que en un mismo dominio pueden coexistir varios registros TXT. Este selector tendrá que incluirse en el DNS y en el servidor de correo que emplea el mecanismo.
Enlaces y referencias
- SPF:
- Constructor de registros SPF: http://www.spfwizard.net/es/
- Testeo de configuración SPF: http://www.kitterman.com/spf/validate.html
- DKIM:
- Configuración de exim4:http://www.iodigitalsec.com/exim-dkim-and-debian-configuration/
- Otro artículo pero en español: http://dajul.com/2010/01/22/firmar-correos-con-dkim-y-exim4/
- Verificar DKIM en el registro DNS: http://www.protodave.com/tools/dkim-key-checker/
- Emplear Perl para configurar DKIM: http://www.pal-blog.de/entwicklung/dkim/setting-up-DKIM-with-Perl.html
Enviando correo hacia el exterior …
bds – backup de sistema …
… que no es lo más original del mundo como nombre pero me estoy acostumbrando a los términos cortos. Funcionan mejor con mi memoria.
Copias de seguridad con attic
Tras haberlo visto mencionado en Planet Debian me he decidido a echarle un vistazo al programa attic para emplearlo como sistema principal de copias de seguridad de servidores autónomos de Debian.