PDF de programación - DKIM

Imágen de pdf DKIM

DKIMgráfica de visualizaciones

Publicado el 15 de Junio del 2021
226 visualizaciones desde el 15 de Junio del 2021
352,9 KB
11 paginas
Creado hace 13a (15/12/2010)
DKIM

Esta son las pruebas de implementación de DKIM que he seguido en un servidor de
pruebas con SuSE Linux, Amavis y SpamAssassin.

Se trata de un caso muy particular, aplicado a nuestro servidor para unos requerimientos
mucho menores de lo que probablemente habrá en instituciones realmente grandes,
como las Universidades. Pero, si puede servir de guía para alguien que lo quiera
implementar, sería suficiente.


1. Introducción

Más o menos todos sabemos lo que es DKIM. Brevemente, es un sistema de
autenticación que permite verificar que el correo llega realmente de quien dice ser el
remitente. La idea es similar a la del conocido SPF. En éste caso, lo que comprobamos
es que el servidor desde donde proviene el correo está autorizado para enviar correo del
dominio desde donde llega. DKIM persigue un objetivo similar, pero de forma
diferente. Se utiliza un sistema de criptografía asimétrica y funciones de hash. Al igual
que SPF, utiliza el DNS para su propósito. Pero en este caso, lo que DKIM hace es
publicar mediante el DNS su clave pública para que servidores remotos puedan verificar
los correos firmados con la clave privada.

De esta forma, el servidor remitente calcula un hash utilizando el cuerpo del mensaje y
alguna de sus cabeceras y lo cifra mediante la clave privada. Cualquier servidor remoto
que quiera verificar el correo, necesitará de la clave pública obtenida a través del DNS
del dominio de origen.

Como ventajas frente a SPF tiene el hecho de evitar los problemas de los fordward, ya
que no se mira quién nos entrega el mensaje, sino quién lo originó. Sin embargo, sí es
sensible a las modificaciones que pueda sufrir el mensaje durante su transmisión (por
ejemplo con disclaimers posteriores a la firma)


2. Pasos previos a la implementación

La forma que hemos utilizado en nuestro caso ha sido mediante Amavis y Postfix. Para
la verificación de firmas que nos llegan, utilizaremos SpamAssassin. Para éste último,
nos va a ser necesario tener instalado perl-Mail-DKIM (así es como se llama en SuSE
y puede ser instalado desde YaST, pero en otras versiones de linux, el paquete es
libmail-dkim-perl). Igualmente, necesitamos habilitar el plugin en SpamAssassin:
Mail::SpamAssassin::Plugin::DKIM, comentando la línea que hace referencia al
mismo en el fichero /etc/mail/spamassassin/v312.pre (en otras distribuciones, el
fichero puede estar en caminos diferente, como /etc/spamassassin/v312.pre). Supongo
que cada uno deberá buscar estos requerimientos adecuados a sus distribuciones e
instalaciones propias.



3. Breve vistazo al funcionamiento de Postfix

Un esquema muy básico de cómo actúa Postfix al recibir un correo es el que sigue:



Los cuadros blancos representan programas y servicios, mientras que los oscuros son
las colas. Cuando decimos que algo viene de la red, es cualquier correo que entra en el
servidor desde la red. Es decir, si el relay de una máquina de nuestra propia red es el
servidor, enviará todos los correos a dicho servidor y este los verá como provinientes de
la red. Solo los correos generados en el propio servidor, serán locales.

3.a Los correos que llegan desde la Red

En /etc/postfix/master.cf esto se puede controlar muy bien. Las líneas implicadas, en
nuestro caso, son:

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
#
submission inet n



#
#-----------------------------------------------------------------------------
#
smtps



#
#-----------------------------------------------------------------------------
#
smtp
#


inet n
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_auth_only=yes
-o smtpd_tls_wrappermode=yes

-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_enforce_tls=yes

10

smtpd

10

smtpd

10

smtpd

-

n

inet n

-

n

-



-

-

n

-



Si nos fijamos, veremos que tenemos los 3 tipos posibles de entradas: submission,
smtps y smtp, los tres relacionados con el servicio smtpd que es el que se encarga de
entregar el correo. Esto significa que dependiendo del puerto al que enviemos el correo,
usaremos submission (587), smtps (465) o smtp (25). Esto es lo que configuramos en
los clientes, diciendo que utilizaremos el servidor ‘fulanito’ para smtp por el puerto 465
(smtps por ejemplo). Para usar los dos primeros (submission y smtps) es necesario estar
autentificado, es decir, tener una cuenta válida, estar dado de alta en sasl_senders y
configurar correctamente el cliente. De esta forma, cualquier cuenta válida puede
autentificarse y siempre entrará en caserv por submission o smtps. Sin embargo, un
correo que venga del exterior (desde alguien que no tenga cuenta en Calar Alto o no esté
autentificado y usando un puerto seguro en su cliente), siempre lo hará por la tercera
opción, es decir, por el smtp, puerto 25.

3.b Correos considerados Locales

En este caso es un correo originado directamente en el propio servidor. No utilizará el
servicio smtpd. Esto solo se aplica a correos originados en el propio servidor de correo


4. Amavis

El Amavis funciona en base a puertos. Por unos puertos recibe información (el correo) y
por otros manda la respuesta (una vez aplicados spam, anti-virus y firmas). El puerto
por el que hacemos escuchar a Amavis es el 10024 y la información retornada
aparecerá en el puerto 10025. En nuestro caso, hasta la fecha, esto ha sido así, tanto si
recibíamos o enviábamos un correo (independientemente de por dónde se recibiese en
Postfix el correo). No se hacía discriminación alguna del lugar de procedencia del
correo. Para analizar todos los correos, se utilizaba la siguiente entrada en el otro fichero
de configuración de Postfix, /etc/postfix/main.cf:



De esta forma, todos los correos, de red o locales, eran analizados. En el fichero
/etc/postfix/master.cf se configuraba el puerto de escucha de la respuesta de amavis:



content_filter = smtp-amavis:[127.0.0.1]:10024

# Escucha en el 10025 la respuesta del Filtro-Amavis
150.214.222.160:10025 inet n - n - - smtpd -o content_filter=
#
# Llamada al filtro - Amavis (a traves del 100024)
smtp-amavis unix - - n - 15 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes


Finalmente, en el fichero de configuración de Amavis: /etc/amavisd.conf definíamos
que amavis solo escuchaba en el puerto 10024 y no definíamos ningún tipo de acción
asociada a ese puerto, para que amavis realizase las que son por defecto: anti-spam y
anti-virus.


$inet_socket_port = 10024; # Puerto en el que escucha Amavis



5. Implementación de DKIM

El problema fundamental que nos encontramos con el planteamiento de más arriba es
que todos los correos pasan a Amavis directamente, tanto los que vienen desde el
exterior como los nuestros. Y una vez en amavis, se realizan las funciones por defecto.
Esto lo podemos ver en la siguiente figura:



$inet_socket_port = [10024,10026]; # Escuchamos en dos puertos



Por supuesto, a las funciones de anti-virus y anti-spam de amvis, podríamos añadir que
se firmasen los correos, pero con la estructura de más arriba, se firmarían tanto los
nuestros como los que lleguen del exterior. Y esto no es lo que queremos.

Afortunadamente, en Amavis podemos definir otros puertos que escuchen y realicen
acciones alternativas. Para ello cambiamos la línea del fichero de configuración de
amavis, /etc/amavisd.conf, por:



Lo que queremos es diferenciar entre correos que lleguen autentificados (nuestros)
y correos que vengan de fuera o no autentificados. Estos últimos pueden ser nuestros
también y se pueden dar si no configuramos bien el cliente de correo o decidimos usar
expresamente el puerto 25 en vez de uno seguro. Y una vez diferenciados, mandar por
el puerto 10024 (los no autentificados) y por el 10026 (los autentificados). En cualquier
caso, la respuesta de Amavis siembre volverá al 10025.

La forma de diferenciar desde dónde nos van a llegar los correos es mediante los
puertos submission, smtps y smtp. Lo que necesitamos es hacer un par de
modificaciones en Postfix. La primera es en el fichero /etc/postfix/master.cf para
decir qué acción seguirá amavis (a qué puerto enviarle el correo) dependiendo desde
donde le llegue el correo al Postfix:







-

n

-



n

-

n

10

smtpd

10

smtpd

-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_enforce_tls=yes
-o content_filter=smtp-amavis:[127.0.0.1]:10026

-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_auth_only=yes
-o smtpd_tls_wrappermode=yes
-o content_filter=smtp-amavis:[127.0.0.1]:10026

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
#
submission inet n -



#
  • Links de descarga
http://lwp-l.com/pdf19315

Comentarios de: DKIM (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad