Guía de medidas para la mitigación de correo no deseado o fraudulento en servicios de correo

Fecha liberación: 
05/02/2021
Riesgo: 
Medio

El correo spam representa una de las amenazas más constantes a los servicios de correo, busca la distribución de información falsa o malware, generalmente intentando realizar una suplantación de identidad de un servicio de correo electrónico válido.

Esto es posible, debido a la naturaleza del protocolo de correo que se describe en el IETF RFC 2822 (https://tools.ietf.org/html/rfc2822), el cual permite que un usuario pueda dar de alta un servicio de correo de salida con cualquier dominio, sin que este deba corresponderle en los registros MX (Mail Exchange) en servidores de nombres de dominio (DNS).

Una medida esencial para prevenir que este tipo de correo llegue a los usuarios, es la implementación de un filtrado antispam y antivirus en el servidor de correo local, el cual puede hacer identificación a partir de patrones conocidos, análisis heurísticos y listado de servidores en listas negras. Este filtrado puede hacerse por medio de un servicio externo en la nube, por un equipo dedicado al filtrado, o como una característica adicional dentro del servicio de correo electrónico local o incluso en los clientes de correo.

Además de ello, en el marco de políticas del remitente (SPF, Sender Policy Framework) es un estándar abierto que especifica un método técnico para prevenir la falsificación de la dirección de correo electrónico del remitente.

 ¿Qué es SPF?

Es un método de autenticación de correo electrónico que permite que su organización especifique los servidores de correo (nombres de dominio y direcciones IPv4 e IPv6 aprobados) que pueden enviar mensajes desde el dominio. Además, SPF ayuda a proteger el dominio frente a la suplantación (spoofing) y permite que los mensajes se entreguen correctamente.

SPF es un estándar definido en el RFC 7208 (https://tools.ietf.org/html/rfc7208) que, previendo que un usuario malicioso pueda dar de alta un equipo que envíe correo con un dominio que no le corresponde, permita identificar las direcciones de origen válidas para dicho dominio, de tal forma que los servidores a los que se envía el mensaje, puedan autenticar este origen, y de no corresponder, asumirlo como fraudulento.

Esta validación se hace por medio de un registro DNS tipo texto (TXT), en el que se enumeran los orígenes autorizados para el envío de correo electrónico de un dominio dado. En caso de no existir los servidores receptores de correo electrónico, asumirán como válido cualquier origen, lo que puede impactar en una suplantación de identidad del servidor correspondiente (el resultado de la verificación será none, de acuerdo con el RFC 7208).

¿Cómo se da de alta un registro SPF?

Para poder contar con un registro SPF, se debe dar de alta un registro DNS de tipo texto (TXT) que contenga la sintaxis valida con el nombre de dominio correspondiente.

Para ello, primero, se deben definir los orígenes que serán válidos para el envío de correo electrónico de un dominio (en este caso, se usará ejemplo.unam.mx). Éstos pueden ser direcciones IP (versión 4 o 6), segmentos de direcciones, nombres de dominio, entre otros.

A continuación, se debe especificar el contenido del registro SPF, el cual tiene el siguiente esquema:

v=spf1 origen1 origen2 … origenN [~all|-all]

Cuyos elementos son:

  • v=spf1:            Indica que el registro es tipo SPF versión 1. Este campo es igual en todos los registros de este tipo.
  • Origen#:          origen del que se asumirán como válidos los correos del dominio especificado, separados por un espacio en blanco, los cuales pueden ser:

    • Direcciones IPv4, con la sintaxis

      • ip4:<dirección-IPv4>
      • ip4:<red-IPv4>/<longitud-de-prefijo>
      • Ejemplos

        • Dirección IP: ip4:192.168.1.1
        • Segmentos de direcciones IPv4: ip4:192.168.1.1/24
        •  
    • Direcciones IPv6, con la sintaxis

      • ip6:<dirección-IPv6>
      • ip6:<red-IPv6>/<longitud-de-prefijo>
      • Ejemplos:

        • Dirección IPv6: ip6:201:::::0
        • Segmentos de direcciones IPv6: ip6:<201:::::0/64>
    • Nombres de dominio (registros A o CNAME), con la sintaxis

      • a
      • >a/<longitud-de-prefijo>
      • a:<dominio>
      • a:<dominio>/<longitud-de-prefijo>
      • Ejemplos:

        • a:ejemplo.unam.mx
        • a:ejemplo.unam.mx/24
    • Registros MX, con la sintaxis

      • mx
      • mx/<longitud-de-prefijo>
      • mx:<dominio>
      • mx:<dominio>/<longitud-de-prefijo>
      • Ejemplos:

        • mx
        • mx/24
        • mx:ejemplo.unam.mx
        • mx:ejemplo.unam.mx/24
    • Mecanismo exists, con la sintaxis

      • exists:<dominio>
      • Ejemplos:

        • exists:ejemplo.unam.mx
    • Mecanismo include, con la sintaxis

      • include:<dominio>
      • Ejemplos:

        • include:ejemplo.unam.mx
  • -~all|-all:           Indica si la verificación es débil (~all) o fuerte (-all). Se recomienda siempre forzar la validación del origen por medio de la opción -all.

Así, por ejemplo, si se deseara dar de alta un registro SPF para el dominio ejemplo.unam.mx con la dirección IPv4 1.2.3.4, su estructura sería la siguiente:

v=spf1 ip4:1.2.3.4 -all

Dado que se pueden incluir diversos orígenes, estos operadores pueden combinarse. Por ejemplo, si se deseara dar de alta un registro SPF para el dominio ejemplo.unam.mx con la dirección IPv4 1.2.3.4, el segmento IPv6 fd6d:17c2:9770:083b::/64, un host que responde al nombre de domino mail.externo.com y cualquier equipo que tenga un nombre de dominio en el espacio interno.org (*.interno.org), se tendría un registro con la siguiente estructura:

v=spf1 ip4:1.2.3.4 ip6:fd6d:17c2:9770:083b::/64 include:mail.externo.com a:*.interno.org

Si desea más información sobre las especificaciones de parámetros en concreto, se puede consultar la sección 5 del IETF RFC7208.

Finalmente, para poder implementarlo, se debe solicitar el alta del registro al administrador de la zona correspondiente al dominio del correo (en el caso anterior unam.mx), especificando que el contenido de este debe ser de tipo TXT. Con ello, tras un cierto periodo de tiempo (regularmente una hora o menos), los servidores de correo externos que tengan configurada la validación SPF, autenticarán sólo aquellos correos enviados desde los orígenes válidos del dominio configurado. Para poder verificar la existencia de un registro SPF en un dominio, se puede ejecutar el comando:

dig TXT nombre.de.dominio

¿Cómo hacer la verificación de origen por SPF en correo entrante?

Si bien, esta tarea depende en específico de cada servicio de correo (MTA, Mail Transport Agent), a continuación, se enumera la forma de habilitarlo en dos de los MTA más comunes:

Para Postfix en GNU/Linux:

1.    Instalar el SPF Policy Agent

·       Para sistemas basados en Debian

sudo apt install postfix-policyd-spf-python

·       Para sistemas basados en Red Hat:

sudo dnf install pypolicyd-spf

2.     Agregar un usuario para la revisión del origen de correo electrónico:

sudo adduser policyd-spf --user-group --no-create-home -s /bin/false

3.     Editar el archivo /etc/postfix/master.cf, y agregar una line que permita especificar que Postfix iniciará el demonio de SPF Policy Agent

policyd-spf  unix  -   n   n       -       0      spawn

   user=policyd-spf argv=/usr/libexec/postfix/policyd-spf

sudo dnf install pypolicyd-spf

4.     Editar el archivo /etc/postfix/main.cf y agregar las siguientes líneas en el área correspondiente:

policyd-spf_time_limit = 3600

smtpd_recipient_restrictions =

   permit_mynetworks,

   permit_sasl_authenticated,

   reject_unauth_destination,

   check_policy_service unix:private/policyd-spf

5.     Reiniciar el servicio de correo electrónico

sudo systemctl restart postfix

Para Exchange Server:

  1. Habilitar la opción antispam para los Mailbox servers.
  2. Habilitar la opción Sender ID agent

Referencias

La Coordinación de Seguridad de la Información/UNAM-CERT agradece el apoyo en la elaboración o traducción y revisión de este Documento a:

  • Manuel I. Quintero Martínez (manuel dot quintero at cert dot unam dot mx)
  • Sergio Anduin Tovar Balderas (anduin dot tovar at cert dot unam dot mx)

 

UNAM-CERT

Equipo de Respuesta a Incidentes UNAM
Coordinación de Seguridad de la Información

incidentes at cert.unam.mx
phishing at cert.unam.mx
https://www.cert.org.mx
https://www.cert.unam.mx
Tel: 56 22 81 69