Habilitar y configurar SPF en IMSVA

Sender Policy Framework es un protocolo alterno a SMTP que pretende ayudar a que un atacante haga mal uso de un dominio que no le pertenece o para el cual no está autorizado. El protocolo es explicado en detalle en nuestro libro Fundamentos e implementación de los protocolos SPF y Sender-ID.

A partir de la versión 8.2, IMSVA incorpora esta tecnología de forma nativa en su MTA Postfix para que las organizaciones protegidas con la tecnología de Trend Micro puedan hacer uso de ella. En versiones anteriores no era posible activarla ya que faltaban librerías de Postfix que Trend Micro no incluía en el paquete con que viene IMSVA y su instalación podría incurrir en la perdida de soporte por parte del fabricante.

NOTA: IMSVA habilita SPF en el Postfix que incluye como MTA, por lo que este procedimiento es igualmente válido para servidores de correo Postfix.

Cabe aclarar que a pesar de que las versiones de IMSVA 8.2 y 8.5 cuentan con las librerías para habilitar SPF, la documentación oficial de Trend Micro no hace mención a este procedimiento por lo que si se quiere una postura oficial sobre si Trend Micro da soporte oficial a este protocolo se debe consultar directamente al fabricante o distribuidor autorizado. También cabe aclarar que debido a lo anterior las instrucciones presentadas aquí se presentan como son y su implementación corre bajo su propia responsabilidad.

Para habilitar el uso de SPF en IMSVA se deben seguir los siguientes pasos. El primero de ellos es encontrar las siguientes líneas y eliminar el caracter “#” para que las líneas queden activas. Esto es en el archivo /opt/trend/imss/postfix/etc/postfix/main.cf.

smtpd_sender_restrictions =
 check_policy_service  unix:private/SPFPolicyd
SPFPolicyd_time_limit = 3600

El segundo paso es encontrar las siguientes líneas y eliminar el caracter “#” para que las líneas queden activas. Esto es en el archivo /opt/trend/imss/postfix/etc/postfix/master.cf.

SPFPolicyd   unix   -      n      n      -      0      spawn
      user=imss  argv=/opt/trend/imss/postfix/etc/postfix/SPFPolicyd/SPFPolicyd.py

Como último paso reiniciamos postfix. Tome en cuenta que el comando “postfix reload” no es suficiente para aplicar este cambio porque se modificó el archivo master.cf que incluye la definición de los demonios así que debemos ejecutar “postfix restart”.

[root@tmims8201 log]# postfix restart
Restarting Postfix
Stopping Postfix                                           [  OK  ]
Starting Postfix                                           [  OK  ]

Estos pasos dejan configurado a IMSVA para que pueda utilizar el protocolo SPF en todas las conexiones que recibe. Para comprobar su funcionamiento basta con establecer una conexión y tratar de utilizar un dominio que tenga su registro SPF público como facebook.com. El resultado se muestra en la siguiente Figura.

spf1Validación de SPF en IMSVA 8.2

La validación de SPF, como podemos observar en esta imagen, se realiza al momento de enviar el comando MAIL FROM. El error obtenido es:

550 5.7.1 <asdf@facebook.com>: Sender address rejected: 
Service unavailable; SPF check failed and transaction closed due 
to the organization’s policy.

El dominio del buzón se utiliza como argumento para realizar el query por el registro TXT de ese dominio como se ve en la primer petición DNS en la captura de paquetes de Wireshark. Adicional a esa consulta vemos que también se solicita el registro MX de facebook.com y el registro A del servidor de correo smtpin.mx.facebook.com. Esto se debe a la estructura del registro SPF de este dominio:

spf2 Registro SPF del dominio facebook.com

En primer lugar observe que el registro SPF nos re direcciona al subdominio: _spf.facebook.com por lo que es necesario en este caso hacer un segundo query para encontrar la definición de las direcciones IP (este segundo query no se muestra en la pantalla anterior de Wireshark). Si observamos el registro SPF veremos que además de definir varios rangos de IP’s también agrega el registro MX y es por eso que vemos las dos consultas adicionales. Además observamos que el registro SPF termina con la sentencia “-all” lo que indica que cualquier IP que no se encuentre dentro de las listadas no está autorizada a enviar correo a nombre de facebook.com. Este tipo de configuración es la ideal para proteger los dominios cuando se usa SPF ya que hay varios dominios que utilizan el mecanismo “~” el cual no evita que otros hagan uso de su dominio como lo demuestran los siguientes ejemplos:

spf3 Registros SPF de google.com y hotmail.com

Debido a este tipo de definiciones, aunque hayamos habilitado SPF, si nuestro IMSVA  recibe correo malicioso haciéndose pasar por gmail.com, este tipo de correos pasaran el filtro de SPF como lo demuestra el siguiente ejemplo:

spf4

Acciones de SPF en IMSVA 8.2

Aquí vemos que aunque el dominio gmail.com también tiene definido su registro SPF, vemos que su definición permite claramente que cualquier otra IP pueda seguir usando su dominio sin que el propio registro lo prohíba y es por eso que en los logs de /var/log/maillog (filtrado como “tail –f /var/log/maillog | grep SPF”) vemos que la acción es “bypass”:

spf5 Definición del registro SPF de gmail.com

La terminación del registro, como vemos, es “?all” lo que no deja claro que cualquier otra IP esté o no autorizada a usar el dominio gmail.com.

NOTA: Al menos a partir de Octubre de 2013, la definición de este registro cambió y ahora utiliza el mecanismo “~”. Para ver un ejemplo del mecanismo “?all” puede verificar el registro del dominio vatican.va.

Por otro lado, las acciones de IMSVA son configurables en el archivo /opt/trend/imss/postfix/etc/postfix/SPFPolicyd/config.ini. Las acciones que se pueden configurar son:

# Actions available:
#  block, return an 5XX error.
#  tempblock, return an 4XX error.
#  bypass, bypass the mail, no special action will be performed.
none=bypass
neutral=bypass
pass=bypass
fail=block
softfail=tempblock
temperror=bypass
permerror=bypass

Para mayor información sobre los resultados y acciones de la validación de los registros SPF puedes leer nuestro artículo Resultados de la validación de SPF.

Si por ejemplo, quisiéramos asegurarnos de que definiciones como la del dominio gmail.com también fallen cuando la IP no es ninguna de las listadas en su registro podemos cambiar la acción de neutral a block y con eso cualquier registro que termine como “?all” provocará un bloqueo cuando la IP no sea verificada satisfactoriamente. Si hacemos este cambio y reiniciamos postfix con un “postfix reload” veremos la diferencia en la acción de IMSVA.

spf6 Cambiando la acción de neutral para que bloquee permanentemente en IMSVA 8.2

Además de esto también podemos usar este archivo para modificar el mensaje que queremos mostrar al SMTP Client cuando se violan las políticas de SPF. Esta definición se encuentra también en el archivo config.ini y sus valores por defecto se muestran a continuación:

[globals]

# Temporary block response in SMTP session
tempblock_res=451 Service temporarily unavailable; SPF check failed and 
transaction closed due to the organization's policy.

# Block response in SMTP session
block_res=550 Service unavailable; SPF check failed and transaction closed 
due to the organization's policy.

En este mismo archivo podemos definir también una lista de dominios / IP’s a los que queremos aplicar un conjunto de acciones diferentes a todos los demás (enforcement list), una lista blanca de dominios / IP’s a los que no queremos aplicar la verificación de SPF y el nivel de debug que queremos se registre en el archivo maillog, su valor por defecto es “1”, pero se recomienda mantenerlo en “2” ya que este nivel no genera demasiada información pero sí graba la respuesta del registro SPF que determinará la acción a tomar.

Como recomendación, se puede habilitar SPF sin afectar el funcionamiento de IMSVA y del flujo del correo como se mostró en esta sección, pero no se recomienda alterar las acciones globales para los resultados de SPF. Se recomienda también cambiar la descripción de los errores de SPF a alguna que satisfaga las políticas de seguridad y privacidad de la organización. Si se conocen dominios de los que sea común recibir SPAM, es recomendable poner esos dominios en el “enforcement list” y cambiar las acciones a blocked en todas las respuestas excepto en la de pass. Esto asegura una mejor protección sin afectar el tráfico normal de otros dominios.

Tome en cuenta también que mucho del comportamiento que tendrá IMSVA con SPF habilitado dependerá de la propia definición SPF que tenga el dominio que se está evaluando por lo que estas respuestas no pueden considerarse como falla del producto. A pesar de que muchos dominios no cuentan con su registro TXT público para este tipo de validaciones, el mantener el filtro SPF activo puede ayudar a proteger al menos de dominios muy conocidos como gmail.com y redes sociales.

 

Este post es uno extracto de nuestra publicación Manual Avanzado de Configuración e Implementación de IMSVA que puedes consultar para mayor información sobre el funcionamiento y configuraciónd de las diferentes opciones de esta solución de Trend Micro. Si requieres mayor información sobre las reglas de creación y transmisión del correo electrónico te recomendamos nuestro libro Fundamentos de Correo Electrónico.

Recuerda que puedes enviarnos tus preguntas y comentarios a nuestra cuenta de Twitter: @redinskala donde encontrarás más información y tips de seguridad.

Gracias por tu visita!

One thought on “Habilitar y configurar SPF en IMSVA

  1. Pingback: Habilitar SPF en IMSVA | RedinSkala | Nichos Para Generar Dinero Con Adsense

Comments are closed.